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

2007年 1月 5日 (金) 13:43:54 JST

パパぱふぅ様

前田です。
この度、私自身の勝手な事情により返信が遅れご迷惑をお掛けしております。
パパぱふぅ様のご説明が大変勉強になり、うれしく思っております。
私自身には身近に関係者がいないために、自分自身で対処しなければなりま
せんので、結構、目的の問題を取り上げている内容を探すのに苦労したりいた
します。

まず、勝手な質問ではありますが、パパぱふぅ様が述べられた下記の内容は

> ２）サーバサイド（OS、DB、その他の設定）がマルチバイトに完全対応していな
> い。
> ３）クライアントサイド（OS、ブラウザ、その他の設定）がマルチバイトに完全
> 対応していない。

２）の内容は国内のサーバの大半がMySQL4.0.xxのバージョンでUTF8に対応
されていないという意味でしょうか。（文脈から推測はできるのですが、解釈に間
違いがあっては申し訳御座いませんので、失礼ながら質問させていただきます。）

３）の内容もUTF8に対応しているかどうかということでしょうか。

お手間お取りいただきますがよろしくお願いいたします。

#本題ですが、
このテーマを通しまして皆様のお力を頂くことができ感謝しております。

MediaWikiのデータベースをMySQL4.0.xxを採用し場合、コンテンツを
BLOB型で保存を行っているようです。

パパぱふぅ様のご意見がMediaWikiが採用しております管理方法から
いたしましても、バイナリ・データとして扱うことが的確であると考えられ
ます。

（つまり、MySQLはあくまでもデータを格納するためのファイルシステムと
して利用することが好ましいという発想からですが、いかがでしょうか。）

しかし、残念ながらMySQLとやり取りする時に利用する文字コードにつ
いてまとめていくためには、私の頭ではしばらく時間がかかりそうです。

大変申し訳御座いませんが、年末年始もお応えいただきました内容に
ついて調べたり、考えたりしておりましたが、結局のところ簡単にまとめる
ことが難しいことに気づきました。

そのため、本テーマで得た知識もありますので、再びMySQLを試してから
まとめ作業を行いたいと考えておりますが、そのようにさせていただいても
かまわないでしょうか。

誠に勝手なことではありますが、再度MySQLを利用する上での文字コード
についてメールさせていただきます。

皆様、今後ともお付き合いよろしくお願いいたします。


06/12/29 に papa pahoo<papa ＠ pahoo.org> さんは書きました:
> 前田様
>
> パパぱふぅです。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/
> ==========================
>
> _______________________________________________
> PHP-users mailing list  PHP-users ＠ php.gr.jp
> http://ml.php.gr.jp/mailman/listinfo/php-users
> PHP初心者のためのページ - 質問する前にはこちらをお読みください
> http://www.php.gr.jp/php/novice.php3
>


-- 
前田　光哉　(MITSUYA MAEDA)
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◆準備中
◆◆ mitsuya.maeda ＠ gmail.com