- reproduce step 1. make a directry and html file to c:\ソソ\a.html 2. select this file via [File] - [Open File...] - result URL bar is file:///C|/%83/%83//a.html. This should view "file:///C|/%83%5C%83%5C/a.html" [ソ] is [0x83], [0x5c] at ShiftJIS. And 0x5c is second byte of ShiftJIS (not file separator). I think that this problem is occured since nsFilePath and nsSimpleCharString don't use unicode(PRUnichar).

Frank can you help us with this.

Hum.... this is a tough one. I am not sure which way is BETTER or correct than the other. I try to copy adn paste file:///C|/%83/%83//a.html into 4.x and 4.x can still visit that page. Not that sure we should fix it. bobj- any opinion ?

0x5C should not be interpreted as a path separator when it is the 2nd byte of a legitimate SJIS character. But in this example, this is not the case. What happens when we have a pathname with legitimate 2-byte SJIS characters which contain 0x5C as the 2nd byte? Does that work? If so, then I don't think there is a problem with the described behavior.

Teruko, Will you please have someone verify this bug? Please test with sequences of valid SJIS kanji and kana. See my last comment/question. (Changed QA assigned to Teruko and moved dp to cc list.)

Ignore my last 2 comments (12/20 and 12/31). I misread the previous comments. This is a good bug. We should see the file name in Japanese in the URL bar after selecting it via the file picker. We probably need to determine the file system character encoding via the OS localization (ACP on Win, System Script on Mac, user locale on Unix?) and then convert to Unicode for DISPLAY in the URL bar. The actual URL should probably remain as-is: %-encoded using the numeric values based upon the file system character encoding. Will someone please confirm that the %-encoded URL currently being displayed will actually open the correct file?

It does open a local file even when the path name contains 5C as part of a JPN named directory.

The display in the Location field should be in Japanese if viewed under Japanese Windows -- maing assumption about the file-system charset. The otehr problem is that of display of actual URL. Currently, %83%5C is displayed/recorded as "%83/" meaning we are showing all ASCII range codepoint using the real ASCII characters rather than the escaped equivalent. I think we should esacpe these as m_kato suggests.

Reassigned to erik for M14

At first, we should fix BUG 5887 ?

I don't think Filesystem in the sidebar is currently a supported feature. So at present there will be nothing to fix in Bug 5887.

Change Platform ans OS to ALL

Probebly, OS is Windows 9x / NT / 2K only. File separater is '\' and it uses SJIS encoding. A easy huck uses IsDBCSLeadByte in nsFilePath. But I don't think that this huck is correct. True implementation should use Unicode in nsFilePath and nsSimpleCharString. VFAT and NTFS have the unicode filename. So I don't know whether 0x83 is lead charactor of DBCS.

Putting on PDT- radar for beta1. Would not hold beta, but erik, please get with rickg to get rid simple char string, replace with ns string.

I agree with m_kato that 5887 should be fix first.

probably a dup of 28171

Non, this problem is nsFileSpec. See prev comment.

Frank, was this bug addressed by your recent URL work?

This is fixed by 28171 and 6770 *** This bug has been marked as a duplicate of 6770 ***

Please retest now that bug 28171 and bug 6770 have been fixed.

It isn't fixed!!! this issue isn't bug 6770 and bug 28171. This problem is nsFileSpecHelpers::NativeToUnix - env. o Mozilla M15 2000031306 o Windows NT WKS 4.0 SP6a JPN - repro step 1. create C:\テスト\ソソ.htm 2. open this file via [File] - [Open File...] - result o URL bar is file:///C|/%83e%83X%83g/%83/%83/.htm o Cannot open this file.

m_kato, do you know how to fix it ? Can you point me the problematic code. (file/line/function) thanks.

Fix code already exists! http://bugzilla.mozilla.org/showattachment.cgi?attach_id=5509

It is worst now. The file:/// is complete broken in M15 for non ASCII . I will only get file:///c|/ if the directory name is in non ASCII. I think this is related to the recent change of nsIFile

mark it M16

all the nsIFile and nsIFileSpec related issue should be look together.

Frank, don't waste any time on nsIFileSpec or nsFileSpec. This interface and class have been deprecated. nsIFile and nsILocalFile is the one true way.

I think this bug have already been fix because 1. other change code from using nsFileSpec to nsILocalFile 2. we check in fix inside nsStdURL The Composer is now still using the nsFileSpec, but I neither can reproduce the problem because the Unicode Path I got is %hh encoded alread. Mark this bug fixed.

fix and check in.

I verified this in 2000042709 Win32 and Linux, and 2000042710 Mac builds.