[電脳] [Debian] [人文系ペンギン使いの憂愁] ロケールの変更ならびに mlterm の設定など

みなさんおばんです、偽ロシア人アレクサーンドル・ニコラーイェヴィチ・スローニンことナカムリャーコフであります。

昨日ようやく賃仕事先での夏期講習の前半戦が終わって一息がつけたので、懸案だったロケールの utf-8 化を行った。論文執筆や賃仕事先での授業で配布するプリントを作成する際に使っている Emacs や ptetex はすでに数ヶ月前から内部コードを utf-8 にしたものを使っているので、ロケールを euc のままにしている理由がなくなった。また、友人や知人からいただく DVD のファイルシステムが UDF を採用しているものが多く、ロケールを euc のままにしているといろいろ不便を起こすようになってきたということもある。ただ、普段酷使するアプリケーションの大半は utf-8 がデフォルトになっているとは言え、普段使いのアカウントでのロケールを完全に utf-8 にすると、kterm で仮名漢字交じり文がきちんと表示されなくなってしまう。もちろん、mlterm を使えばそうした問題は解決されることは、数年前から知っていた。だが、mlterm のフォント設定はわたしには非常に複雑なものであり、これまで望み通りの設定を行えたことがなく、インストールはしてもずっと HDD の肥やしという状態だった。ターミナルエミュレータの乗り換えとそれに伴う諸々の設定が面倒臭いという理由で、これまで本格的にロケールの乗り換えに躊躇してきたのだ。だが、いいかげん mlterm の設定を何とかしてみようと思った（現実逃避の一環でもある（苦笑））。

ともあれ、普段使いのアカウントのロケールを utf-8 に変更する際に必要な作業は、次の通りである。

• ロケールの変更
• ホームディレクトリに置かれているシェルの設定ファイルの編集
• mlterm のフォント設定
• GNU screen の設定

ロケールの変更方法は Linux ディストリビューションによって流儀がかなり違うので、各自の環境に合った設定方法については検索エンジンなどで調べていただきたい。Debian lenny でのロケールの変更は、とても簡単である。以下のコマンドをお好きなターミナルエミュレータを用いて投入するだけで済む。ただし、いずれのコマンドも管理者権限で投入する必要があることは言うまでもない。

Debian lenny ではデフォルトのエンコーディングは utf-8 なのでロケールの再構築は特段必要ないとは思うが、万が一2つ目のコマンドから投入してみてうまくゆかない場合には、以下のコマンドを先に投入すると問題が解決されるかもしれない。

dpkg-reconfigure locales

上記のコマンドを投入する必要がない場合には、次のコマンドを管理者権限で投入する。

update-locale LANG=ja_JP.UTF-8

次は、ホームディレクトリに置かれているシェルの設定ファイルを編集する作業である。早い話が、環境変数LANG の値を変更する作業である。これについても普段用いているシェルによって設定方法が異なるので、各自検索されたい。以下の文言は bash 用のものである（しかも、Plamo linux を使っている頃から使い回しているものなので、Debian などをクリーンインストールされた方のものとはかなり異なったものになると思う。どうか適宜読み換えていただきたい）。

~/.bashrc の LANG の箇所を、LANG=ja_JP.euc-JP から LANG=ja_JP.UTF-8に書きかえた。ただし、その際にはターミナルの種類によって場合分けをするような設定にした。

# 端末によって日本語表示する/しないの切り替え
if [ "$TERM" = "linux" ] ; then
  LANG=C
else
   LANG=ja_JP.UTF-8
fi
export LANG

一度ログアウトをして再ログインして、mlterm の設定を行う。

mlterm のフォントの設定は、~/.mlterm/font ファイルの編集によって行う。

わたしは、次のような設定にした。ターミナルエミュレータはやはり昔ながらの等幅のビットマップフォントでの表示に限るということで、TrueType フォントは用いないことにした。

TCVN5712 = 14,-*-.vntime-*--14-*-iso8859-1;
ISO10646_UCS4_1 = -efont-fixed-medium-r-normal--%d-*-iso10646-1;13,
-misc-fixed-medium-r-normal--18-*-iso10646-1;13,
-gnu-unifont-medium-r-normal--*-iso10646-1;
ISO10646_UCS4_1_BIWIDTH = -efont-biwidth-medium-r-normal--%d-*-iso10646-1;13,
-misc-fixed-medium-r-normal-ja-13-*-iso10646-1;18,
-misc-fixed-medium-r-normal-ja-18-*-iso10646-1;

