[本] プログラマのための文字コード技術入門



文字コードをあれこれといじる必要が出てきたら、一度読んでおくべき本。
今すぐ実践で使えるかというとそういうわけではなくて、背景知識として理論を知っておかないと、いずれ手間をくう事になる。

目次

第1章 文字とコンピュータ
第2章 文字コードの変遷
第3章 代表的な符号化文字集合
第4章 代表的な文字符号化方式
第5章 文字コードの変換と判別
第6章 インターネットと文字コード
第7章 プログラミング言語と文字コード
第8章 はまりやすい落とし穴とその対処
Appendix


Webで色々と文字コードの説明について読むのだが、本書を読まないとわかりにくい所というのが確かにある。
それは、文字集合は一体どういう理屈でできてるのか、という点である。

文字コードの成り立ちから、JISの歴史、Unicodeをツボよく押さえている。
包摂、結合文字、漢字統合などの概念もちゃんと書かれている。

特に、包摂に関してはちゃんと文字コードを知っておこうとする人は必ず知っておくべき事だと思う。
同じ漢字は同じコードポイントを割り当てる、という事で。
1点の辶と2点の辶は同じである。

んな事を強調するのは、メールで使用されるISO-2022-JPに「梯子高」が入ってなかったりするからなのだが、こういう事のクレームを対応していると、一般の人にもコンピュータで文字を扱うという難しさを知って欲しい所もある。

名前が上手く出ない、というのは確かに致命的だと思う。
けれど、それは書体の違いなのではないか?
そう言い返したいのだが、「化けてるものは化けてる」と言う相手には通じない。
この辺は6章のインターネットと文字コードの箇所で触れられる。
個人的には、インターネット上でASCII以外を扱う方法であるMIMEにはこっぴどくやられているので、色々と期待するモノもあったが、実際痛い所は後回しにされる。
この本にかいてある方法だけで、添付ファイル名をとったら、絶対に痛い目見る事は保証してあげてもいいぐらい。
ちなみに、解決策はない。


プログラミング言語での扱いとして、Java, Rubyが紹介されている。
Javaの内部コードはUTF-16ではなかったか?
Unicodeというと、文字集合であって、符号化されていないのであつかえないのではないかな、と思うのだが
(J2SE5.0からだった)。
個人的にPerlではないのはなぜなのかと問い詰めたい。


落とし穴とその対処の章には文字化けやチルダ問題などおもしろいトピックについて色々とかいてあるが――
一番期待するNEC外字、IBM外字、MSのcp932については書かれていない。
おそらく文字コードで本を買おうという人間のほとんどは、そういう所を期待しているのだと思うが、それに応えていないんじゃないか。
実践的ではない、と思うゆえんである。


以下、オマケのようなもの。

Unicodeの制定については、結構ぐにゃぐにゃしたものがある。
なので、文化的中立でないのは当然で、実際に文字を追加する時にどういうやりとりになったか、というのは昨年から今年Unicodeの絵文字の改訂に携わった小形さんのページから伺える。

 絵文字が開いてしまった「パンドラの箱」第7回--そして舞台はダブリンから東京へ
  http://japan.cnet.com/sp/column_emojipandora/story/0,3800105535,20407951,00.htm
  →絵文字のハナシだけではなく、Unicodeの世界についても
   伺える良記事。第一回から読むべし。
 
 [文字コード]INTERNET Watchに記事を書きました
  http://d.hatena.ne.jp/ogwata/20100714/p1


こういうのをみてると、政治的な所もすごくあるのだなあ、と納得してしまう。


Perlの日本語処理については、現在はUTF-8で扱い、変換はEncode.pmを使用するようになっている。
この辺は、まるごとPerlなどがわかりやすくて参考になる。





いつもの感じで言えば、まあ、そんなに難しいハナシではなくて、

 Perl で utf8 化けしたときにどうしたらいいか
  http://d.hatena.ne.jp/tokuhirom/20080408/1207619640

入り口で decode して、内部ではすべて flagged utf8 で扱い、出口で encode する。これがすべてです!とにかくこの基本方針をまもっていれば幸せになれます。

 

という事だそうです。


・・・・おじいさんが携わっているプロジェクトでは、レガシーなコードをあつかっているせいで、内部は未だにunflagged utf8ですorz
なんでやねん・・・
下手にXML::DOMなんか食わせると、flaggedになってもどってくるし。
バグの元なのになあ。。。


ブログ気持玉

クリックして気持ちを伝えよう!

ログインしてクリックすれば、自分のブログへのリンクが付きます。

→ログインへ

なるほど(納得、参考になった、ヘー)
驚いた
面白い
ナイス
ガッツ(がんばれ!)
かわいい

気持玉数 : 0

この記事へのコメント

Farsse
2010年07月16日 02:10
昔は、"CJKV" が1つのキーワードでしたね。
CJKV 多言語処理、とか言う本があったよなぁ、と思って調べてみたら出てこなくって。。。
CJKV 日中韓越情報処理、と言う本みたいですな。
http://books.google.co.jp/books?id=U36IQGjmfqMC&printsec=frontcover&dq=CJKV&hl=ja&ei=Yz0_TOOONYnUvQOuyIFQ&sa=X&oi=book_result&ct=result&resnum=1&ved=0CCsQ6AEwAA#v=onepage&q&f=false

個人的には、UTF-7, UTF-8 と同列に UTF-16 とか言って欲しくないですよ。
UCS2, UCS4 と言ってもらった方が、わかりやすいというか何というか。
UTF-16 って、エンコードしてないよね、とか言いたくなってしまうわけで。
(実際は、微妙に違う)

で、当初から危惧されていたとおり、全然文字数が足らなかったわけで。
さっさと、UCS4 に移行しようよ。

ちなみに、わたしの手元には、
「国際化プログラミング ~I18N ハンドブック~」
http://www.amazon.co.jp/dp/4320029046
なんて本があったりします。
1万円超えてるけどなー。。。orz
2010年07月16日 08:44
CJKV 日中韓越情報処理は、ちろっと本屋で見ただけだけれど、浩瀚な本でしたなあ。
分厚すぎww

この記事へのトラックバック