Can't save page as file with chinese filename

RESOLVED FIXED

Status

()

Core
Internationalization
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: Che-Ching Wu, Assigned: mkaply)

Tracking

Trunk
x86
OS/2
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

14 years ago
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

Updated

14 years ago
Assignee: file-handling → smontagu
Component: File Handling → Internationalization
QA Contact: ian → amyy
(Assignee)

Comment 1

14 years ago
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.
Assignee: smontagu → mkaply
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

14 years ago
Created attachment 144753 [details] [diff] [review]
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.

Updated

14 years ago
Attachment #144753 - Flags: review+

Comment 3

14 years ago
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
(Assignee)

Comment 4

14 years ago
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.
(Assignee)

Comment 5

14 years ago
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 6

14 years ago
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...
The patch is not quite right.  The length of the resulting string is too long.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 144797 [details] [diff] [review]
fix v2

The inputLen should not be set to length*2+1.  We were converting twice as much
data.
Attachment #144753 - Attachment is obsolete: true
Created attachment 144801 [details] [diff] [review]
fix v2.1

Oops, removed too many comments.  Also, we don't need to worry about the
terminating null.
Attachment #144797 - Attachment is obsolete: true

Updated

14 years ago
Attachment #144801 - Flags: review?(mkaply)

Comment 10

14 years ago
(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.


(Assignee)

Comment 11

14 years ago
The new patch has been checked in to trunk and 1.4
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → FIXED
(Assignee)

Updated

14 years ago
Attachment #144801 - Flags: review?(mkaply)
You need to log in before you can comment on or make changes to this bug.