User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 (Beta/Release) Build ID: 20130201190337 Steps to reproduce: Go to: ftp://ftp.picosystems.net Change to pub directory. Actual results: File:Signetics_Linear_Data_Manual_Vol3_Video_1987.pdf 73675 KB 07/21/2013 04:20:00 AM File:YHP_OptDevice_1989_90.pdf 55592 KB 01/23/2012 12:00:00 AM File:Yamaha_LSI_ç?»å??ç·¨_1994.pdf 18110 KB 01/23/2012 12:00:00 AM File:ã??ã?§ã?©ã?³ã??ã?£_ã??ã?¼ã?¿ã?³ã?³ã??ã?¼ã?¿_1988.pdf 27628 KB 03/23/2012 12:00:00 AM File:ä¸?æ´?å??å°?ä½?_ã?«ã?¼ã?ªã?¼ã??ã?£ã?ªç?¨é??ç©?å??路編_1991_92.pdf 108295 KB 03/18/2012 12:00:00 AM File:ä¸?æ´?å??å°?ä½?_表é?¢å®?è£?ç?¨ã??ã?©ã?³ã?¸ã?¹ã?¿ç·¨_1990.pdf 112157 KB 03/18/2012 12:00:00 AM File:ä¸?è?±å??å°?ä½?_ã??ã?¤ã??ã?¼ã?©ã??ã?£ã?¸ã?¿ã?«ï¼©ï¼£ç·¨_1979.pdf 65176 KB 03/17/2012 12:00:00 AM File:ä¸?è?±å??å°?ä½?_ã??ã?¤ã?¯ã?­ã?³ã?³ã??ã?¥ã?¼ã??​¢é?£ï¼¬ï¼³ï¼©ç·¨_1979.pdf 58195 KB 03/17/2012 12:00:00 AM File:ä¸?è?±å??å°?ä½?_ã?ªã??ã?¢ï¼©ï¼£ç·¨_1981.pdf 86867 KB 03/17/2012 12:00:00 AM File:太é?½èª?é?»_TAIYOYUDEN_PRODUCTS_1999.pdf 64061 KB 03/23/2012 12:00:00 AM File:æ?¥ç«?_HITACHI_Power&Industrial_Semiconductor_1978_79.pdf 69317 KB 03/19/2012 12:00:00 AM File:æ?¥ç«?_å°?ä¿¡å?·ã??ã?©ã?³ã?¸ã?¹ã?¿_1990.pdf 79323 KB 03/19/2012 12:00:00 AM File:æ?¥ç«?_ＩＣã?¡ã?¢ã?ª_1982.pdf 38137 KB 03/19/2012 12:00:00 AM File:æ?¥ç«?_ＩＣã?¡ã?¢ã?ª_1983.pdf 42269 KB 03/19/2012 12:00:00 AM Expected results: The characters displayed are japanease. mget NationalSemiconductor_PLD_1993.pdf? n mget PMI_リニアＩＣ_1988_89.pdf? n mget Philips_SurfaceMount_SC10a_1991.pdf? n mget Philips_SurfaceMount_SC10b_1991.pdf? n mget RCA_LinearIC_1984.pdf? n mget RCA_QMOS_1984.pdf? n mget Raytheon_Linear_1976.pdf? n mget Signetics_Linear_Data_Manual_Vol1_Communications_1987.pdf? n mget Signetics_Linear_Data_Manual_Vol2_Industrial_1987.pdf? n mget Signetics_Linear_Data_Manual_Vol3_Video_1987.pdf? n mget YHP_OptDevice_1989_90.pdf? n mget Yamaha_LSI_画像編_1994.pdf? n mget フェランティ_データコンバータ_1988.pdf? ^C Continue with mget? y mget 三洋半導体_カーオーディオ用集積回路編_1991_92.pdf? n mget 三洋半導体_表面実装用トランジスタ編_1990.pdf? n mget 三菱半導体_バイポーラディジタルＩＣ編_1979.pdf? n mget 三菱半導体_マイクロコンピュータ関連ＬＳＩ編_1979.pdf? n mget 三菱半導体_リニアＩＣ編_1981.pdf? ^C Thee above is subset shown using Ubuntu Linux ftp. The Japanease characters can be fed successfullly to Google Translate. 1. They are not displayed as such. 2. The real annoying problem is that you cannot right click and save as. "not saved because source cannot be read" The English name work fine.

