apache / apache/netbeans

FTP: non-ASCII filenames corrupted to "?" — client never negotiates UTF-8 (OPTS UTF8 ON)

Open
#9,570 1 comment 0 reactions 0 assignees View on GitHub
kind:bug needs:triage PHP
Dominant language
Java
Stars
3.1k
Forks
935
Avg merge
2d 3h
Merged PRs (30d)
17

Description

### Apache NetBeans version

Apache NetBeans 31

### What happened

When uploading files or folders whose names contain non-ASCII characters
(Cyrillic in my case) through a PHP project's "Remote Web Site (FTP, SFTP)"
run configuration, the names are corrupted before they reach the server.
Every non-ASCII character is replaced with a question mark.

The IDE's own FTP log shows the correct name in the outgoing command, while
the server echoes back question marks — one per character:

CWD производи
550 Can't change directory to ?????????: No such file or directory

The corruption therefore happens when the command is encoded for the control
channel, not when the name is read from disk. Names display correctly
everywhere inside the IDE.

The session contains no FEAT command and no OPTS UTF8 ON. The client never
negotiates UTF-8 (RFC 2640), so it falls back to a charset that cannot
represent these characters.

This is not only a display problem. The upload appears to succeed and no
error is shown in the IDE, but:

- MKD creates a directory literally named "?????????" on the server
- files are then uploaded into that directory under corrupted names
- the correctly named target directory is never found or used

The remote site is silently polluted with garbage directories and files
while the IDE reports success.

The server is Pure-FTPd, which supports UTF-8. WinSCP transfers the same
files to the same server with the names fully intact, so this is a
client-side issue.

### Language / Project Type / NetBeans Component

_No response_

### How to reproduce

Server requirement: any FTP server that supports UTF-8 (RFC 2640).
I used Pure-FTPd; the same behaviour should occur with vsftpd or ProFTPD
with UTF-8 enabled. Verifying with a second client (WinSCP, FileZilla with
"Force UTF-8") on the same server confirms the server side is fine.

1. Create a PHP project (File > New Project > PHP > PHP Application).
2. In Run Configuration, set "Run As" to "Remote Web Site (FTP, SFTP)".
3. Click Manage, add a new FTP connection with the server credentials,
and confirm Test Connection succeeds.
4. In the local project's source folder, create a directory whose name
contains non-ASCII characters, e.g. производи
5. Inside that directory, create a PHP file whose name also contains
non-ASCII characters, e.g. весетео-офис-додатак.php
6. In the Projects window, right-click that single file and choose
"Upload..." from the context menu.
7. Open the Output window and select the tab named after the FTP
connection to see the protocol log.
8. Inspect the server contents with another FTP client or via the
hosting file manager.

Result:
- The log shows 550 responses where the server echoes ????????? back
- MKD creates a directory named "?????????"
- The file is stored inside it with its own non-ASCII characters replaced
by question marks
- The IDE reports the upload as successful, with no warning or error

Expected:
- The directory and file appear on the server with their original names

Note that the IDE itself runs under UTF-8 (see System line above), and
Cyrillic names display correctly throughout the IDE. The Windows system
ACP is 1252, but that is not the cause: the filename is intact in the
IDE's own outgoing log line and is corrupted only when encoded for the
FTP control channel. Apache Commons Net defaults to ISO-8859-1 there
regardless of platform locale, so this should reproduce on any system.

### Did this work correctly in an earlier version?

No / Don't know

### Operating System

Microsoft Windows 11 Pro 10.0.26200 (build 26200) 64-bit

### JDK

26.0.2+10

### Apache NetBeans packaging

Community provided installer

### Anything else

_No response_

### Are you willing to submit a pull request?

No

Contributor guide

Open the contributing guide

Research direction

Trace the FTP upload path used by the PHP project's Remote Web Site configuration, starting with the FTP control-channel handling described in the report. Verify the protocol log and server result, then confirm that UTF-8 negotiation preserves non-ASCII directory and file names without reporting a false success.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.