135854 - Japanese in escaped characters in File | Save as dialog

Status: RESOLVED WORKSFORME

(Core :: Internationalization, defect, P3)

Description

[Yuying Long]

Build: 04-04 trunk build on all platforms.

Steps:
1. Launch Netscape and open Composer.
2. Open a Japanese named file.
3. Regardless modify the file or not, and go to File | Save As.

Result:
There will be a save file dialog show up, and the existing Japanese name is
displayed as escaped character, e.g. %93%FA%96%7B%8C%EA.html.

This is a regression from N6.2.1, Japanese file name display fine on N6.2.2.

I also saw it on 03-06 trunk build, so it has been there for a while.

Comment 1

[nhottanscp]

This is not i18n specific and same for browser saveAs.
E.g. "test file.html" turns to "test%20file.html".

Comment 2

[Yuying Long]

Hmm, then it's mostly a dup. of bug 130079.

Comment 3

[Shanjian Li]

Yuying, since 130079 has been checked in, could you verify if this is a dup of
130079?

Comment 4

[Yuying Long]

No, it still showing as escaped characters on 04-15 branch build / Mac 10.1.3
and 04-12 trunk build / WinME-JA. (bug 130079 was checked in both trunk and
branch build).

And the space still display as "%20" in this dialog.

Comment 5

[Shanjian Li]

reassign to darin.
This is a regression directly caused by bug 124042. 
The URL for local file is stored in system charset, instead of UTF8. There are 2
options to fix this problem:
option A, convert file path from system charset to utf8 and store the utf8
string in url. Converting back to system charset before displaying. (We may
display ucs2 string directly in title in future.)
option B, (hack) If it is file scheme, we assume it is system charset instead of
utf8. 

Comment 6

[Darin Fisher]

how critical is this bug?  should this be nsbeta1?

Comment 7

[Kasumi]

No matter with critical or not.
It is regression.

Comment 8

[nhottanscp]

Yuying, could you attach a screen shot?
I think this does not look good but the file is usually saved as a different
name, also it is possible to restore the original name by selecting the original
file in the save as dialog list. So my opinion is that this is not nsbeta1+.

Comment 9

[Yuying Long]

Attachment: a screen shot for save as dialog

Notice the original name in Japanese, and the one inside save as dialog is
escaped.

Yes, this problem happens when "Save As" or "Save charset As(Composer)" but not
"Save".  The data can be saved properly but the name looks ugly.

Comment 10

[nhottanscp]

The escaped string in the screen shot, it is Shift_JIS which is a system charset
for Japanese Windows. I think simply unescaping it would solve the display problem.
Shanjian, why do you think this is related to UTF-8 URI?

Comment 11

[Darin Fisher]

nhotta: one of the changes that went in w/ support for UTF-8 URI was the switch
to make GetFileBaseName not unescape the result before returning it.  this was
done because the result from GetFileBaseName has to be UTF-8.  as a result, the
caller must unescape the string if that is what is appropriate.  i tried to
fixup all of the callers, but i obviously missed this one.  if the caller is JS
code, then we have a problem because i don't believe that there is any
scriptable method to unescape an URL-escaped string... or is there?!

Comment 12

[nhottanscp]

>this was done because the result from GetFileBaseName has to be UTF-8
but looking at the screen shot, it is not UTF-8

>i don't believe that there is any scriptable method to unescape an URL-escaped 
>string... or is there?!
unescape() uses UTF-8 as a default (and use a document charset if available)
http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#3188

So when the URI is escaped in not UTF-8 (but Shift_JIS) then calling unescape()
would be a problem.

Comment 13

[Shanjian Li]

Darin, in the other bug I assigned to you today, that one is in filepicker. I am
not sure about this one. In that bug, window title takes system charset only. So
we need to converted back from utf8. (In future, we should try to display
unicode string directly.)

Comment 14

[Darin Fisher]

nhotta: my point was that an URL escaped string is ASCII compatible and can
therefore be treated as UTF-8 _unless_ you unescape it.  so, the fact is..
GetFileBaseName returns bytes that can be interpreted as UTF-8.  however, once
unescaped.. there is no guarantee that the text will be UTF-8 or native-charset
encoded.

Comment 15

[nhottanscp]

If 'originCharset' is set then unescaped string can be converted to Unicode
using that value. How about adding a function to nsIURI which unescape and
convert to Unicode using originCharset? I think that would be useful to display
URI to UI.

Comment 16

[Darin Fisher]

nhotta: given that nsIURI exposes the originCharset attribute, i think it'd be
sufficient to write up a helper function (maybe on nsIIOService) that does this
conversion.  that way the many nsIURI implementations don't have to duplicate
that functionality.

Comment 17

[Darin Fisher]

mass futuring of untargeted bugs

Comment 18

[Kasumi]

*** Bug 154469 has been marked as a duplicate of this bug. ***

Comment 19

[Carine Held]

Still a problem in 11-07-08 build.

Comment 20

[Simon Montagu :smontagu]

WORKSFORME on all platforms