文字コード掲示板

Re^3:MS系文字コードを今後どうするのか

> > まず、libiconv の本家へのマージに関してですが、他の方にもプッシュしてもらっ
> > たのですが、あまり芳しくありませんでした。
>
> では私がもう少し問題+パッチの内容を整理して理解できたら、再トライしてみましょ
> う。

よろしくお願いいたします。

ISO-2022-JP-MS を加えたパッチの場所は、次を参照ください。

お試し版 cp932-family パッチ
http://www2d.biglobe.ne.jp/~msyk/cgi-bin/charcode/bbs.cgi?c=gr&n=199

> > 仕方が無いので、ISO-2022-JP-MS というものを独自に定義して実装する事を考えて
> > います。
>
> 納得です。libiconv的には、新しいエンコードを定義してはならないということもない
> でしょう。それに既存のエンコードの変更ではなく追加ならば、EXTRAに押し込めるこ
> とで、説得しやすいかもしれません。

Bruno さんは、SJIS/EUC-JP/ISO-2022-JP に手を加えると、たとえそれがバグ修正でも
ダメな感じですので、libiconv での SJIS/EUC-JP/ISO-2022-JP の変換の問題 (YEN SIGN
問題や JIS規格と異なるマッピング) は放置するしかないのかもしれません。

そうすると、ますます、MS系文字コード優位になりますね。
個人的には、それでもかまわないのですけれども。

> # ただし日本で実際に使われるケースでは
> # 厳密なeuc-jpやjisなんてホトンド意味が無い(苦笑)

JIS規格だけでは実装するのに情報が不十分で解釈の違いなどにより実装にばらつきが生
じて互換性が損なわれるという問題があります。
標準規格としてきちんと機能しているとは言えないのが悲しいところです。

> > ただ ja_JP.eucJP ではない別の名前を使用するとなると、ロケール名を直接参照し
> > ているようなソフトの修正が必要となるなど、いろいろと面倒な事になるので、現実
> > 的ではないのではないかという印象を持っています。
>
> 問題はそこなんですよね。たとえばVimでは実質的にeuc-jpという設定しかできなくて、
> それをそのままiconv(3)に渡してしまっています。Vim1つであれば、修正してもらうこ
> とは難しくないのですが、別のアプリも合わせて考えるといっそeuc-jpをeucJP-msにし
> てしまいたくなる。iconv(3)に厳密モードと、実用モードみたいな概念があって切り替
> えられると良いかなとか、それなら単にラッパーで実現することも不可能ではないです
> ね。そこら辺りにアイデアがないものかなぁ、と私も悩んでいます。

GNU libc であれば、gconv-modules の alias 設定で、SJIS を CP932、EUC-JP を eucJP-ms
ISO-2022-JP を ISO-2022-JP-MS にしてしまう事が可能です。
※gconv-modules の設定を有効にするためには、iconvconfig コマンドを実行する必要が
あります。

Qt(KDE) では、環境変数 UNICODEMAP_JP で、どの変換表を用いるかという事と、ベンダー
定義文字(nec-vdc,ibm-vdc)、ユーザー定義文字(udc) を有効にするかどうかの設定が可
能となっています。

> ところで、ちょっと毛色が変わりますがIBMのICUって試されたことありますか? 無いよ
> うでしたら調査+評価してみようかと考えています。
> http://www-306.ibm.com/software/globalization/icu/index.jsp

ICU は試したことがありません。
変換表に関して参照した事はあります。