Closed
Bug 73710
Opened 23 years ago
Closed 23 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•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Assignee | ||
Comment 2•23 years ago
|
||
cannot make it. move to moz0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Assignee | ||
Comment 3•23 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•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Assignee | ||
Comment 4•23 years ago
|
||
move back from nhotta to ftang and target moz0.9.1 This case both 78614 and 80865
Assignee | ||
Updated•23 years ago
|
Assignee | ||
Comment 5•23 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•23 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•23 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 9•23 years ago
|
||
I test all the case in 64235 with my fix. It break nothing. Here is the patch
Assignee | ||
Comment 10•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Whiteboard: patch need review
Assignee | ||
Comment 11•23 years ago
|
||
fixed and check in
Status: ASSIGNED → RESOLVED
Closed: 23 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
•