[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]
[webdav-jp:0798] Re: glibc への CodePage 932 追加について (Re: Apache 2.0.46 へのパッチ適用に付いて)
森山です。
At Tue, 8 Jul 2003 11:35:14 +0900,
ODAGIRI Koji さん:
> > > 1)OpenI18N に上記コードの標準化を依頼する
> > > 何だかんだ言っても、上記の変換テーブルは一種のデファクトスタンダードであり
> > > 標準化する価値はある
> > > →各種標準への準拠をうたっている Red Hat は取り込まざるを得ない
> > >
> > > 2)MIRACLE LINUX と Debian、あと Vine 辺りに取り込んでもらう。
> > > →日本市場における商品競争力維持のため、Red Hat も取り込まざるを得ない
>
> MIRACLE LINUXはもちろん取り込む予定ですので、お任せください。
よろしくお願いします。
たぶんディストリビューションに取り込むとなると、KDE / GNOME など
のデスクトップ環境での日本語ファイル名や、Linux Kernel の NLS の
変換との整合が取れていた方が良いと考えています。
個人的に調べた結果は次のとおりです。
KDE(Qt)
webdav-ja:0797 に書いたとおり
(テストは、ローマ数字などと、内田百間(日→月) で確認したの
みですが。)
Linux Kernel の NLS の変換と KDE(Qt) の変換
vfat を codepage=932,iocharset=euc-jp でマウントした場合、
ファイル名にローマ数字などが含まれているとファイルマネージャ
からファイルを開けないなどの不具合が発生します。
※ ごく簡単なテストしかしていませんが、次のようにする事で大
丈夫なようです。(Linux 2.4.18)
・linux/fs/nls_cp932.c での Unicode→cp932 の変換を、
Win32API の WideCharToMultiByte() の変換に合わせる。
・linux/fs/nls_euc-jp.c での cp932⇔eucJP-open の変換でロー
マ数字等は 13 区を使うようにする。
eucJP-ms の日本語ロケール名
試しに、ja_JP.eucJP-ms や js_JP.eucJP-open という名前が使
えるようにして、LANG=ja_JP.eucJP-ms などと設定。そして、KDE
を起動するという事をしてみましたが、KDE のファイルマネージャ
で日本語ファイル名を表示できませんでした。
Qt の文字コード変換を用いているソフトは、環境変数 LANG と、
UNICODEMAP_JP の両方の設定が必要ですが、eucJP-ms の日本語ロ
ケール名が新たに作られた場合には、UNICDOEMAP_JP の設定がなく
ても、eucJP-ms の変換が行えるようにする必要があるかもしれま
せん。
iconv() を使うソフトへの影響
mutt と iconv()
そのまま使えます。
libiconv, Glibc のパッチとも既存の sjis/euc-jp/iso-2022-jp
間の変換は従来通りですので影響ありません。
vim6 と cp932
現行の libiconv の cp932 の実装に依存して、sjis の代わりに
cp932 を設定する方法が Web で紹介されているのですが、cp932
を MS 互換に直すと、そのような設定では正しく変換できない文字
が出てきますので注意が必要です。
以下は現行のパッチの課題点です。
Glibc のパッチ
テストデータ、ロケール用のデータを作成してありません。
libiconv のパッチ
cp932.h で CP923.TXT の変換ではなく、SHIFTJIS.TXT の変換と
同一としている事に関するコメントが未削除。
iso-2022-jp との変換
libiconv のパッチでは、iso-2022-jp の Unicode→iso-2022-jp
の変換で FULLWIDTH TILDE を「〜」に変換できるように、多対 1
の変換を入れてあります。(「〜」以外の他の文字も同様です)
Glibc のパッチでは、そのような事はしていません。Glibc のパッ
チでは、cp932/eucJP-ms → iso-2022-jp の変換を正しく出来ませ
んので注意が必要となっています。
Unicode へ変換して文字列比較するなどの時に問題にならないよ
うに、「〜」を FULLWIDTH TILDE と対応付けするような MS 版の
iso-2022-jp も追加した方が、MS 系のエンコーディング変換と
JIS 系のエンコーディング変換を分けて考える事できて良いと個人
的には考えています。
MS 版の iso-2022-jp は、Windows コードページ 50220 互換の
変換を追加する事で実現できますが、変換表をどこから入手するの
かという問題があります。
Windows の日本語EUC (コードページ 51932) との変換
日本語版 Samba には日本語EUC として Windows コードページ
51932 相当の "EUC" と、eucJP-ms 相当の "EUC3" があります。
Sabam 的には、iconv() で cp51932 が使えると、日本語版
Samba で作成された "EUC" の日本語ファイル名をそのまま引き継
げるようになるので、便利だろうなと考えていたりします。
ただ、cp51932 を追加するとした場合、コードページ 50220
と同様に変換表をどこから持ってくるのかという問題があります。
日本語EUC の亜種が増えるのは、あまり良くないかもしれません。
> > > MIRACLE や Vine な方も eucJP-ms + Samba 3.0 な快適環境は如何ですか? ;->
>
> Samba3.0日本語版も早めに出すようがんばりましょう。
今やっている事は、日本語版を作るというよりも、Samba 3.0 のマルチ
バイト処理のバグ潰しをしているという事になると思います。
ある程度使えるようになったら、多くの人に使ってもらってバグ出しし
ていかないといけませんね。
‖ 森山 将之 (MORIYAMA, Masayuki)
‖ E-Mail: msyk@xxxxxxxxxxxxxxxxx