[pgsql-jp: 39335] Re: 'encoding "EUC_JP" has no equivalent in "UTF8"' の理由

2008年 4月 2日 (水) 00:27:03 JST

石井です．

> ミラクル・リナックスの森山です。
> 
> 1年ほどまえ PostgreSQL に cp51932 を追加する機会がありながら
> 作業するといっておきながら、作業をせずに申し訳ありませんでし
> た。

ちょっと期待していましたが...

それはともかく，詳しいまとめ，ありがとうございます．だいぶすっきりしま
した．

> Tomoyuki Asakawa wrote:
> > このあたり参考になるとおもいます。(って、このプロジェクト どうなったんだ
> > ろ？)
> >
> > http://sourceforge.jp/projects/legacy-encoding
> > http://legacy-encoding.sourceforge.jp/wiki/
> > http://lists.sourceforge.jp/mailman/listinfo/legacy-encoding-talk-ja
> > http://www.ipa.go.jp/about/jigyoseika/05fy-pro/open/2005-1467a.pdf
> > http://www.ipa.go.jp/about/jigyoseika/05fy-pro/open/2005-1467d.pdf
> 
> PHP に関しては upstream にパッチがマージされ 5.2.1 から CP51932
> と ISO-2022-JP-MS が使えるようになっています。また、Perl に関
> しては、成瀬氏が別途 Encode::EUCJPMS モジュールを開発されて
> CPAN にアップされていますので、そちらを使う事で Perl の Encode
> モジュールで cp51932, eucJP-ms, cp50220, cp50221 が変換可能と
> なります。(Encode::EUCJPMS をインストールした後で enc2xs -C
> を実行しておく事で piconv, convmv でも使えるようになります。)
> 
> マイクロソフト標準キャラクタセットを扱う場合の基本的な考え方
> は次の通り。
> 
>   1. クライアント(ブラウザ)とサーバーでのやりとりは CP932も
>      しくは UTF-8 を使う。
>   2. スクリプトエンコーディングは、UTF-8(Unicode) もしくは、
>      eucJP-ms を使う。
>   3. DB はスクリプトエンコーディングに合わせる。
> 
>   ※ クライアントとサーバーのやりとりを UTF-8 で行う場合はスク
>     リプトと DB も UTF-8 とするが望ましい。
> 
> Web ブラウザに表示するエンコーディング、スクリプトエンコーディ
> ング、DB のエンコーディングを cp51932 に統一できれば一番楽な
> のではないかという考え方もあるかと思いますが実際に使うことを
> 想定して検討すると一筋縄ではいかないことがわかります。
> 
> たとえば、Firefox の EUC-JP では、JIS X 0212 を 3 バイトコー
> ドで POST してくるため、cp51932 -> UTF-8 (Unicode) という変換
> でエラーが発生するなどの問題があります。
> 
> 次の 6 つを明確に区別できていなければ、EUC-JP符号化方式での文
> 字化けの対策をすることは困難という状況と言えると思います。
> 
> 1. EUC-JP          JIS X 0208, JIS X 0212 (ベンダ拡張なし)
> 2. cp51932         JIS X 0212 無し (NEC特殊文字、NEC選定IBM拡
>                    張文字追加)
> 3. eucJP-ms        eucJP-open と同一の文字集合で Unicode 変換
>                    の違いにより eucJP-ascii, eucJP-0201,
>                    eucJP-ms の 3 つが定義されている
>                    大文字のローマ数字などの重複定義文字の変換
>                    の正式な規定はないため実装依存の可能性を考
>                    慮する必要あり。
>                    PostgreSQL の EUC_JP。ただし Unicode との変
>                    換ではユーザー定義文字の変換は行われない
> 4. eucJP-ms-ex     eucJP-ms の ユーザー定義文字領域を潰して
>                    NEC選定IBM拡張文字追加
> 5. cp51932-firefox cp51932 に JIS X 0212 を追加
> 6. cp51932-ex      cp51932-firefox に eucJP-open の 0x8ff3f3
>                    ～ 0x8ff4fe を追加
> 
> 4, 5, 6 は私が勝手に名前を付けたものですが、Unicode から
> cp51932-firefox, cp519323-ex に変換する際に、重複定義されてい
> る文字の優先順位として次のルールにしたがいます。
> 
> Unicode -> cp51932-firefox, cp51932-ex 優先順位
>   JIS X 0208 > NEC特殊文字 > NEC選定IBM拡張文字 > JIS X 0212
> 
> Unicode -> eucJP-ms-ex の優先順位
>   JIS X 0208 > NEC特殊文字 > JIS X 0212 + 0x8ff3f3～0x8ff4fe
> 
>   ※ SMAP の草ナギ剛の「ナギ」の文字が NEC選定IBM拡張文字と JIS
>     X 0212 の両方で定義されているので、cp51932-ex, eucJP-ms-ex
>     は次のような変換となります。
> 
>       cp51932-ex  -> Unicode -> cp51932-ex
>       F9AC        -> U+5F45  -> F9AC
>       8FBCF4      -> U+5F45  -> F9AC
> 
>       eucJP-ms-ex -> Unicode -> eucJP-ms-ex
>       F9AC        -> U+5F45  -> 8FBCF4
>       8FBCF4      -> U+5F45  -> 8FBCF4
> 
> cp51932-ex のようなものを追加したとしても、IE の EUC-JP (cp51932)
> で JIS X 0212 を表示できませんので。アプリケーション側で、 数
> 値文字参照形式に変換してやるなどの処理が必要になってくるでしょ
> う。
> 
>   ※森鴎外の「鴎」の「区」が「區」になっている文字は、JIS X 0212
>     に定義されていて NEC選定IBM拡張文字では定義されいません。
>     Windows では cp51932 から Unicode への変換で次のような変換
>     が行われるので注意が必要です。
> 
>       cp51932 -> Unicode
>       8FECBF  -> U+4E57(乗) U+FF7D(JIS X 0201 の'ス')
> 
> Web アプリケーションなどで文字化けを起こさないようにするために
> はユーザーが入力した文字列に対して、次のような処理を行う事が必
> 要と思われます。(一例)

