SLザウルス上の日本語ファイル名



@はじめに

 SLザウルス上で日本語名のファイル/ディレクトリを扱うにあたっては、いくつかの問題があります。


 まず、一つめの問題は、標準の GUI 環境である Qtopia と、コンソール上での日本語ファイル名の取り扱い方が一致していないと言うことです。
 これは、基本的にコンソールが旧来の UNIX 環境に準拠しているためであり、実質的に SLザウルスの上で複数の環境が混在していることによる弊害と言えます。


 さらに、問題を複雑にしているのは、これは何も SLザウルスに限った話では無いのですが、ファイルシステム上のファイル/ディレクトリ名と、内部の実データの文字コードが必ずしも一致しないと言うことです。
 
 SLザウルスでは通常、日本語のファイル/ディレクトリ名は、一律に UTF-8 の文字コードでマウントされています。しかし、これはファイルの内容にまで及ぶものではありません。
 その為、コンソール上でファイル名は正常に表示されているのに、ファイルの中身を表示してみると文字化けを起こしたり、逆にファイルそのものは正常であってもコマンドラインからファイル名が識別出来ないと言った事態がまま発生します。

文字コードの不整合による文字化けの例 文字コードの不整合による文字化けの例

 こういった状況は、往々にして Windows 等の他機種で作成したテキスト文書を表示・編集しようとした場合等に発生します。
 ただし、これに関してはあくまでもデータ形式の問題であり、どちらかと言えばアプリケーションレベルに於いて処理すべき問題とも言えます。


 これらを踏まえた上で、このページでは Qtopia 、コンソール、それぞれの環境での日本語名のファイル/ディレクトリの取り扱いについてまとめてみることにします。

 

@日本語文字コードの種別

 SLザウルスで日本語を扱う際、直接的に関わってくる日本語文字コードは、概ね以下のようなものになると思われます。

・UTF-8
 Qtopia が標準で用いる文字コードです。
 Qtopia 上の標準アプリケーション(メモ帳等)や、ファイルタブで作成した日本語のファイル/ディレクトリ名には全て UTF-8 が用いられます。


・EUC
 Extended UNIX Code の名の通り、 Linux(UNIX) 環境で広くに用いられている文字コードです。
 これまでの UNIX 上で一般的に使われていたこともあり、コンソールベースで日本語を扱う際には、他の文字コードと比して使われる場面が多く、実際トラブルも少ないようです。


・Shift-JIS
 Windows 等で一般的に用いられている文字コードです。
 そのこともあって、比較的取り扱う機会の多い文字コードの一つです。


 この他にも、日本語文字コードはまだいくつも存在します。

 ただし、 SLザウルスでは Windows 上でフォーマットされたメモリカード等、 VFAT の領域に UTF-8 以外の文字コードを用いた日本語名のファイル/ディレクトリを作成することは出来ません。
 逆に言えば、本体内や、あらかじめ EXT2/3で領域を確保したストレージ等を用意した上で”意図的に”文字コードを指定して作成したりしない限り、 SLザウルスのファイルシステム上に UTF-8 以外の文字コードで日本語名のファイル/ディレクトリが存在することはありません。

 SLザウルスでは UTF-8 以外の文字コードは、基本的にはあくまでもファイル内部の文字コードとしてのみ存在すると言うことになります。



@標準 GUI 環境 Qtopia での日本語ファイル名の取り扱い

 Qtopia から扱われるファイルシステムでは、基本的に日本語のファイル名やディレクトリ名の文字コードは UTF-8 で統一されています。
 仮に、別の文字コードを用いた日本語名のファイル/ディレクトリが存在する場合はシステムによって隠蔽され、Qtopia 上からは見えなくなります。

 Qtopia 環境に於いては、そもそもが基本的な操作自体を全て GUI で行っているわけでもありますし、日本語ファイル名の取り扱いについて意識しなければならない場面と言うのは殆ど無いかと思われます。



