文字コードのお話のお話

こんにちは。

社内で勉強会をする機会があったのでその資料をSlideShareにアップしました。

http://www.slideshare.net/shunjikonishi/ss-14537848

僕自身は文字コードネタはJIS2004が出たあたりまでは、興味深く追いかけてましたがその後のあまりの混迷ぶりについていけなくなって脱落しました。(^^;;;

例えば製品やライブラリを調査する際にはよくソースコードを読んだりするわけですが、そういうのは深く調べていけばいつかは底にたどり着きます。しかし文字コードはどこまで潜っても底が見えない！そういう意味では技術者向きのネタではないような気もしています。

この資料でははしょっている部分もたくさんあるんですが、文字化けの原因を推測するという目的に対しては十分なんじゃないかと思います。
ご意見、ご感想、誤りの指摘等あれば是非コメントお寄せください。m(_ _)m

□□□□

今回久しぶりに気合を入れて文字コード関連の資料をあさりましたが、実のところそれほど目新しい発見はありませんでした。
Mac OS Xのファイル名で合成文字が普通に使われているのにびっくりしたくらい。

約5年のブランクがあるのにそれほど目新しい発見がないということは文字コード問題がようやく収束に向かいつつあるということなのかもしれません。
JISが新しい規格を提案することはおそらくもうないでしょうし、はやいところUnicode一択の世界になってほしいものです。

その一方でサロゲートペアへの対応は思ったほど進んでないとも感じました。
個人的にはこれはFEPの問題が大きい気がしています。例えばサロゲートペア説明の定番文字「魚花(ほっけ)」。(このブログでも保存できません。。。(--)

Windows7のOffice IME 2007では普通に変換候補として表示されますが、iOS6では候補に挙がってきません。要するに簡単に入力する手段がないからいつまでも普及しない。
ただWindowsで入力できるのであればそろそろ「特殊な文字」という言い逃れもできないフェーズに来ていると思うんですけどね。。。。エンドユーザーに対して「できません」が、いつまで通用するのかはかなり怪しいと思っています。

メールに関してはもはや「正しいISO-2022-JP」が復権する可能性はないと思っています。「Shift_JIS」と「Windows-31J」が正しく使い分けられることも多分ないでしょう。
Webに関しては大分Unicode化が進んでいてそうしたことに煩わされる機会も減っているように思いますが、メールはiso-2022-jpで送信する慣習がなかなかすたれないですねぇ。。。(--
誰かが送信メールを各国語に自動翻訳してマルチパートで送ることができるようなメールクライアントを開発すればUnicode化が一気に進むかもしれません。(^^;;;

以上、文字コードの資料を作成してのとりとめのない感想でした。