#4261 closed Bug report (rejected)
Character encoding bug
| Reported by: | D-4 | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | FileZilla Client |
| Keywords: | japanese, SJIS, encoding | Cc: | |
| Component version: | Operating system type: | Linux | |
| Operating system version: | Mandriva 2007 Spring |
Description
Create a folder named "パーソナル" (without the quotes) on a server using the SJIS character encoding (japanese). (Mostly Microsoft Windows Japanese-hosted)
In the remote directory tab, it will display correctly. However, in the remote tree list and in the log, it displays as "p[/i" (without the quotes). It is possible to enter into that directory, but any operation done within it produce a bug - creating something in it creates it in the parent directory, it's impossible to download files that were put in there by another user, etc.
Change History (4)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
| Priority: | high → normal |
|---|---|
| Resolution: | → rejected |
| Status: | new → closed |
a server using the SJIS character encoding
Such a server is in blatant violation to the FTP specifications. Read http://wiki.filezilla-project.org/Character_Set
comment:3 by , 15 years ago
| Resolution: | rejected |
|---|---|
| Status: | closed → reopened |
I meant that the remote file system is SJIS. If that is still in violation with the FTP specifications, why was mostly complete support implemented at the first place?
comment:4 by , 15 years ago
| Resolution: | → rejected |
|---|---|
| Status: | reopened → closed |
Then your server has to convert it into UTF-8 or alternatively transliterate it into ASCII.
What FileZilla does on broken servers is guesswork if it encounters non-UTF-8 data. Some random sequence of bytes could be in absolutely any encoding.
The same name as a file seems to cause no problem, only a folder does.