Same issue with IE11, are you sure it's not an issue with the FTP?

NB: and remember Firefox 18 is EOLed, the last version is Firefox 25.

Well at this point, there is probably a probelem with both. A friend in Austrailia was able to transfer the files using another FTP client under Windows (probably windows 2000). I don;t know how they displayed. In Ubuntu 12.04 lInux, the Japanease characters display as garbage using the FTP ls command. They display as Japanease characters when using mget *.pdf (where yu have to answer y or n to transfer the file. so mget *1988* or mget *.pdf would help me be able to transfer the file. The transferred file retains the correct Japanease names when transferred to Ubuntu. The bugs then are: 1. Ubuntu 12.04 "ftp" command: ls displays garbage for Japanease characters in the filename. mget displays the filenames correctly. Files transfer with the correct Japanease names. 2. Firefox 18 shows the ftp directory incorrectly when Japanease filenames are present using "ls". 3. Save target as doesn't work. e.g. Try to save a Japanease file as "something.pdf" or as the original name works for English filenames, but not filenames containing Japanease characters. Asides: Ubuntu can, apparently display Japanease Characters. I don't know what is requred to input them. I'm mostly concerned that "Save Target as" didn't work in Firefox. FF 18 vs FF 22 Noted. Firefox 18: I have been running since June 2013 off of the Ubuntu live CD which is bundled with Firefox 18 after a hard drive crash with Windows.

I tried in command line with cmd.exe, the FTP requests a login and a password. Are they public? If yes, could you paste them, please.

With Nightly (v28) on OS X, I see the correct filenames in the FTP directory listing, but *only* if I manually choose "Japanese (Shift_JIS)" from the Character Encoding menu. So apparently the FTP server is using Shift-JIS in the directory listing. IMO, it would be better (more widely interoperable) if it were configured to use Unicode (UTF-8). Note that in Firefox 25, the filenames look wrong even when Shift_JIS is chosen. I'm not sure what's been changed in Nightly to fix this; something about Japanese encoding converters or the HTML parser, maybe.

loic: It's anonymous FTP so USER:anonymous Password: is customarily your email address

According to the Page Info, the generated FTP page's content-type is "text/html; charset=windows-1252". Looks like this is the cause of mismatching encoding. I'm not sure if this is our internal bug, though. Using View Source, the file names are listed in UTF-8 without any broken characters. I guess in network level, our module handles the file names correctly.

Does it? If it handled it at the network level, would you assume that save as would work?

Recently I encountered this bug when I accessed a Russian ftp server using Firefox 25.0.1 on Windows.

The FTP dir listing stream converter belongs to the network layer.

This server support FEAT/UTF8. dup of bug 26767.

Non-ASCII filenames should be accessible even if the server doesn't support FEAT/UTF8. We should escape non-ASCII characters in the URL if the byte sequence is invalid as UTF-8. The mojibake would be acceptable unless the server supports FEAT/UTF8, so concentrating this bug on the [Save As] issue.

(In reply to Masatoshi Kimura [:emk] from comment #12) > Non-ASCII filenames should be accessible even if the server doesn't support > FEAT/UTF8. > We should escape non-ASCII characters in the URL if the byte sequence is > invalid as UTF-8. > The mojibake would be acceptable unless the server supports FEAT/UTF8, so > concentrating this bug on the [Save As] issue. non, non. no wayt to detect charset perfectly for FTP LIST command. Most modern FTP server supports FEAT/UTF8, so we should use it to avoid character corruption.

emk-san, if server doesn't support FEAT/UTF8, I make sense you say. But this server supports it.

In my case, while the server had "UTF8" in the "FEAT" response, it didn't return UTF-8 filenames until I send "OPTS UTF8 ON". Unfortunately FEAT/UTF8 is not so reliable. In any case, non-ASCII filenames should be accessible even if the client doesn't comply with RFC 2640. At least IE11 did not have this issue despite that it didn't implement RFC 2640. I'll file a new bug for clarification.