[PHP-users 31158] Re: MediaWikiとMySQL間で利用する文字コードについて

[papa pahoo]

前田様

パパぱふぅです。MySQL4.0xから5.xへ移行できないというのは、プログラムの設
計上の問題かと思われます。文字セットに留意した設計がなされていれば、経験
上、ちょっとした変更で移行できます。

PHPの話から少し外れますが、個人的な感覚として、テキストを扱う場合には型
制限が厳しいもの――Ｃ言語のchar* とかRDBMSのCHARとか――は扱いにくいで
す。PHPの変数やMySQLのTEXTのように、少なくとも格納するバイト長の制約が緩
いものが好きです。
また、UTF-8でソースが書けない処理系も敬遠しておいた方がいいですね。最初
はEUCやShift_JISでソースを書いていても、世界に出るためにはUTF-8が必要に
なります。たとえばXMLの世界は、原則としてUTF-8ですから。

MediaWikiの場合、グローバルな文字セットを扱う必要があるので、UTF-8になっ
ているのは当然のことかと思います。私は、自宅ではMacintoshも使っているの
ですが、世界中の文字がマルチバイトで扱えることは普通だと思います。
MediaWikiはワールドワイドでチェックされているので、ソース自身に文字セッ
トに依存するバグはほとんど無いことでしょう。しかし、国内のレンタル・サー
バにインストールする場合、サーバ側の設定の制限で、文字化けが発生すること
があるようです。

経験上、文字セットに絡む問題が発生するのは以下の３箇所です。

１）プログラム・ソース（内部処理）がマルチバイトに完全対応していない。ま
たは、機種依存文字を許している。
２）サーバサイド（OS、DB、その他の設定）がマルチバイトに完全対応していな
い。
３）クライアントサイド（OS、ブラウザ、その他の設定）がマルチバイトに完全
対応していない。

MediaWikiは１）はクリアしているはずですが、前述のように、国内のレンタル
・サーバでは２）をクリアできない場合があります。
MySQLではないのですが、少し前のDB2で、一部の日本語記号（JIS第1水準なのに）
が化けるという問題がありました。IBMに聞いたら「文字セットの仕様」と言わ
れ、トホホな思いをしたことがあります。仕方がないので、自前の変換テーブル
を用意しました。
MySQLの場合、私の身近な人間がマルチバイト化に協力しているので、安心して
仕事で使っています（4.0.xを使うこともあります）。ただし、MySQLにバグがな
いわけではありません。知り合いがいると、バグや制限情報が“速やかに＋日本
語で”入手できるというのが大きなメリットだからです（笑）。
また、Windowsでは３）をクリアできない場合がありましたが、Windows XP SP2
+ IE7でほぼ解消できた感じです。

さらに、たとえ１〜３）のすべてをクリアできて、機種依存文字を使っていない
としても、環境によってフォントの字形そのものが異なる（異体字）場合があり
ます。とくに人名の場合、字形が変わることを非常に問題視するユーザーがいる
ので、設計者としては気を配らなければなりません。
Windows Vistaでは一部の字形が変更になるので、画面の表示とプリンタ印字が
異なるという10数年前の悪夢が蘇るのではないかと懸念しています。

私の場合、化ける可能性がある文字グループをバイナリ・データとして持ち歩い
ています。で、個人名を扱うようなシステムをつくる場合には、入力系／内部処
理系／DB系／画面出力系／帳票印字系の各々の単体テストの段階で流し込みチェッ
クして、総合テストの前に潰すようにしています。結合後に文字化けが発生する
と、原因特定に時間がかかってしまうからです。
ただ、さすがに俺様プログラムを組む時には、そこまでやっていませんが（笑）。

文字コードに絡む諸問題については、うちのホームページに随時アップしている
ので、参考にしていただければ幸いです。⇒
http://www.pahoo.org/e-soul/webtech/encode/

==========================
  パパぱふぅ
  http://www.pahoo.org/
==========================