最近、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）という規格に落ちつきました。

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

一方、ひらがなやカタカナ、漢字を組み合わせて使う日本語の場合、文字の種類は膨大で1バイト＝256種ではとうてい足りません。そこで2バイト（2^16＝65536種）を用いて文字を区別することにして、1978年に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コードの符号化方式と呼ばれます。

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

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

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

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

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

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

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

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

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

Plamo LinuxとUnicode

前述のようにUnicodeは2000年代になって急速に普及したものの、当初はソフトウェアの内部処理用として利用され、画面表示やファイルシステム上の文字コードには、過去との互換性の観点からEUC-JPやShift-JIS等が使われ続けました。

しかしながらUnicodeが広く普及してくると、画面表示やファイルシステム上の文字コードもUnicode（の符号化形式の1つであるUTF-8）で統一してしまおう、という動きが出てきました。

たとえば画面表示やファイルシステム上の文字コードをEUC-JPにしていると、画面やファイルシステムとデータをやりとりするたびに内部用のUnicodeと外部用のEUC-JPを変換する必要があり、変換漏れがあると思わぬところで文字化けが生じてしまいます。

この問題は本連載の中で何度かとりあげたことがあるように、さまざまなソフトウェアで繰り返し発生しており、最近のPlamo Linux環境でも以下のような問題が見つかっています。

LibreOfficeからファイル名を日本語にしたファイルを印刷できない

LibreOfficeで"平成27年度予算案.ods"のようなファイル名の文書を作ると、編集や保存には問題ないのに、印刷しようとすると「プリンタを起動できませんでした」というエラーが表示され印刷できません。

この問題は恐らく、印刷システムであるCUPSが受け取るファイル名はUTF-8でなければならないのに、LibreOfficeがプリンタにファイルを送る際、ファイル名をEUC-JPからUTF-8に変換し忘れていることが原因でしょう。

ファイル名を英数字のみにしておけば問題ないし、いったんPDFにexportしてやれば印刷できるのでそう致命的な問題ではないものの、つい忘れて印刷しようとした際に「あれれ？」となることがよくあります。

FirefoxがUTF-8で「ダウンロード」という名前のディレクトリを作ろうとする

Firefoxはファイルをダウンロードする際の保存先として、ホームディレクトリに「ダウンロード」という名前のディレクトリを用意するものの、「⁠ダウンロード」という名前をUTF-8で作成してしまうため、EUC-JPな環境から見ると文字化けしてしまいます。

ダウンロードしたファイルのファイル名はEUC-JPになりますが、同じ名前をUTF-8で表わした空のファイルができたりもするので、ダウンロードしたファイルをファイルシステムに書き込む手順のどこかに文字コード変換の見落しがあるようです。

VLC-2.xがEUC-JPなファイルを読めない

VLC-1.xはビルド時の設定で「非UTF-8なファイルシステムに対応する」というオプションが用意されていて、そのオプションを指定してビルドすればEUC-JPな日本語ファイル名を読めていました。しかしこの機能は、VLC-2.0にバージョンアップした際に削除され、最近のVLCではUTF-8以外のファイル名は読めなくなってしまいました。

mplayerベースのSMPlayerではEUC-JPなファイル名も読めるし、VLCでもDolphin等のファイラーからアプリを指定して起動すれば再生できるのでそう困るわけではないものの、以前は使えていた機能がバージョンアップによって使えなくなったのは気にくわないところです。

これらの問題（VLCの場合は「仕様」ですが）は、ソフトウェアのどこかで内部用のUnicodeとロケールで指定されるファイルシステム用の文字コードの変換作業を忘れていることが原因でしょう。

この種の変換漏れは多言語化におけるバグだと思ってはいるものの、ファイルシステムの文字コードをUnicode（UTF-8）にしていると変換漏れがあっても露見しないため直りそうな気配がありませんし、最近では自分でソースコードを追いかけて修正するのも億劫になってきました。そこで、Plamo LinuxでロケールをUTF-8にするにはどれくらい修正が必要か、またその場合どのような問題が生じるかを調べてみることにしました。