[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:03331] Re: ja_JP locale
吉山です。
I received from Kaz.Sasayama@xxxxxxxxxxxxxxx on 12 07 , 1997.
+ AY> をを，素晴らしい．キャラクタ ID の命名ルールはこれでいいのかどうかは
+ AY> 分かりませんが，こういうのが欲しかったんです（どこにあったんですか？）．
+ glibc 1.9xのころに入っていたと思ったんですが、Linux-GCCの開
+ 発用メーリングリストに入っていたころに拾ったもののようです。
+ しかし正しいのかどうかは分かりません。対応するcharmapファイ
+ ルもないし、localdefにも通らない。
以前のプロジェクトでも同様の報告がありました。
何故 localedef に通らないのでしょうか？
# 基本的に signed char だからでしょうか。
+ AY> 良い参考文献などありましたら，御教示願います．
+ The Open GroupのUnix仕様が以下の場所にありました。元になる規
+ 格はPOSIX.2だと思うんですが、まだそれは見付けていません。
+ http://www.rdg.opengroup.org/onlinepubs/7908799/xbd/charset.html
+ http://www.rdg.opengroup.org/onlinepubs/7908799/xbd/locale.html
+ これによると多バイト文字とワイド文字の変換は、処理系依存のよ
+ うです。多バイト文字EUCでワイド文字ISO 10646とかだと、これだ
+ けでは対応できませんね。ロッキングシフトもダメみたいです。
ロッキングシフトってのは、JIS のシフト状態がある奴の事ですか？
用語に弱いもので…。
+ glibcにEUC/JIS対応を追加したとき、ワイド文字をどうしたらいい
+ かっていうのが気になります。
他の兼ね合いと glibc 本来のポリシーへの敬意によって、以前のパッチで
はワイド文字を UCS4 で実装していました。今実装している変換関数も同様で
す。localedef なんかの絡みもありますし。
基本的には、
1) locale ディレクトリ下に各コード系用の変換テーブルがあれば
それを使用。
2) なければ、本来の UTF->UCS 変換関数を実行
というポリシーで実装しています。
+ 4.4BSDではこのあたりどうしているんでしょうか？
EUC の亜種でやっているという話を聞いた事があります。
+ charmapファイルを拡張して、`<encoding_scheme> euc'とか。
まだまだ勉強の足らない私です。
---
name : 吉山あきら (Akira Yoshiyama)
e-mail : yosshy@debian.or.jp, yosshy@xxxxxxxxxxxxxxxxxxxxx
URL : http://jedi.seg.kobe-u.ac.jp/~yosshy/linux.html