Guenter Knauf wrote: > Bill, > William A. Rowe, Jr. schrieb: >> To confirm; if UTF8 characters are *invalid* and won't be accepted for >> path names, this feature should be set. If the server *can* name files >> in UTF8 this is the correct feature, even if the file names would appear >> 'odd' to the local user. This is why the feature is correct for Unix. > hmm, then I probably add the directive but comment it out, and explain > with a note; > I've just tested and transfered from Linux a file with UTF-8 German > Umlaute äöüß, and it was stored on the server, then retrieved same file > from Win32, and that worked; however when I access the filesystem with > the client then the filename is garbage, but still accessable. If I > store a file with German Umlaute with the client then FileZilla is noz > happy with it, and reports: > Status: Invalid character sequence received, disabling UTF-8. Select > UTF-8 option in site manager to force UTF-8.
Read the specs carefully. This is allowed. It is not necessary to "disable UTF8" or stop using it, but simply treat a specific filename as an exception. Unix suffers this already, when several users of the same directories each use different local codepages. Windows is immune because all charsets ultimately are folded back into a unicode filesystem, but unix has no such concept. OS/X comes close. > So if the user wants to serve files which were created via client then > its required to disable the UTF8 feature I think ... > Probably we can add a new directive for the future which can specify > conversion like mod_char_lite; something like: > FTPCharsetSourceEnc > I think from this other systems can also profit, or? Absolutely not. Characters from 0x80 - 0xFF have absolutely no definition within FTP, they mean nothing. There is not so much as a mention of naming files with ISO-8859-1 or similar, it's an ASCII protocol. If you were to fix the netware case, the fix would be in APR; to treat all file naming with consistency and use UTF-8. But this is probably much more trouble than it's worth. Keep in mind some FTP clients don't even look to FEAT UTF8 to understand what filenames they are seeing, and presume their local native codepage. With no mechanism to determine the server and client side naming convention (other than FEAT UTF8) such filenames have always enjoyed inconsistency.
