[[diary/Kojima]]
・Plamo-5.3.1 をUTF-8環境で使う
Plamo Linuxでは、昔から LANG=ja_JP.eucJP にしていたのだけれど、
昨今のUTF-8化の風潮に抗うのも面倒になったので、LANG=ja_JP.UTF-8 で使う方法を調べてみた。
実のところ、最近の統合デスクトップ環境(Xfce/Mate/KDE)ではLANGを切り替えるだけで問題なくUTF-8で使える
(というか、UTF-8の方がちゃんと動く ;-)ので、コンソールは EUC-JP、Xを起動したら UTF-8 という折衷環境にしてみた。
- ~/.xinitrc の変更
X起動時の設定ファイル ~/.xinitrc で LANGとJLESSCHARSET, OUTPUT_CHARSET を ja_JP.UTF-8 に変更する。
それぞれ指定の仕方が違うので要注意
#LANG=ja_JP.eucJP
LANG=ja_JP.UTF-8
JLESSCHARSET=utf8
OUTPUT_CHARSET=UTF-8
export LANG JLESSCHARSET OUTPUT_CHARSET
OUTPUT_CHARSETってglibc2の古いバージョンのみで必要、と書いてあるのだけれど、試してみると、これを指定しないと mo ファイルのメッセージがちゃんと表示されない模様。
# これはむしろ /usr/share/locale/ja_JP** 回りの設定がマズいのかも知れない
- ~/.bashrc の変更
bash起動時に実行される ~/.bashrcにもLANGとJLESSCHARSETを指定している部分があるので、それをコメントアウトする。
# 端末によって日本語表示する/しないの切り替え
#if [ "$TERM" = "linux" ] ; then
# LANG=C
#else
# LANG=ja_JP.eucJP
#fi
#LANG=ja_JP.eucJP
#export LANG
# JISで表示できない端末はEUCにする
#if [ "$TERM" = "xterm" -o "$TERM" = "dtterm" ] ; then
# JLESSCHARSET=japanese-euc
#fi
とりあえずこれくらいで、コンソールでは /etc/profile で設定される
JLESSCHARSET=japanese-euc
...
OUTPUT_CHARSET=EUC-JP
LANG=ja_JP.eucJP
...
export JLESSCHARSET LESS JSERVER TZ OUTPUT_CHARSET LANG PKG_CONFIG_PATH
が実行されて ja_JP.eucJP 環境、X を起動すると~/.xinitrc でこれらの設定を上書きして ja_JP.UTF-8 で動作する模様。
- むしろ問題はファイルシステム上の日本語ファイル名で、ローカルにファイル名がEUC-JPなファイルを持っていると、ファイル名をUTF-8に変換してやらないと利用できない。ただ、手元だとその手のファイルはローカルではなくファイルサーバにまとめているので、マウント時にsambaを経由することで文字コードは自動的に変換できている。
# mount -t cifs //fileserver/public /public -o user=kojima,iocharset=utf8
NFSとsambaのパフォーマンスの違いまでは調べてないけど、MP3ファイルやmp4な動画を再生するレベルでは特に問題ない印象 -- [[kojima]] &new{2015-02-19 (木) 16:02:15};
- 当初は、smb.confで'dos charset' あたりをUTF-8にしなければいけないのかと思ってたんだけど、cifsモジュールあたりでCP932からUTF-8への変換をしてくれてる感じ。
Module Size Used by
nls_cp932 76865 0
arc4 1431 0
ecb 1421 0
md5 1325 1
hmac 1981 1
nls_utf8 932 3
cifs 216272 4
...
- UTF-8な環境だと、VLCとかmcomixとかも動くんだけど、Plamoのパッケージ管理ツール(installpkg2)でEUC-JP決め打ちでメッセージを出しているところがあるんで、updatepkg/removepkg するとメッセージが文字ばけするですね。実害はないと思うけど、きちんと対応するにはbashでgettextあたりを使わないといけない感じ。 -- [[kojima]] &new{2015-02-19 (木) 16:22:16};
- 当初は、sambaを使えば文字コードの変換は可能なものの、サーバレベルで文字コードを指定していたから、Windows用にcp932で提供するサーバと、UTF-8で提供するサーバを別に立てないといけないだろうな、と思っていたけど、cifs モジュールあたりでそのあたりを吸収してくれたので思ったよりも簡単だった。こうなるとむしろファイルシステムの文字コード変換機能が無いNFSの方に不満を感じるところ。まぁ、その分パフォーマンスはいいのだろうとは思うけど。 -- [[kojima]] &new{2015-02-19 (木) 19:29:53};
- emacsの設定ファイルは euc-jp を決め打ちしているところがあるけれど、むしろ
(set-locale-environment nil)
みたいに明示的には設定せず、EmacsがよきにはからうようにしてやればLANGなりlocaleなりの設定に合わせてくれる感じ。もちろん、他の set-terminal-coding-system とかもコメントアウトして無効化しておく。 -- [[kojima]] &new{2015-02-21 (土) 23:07:31};
- 手元でも emacs の euc-japan 関係の設定は全てコメントアウトしてますね :-) -- [[TenForward]] &new{2015-02-26 (木) 15:34:57};
- ざっくりと使った感じ、日本語のmanページがja_JP.eucJPになっているから文字化けするですね。あと ~ 以下の各種設定ファイルにも日本語でコメントが書いてあるから、emacsとかじゃないとちゃんと表示できない感じ。このあたりをまとめて修正するようなスクリプトでも書いてみるかな？ -- [[kojima]] &new{2015-02-26 (木) 23:07:16};
- でも、UTF-8環境にして何がうれしいか、と言われると、VLCとか kodi(xmbc)とか mcomix がちゃんとファイル名を読めるようになるぐらいだから、それほど大きなメリットも感じないところ(w まぁ、SQLite3を使うようなコードを書くときはUTF-8にしとく方が便利ではあるけれど、EUC-JPな環境でもそれ用にmate-terminalでもあげれば間に合ったので、必須ではない感じ。 -- [[kojima]] &new{2015-02-26 (木) 23:17:33};
- rubyとかpythonのイマドキツール系はUTF-8でないとツラいの多いですね。plamolinux.orgを生成してるoctopressもLANG=ja_JP.UTF-8 rake generateみたいにしてますし、開発系のもそういうの多いです。仕事でPlamoを使ってるとまあそれなりの割合でUTF-8でないとマズい環境はありますね。 -- [[TenForward]] &new{2015-03-11 (水) 15:02:51};
- あとfirefoxで日本語ファイル名のファイルを保存する際の問題、バグ報告は受け付けられたものの全く直る気配がないので結構不便ですw -- [[TenForward]] &new{2015-03-11 (水) 15:05:13};
- 手元では、
-- kojima2 なアカウントを作る
-- kojima2 の各種設定ファイルをUTF-8用に調整
-- /etc/passwd をいじって、kojima と kojima2 の UID を同じにする
-- run level4(GUIログイン)で起動
-- fast user switch(KDEなら ctrl+alt+F7|F8)で必要に応じてkojima(EUC-JP)とkojima2(UTF-8)を切り替える
みたいな感じにしてみた。-- [[kojima]] &new{2015-03-12 (木) 12:22:11};
- 私も今の所はUTF-8専用アカウント使ってsu -してますw -- [[TenForward]] &new{2015-03-15 (日) 02:25:43};
- 私は今の所はUTF-8専用アカウント使ってsu -してますw -- [[TenForward]] &new{2015-03-15 (日) 02:25:43};
#comment
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
