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

2008年 3月 31日 (月) 17:13:36 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.
---------------------------------------------------------

--
ミラクル・リナックス株式会社
森山 将之 moriyama ＠ miraclelinux.com
Web: http://www.miraclelinux.com/