@コンソール上での日本語ファイル名の表示

 コンソール上に於いて、日本語名ファイル/ディレクトリ名を取り扱うにあたっては、当然ですが、まず「日本語が表示出来る」と言うのが大前提となります。

 コンソールでの日本語表示の可否については、使用するコンソール本体の機能に依存します。

 標準のコンソール(ターミナル)でも日本語の表示自体は不可能ではないのですが、扱える日本語コードは EUC 固定となっています。
 しかし、前述の通り、標準 GUI 環境 Qtopia のファイルタブやメモ帳等で作成した日本語名のファイルやディレクトリの文字コードは UTF-8 を用いています。そのため SHARP 純正のターミナルではこれらの日本語ファイル名を見ることが出来ません。な、なんだかなぁ(^^;)。

 そこで、コンソール環境でそれらの日本語ファイル名を取り扱うにあたっては、 UTF-8 の日本語表示が可能なコンソールを別途用意してやる必要があります。

 現在の所、私が確認している UTF-8 の日本語表示に対応したコンソールには、以下のようなものがあります。

いとしのliza [きむらかずしさんのページ
qpe-embeddedkonsole-ja_1.6.0-jinput3_arm.ipk
qpe-embeddedkonsole-ja_1.6.0-wide3_arm.ipk

SL-C700 の お部屋 [川島 俊之(TOS)さんのページ
opie-terminal-ja_1.0.2_arm.ipk

 これらのコンソール上では「Fn+Q」を押すと表示されるメニューから Charset の指定を行うことにより、任意の文字コードの日本語表示が可能です。

qpe-embeddedkonsole-ja_1.6.0-wide3 opie-terminal-ja_1.0.2




@コンソール上での日本語入力

 コンソール上で日本語名のファイル/ディレクトリを操作するためには、これも当たり前のことですが、「日本語を入力」する必要があります。

 コンソールで日本語を入力するためには、ホームディレクトリ(/home/zaurus/)に以下の内容のファイル .inputrc を作成します。

--------------------------------------------------------------------------------------------------
# /home/zaurus/.inputrc
 set convert-meta off
 set meta-flag on
 set output-meta on
--------------------------------------------------------------------------------------------------

 これによって、コンソールで日本語を入力することが出来るようになります。

 一応、パッケージも用意しておきましたので、よろしければご利用下さい。


 qpe-embeddedkonsole-ja_1.6.0-jinput3_arm.ipkopie-terminal-ja_1.0.2_arm.ipk では、ウィンドウの最下段に日本語入力欄が用意されており、これを用いることで標準の IME での日本語入力が可能です。

 ちなみに、日本語入力欄を持たないコンソール、標準のターミナルや qpe-embeddedkonsole-ja_1.6.0-wide3_arm.ipk での日本語入力は、 SIP (ソフトウェアキーボード)経由のみとなります。


 なお、この日本語入力の設定は、正確にはコンソールやシェルに対してのものでは無く、 GNU readline に対するものです。
 readline はその名の通り、コマンドラインの文字列入力を取り持つモジュールです。
 りなざう標準のログインシェルである /bin/bash はこの readline の機能を利用しているため、このモジュールに対する設定を適切に行ってやることにより、日本語の入力が可能となるのです。
 逆に readline モジュールを使用していない /bin/sh 等をログインシェルに指定した場合は、日本語入力は出来ませんので注意して下さい。

 なお、シェルに引き渡される日本語文字コードは、コンソールの Charset 設定に従います。
 Charset の設定が UTF-8 であれば UTF-8 で、 EUC であれば EUCで入力内容が引き渡されます。

UTF-8の場合 EUCの場合



@日本語に対応したアプリケーション


・nkf(Network Kanji Filter)

・FD Clone

・その他、エディタ等



@補則 LOCALE(ロケール)について

 単純に日本語の入力・表示だけを考えるのであれば、以降の設定は必須ではありません。

 ただし、それはあくまでも使用しているアプリケーション=ユーザーレベルで、明示的に使用するコードを指定することが可能であると言うことに過ぎません。これらの設定は、システム全体がどの言語で、どのコードを用いているかを特定させるものでは無いのです。

 それを特定するために存在する機構が、 LOCALE(ロケール)です。

 LOCALE に対応したアプリケーションは、規定の環境変数を参照することによって、システムで使用されている言語・文字コードを特定します。
 厳密に言えば、アプリケーション側の LOCALE の実装には対応するライブラリ等が用意されていることが前提になります。

 とは言え、単純に現在のシステム上の言語・文字コードを特定するだけであれば、以下の環境変数を設定するだけでも事足ります。

 LOCALE で規定されている環境変数は以下の 6つです。


 また、上記のカテゴリをまとめて設定するものとして、


があります。

 LC_ALL は上記の 6種を一括して指定します。
 逆に LANGLC_COLLATE〜TIME が設定されていない場合にデフォルトとして用いられます。

 また、これらとは別に、言語の設定でよく用いられている環境変数として LANGUAGE があります。
 これは元々、 GNU gettext 独自のものであり、本来は GNU gettext のみが参照するものでした。
 ただし、それは同時に gettext を用いているアプリケーション全てに影響を及ぼす環境変数であるとも言えます。
 さらに、実際問題として gettext を用いたアプリケーションが広く使われていることから、gettext と関係無くとも、使用する言語の特定に用いるアプリケーションも出てきたようです(マテ)。


 これら LOCALE の実装については、あくまでも指針であり最終的な実装はアプリケーション側に任されています。また、システムによっては前述のライブラリの整備が行き届いていない場合も多く、現実問題としてはまだまだ一般化には至っていません(涙)。

 とは言え LC_ALLLANGUAGE あたりは設定しておいても良いかと思います。
 LOCALE に基づいて、これらの設定を参照する場合、 LC_ALLLANG よりも優先されるため、最低限これだけでも設定しておけば問題は無い筈です。

 これらの環境変数の設定はホームディレクトリ(/home/zaurus/)の .bashrc 等で設定します。


--------------------------------------------------------------------------------------------------
#/home/zaurus/.bashrc

 LANGUAGE=ja_JP.UTF-8;export LANGUAGE
 LC_ALL=ja_JP.UTF-8;export LC_ALL
   |
  以下略
--------------------------------------------------------------------------------------------------

 なお、りなざうのデフォルトでは LANG=ja のみが設定されています。そういう意味でも、LANG の設定は変えずに残したままにしておくので良いかもしれません。
 ちなみに、この設定の意味は、日本語使うけど、文字コードまでは特定しないよん。ってなくらいのモンですか。
 ・・・正直、 Qtopia が UTF-8 で走ってること考えると、いっそ

--------------------------------------------------------------------------------------------------
LANGUAGE=ja_JP.UTF-8
LANG=ja_JP.UTF-8
LC_ALL=ja_JP.UTF-8
--------------------------------------------------------------------------------------------------

にしちゃっても良いかとも思うんですが・・・。

 逆にコンソールベースで考えて、比較的問題の少ない既存の EUC 環境を優先させたいと言うのなら、やはり

--------------------------------------------------------------------------------------------------
LANGUAGE=ja_JP.eucJP
LANG=ja_JP.eucJP
LC_ALL=ja_JP.eucJP
--------------------------------------------------------------------------------------------------

にするべきかと。

 なんか、このへんどっちつかずになっちゃってる感がありますな。


 つか、LOCALE に関する資料見てるとこんな記述も・・・。

--------------------------------------------------------------------------------------------------
glibc-2.2 はマルチバイトのロケール、特に上記で作成された UTF-8 ロケール をサポートします。
ですが glibc-2.1 や glibc-2.1.1 は実際にはマルチバイト をサポートしません。
   |
  中 略
   |
ここで述べた全てのことは、glibc-2.2 が出ればもはや必要なくなります。 
--------------------------------------------------------------------------------------------------

 ふむむ?。えーと・・・、

--------------------------------------------------------------------------------------------------
$ ls -la /lib/libc*

-rwxrwxr-x    1 root     root      1152468 Jun 23  2004 /lib/libc-2.2.2.so
lrwxrwxrwx    1 root     root           13 Feb 14 14:57 /lib/libc.so.6 -> libc-2.2.2.so
   |
  後 略
--------------------------------------------------------------------------------------------------
 でも、 /usr/lib/locale や /usr/share/locale はやっぱり用意されてなかったり・・・。

 ・・・ちゃんと LOCALE 使おうよ(涙)。


参考ページ

and Special Thx for Takashi SHIRAI!! (^^)


このページの文責: TAKETYON

Return to home