武藤＠Debianぷろじぇくとです。
「Sargeをインストールしたらコンソールで日本語が出ない/化ける」というの
を各所で見かけているので、想定質問への回答という形のサマリを投げておき
ます。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
Q. コンソールでなぜ日本語が化けるの？
A. Linuxの標準コンソールでは日本語を表示することはできないからです。
Q. なら、なぜインストーラでは日本語出ていたの？
A. これは、jfbtermというフレームバッファ上で動作する各国語対応端末アプ
リケーションを起動してその上で表示していたからです。似たような日本
語対応のアプリケーションとしてはkonがあります(konはフレームバッファ
の必要はありません)。
Q. なんでインストーラが終わったあともjfbtermを動かしたままにしておかな
いの？
A. jfbtermは「アプリケーション」です。欧米やキリル語圏ではコンソール表
示に動的にパッチを当てることでその言語文字を表示できますが、日本語
(ほか中国語韓国語(いわゆるCJK)など)はこのやり方はできません。unicon
というカーネルへのパッチもあるのですが、メンテナンスされていないこ
と、日本語固有になってしまうこと、カーネルが大きくなることを考える
と採用される見込みはありません。
アプリケーションの場合、起動の手順が障害になります。日本語表示をす
るためにはどこかでアプリケーションを起動して、以降の処理をこのアプ
リケーションの中で表示するようにしなければいけませんが、それを綺麗
に実現する方法が思いつきません。
そして、X Window Systemはコンソールチェックをしているため、
端末デバイス名の変わるjfbtermの中から一般ユーザーがこれを起動するこ
とはできません。
それから、「インストールが終わったらいじったコンソール状態は元のコ
ンソールに戻すべきだ」という意見があり、しばらく議論になっていまし
た(現状はどの言語でも「元の英語(ISO8859-1)コンソール」に戻るように
なっています)。
Q. つーか、なんで標準で全部日本語なの？
A. 全体の環境変数を司る/etc/environmentファイルにインストーラから導出
したLANG環境変数、値ja_JP.EUC-JPが記述されているからです。
メリットはユーザーが個々にLANGを設定しなくても日本語が使われる
ことです。X Window Systemを使うときにはこちらのほうが便利でしょう。
デメリットは文字を表示できるできないに関わらず日本語が使われること
です。つまり、Linuxの標準コンソールでも日本語が使われてしまいます。
LANG=Cに変更するかこの行を消せば、英語が標準になります(ユーザーは各
自の設定でLANG=ja_JP.EUC-JPを設定する)。
Q. 条件判定とかできないの？
A. 誰か良いアイデアを持っていて、コードを書けて、対象となるパッケージ
メンテナを説得しようという人はいませんか？
私が考えたのは、少なくともrootでttyがコンソールの場合にLANG=Cを使う
のはどうか、というものでしたが、「それは解決じゃなくてハックなので
ダメ」と却下されました。このメンテナの意見は理解できます。
小汚い手を使わずスマートにをモットーに、かつ欧米圏では問題の本当の
理解は困難だし別に必要としてない、と厳しい条件下にあります。ちなみに
「日本語の場合には特別にja_JP.EUC-JPを設定せず、デフォルト値をCにし
てしまえ」というのには私はその後のデスクトップの利便性の面で賛同し
かねます。多分コードも汚くなるのでよくない。
Q. それはさておき、set-language-envで設定しようとしたらjfbtermが
/dev/fb0を開けないといって起動しないんだけど？
A. jfbtermはフレームバッファを必要としますが、i386系ではフレームバッファ
はモジュール化されており、このモジュールを登録しないと利用できませ
ん。インストーラではvesafb、vga16fbの順に試行して登録しています。カー
ネル2.6を使っている場合にはさらにfbconが必要です。
一度再起動すると、このモジュール登録が自動的には行われないため、
jfbtermの起動ができないことになります。
modprobe -q vesafb || modprobe -q vga16fb
を実行してみてください(もっと適切なフレームバッファモジュールがある
ことを知っているなら、それを登録するのもよいでしょう)。さらに、
linux26(カーネル2.6)でインストールしていた場合には
modprobe -q fbcon
も必要です。
これで、フレームバッファデバイス/dev/fb0が利用できるようになり
(/proc/fbを参照)、language-envからjfbtermを起動できます。
Q. なんでlanguage-envの中でフレームバッファ登録まで処理しないの？
A. フレームバッファドライバはアーキテクチャ固有であり、language-envで
やることではないと思います。
Q. jfbtermを単独で起動するとなんかいっぱいログが出てくる上に化けるよう
な？
A. unifontフォントパッケージしか入っていない場合には、現在のEUC-JPか
らUTF-8に内部変換する必要があります。また、標準では冗長なログが出る
ので、これをオプションで黙らせるようにします。一般的な書式は次のと
おりです。
jfbterm -q -c other,EUC-JP,iconv,UTF-8
(dpkg-reconfigure localesで作ったあとLANGにja_JP.UTF-8を設定すれば、
-c以降のオプションなしに表現することもできます)
Q. モジュールの登録からjfbtermの起動までメンドクサすぎるのですが…
A. Debian的に完全な解決ではありませんが、
http://kmuto.jp/debian/tettei/pool/main/jconsolewrapper_1.4_all.deb
というのを用意してみました。これをdpkg -iでインストールしておき、
jc[Enter]
とするとモジュールの登録〜日本語コンソールになります。exitで終わります。
前述したように、一般ユーザーがこの中からX Window Systemを起動するこ
とはできないことに注意してください。
Q. 今後何か改善の見込みは？
A. Sargeでは現状のこれで行く予定です。これでは不便だと思う方は改善案を
debian-boot@lists.debian.org(英語)で議論頂けると幸いです。ただ、来
月にはファイナルイメージを出すので、Sargeに向けての大きな変更は却下
される可能性が大です(おそらくEtch以降ということになるでしょう)。
私の考えでは、アプリケーションではなくconsole-commonのようにコンソー
ルに直接作用するような形でマルチバイト文字をいじる機構がないとどう
にも抜本的な改善は図れないのではないかと思います。Unicodeフォントを
全部カーネルにつっこむのはナンセンスですから、カーネル側ではそういう
文字を許容する仕組みを持ちつつ(すでに大丈夫だったりするのかな？)、
うまくディスクからフォントファイルをひっぱって画面に表示するという
デザインです。思いつきにすぎず、実現の可能性があるのかすらわかりま
せんが。
--
武藤 健志＠ kmuto @ kmuto.jp
Debian/JPプロジェクト (kmuto@debian.org, kmuto@debian.or.jp)
株式会社トップスタジオ (kmuto@xxxxxxxxxxxxxxx)
URI: http://www.topstudio.co.jp/~kmuto/ (Debianな話題など)
Attachment:
pgpaGZK9KGIZc.pgp
Description: PGP signature