このあたりはいちいちうなずけますね．

>   0. 文字コードの自動判定は行わない。
>      - これは絶対条件。
>   1. 符号化方式として正当なバイト列かどうかをチェックする。
>      - UTF-8 はもちろんこと、シフト符号化方式、EUC-JP 符号化方
>        式でもバイト列の正当性チェックはルーズな変換ルーチンに
>        による不具合回避をする意味でもやっておく事をお薦めしま
>        す。
>      - 特定の不正なバイト列をはじくのではなく正当なバイト列の
>        みを通過させるような処理にする。
>   2. アプリケーション・ソフトウェアで正しく処理出来る文字やエ
>      ンコーディングかどうかをチェックする。
>      - 使用するソフトが扱える文字集合が不明な場合は、JIS X 0208
>        の文字だけに制限するようにする。
>   3. 必要であれば、ここで文字コード変換ルーチンに対して入力文
>      字コードを正しく指定して文字コード変換をする。
>      - ここでの変換では、シフトJIS符号化方式からEUC-JP符号化
>        方式に変換する場合、95区～120区の扱いに注意すること。
>        必要であれは、2 の段階で94区までに制限しておく。
>   4. 重複定義されている文字がある場合は、どれか一つのコードポ
>      イントに正規化する。
>      - 重複定義の文字の問題が原因で検索した文字列がヒットしな
>        いという事態が発生した場合に原因究明に時間がかかる事が
>        予想されますので注意しておいた方がいいでしょう。
>        * EUC-JP符号化方式の「ナギ」や UTF-8 の「～」など。
>   5. 0～4を通過したものに対してセキュリティ対策を行う事。
> 
> このような処理を行っていれば、EUC-JP符号化方式で統一するという
> 事も可能になってくるでしょう。JIS X 0212 が多い分、シフトJIS符
> 号化方式よりも考慮すべき点が増え難易度は確実に上がりますが。
> ブラウザによって JIS X 0212 を直接 POST してくるものと、数値文
> 字参照で POST してくるものがありますから入力側では正規化処理、
> 出力側では JIS X 0212 の数値文字参照への変換処理が必要になって
> くるでしょう。(cp51932 に変換できない JIS X 0212 は捨てるとい
> う選択肢もあるでしょう。)
> 
> PostgreSQL に cp51932ex を追加して幸せになれるのか私には自信が持てません。

やめた方がよさそうですかね．

> そうこうしているうちに Unicode 5.1.0 がリリース直前という状況
> になってきています。
> 
>   http://www.unicode.org/versions/Unicode5.1.0/
> 
> 個人的には、次の拡張が日本語情報処理にとってインパクトがある
> とみています。
> ---------------------------------------------------------
> A major feature of Unicode 5.1.0 is the enablement of
> ideographic variation sequences. These sequences allow
> standardized representation of glyphic variants needed for
> Japanese, Chinese, and Korean text. The first registered
> collection, from Adobe Systems, is now available at
> http://www.unicode.org/ivd.
> ---------------------------------------------------------

たしかに「インパクト」はありそうですが，これは我々にとって吉でしょうか？
それとも凶でしょうか？それすらわからないorz
# とりあえず以下を見ただけなのですが．
# http://gaiji.sourceforge.jp/index.php?Unicode%20Ideographic%20Variation%20Sequence%20%E3%81%AE%E6%A6%82%E8%A6%81
--
Tatsuo Ishii
SRA OSS, Inc. Japan