MORIYAMA Masayuki
moriy****@mirac*****
2006年 4月 5日 (水) 21:20:11 JST
森山です。
○ ISO-2022-JP-MS で非対称な変換を行う事に関して
> > 逆に、ISO-2022-JP-MS がメールのやりとりにだけしか使われないという保障
> > があるのか? と考えると、MUA 依存の実装を行う事は、テキストエディタでの
> > 利用の場合のように弊害があるので、避けたいところです。
>
> ということは，現在そのような符号化文字集合はエディタで使われれている例
> は示せないということですね．
>
> では，現在新しい7ビット及び8ビットの2バイト情報交換用符合化漢字集合は
> 新たに作成しないという合意を覆すまでの必要はないという結論になります．
ISO-2022-JP-MS の実装に関して、Unicode へ変換する時には、Windows 機種
依存文字を変換するようにし、Unicode から 7ビットJISコードに変換する際
には、US-ASCII と JIS X 0208:1997 だけを変換するようにする。
ISO-2022-JP として認められていない文字が含まれている場合は、変換できな
いようにしておくという事であれば、合意を覆すわけではないから良いという
事になるでしょうか?
○ MUA でのメール送受信について
> > MUA で、メール受信の時だけ ISO-2022-JP-MS を使い、メール送信は必ず
> > UTF-8 で行うという事になれば、ISO-2022-JP-MS を IANA Registry に登録す
> > る必要は無くなると思います。
>
> というか，メールの送受信をUTF-8でおこなってしまえばよいのでは？
メールの送受信ともに UTF-8 にすれば問題ないという事に異論はありません。
実際に、問題になるのは、完全に UTF-8 環境に移行するまでの間、
ISO-2022-JP という名前で Windows 機種依存文字を含むメールを受信した時
の話で、その場合、どうしたら良いのか、良いアイディアはあるでしょうか?
○ eucJP-ms と cp51932 の違いに起因する問題
次の図に示すように、Webブラウザ ⇔ PHP ⇔ MySQL (5.0.3以降) というパス
で CP51932 が処理されている場合は、一見問題なく動作しているように見え
ますが、右側のパスのように eucjpms を cp932 に文字コード変換して表示さ
せるなどすると、文字化けが発生します。
'髙' を POST '髙' で表示される '・' で表示される。
↓ ↑ ↑
+--------------------------------+ +--------------------------+
|Web ブラウザ (IE, Firefox など) | |MS-Access |
| EUC-JP(CP51932) で表示 | | |
| EUC-JP(CP51932) で POST | | |
+--------------------------------+ +--------------------------+
│ ↑ ↑
0xFCE2でPOST 0xFCE2 0xF3E0 (ユーザ定義文字)
↓ │ │
+--------------------------------+ +--------------------------+
|PHP | |MyODBC |
| 内部エンコーディング = EUC-JP | | クライアント |
| HTTP入力 = 無変換 | | エンコーディング = cp932|
| HTTP出力 = 無変換 | +---------------------------+
+--------------------------------+ ↑
│ ↑ │
0xFCE2でDBに格納 0xFCE2 │
↓ │ │
+--------------------------------+ │
|MySQL |────────┘
| DBエンコーディング = eucjpms |
+--------------------------------+
MySQL を直接操作して上記の現象を再現させる方法
-------------------------------------------------------------
TeraTerm Pro で文字コードを EUC に設定して以下の操作を行う。
# TeraTerm Pro の EUC は CP51932 モドキです。
# CP51932 の表示は可能ですが、NEC選定IBM拡張文字の入力が出来ません。
# SJIS->EUC の変換で CP932 の IBM拡張文字に対応していない為。
mysql> SET NAMES eucjpms;
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE DATABASE eucjpms_db DEFAULT CHARACTER SET eucjpms;
Query OK, 1 row affected (0.00 sec)
mysql> USE eucjpms_db;
Database changed
mysql> CREATE TABLE eucjpms_table ( code TEXT, ch TEXT );
Query OK, 0 rows affected (0.08 sec)
mysql> insert into eucjpms_table values( 'ADA1', '①' );
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO eucjpms_table VALUES ( 'FCE2', _eucjpms 0xFCE2 );
Query OK, 1 row affected (0.00 sec)
mysql> SELECT code,HEX(ch) FROM eucjpms_table;
+------+---------+
| code | HEX(ch) |
+------+---------+
| ADA1 | ADA1 |
| FCE2 | FCE2 |
+------+---------+
2 rows in set (0.00 sec)
mysql> SELECT * FROM eucjpms_table;
+------+------+
| code | ch |
+------+------+
| ADA1 | ① |
| FCE2 | 髙 | ← CP51932 で表示させると '髙' に見えますが、eucJP-ms
+------+------+ では、本来ユーザ定義文字。
2 rows in set (0.00 sec)
TeraTerm Pro の文字コードを SJIS に設定しなおして次の操作を行う。
mysql> SET NAMES cp932;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM eucjpms_table;
+------+------+
| code | ch |
+------+------+
| ADA1 | ① |
| FCE2 | | ← 元々、eucjpms でユーザ定義文字だったものが正しく表示
+------+------+ されるようになっただけ。
2 rows in set (0.00 sec)
mysql> SELECT code,HEX(CONVERT(ch using cp932)) FROM eucjpms_table;
+------+------------------------------+
| code | HEX(CONVERT(ch USING cp932)) |
+------+------------------------------+
| ADA1 | 8740 |
| FCE2 | F3E0 |
+------+------------------------------+
2 rows in set (0.01 sec)
-------------------------------------------------------------
eucJP-ms と cp51932 が別物であるという認識が無いと、上記のような事
(CP51932 を eucjpms な DB に直接格納してしまう) をしてしまう危険性があ
ります。
Web ブラウザからのアクセスだけであれば、文字化けしないという事で、問題
がある事に気が付いていない例は多いかもしれません。
--
森山 将之 moriy****@mirac*****
ミラクル・リナックス株式会社