森山です。

On Mon, 07 Nov 2005 14:48:02 +0900
Yasufumi Kinoshita <kinoshita.yasufumi@xxxxxxxxxx> wrote:

> cp51932についての私見を述べさせてください。
> 
> ご指摘の記事の中に出てくる
> http://www.rikai.com/library/kanjitables/kanji_codes.euc.shtml
> をざっと見たところ、eucJP-openとの違いは、SJISでの「NEC選定IBM拡張文字」(ED40〜EDFC)を
> そのままの句点コードに対応するEUCでの領域 (F9A1〜FCFE) に割り当てているみたいです。
> この領域は eucJP-open ではSJISでの 外字領域を保持する部分の一部です。
> cp51932への対応は少なくともEUCで外字領域を保持することと二者択一になりそうですね。
> ただ、SJISで直接格納できないPostgreSQLと違い、MySQLのcp932では外字領域が考慮されているので、
> MySQLではEUCで外字を格納するケースのほうが稀かも知れません。

DB を EUC とするのは、5.8.0 以前の Perl でプログラミングする場合にスクリ
プトを EUC とする場合に、それにあわせて DB も EUC にするという事はあると
思います。その場合、Web ブラウザへの入出力文字コードを EUC にする事で、
余計な手間をかけずにプログラミングするという事は一般的なのかもしれませ
ん。そのようなシステムでは、CP51932 なデータが DB に格納されてしまうとい
う事が起きます。

> またもうひとつ分かれ道がありまして、「NEC特殊文字」は「JIS X 0208(EUCでは２バイト文字)」と、
> 「NEC選定IBM拡張文字、IBM拡張文字」は「JIS X 0212(EUCでは３バイト文字)」と
> それぞれ重複する文字があり、MySQLでの cp932→eucjpms の変換では JISの文字がある場合は
> JISの文字として変換されます。
> （※PostgreSQLではNEC特殊文字だけはそのままの句点コードで変換されるようですが。)
> このポリシーのまま対応すればどちらにせよ、ご指摘の問題の発端となっている文字は
> JIS X 0212(補助漢字)に変換され、EUCでは"8F"で始まる３バイト文字に変換されます。
> しかし個人的にはJISの文字に揃える変換の方が、検索などの実用上望ましいと思います。
> ご指摘の問題の原因は、マッピングの差異も確かにあるのですが

> 寧ろ、「JIS X 0212」までで規定されているEUCエンコーディングでの３バイト文字を
> 表示できないIEの不具合なのではないでしょうか？

かなり古い資料になりますが、

UNIX System V リリース 4 日本語環境共通規約 第 1 版
発行所: 株式会社トッパン
ISBN4-8101-8539-7

には、 日本語EUCのコードセット2 (JIS X 0201 片仮名), コードセット3
(JIS X 0212 補助漢字) は必須ではない事が明記されていましたので、
IE の不具合とは言い切れないでしょう。

それよりも、CP51932 + JIS X 0212 が表示可能で POST するデータは 
CP51932 だったりすると、FireFox でサポートしている EUC-JP が、
eucJP-open なのか、CP51932 なのか迷ってしまいそうです。

> FireFox(WinXP版)では"FAE3"も"8fc7cb"も両方表示できるので(cp51932が考慮されていますね・・)、
> ページ上から入力を行おうとしない限りは文字化けは起こらないと思います。

そもそも Windows 標準キャラクタセットを EUCエンコーディングのまま外部
とデータ交換しようとする事に無理があるというのが個人的な見解です。

現行のままでも、Windows 標準キャラクタセットを文字化けせずに扱う方法は
ありますから、適切なシステム構築ができるように情報を整理して提示する必
要があるのでしょうね。

‖森山 将之 (MORIYAMA Masayuki)
‖e-mail: msyk@xxxxxxxxxx