サーバOS変更と文字コードについて

以前書いたとおり、我が家でファイルサーバ・IMAPサーバとして使っているOSをPlamo Linux 4.2.1からDebian GNU/Linux 4.0に変更しました。


懸念事項として、Plamo Linux 4.2.1からDebian GNU/Linux 4.0の変更に伴い、日本語ファイル名やフォルダ名の文字コードに変更があったことです。
EUC-JPからUTF-8になりました。

2007年7月31日現在においては、保存される日本語ファイル名はPlamo Linux 4.2.1の環境で使用していたEUC-JPとなっています。
その環境で、クライアントで文字化けしないようにするための文字コードの変換作業については下記のとおりとなっています。
多分。

NFSでSambaと同様に文字コードの変換って出来ないのでしょうか？
「[linux-users:99504] NFSサーバーでEUCをShift-JISに変換してエクスポートできますか？」を読んだ感じでは出来なさそうですが・・・。
ちょっと調べてみたいです。

また、OSのデフォルトの文字コードが変わることによりどこまで影響が出るのか分かっていないので、こちらもちびちび調べたいと思います。

文字コード調査(テキトー)

Debian GNU/Linuxの文字コードがUTF-8のようですので、勉強のためにうちのシステムの文字コードについて調べてみました。

よく分からずにテキトーにやってます。

以下の記述は私のテキトーな調査を基に記述しています。
けっして信じないでください。


日本語名のフォルダを作成してみます。
以下のフォルダ作成は、Vine Linux 4.1のGNOMEターミナルエディタからDebian GNU/Linux 4.0にtelnet接続して行いました。

$ mkdir UTFです      <-- GNOMEターミナルをUTF8に設定し、
                      フォルダ"UTFです"を作成

$ mkdir EUC鐃叔わ申  <-- GNOMEターミナルをEUC-JPに設定し、
                      フォルダ"EUCです"を作成
                      (入力中に文字化けします)

$ ls                 <-- GNOMEターミナルをEUC-JPに設定
                 (日本語名のフォルダは全て文字化けしてしまいます)
??能??  Comic_etc  EUC?任?  Game  HONDA  KOUSHIEN  TV_Cinema  
UTF�с™  WallPaper  WallPaper2  Web 

$ ls                 <-- GNOMEターミナルをUTF8に設定 
                 (UTF-8の日本語名のフォルダだけ正常に表示されます)
??ǽ??  Comic_etc  EUC?Ǥ?  Game  HONDA  KOUSHIEN  TV_Cinema  
UTFです  WallPaper  WallPaper2  Web

ここまででフォルダなどを作成したところをVine Linux 4.1のKonquerorで参照したのが下記です。
Vine Linux 4.1の文字コードはEUC-JPです。

日本語のフォルダ名がついているのは下記の3つです。
芸能人・・・Debian GNU/Linux (UTF-8の環境)に変更する以前から作成してあったフォルダ名EUC-JPのフォルダ

UTFです・・・上でGNOMEターミナルをUTF-8に設定した後に作成したフォルダ(化けてます)

EUCです・・・上でGNOMEターミナルをEUC-JPに設定した後に作成したフォルダ

GNOMEターミナルをUTF-8にして入力したフォルダ名はUTF-8で、GNOMEターミナルをEUC-JPにして入力したフォルダ名はEUC-JPで保存されていると思われます。


自分で作ったファイル名/フォルダ名の文字コードを調べるスクリプト(信頼性0)で調べると次のようになりました。

��ǽ�� (Directory)->
   EUC-JP               <-- 狙い通り！
Comic_etc (Directory)->
   ASCII
EUC�Ǥ� (Directory)->
   EUC-JP               <-- 狙い通り！
Game (Directory)->
   ASCII
HONDA (Directory)->
   ASCII
KOUSHIEN (Directory)->
   ASCII
TV_Cinema (Directory)->
   ASCII
UTFです (Directory)->
   UTF-8               <-- 狙い通り！
WallPaper (Directory)->
   ASCII
WallPaper2 (Directory)->
   ASCII
