| No.279 | 投稿日時: | 2005/03/09(水) 14:41 <↑親記事:No.277> |
| 投稿者: | 村岡太郎 <E-Mail> <URL> |
ありがとうございます。
> まず、libiconv の本家へのマージに関してですが、他の方にもプッシュしてもらっ
> たのですが、あまり芳しくありませんでした。
では私がもう少し問題+パッチの内容を整理して理解できたら、再トライしてみましょ
う。
> 仕方が無いので、ISO-2022-JP-MS というものを独自に定義して実装する事を考えて
> います。
納得です。libiconv的には、新しいエンコードを定義してはならないということもない
でしょう。それに既存のエンコードの変更ではなく追加ならば、EXTRAに押し込めるこ
とで、説得しやすいかもしれません。
# ただし日本で実際に使われるケースでは
# 厳密なeuc-jpやjisなんてホトンド意味が無い(苦笑)
> ただ ja_JP.eucJP ではない別の名前を使用するとなると、ロケール名を直接参照し
> ているようなソフトの修正が必要となるなど、いろいろと面倒な事になるので、現実
> 的ではないのではないかという印象を持っています。
問題はそこなんですよね。たとえばVimでは実質的にeuc-jpという設定しかできなくて、
それをそのままiconv(3)に渡してしまっています。Vim1つであれば、修正してもらうこ
とは難しくないのですが、別のアプリも合わせて考えるといっそeuc-jpをeucJP-msにし
てしまいたくなる。iconv(3)に厳密モードと、実用モードみたいな概念があって切り替
えられると良いかなとか、それなら単にラッパーで実現することも不可能ではないです
ね。そこら辺りにアイデアがないものかなぁ、と私も悩んでいます。
ところで、ちょっと毛色が変わりますがIBMのICUって試されたことありますか? 無いよ
うでしたら調査+評価してみようかと考えています。
http://www-306.ibm.com/software/globalization/icu/index.jsp