Closed Bug 65991 Opened 24 years ago Closed 4 years ago

conversion problem (fromU)- ISO-2022-JP/EUC-JP encoder cannot map \u301C

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: nhottanscp, Assigned: nhottanscp)

References

Details

(Keywords: helpwanted, intl)

ISO-2022-JP encoder returns NS_ERROR_UENC_NOMAPPING for \u301C. In HTML Editor, set charset to ISO-2022-JP and input the character then save. The character is saved as NCR #12316; instead of JIS 0x2141. Macitoch: Japanese IME, in Japanese mode, type tilda. Windows: Use "Character Map" accessory.
Keywords: intl
accept. Mark it as moz0.9
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
The same problem in EUC-JP encoder, \u301C cannot be converted and saved as NCR 〜
Summary: ISO-2022-JP encoder cannot map \u301C → ISO-2022-JP/EUC-JP encoder cannot map \u301C
Summary: ISO-2022-JP/EUC-JP encoder cannot map \u301C → conversion problem- ISO-2022-JP/EUC-JP encoder cannot map \u301C
Summary: conversion problem- ISO-2022-JP/EUC-JP encoder cannot map \u301C → conversion problem (fromU)- ISO-2022-JP/EUC-JP encoder cannot map \u301C
Changed QA contact to ylong@netscape.com.
QA Contact: teruko → ylong
jis0208.ump seems to be made by CP932.TXT. In CP932.TXT, JIS 0x2141 mapped to \uFF5E. Other characters(JIS 0x2140,2141,2142,215D,2171,2172) have the same problem. (see http://www.autumn.org/etc/unidif.html) I think,,, 1. Native widgets get chars in native encoding. 2. Convert the native encoded text to UCS-2 (with OS's or Moz's converter?) 3. If a mapping table of the converter converts JIS 0x2141 to \u301C, mozilla converter will fail. (*)OS/2 and MacOS native converter maps SJIS 0x8160 (JIS 0x2141) to \u301C
cannot make it for moz0.9. push to moz 0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
nhotta- I am overload- can you help this one ?
Assignee: ftang → nhotta
Status: ASSIGNED → NEW
*** Bug 60400 has been marked as a duplicate of this bug. ***
moved nsbeta1 from the duplicated bug
Keywords: nsbeta1
> 1. Native widgets get chars in native encoding. yes > 2. Convert the native encoded text to UCS-2 (with OS's or Moz's converter?) OS converter is used > 3. If a mapping table of the converter converts JIS 0x2141 to \u301C, > mozilla converter will fail. Not sure but this bug is about converting from \u301C to a document charset. The problem can be reproduced without the user input, like a file below. Save as ISO-2022-JP or EUC-JP generate the NCR. <HTML> <BODY> &#x301C; </BODY> </HTML>
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla0.9.2
changing keyword to nsbeta1-.
Keywords: nsbeta1 → nsbeta1-
not critical. move to moz0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → ---
not that critical. move to m9.5
Target Milestone: --- → mozilla0.9.5
move to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
This is a mapping problem as bug 54135, reassign to ftang.
Assignee: nhotta → ftang
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.6 → mozilla0.9.7
reassign to nhotta- sorry, I really not sure what else should I do for this bug.
Assignee: ftang → nhotta
add 'helpwanted' keyword
Keywords: helpwanted
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → ---
Target Milestone: --- → mozilla1.2
Status: NEW → ASSIGNED
Target Milestone: mozilla1.2alpha → ---
I think this bug has resolved by Bug 108136 fix.
QA Contact: amyy → i18n
Even though this bug hasn't been marked fixed, it was actually fixed. However, encoding_rs regresses this due to the Encoding Standard not having this special case. annevk, should the Encoding Standard have this special case? Filed https://github.com/whatwg/encoding/issues/114
See Also: → https://github.com/whatwg/encoding/issues/114

WONTFIXing per spec issue.

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.