238445 - Can't save page as file with chinese filename

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[Che-Ching Wu]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7a) Gecko/20040225
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7a) Gecko/20040225

Can't save page as file with chinese filename

Reproducible: Always
Steps to Reproduce:
1.Open one page
2.Click File->Save Page As
3.Add any Chinese character to filename
4.Click Save
5.The dialog was closed and nothing happened

Comment 1

[Mike Kaply [:mkaply]]

I have no idea how this one has existed so long.

Problem is here:

http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsNativeCharsetUtils.cpp#1019

resultLen must be more than inputLen, since inputLen is number of unicode chars
and we could have more native chars than we had unicode.

Working on a solution.

Comment 2

[Mike Kaply [:mkaply]]

Attachment: Fix for problem

Buffer for conversion needs to be twice as many chars as the unicode string
since one unicode char can become two platform bytes.

Comment 3

[Roland Mainz]

Comment on attachment 144753 [details] [diff] [review]
Fix for problem

> +    size_t inputLen = (flat.Length()*2) + 1; // include null char

Please make that
+    size_t inputLen = (flat.Length()*sizeof(PRUnichar)) + 1; // include null
char

Comment 4

[Mike Kaply [:mkaply]]

I didn't mean sizeof(PRUnichar), I meant two.

The issue here is converting from Unicode to a native charset. the sizeof
PRUnichar is irrelvant.

When x number of unicode characters is converted to a native character set (not
UTF-8 or GB18030), the maximum number of chars that can result is x*2.

It has nothing to do with the size of a PRUnichar.

Comment 5

[Mike Kaply [:mkaply]]

Fix checked in.

Comment 6

[Roland Mainz]

Michael Kaply wrote:
> When x number of unicode characters is converted to a native character set 
> (not UTF-8 or GB18030), the maximum number of chars that can result is x*2.
> It has nothing to do with the size of a PRUnichar.

Ouch... you're right... I didn't saw that from the patch, only from looking at
the original source...

Comment 7

[jhp (no longer active)]

The patch is not quite right.  The length of the resulting string is too long.

Comment 8

[jhp (no longer active)]

Attachment: fix v2

The inputLen should not be set to length*2+1.  We were converting twice as much
data.

Comment 9

[jhp (no longer active)]

Attachment: fix v2.1

Oops, removed too many comments.  Also, we don't need to worry about the
terminating null.

Comment 10

[Jungshik Shin]

(In reply to comment #4)

> When x number of unicode characters is converted to a native character set (not
> UTF-8 or GB18030), the maximum number of chars that can result is x*2.

  It's probably true on OS/2, but it's not always the case in general. In
addition to GB18030,  EUC-JP, EUC-KR and EUC-TW need more than two bytes for
some Unicode characters.

Comment 11

[Mike Kaply [:mkaply]]

The new patch has been checked in to trunk and 1.4