Open Bug 65991 Opened 20 years ago Updated 4 years ago

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

Categories

(Core :: Internationalization, defect)

defect
Not set
normal

Tracking

()

ASSIGNED

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: nsbeta1nsbeta1-
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
Depends on: encoding_rs
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
You need to log in before you can comment on or make changes to this bug.