Web (Directory)->
   ASCII

一応私の意図通りになっているようです。
(フォルダ名のエンコードもスクリプトの動作も)
繰り返しますが、信頼性0です。

ちなみにスクリプトの中身はこうです。
信頼性0です。
私はシェルスクリプトなんて作ったことろくにありません。
よく分かりません。
(というか、誰か教えて・・・)

中でnkfを--guessオプションをつけて使用しています。
おそらくnkf 2.0.4以降が必要だと思います。

#!/bin/sh

error_flag=1    # Initial valuable (ERROR)

for name in *; do
    if [ -L "$name" ];then
        # Symbolic link
        type="Symbolic link"
        error_flag=1
    elif [ -d "$name" ]; then
        # directory
        type="Directory"
        error_flag=0    # success
    elif [ -f "$name" ]; then
        # file
        type="File"
        error_flag=0    # success
    else
        # unknown
        type="Unknown type"
        error_flag=1    # error
    fi

    if [ $error_flag = 0 ]; then
        echo "$name ($type)->"
        echo -n "    "
        echo -n "$name" | nkf -guess
    else
        echo "$name ($type)"
    fi
done

exit 0

UTF-8によるscreen文字化け

家内ネットワークのファイル/IMAPサーバとして使いはじめたDebian GNU/Linux 4.0の日本語環境はデフォルトがUTF-8みたいです。

xxx@julie:~$ echo $LANG
ja_JP.UTF-8

ついにうちにもUTF-8の環境が出来てしまったみたいです。


で、EUC-JPのVine Linux 4.1からtelnetでDebian GNU/Linux 4.0にアクセスした際に文字化けする現象が発生していました。
(後述しますが、私の設定の問題です。)


次のような文字化けの現象が発生していました。

・KDEのKonsole(以下Konsole)の「設定」ー「エンコーディング」をutf8にしても文字化けが解消されない
・GNU Screen(以下screen)を使用していない状態でKDEのKonsoleの「設定」ー「エンコーディング」をutf8に変更すると文字化けしない


screenを使用せずにKonsoleをUTF-8の設定にすれば文字化けしないので、どうやらscreenの設定が悪いようです。
そういえば、.screenrcではろくに設定をしていませんでした。

escape ^L^L
hardstatus alwayslastline "screen |%c %m/%d | %w"

ネットで調べると.screenrcの設定例は色々見つかるのですが、自分の場合は少しずつ設定を追加していこうかと思っています。


screenのマニュアルを調べたところ、次のような対策があるみたいです。
もちろん他にもあるとは思いますが、私が簡単に見つけられた方法の中で手軽だと思ったのが下記の2つでした。
Konsoleのエンコーディングはutf8に変更することが前提です。

(1) "-U"オプションをつけて起動する
screenのマニュアルには次のようにあります。

