文字コード掲示板

Re: Unicode => eucJP-ms の対応について

成瀬さん、こんにちは。

返事が遅くなり申し訳ありません。

1. U+0080 - U+009F (eucJP-ms の C1集合)

本当は、C1集合も変換するのが望ましいのかもしれません。

ただ、vim6 の filencodings 指定のように、列挙されている文字コードでファイルが開けるか否かで、文字コードの自動判定のような事を行う場合は、EUC の C1集合は変換されない方が都合が良い場合もありそうです。

2. U+00A5 および U+203E

2.1 セキュリティ上の懸念

JIS X 0201 ラテン文字の 0x5C を U+00A5 YEN SIGN, 0x7E を U+203E OVERLINE に対応付けすると必然的にU+0080以降にある文字が、ASCIIの範囲に変換されてしまいます。

2.2 意味上の対応関係 (JIS X 0201 ラテン文字と US-ASCII)

glibc の iconv(3) では、

sjis
\ (0x5C)⇔YEN SIGN (U+00A5)
~ (0x7E)⇔OVERLINE (U+203E)

euc-jp
\ (0x5C)⇔REVERSE SOLIDUS (U+005C)
~ (0x7E)⇔TILDE (U+007E)

としている事から、sjis⇔euc-jp の相互変換を実現するために、次のような変換を追加してあります。

sjis
\ (0x5C)←REVERSE SOLIDUS (U+005C)
~ (0x7E)←TILDE (U+007E)

euc-jp
\ (0x5C)←YEN SIGN (U+00A5)
~ (0x7E)←OVERLINE (U+203E)

eucJP-ms は、これと同じ変換を取り入れてあります。

libiconvパッチや glibc 2.3.3 以降の cp932,eucJP-ms では、Unicode からの変換で U+00A5 YEN SIGN や　U+301C WAVE DASH を受け付けるような多対1 の変換を行っていますが、成瀬さんのような疑問が生じるのであれば、余計な事はやらない方が良かったのかもしれません。悩みどころです。

ちなみに、文字名称や IANAの文字セット登録の内容に厳密に従うと、EUC-JP → Shift_JIS といった変換で、'\'(REVERSE SOLIDUS) が '＼' に変換されてしまったりします。
規格上は正しくても、実用的に使う上では問題となってしまいます。

例)
http://oss.timedia.co.jp/index.fcgi/kahua-web/show/MySQL%c6%fc%cb%dc%b8%ec%a4%ce%ce%b9
→「5.文字化け」参照

参考)
IANA CHARACTER SETS
http://www.iana.org/assignments/character-sets

従来の文字コードとUnicodeの対応に関する諸問題
http://euc.jp/i18n/ucsnote.ja.html

[ 記事一覧 | 返信(R) | 引用して返信(Q) ]