あと、mlterm を起動させて Ctrl キーを押さえながらマウスを右クリックして、mlterm の各種設定を行う（もちろん、~/.mlterm/main をエディタで編集しても構わない）。「エンコーディング」タブの「エンコーディング」は「UTF-8」を選択し、「Unicode経由でペーストを処理する」にチェックを入れる（その他のことがらについては、お好みの設定を各自楽しんでいただきたい）。一連の設定を済ませたら、「保存＆終了」をクリックし、mlterm を再起動させる。

この設定を行って、仮名漢字交じり文が lv コマンドなどできちんと表示されるか確認されたい。わたしの場合は、チェコ語などで用いられている補助記号付きのラテン文字（例えば、「アントニーン・ドヴォジャーク Antonín Dvořák」の「í」や「á」や「ř」など）やロシア語などで用いられるキリル文字も表示されないと使いものにはならないので、w3m で新聞サイトなどを表示させてみた。リンク先のこの画像やこんな画像やこんな画像などを参照されたい。

次に行うのは、GNU screen の設定である（GNU screen が何のことか分からない方は、Google などで検索されたい）。これについても、非常に簡単に設定できる。~/.screenrc へ次のように書き込む。

# 使用する漢字コード: utf-8
defencoding utf-8
encoding utf-8 utf-8

これで、最低限の設定が済んだ。

追記（2009/08/11）: ロケールをutf-8 に変更したところ、ptetex （utf-8対応）一式とともにビルドした xdvi で一つ一つのページをマウスでクリックして閲覧することができなくなってしまった。キーボード操作でページの移動は問題なくできた。根本的な原因はよく分からないが、とりあえず

LANG=ja_JP.euc-JP xdvi &

として起動させてみたところ、これまで通りそれぞれのページをマウスでクリックして閲覧することができるようになった。というわけで、.emacs の野鳥周りの xdvi に関わる設定も次のように書き直して使っている。

(setq dvi2-command "LANG=ja_JP.euc-JP xdvi")

追記2（2009/09/02）: また、ロケールを変更してから、opera で仮名漢字交じり文を入力することができなくなってしまった。6-7年前からひたすら opera を愛用してきたので（firefox も性能が上がってきているので決して悪くはないのだが、あの軽快な動作と変態的なインターフェイスに慣らされてしまったので、今さら捨てがたいのだ）、これはさすがに痛い。確かに、qt をベースとしたアプリケーションと GTK+2 アプリとの相性は昔から悪いということはいろんなところで聞かされてきたことながら、opera で日本語入力を円滑に行うためだけにあの馬鹿みたいに重い上に多言語周りの対応がドンクサイ KDE 一式を入れるというのもあまり賢い解決策とは思えない（昔は中欧あたりにたくさんいるような大柄美人――なんやそれと言われてしまいそうですが……――を彷彿とさせるデザインに結構惹かれて KDE を愛用していたのだが、xfce4 に乗り換えてからはすっかりこちらの方が気に入ってしまい、KDE を使う気が完全になくなってしまった）。こちらに関しても、どなたか原因と対策についてご存じの方はいらっしゃらないだろうか。ちなみに、xfce4 のxinitrc には

XMODIFIERS="@im=uim"
export XMODIFIERS

という行を記してみた。これを入力したのちに X から一度抜けて再ログインした直後には、Opera で漢字仮名交じり文を入力できるようになった。だが、すぐに Opera がフリーズしてしまった。そののちに Opera を再起動してみると、uim-skk を起動させることさえできなくなった。こうしたことが続くようだったら、やはり X Window System の下でウェブブラウザを用いる際には firefox 一本に絞った方が時間の節約のためにも良いのかもしれない。（Opera 10 の Windows 版は linux 版のものよりも動作が機敏な感じがする上に、件の問題が起きないのは言うまでもない。という訳で、どうしてもこれまで通り Opera や Skype が使いたければエミュレータかもしくはノートPCの Windows 環境でバリバリ動かすというのが無難なのかもしれない（溜息）。）

ともあれ、こうしたことが起きる原因と対策について何か少しでもご教示していただけると、はなはだ幸いである。

さらに追記（2009/09/12）: 結局、qt4版のテスト版（deb ファイルではなく古式ゆかしき tarball）に入れ直して、上記の設定ファイルを使わないようにしてから再ログインしてみたところ、従来通り普通に漢字仮名交じり文を入力できるようになった。なんだかんだ言っておぺらたん(´Д｀；)ハアハアOpera派なので、ひとまず助かった。

――まったくもって訳が分からない。おやすみなさい……。