玩式草子─ソフトウェアとたわむれる日々

第69回 Plamo LinuxをUTF-8で使う[その1]

この記事を読むのに必要な時間:およそ 4 分

最近,Knoppix日本語版の開発終了に伴い,開発元だった産総研のサイトも閉鎖された,というニュースを目にしました。

図1 閉鎖された旨を伝えるKnoppix日本語版のサイト

図1 閉鎖された旨を伝えるKnoppix日本語版のサイト

Knoppix日本語版はインストール不要のLiveCDの代表として,書き換え不可なKioskPCやハードウェアのテスト,トラブル時のレスキューなどに広く使われていました。Plamo LinuxのLiveCD版であるP-Plamoも,作成動機の1つはKnoppix日本語版でした。

産総研(産業総合研究所)「研究」機関であり,そこで働く職員には「研究(=新しい発見)⁠が求められます。その意味で「Knoppix日本語版の開発終了」というニュースは,日本語化はすでに「研究」テーマでは無くなったんだなぁ,という感慨にひたらせるものでした。

「日本語化」が研究テーマで無くなった最大の理由は多言語化の進展です。最近のソフトウェアの多くはあらかじめ「多言語化」されており,わざわざ「日本語化」しなくても,各種言語の1つとして「日本語」が利用できるようになっています。その背景にあるのが,Unicodeと呼ばれる文字コードの規格であり,それを実装したUTF-8という符号化形式です。

一方,Plamo Linuxでは,いまだに伝統的なEUC-JPという符号化形式を利用しており,最近ではそのためにいくつか不具合が生じるようになってきました。そこで今回は,これら文字コードについてあらためて考えるとともに,Plamo LinuxをUTF-8環境で使う方法について紹介してみます。

文字コードと「日本語化」

具体的な設定方法等に触れる前に,⁠文字コード」について簡単に復習しておきましょう。

コンピュータはビットのON/OFFで表現できる二進数を元に設計されています。そのため,コンピュータで処理するデータは,全て何らかの形で数字(二進数)に変換してやる必要があります。すなわち,アルファベットやカタカナ,ひらがな,漢字といった「文字」も,コンピュータで処理するためには数字に変換してやる必要があるわけです。

文字を数字として扱うためには,アルファベットの「A」や漢字の「亜」など,それぞれの文字に固有の数字を割りあてる必要があります。どの文字にどの数字を割りあてるかに必然的なルールは存在しないものの,コンピュータやソフトウェアのメーカごとに独自の割り当てをするとデータやソフトウェアの互換性が損なわれてしまいます。

コンピュータが生まれた米国の場合,黎明期にはさまざまな試行錯誤があったものの,アルファベットの大文字小文字と数字,各種記号など100種ほどの文字を16進数の0x00から0x7fに割り当てるASCII(American Standard Code for Information Interchange)という規格に落ちつきました。

IBMではASCIIが生まれる以前からEBCDIC(Extended Binary Coded Decimal Interchange Code)と呼ばれる割り当てを利用しており,この規格は現代でも汎用機の世界で生き残っています。

1バイト=8ビットあれば2^8=256通りの状態を表現することができます。しかし,アルファベットではせいぜい100種類ぐらいの文字を区別できればいいので,ASCIIでは8ビットのうち最初の1ビットを使用せず,7ビットで128種の文字を区別するようになっています。

一方,ひらがなやカタカナ,漢字を組み合わせて使う日本語の場合,文字の種類は膨大で1バイト=256種ではとうてい足りません。そこで2バイト(2^16=65536種)を用いて文字を区別することにして,1978年にJIS X 0208という規格が定められました。

使用頻度や難しさに応じて漢字を「第一水準」⁠第二水準」に分類したのがこの規格です。正確に言えばこの段階での名称はJIS C 6226でしたが,話の流れ上,広く知られている改訂後のJIS X 0208という名称で呼んでおきます。

JIS X 0208では「あ」という文字には0x2422(16進数の24と22)⁠⁠亜」には0x3021という数字が割り当てられています。一方,ASCIIでは0x24に$(ドル記号)⁠0x22には"(ダブルクォート)が割り当てられているので,日本語の「あ」を示すつもりで0x2422と指定しても,コンピュータは$"と判断してしまうかも知れません。

このような問題を回避するために,JISが定めた文字コードをASCIIと区別して使うための仕組みがいくつか考案されました。電子メールで広く用いられているISO-2022-JPやMS-DOSと共に普及したShift-JIS伝統的なUNIX環境で利用されているEUC-JPといった文字コードはこの仕組みの名称で,正確に言えばJISコードの符号化方式と呼ばれます。

ISO-2022-JPでは,文字列の前後に「この部分はASCII」⁠この部分はJISコード」という風に,使っている文字コードの種類を示す記号(エスケープ・シークエンス)を付けて区別します。EUC-JPではJISが定めた2バイトを1バイトずつに分解し,それぞれにASCIIでは使っていない8ビット目を立ててASCIIと区別できるようにしています。Shift-JISでは,JISが定めたコードを既存のコードと重ならないようにさまざまな領域に移動(シフト)して,半角カナ(1バイトカタカナ)などと共存できるようにしています。

