Closed
Bug 73710
Opened 24 years ago
Closed 24 years ago
nsUnicodeDecodeHelper to support overwrapping ranges
Categories
(Core :: Internationalization, defect)
Core
Internationalization
Tracking
()
RESOLVED
FIXED
mozilla0.9.1
People
(Reporter: nhottanscp, Assigned: ftang)
References
Details
(Keywords: intl, Whiteboard: patch need review)
Attachments
(1 file)
3.58 KB,
patch
|
Details | Diff | Splinter Review |
Currently, overwrapping first byte range as below (0xC6 and 0xF9) is not supported.
60 static uRange g_BIG5HKSCSRanges[] = {
61 { 0x00, 0x7E },
62 { 0x81, 0xA0 },
63 { 0xA1, 0xC6 },
64 { 0xC6, 0xC8 },
65 { 0xC9, 0xF9 },
66 { 0xF9, 0xFE }
67 };
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Assignee | ||
Comment 2•24 years ago
|
||
cannot make it. move to moz0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Assignee | ||
Comment 3•24 years ago
|
||
the problem is in
144 NS_IMETHODIMP nsUnicodeDecodeHelper::ConvertByMultiTable(
The current logic find a matching range
165 for (i=0; i<aTableCount; i++)
166 if ((aRangeArray[i].min <= *src) && (*src <= aRangeArray[i].max))
break;
167
and then process line 168-197. If it faild , it won't try the next range. We need
to change the logic so it will try next range if either uScan reutrn false or
uMapCode return false.
nhotta- I am overload. Can you help ?
We need this to fix the remaining HKSCS problems.
Assignee: ftang → nhotta
Status: ASSIGNED → NEW
Reporter | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Assignee | ||
Comment 4•24 years ago
|
||
move back from nhotta to ftang and target moz0.9.1
This case both 78614 and 80865
Assignee | ||
Updated•24 years ago
|
Assignee | ||
Comment 5•24 years ago
|
||
Change this routine should impact the following conversion
EUCKR to Unicode
Big5 to Unicode
BIG5HKSCS to Unicode
EUCTW to Unicode
I may need to undo the part shanjian and
jshin@pantheon.yale.edu fixed in r1.12 of nsUnicodeDecodeHelper for bug 64235
and 25037. The fix there seems won't work for some cases.
jshin@pantheon.yale.edu- the part of code should not impact ucvcn nor ucvja, but
it should impact ucvko ucvtw and ucvtw2. Do you have good test cases for EUCKR
that I can try after I undo that fix?
Comment 6•24 years ago
|
||
I listed several test cases in comments for bug 64235 and 25037.
( NYTimes, French/German Yahoo, Dell web page, etc). Bug 64235/25037
are about *protecting* mozilla against malformed pages as you may
know.
BTW, it seems like this patch for overlapping range will make it much
easier to implement other encodings to Unicode converters.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 9•24 years ago
|
||
I test all the case in 64235 with my fix. It break nothing. Here is the patch
Assignee | ||
Comment 10•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Whiteboard: patch need review
Assignee | ||
Comment 11•24 years ago
|
||
fixed and check in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 12•23 years ago
|
||
Ervin, can you check the original problem 80865 is fixed on nightly?
Comment 13•23 years ago
|
||
Verified in nightly 2001051622, bug 80865 is fixed.
You need to log in
before you can comment on or make changes to this bug.
Description
•