-U   UTF-8 モードで screen を動作させる。
     このオプションは、ユーザの端末が UTF-8 エンコードされた
     文字を理解し、また送信してくることをscreenに伝える。
     また新規ウィンドウのデフォルトエンコーディングが
     `utf8' になる。

(2) screenのコマンドモードでutf8コマンドを使用する

utf8 [on|off [on|off]]
     現在のウィンドウが用いるエンコーディングを変更する。
     utf8 を on にすると、ウィンドウに送られる文字列は
     UTF-8 エンコードされる (逆も同じ)。 パラメータを
     省略すると状態をトグルする。二つ目のパラメータを
     与えると、ディスプレイのエンコーディングも同時に
     変更される (これは screen の "-U"オプションで
     指定するほうが良いが)。 "defutf8" も参照のこと。
     これは新規に生成されるウィンドウのデフォルトを変更する。

うちの場合、デフォルトはVine Linux 4.1のEUC-JPで使用しているため、必要な時に(2)の方法を用いる(screenのコマンドモードに入り、"utf8 on on"というコマンドを使用してUTF-8に変更する)方がいい気がします。
多分。

Zaurusのnkfを新しくした

私がZaurusにいれていたnkfは、どうやらguessオプションに対応していないようです。
バージョンは次のとおりでした。

$ nkf --version
Network Kanji Filter Version 2.0 (3/0301/Shinji Kono)
Copyright (C) 1987, FUJITSU LTD. (I.Ichikawa),
    2000 S. Kono, COW, 2002-2003 Kono, Furukawa

そこでZaurusのnkfを新しくできないかと考え、前回書いたようにnkfを作成してみました。

nkfはこちらから2.0.8aをもらってきました。

とりあえず出来たバイナリ"nkf"をZaurus上にコピーしてそこにパスを通せば使えるようになりました。

$ nkf --version
Network Kanji Filter Version 2.0.8 (2007-07-09)
Copyright (C) 1987, FUJITSU LTD. (I.Ichikawa),2000 S. Kono, COW
Copyright (C) 2002-2007 Kono, Furukawa, Naruse, mastodon

$ nkf --guess code_test
EUC-JP

バッチリみたいです。


ちなみにnkfのguessオプションですが、nkf 2.0.4のChange Logに次の記述がありました。

nkf 2.0.4 からの仕様変更
1.--guess とすると、文字コードの判定結果を出力します。

2.0.4で追加されたのでしょうか？

ZaurusをSambaクライアントに

「ZaurusをNFSクライアントに」ではZaurus(SL-C3000)をNFSクライアントにしましたが問題がありました。

問題１
ファイル名の日本語が表示出来ていません。

以前Sambaサーバ上のファイル名はShift-JISにしました。
NFSサーバとして使用している場合にはEUC-JPになっているはずです。多分。

ZaurusではSambaとNFSの両方で日本語表示できないということは、ZaurusはShift-JISでもEUC-JPでもないということでしょうか？
もしかしてUTF-8？

問題２
1Gくらいあるフォルダを"cp -ar"でNFS領域にコピーしたのですが、途中でcpがデッドロックとやらになってしまい止まってしまいました。

ログ(syslog)とか見てみたのですが、参考になるようなログはみつかりませんでした。
この場合どのログをみればよかったのでしょうか？
デッドロックの問題は原因がつかめていません。
まだ設定が不足している箇所も多数あると思いますが・・・。


上記のような問題が発生しているのを避けるため、NFSではなくSambaを使用してJULIE(NFSサーバ兼Sambaサーバ)にアクセスしてみるのはどうかと考えました。
本来であればNFSの設定を見直すべきかもしれませんが。

NFSの文字コード指定ってあるのか分かりませんが、Sambaならあるのは以前確認済みですし、日本語表示もなんとかなるのではないかとほのかな期待を抱いてやってみることにします。

(1) Zaurus用smbmountを取得
こちらからsmbmount_0.1_arm.ipkを取得し、インストールしました。
(後ほど述べますが、ここでインストールしたsmbmount_0.1_arm.ipkはその後アンインストールしました)

(2) JULIE(Sambaサーバ)の領域をマウント

#sudo smbmount //julie/share /mnt/julie/
    -o username=xxx,ip=xxx.xxx.xxx.xxx

としてマウントしました。


(1)～(2)までで、とりあえずZaurusをSambaクライアントとして使用できるようになりました。
NFSを使用したときよりSambaを使っている方が動作が軽快な気がします。
(もちろんNFS設定をチューニングすればいいのかもしれません)

ところが、Zaurusのファイルマネージャではやはりファイル名の日本語表示が出来ていませんでした。

smbmountのオプションとしてcodepageとiocharsetがありますが、(1)でインストールしたsmbmount_0.1_arm.ipkでは対応していませんでした。

探してみたところcodepageとiocharsetのオプションに対応したsmbmountを配布されているサイトがありました。
こちらからsmbmount_2.2.8a-ja-1.0_arm.ipkをいただいてきてインストールし、次のようなコマンド引数でマウントしました。

sudo smbmount //julie/share /mnt/julie/
    -o fmask=666,username=xxx,ip=xxx.xxx.xxx.xxx,
       codepage=cp932,iocharset=utf8

結果、Sambaサーバ上の日本語ファイル名のファイルを、Zaurusのファイルマネージャで日本語表示出来るようになりました。



ちなみに、smbmountのオプションとして渡したiocharsetとcodepageは、Sambaのマニュアルには次のようにあります。

iocharset=<arg>
Linux 側のコードページ-文字コード変換 (NLS) で使用される文字コードを設定する。引数は iso8859-1 のようなキャラクタセットの名前でなくてはいけない。 (注: カーネル 2.4.0 以降のみサポートされる)


codepage=<arg>
サーバ側で使用される文字コードを指定する。 iocharset オプションを参照。例えば cp850 などである。 (注: カーネル 2.4.0 以降のみサポートされる)

私が行った設定の場合、iocharsetの説明中のLinuxとはZaurusを指し、codepageのサーバとはSambaサーバであるJULIE(Plamo Linux)を指します。

また、CP932はマイクロソフトのShift-JIS拡張らしいです。

Kontact(KMail)がutf-8になる

最近KDEを常用するようになり、Kontactも使用するようになりました。
Kontact 1.2.5です。



フィード(Akregator)はとてもいい感じです。
RSSは便利だなぁと、今さらながら思います。

登録しているサイトが更新されると、ちゃんとKDEパネルに表示されます。

拡大。
時計のとなりの"1"と出ているのがそうです。
新着一件ということです。



カレンダーはiCalフォーマットを使用してGoogleカレンダーを表示させています。
Googleカレンダーの更新は出来ませんので、表示させているだけですが。

Googleカレンダー側が他のアプリケーションでGoogleカレンダーを表示させた場合に読み取り専用にしかならないようです。
　　Googleヘルプセンター


メールの送受信はKontactからKMail 1.9.7を使用しています。
IMAPとPOP3のメールを取り込んでいます。

受信は特に問題は起きていないのですが、送信する際にメールがutf-8になってしまうという現象が発生しました。

ネットで検索してみたところ、KMailの設定で文字コードをiso-2022-jpを先頭に持ってくるとiso-2022-jpで送信できるようになるという情報がありましたので、そのようにしてみました。


が、やはりutf-8になってしまいます。


色々試してみたところ、うちでは現状次のような状況になってしまうようです。
以下の実験はすべて、「件名」を「テスト」、本文を「テストです」にしたメールを送信してみました。

・KontactからKMailを使用して文字コードを変えずに送信する
　→utf-8になる

　　Subject: =?utf-8?b?44OG44K544OI?=
　　Content-Type: text/plain;
　　  charset="utf-8"
　　Content-Transfer-Encoding: base64

・KDEメニューからKMailを立ち上げ(つまりKontactは起動しない)、文字コードを変えずに送信する
　→iso-2022-jpになる

　　Subject: =?iso-2022-jp?b?GyRCJUYlOSVIGyhC?=
　　Content-Type: text/plain;
　　  charset="iso-2022-jp"
　　Content-Transfer-Encoding: 7bit

・KontactからKMailを使用して送信する際に、「メール作成」画面で「オプション」メニューから「エンコーディングの設定」を選択し、iso-2022-jpを指定する。

→iso-2022-jpになる

　　Subject: =?iso-2022-jp?b?GyRCJUYlOSVIGyhC?=
　　Content-Type: text/plain;
　　  charset="iso-2022-jp"
　　Content-Transfer-Encoding: 7bit

送信する際に文字コードを指定すれば、今のところ問題は発生していないようです。


結果として、Kontact経由でKMailからメールを送信する場合、文字コードをiso-2022-jpに明示的に指定しないとutf-8になってしまうみたいです。

KMailやKontactの設定が悪いのでしょうか？

nkfでも文字コードって調べられるのですね

何か出来るオプションがあるはずだと思いつつ、調べもせずに放置していたのですが・・・。

nkfでもテキストファイルの文字コードを調べられるのですね。
今まではkcc -cでしかしたことありませんでした。

$ nkf --guess linux_print01.txt
EUC-JP

いや、お恥ずかしい。