とある画像DBでの話。
僕がDBをつかったサイトを構築する場合、基本的にPHPもDBもEUCを使うことにしている。なぜかというと、文字コード上のトラブルが少なく、EUCを扱えるアプリケーションも多いから。
使える文字の多さでは、Unicodeがよいし、将来的にはユニコードが良いのだろうけど、実際、完全にUnicodeを扱えるエディタが少なかったり、Mac/IEでUnicodeの表示がおかしかったりなどで、基本的には使いたくないと思っていた。
それに、Unicodeじゃないと表現できない文字って、そうそう使うことが無いし・・と思っていたら、ほぼ完成したDBにて、Unicodeでしか表現できない文字（米＋造みたいな）を出したい・・・といわれ、途方にくれる。
いまから、DBとPHP,HtmlをすべてUnicodeにするのはむちゃくちゃ手間がかかるし、DBが文字化けしたら、目も当てられない。たった1文字の為にはいまから使う文字コードを変換するのはすごく手間がかかりすぎる。
しかし、文字には文字自体に意味があるので、文字が変わればコンテンツとして意味が変わってしまうし・・・。
頭痛い・・。
そもそも、なぜその1文字に気づかなかったかというと、文字データをもらった際に、エクセルでファイルをもらったのだが、Macでその書類を開いた時点で、MacのExcel(v.X)が、Unicodeに対応してないらしく、ぼっこしその文字が欠落していたのである。だから、まったく気づかなかった。（紙ベースの資料と比較すれば良かったので、こちらの手落ちとも言える）
うがー。頭痛い。
Unicodeの問題点は、
・すべてのアプリが対応してるとは言えない、もしくは対応してても問題が多い
たとえば、僕がマックでよく使うAppleWorksや、mi(mi自体はutf対応してるが、IMの文字パレットからUnicodeの文字をペーストできない）が、対応してない。つまり、テキストデータのやり取りができない。
WordやExcelもダメだった（v.Xなので、最新版は対応してるのかもしれないが）
Windows上のアプリでも、Unicode対応をうたってるアプリでも内部エンコードがSJISのものがあって、そういうものはUnicode対応といいつつ、実は対応できない。
実際、ViViというエディタをメインで使っているのだが、これも表向きはUnicode対応だが、内部エンコードがSJISのため、すべてのUnicodeを表示はできない。
DreamWeaverは、ありがたいことにかなり確実にUnicodeに対応しているのだが、いかんせん、コードの認識を意図的に変更できないため、DWが認識に失敗すると、もとに戻せなくなる。
また、Unicodeの問題として、解決できない最大の問題として、見た目は同じだけどコードが違う文字が多々存在するということである。〜（チルダ）など、よくおかしくなる。
EUCを使っていれば、そういったトラブルは皆無なのである。
(SJISの場合、別な理由で文字化けしやすいので使わない）
・・・・しかし、ここに来て、Unicodeじゃないと表現できない文字が出てきたので、そうとうに頭が痛いのである。
ｷﾞｷﾞー