文字コードに関する問題は日本だけでなく,漢字を使っている東アジア各国でも生じ,中国や台湾,韓国といった国々が,それぞれ独自の規格で文字と数字の対応を定義し,それを使いこなすためのソフトウェアを開発していきました。

一方,コンピュータやソフトウェアが国境を越えて普及していくにつれ,それぞれの国ごとに文字と数字の対応が異なっているのが大きな問題になってきました。そこで考案されたのが,世界中のすべての文字を統一の枠組みで数字と対応づけよう,というUnicode(ユニコード)の考え方です。

Unicodeでは,日本や中国,韓国等の既存の規格を参考にしつつも,それらとは全く異なるルールで全ての文字に2バイトの数字を割り当てています。

Unicodeではアルファベットの"A"はU+0041,漢字の「亜」にはU+4E9Cという数字が割り当てられています。ここで使われている"U+"という表記は,16進数表記を意味する"0x"と同等なものの,Unicodeであることを明示するための記号になっています。

JISコードをコンピュータ上で扱うためにISO-2022-JPやEUC-JP,Shift-JISといった符号化方式が考案されたのと同様,UnicodeでもUTF-16やUTF-8といった符号化方式が考案され,現在ではUTF-8が広く利用されています。

世界中の全ての文字を2バイト(=65536種類)の枠に収めるためには,文字の無用な重複は可能な限り避ける必要がある,Unicodeの主宰者たちはそう考えて,日本語や中国語,韓国語で使われている似た形の漢字は1つの文字としてまとめてしまうことにしました(CJK統合漢字)⁠各国の文化的背景を無視したこの強引な統合化によって初期のUnicodeはずいぶん批判されることになり,筆者の世代には未だにUnicodeに対する抵抗感が残っています。もっとも,世界中の全ての文字を2バイトの枠に収めるというUnicodeの当初の目論見は早々に破綻して,最近では既存の2バイト枠(UCS-2)と互換性を持たせつつ枠を4バイトにまで拡張してより多くの種類の文字を扱える規格(UCS-4)へと進化しています。

時代の流れを整理すると,JISコードの最初のバージョンが定義されたのが1978年その規格に基づいてShift-JISやEUC-JPが考案されたのが80年代の前半です。Shift-JISはMS-DOSに採用されPC-98シリーズに代表されるパソコンに,EUC-JPはUNIX系OSに採用されてワークステーションに,ISO-2022-JP(の前身であるJUNETコード)は電子メールやネットニュースなどインターネットを中心に広まっていきました。

当時,海外で開発されたソフトウェアは文字コードとしてASCIIしか想定しておらず,そのままでは日本語を使うことができません。そこで,それらのソフトウェアを改造し,何とかして日本語を表示させようとしたのがいわゆる「日本語化」の試みです。それらの試みは,元のソースコードに対するパッチとして開発され,メーリングリストやネットニュースを通じて広く利用されていました。

これら「日本語化」されたソフトウェアを整理して,Linux上で簡単に利用できるようにしたのが真鍋敬士さんの「JE(Japanese Environment)⁠パッケージで,Plamo Linuxの淵源の1つです。

一方,Unicodeは1991年に最初のバージョンが公開されたものの,アルファベット1文字を表わすにも2バイトが必要なため欧米圏では効率が悪いと嫌われ,日本でもCJK統合漢字などの扱いで評判が悪かったり,文字の並び方がJISコードとは異なり従来の文字コードに変換するためには対応表が必要だったりしたため,当初はなかなか普及しませんでした。

Unicodeには複数の部品から文字を合成する「合字」といった仕様も組み込まれており,ソフトウェア的に対応するのが大変だったという事情もあります。

しかし,90年代の後半になってくるとUnicodeの仕様も改善され,効率の悪さもコンピュータの性能向上であまり気にならなくなり,Unicodeを扱うためのライブラリ類も整備されてきました。加えてインターネットの急速な普及によって,ソフトウェアが多言語に対応することがますます重要になりました。そのためGNOMEやKDEといったデスクトップ環境をはじめ,JavaやPython,Swiftといった新しい世代の言語,SQLiteデータベースなど,多くのソフトウェアがUnicodeを積極的に採用し,多言語に対応していくようになりました。

Unicodeを採用し多言語対応を前提に作成されたソフトウェアの場合,表示するメッセージは簡単に差し替えられるようになっているので,メッセージをそれぞれの言語に翻訳したメッセージカタログを用意するだけで新しい言語に対応することができます。そこにもはや「研究」の要素は無く,⁠日本語版」として独自のバージョンを用意する必要性も薄くなりました。⁠Knoppix日本語版」の開発終了も,このような時代の流れの反映でしょう。

著者プロフィール

こじまみつひろ

Plamo Linuxとりまとめ役。もともとは人類学的にハッカー文化を研究しようとしていたものの,いつの間にかミイラ取りがミイラになってOSSの世界にどっぷりと漬かってしまいました。最近は田舎に隠棲して半農半自営な生活をしながらソフトウェアと戯れています。

URLhttp://www.linet.gr.jp/~kojima/Plamo/index.html

コメント

コメントの記入