はじめまして、ではないんですが(苦笑)ちょっとMS系文字コードについて幾つか質問
(相談?)したいことがあって書き込みします。よろしくお願いします。
WindowsにおけるCP932とBruno氏のlibiconvにおける定義がズレているのは承知してい
ます。森山さんのlibiconvパッチのうち、CP932とUCSとの変換の実際の動作について
は、実に納得しています。2002年の[sugj-tech]を仲介としたBruno氏とのやりとりで、
一定の理解を得られているところまでは確認しました。にも関わらず、現在に至るまで
その部分に関してlibiconv本家には反映されていませんね。何か、その後に変更を拒否
されるようなやり取りがあったのでしょうか? それとも単にパッチを送っていないため
にBruno氏としても手が出せない、ということなのでしょうか?
次にいわゆるEUCとJISの問題です。これについては何が正しいとか、どうすべきか明確
なビジョンを私はまだ持てていないのですが、MS系文字コードとの変換用にとeucJP-ms
を定義しサポートするというのは妥当だと思っています。となれば当然JISに相当する
MS系エンコードもサポートされてしかるべきでしょうね。ただそうなってくると、OSと
のロケール指定の関係から、やや面倒なことになるんじゃないかなぁという気もしてい
るんです。
というのも日本での使用では、結局のところどうしたってWindowsのCP932との変換がメ
インになってしまうのですから、libiconv本家に統合しないのならば、euc-jpを
eucJP-msと同じ定義にしてしまったほうが余計な混乱はないんじゃないか、そんな誘惑
にも駆られます。実際に自家使用しているiconvはそうしてます(苦笑)。逆にちゃんと
eucJP-msをIANAに登録されるまで持っていく、というのもありだと思うんですが、現状
がどうなっているのか、(まったく0の場合)そうするにはどういうプロセスが必要なの
か、まったく見通しが立たないんですね。
ちょっと散漫になってしまいましたが、私の目的は非常に単純で「libiconvのようなデ
ファクトスタンダードなライブラリに、日本語コードの実情に即した変換ができるよ
う、本家のレベルで実装させたい」ということなのです。その際、できればライブラリ
の利用者に負担や誤解の少ない方法であればベストだと考えますが、それは努力目標と
いうところです(^-^;。で、この目標に対して、何か森山さんの思うところがあればお
聞かせ願いたい次第です。
興味がありましたら、お時間のある時で結構ですので、お考えをお聞かせください。
| No.277 | 投稿日時: | 2005/03/07(月) 01:02 <↑親記事:No.276> |
| 投稿者: | 森山 将之 |
まず、libiconv の本家へのマージに関してですが、他の方にもプッシュしてもらったのですが、あまり芳しくありませんでした。
私が英語で直接やり取りできれば、いろいろと打つ手はあるとは思うのですが、私が直接やりとりしていないため、こちらの意図を十分伝えきれていないのかなという感じです。
eucJP-msに関しては、すでに日本ベンダ協議会により作られたものだったので、それを利用できましたが、JISコード(ISO-2022-JP)に関しては、「XML日本語プロファイル」で、x-iso2022jp-cp932 というものがあるのですが、次の点がネックとなってしまっています。
----------------
参考 2 いったんシフトJIS又は日本語EUCを経由するからといっても， [IETF RFC 1468]が許していない文字が使用できるわけではない。たとえば，x-sjis-cp932は, NEC特殊文字, NEC選定IBM拡張文字, IBM拡張文字, ユーザ外字を表現できるが，x-iso2022jp-cp932がそれらの文字を表現できるわけでははない。
----------------
CP50220/CP50221/CP50222 のいずれかを実装する事も考えた事がありますが、ユーザー定義文字をエンコードできないとか、一般的にあまり実態が知られていないエンコーディングの為、イマイチだと感じています。
仕方が無いので、ISO-2022-JP-MS というものを独自に定義して実装する事を考えています。
iconv(3) では純粋にエンコーディング変換だけを行う事とし、NEC特殊文字, NEC選定IBM拡張文字は JIS X 0208 のエスケープシーケンス、JIS X 0201 片仮名は ESC ( I、ユーザー定義文字は ESC $ ( ? にしたいと考えています。
ESC $ ( ? は、JIS X 0202:1998 (ISO/IEC 2022:1994) の次の規定を利用します。
-----------------------
13.3.3 私用 どのエスケープシーケンスにおいても, 終端バイトの Fp (すなわち, 03 の列) は, 私用のため保留とする。私用のためのエスケープシーケンスは, ISO 2375 の登録対象外とする。これらは, 交換当事者間の合意によって定義する。
-----------------------
ISO-2022-JP-MS は、CP50220/CP50221を受け入れ可能で、CP50220/CP50221 では、考慮外のユーザー定義文字に関しても、ISO-2022-JP-MS の実装を行っていればやりとりが可能となります。
libiconv 用には、お試しパッチを作成してあり、glibc に関しては最近になって、実装を始めた所です。
Linux では、glibc を使っているので、日本語ロケール、iconv(3) での変換で SJIS/EUC-JP/ISO-2022-JP をMS系で統一する事も可能になってきます。
ただ、「Linux における日本語ロケールに関する指針」では次のような事も書かれていて、ja_JP.eucJP の実態を eucJP-ms にする事に対して、好ましい事ではないのかなとも考えてしまいます。
----------------------
補足: この文字コードの定義は「日本語 EUC」以外の文字コードの利用を
禁止するものではない。ユーザの設定により他の文字コードに切り換える
ことができた方が望ましい。あくまでも利便性のために、「文字コードと
して少なくとも日本語 EUC が利用できること」「デフォルトを日本語 EUC
にすること」を推奨するものである。また他の環境との互換性のため外字
を必要とする場合には ja_JP.eucJP ではなく別の名前を使用することが望
ましい。
----------------------
ただ ja_JP.eucJP ではない別の名前を使用するとなると、ロケール名を直接参照しているようなソフトの修正が必要となるなど、いろいろと面倒な事になるので、現実的ではないのではないかという印象を持っています。
個人的には、MS系文字コードで統一した環境を構築できるようにしたいと考えています。
| No.278 | 投稿日時: | 2005/03/07(月) 18:29 <↑親記事:No.277> |
| 投稿者: | 森山 将之 |
http://www.iana.org/assignments/character-sets
ietf-charsets mailing list
http://www.apps.ietf.org/ietf-charsets.html
RFC 2978 - IANA Charset Registration Procedures
http://www.faqs.org/rfcs/rfc2978.html
標準情報(TR) TR X 0015:1999
XML 日本語プロファイル
http://www.y-adagio.com/public/standards/tr_xml_jpf/toc.htm
[XML MOJI 01119] charset登録
http://www2.xml.gr.jp/log.html?MLID=xmlmoji&N=1119
Variations of mapping from Japanese encodings to Unicode
http://mail.apps.ietf.org/ietf/charsets/msg00933.html
Registration of new charset: sjis-unicode-09
http://mail.apps.ietf.org/ietf/charsets/msg00934.html
Registration of new charset:sjis-jisx0221-1995
http://mail.apps.ietf.org/ietf/charsets/msg00935.html
Registration of new charset:sjis-jdk117
http://mail.apps.ietf.org/ietf/charsets/msg00936.html
Registration of new charset:eucjp-unicode-09
http://mail.apps.ietf.org/ietf/charsets/msg00937.html
Registration of new charset:eucjp-jisx0221-1995
http://mail.apps.ietf.org/ietf/charsets/msg00938.html
Registration of new charset:eucjp-open-19970715-ms (← eucJP-ms)
http://mail.apps.ietf.org/ietf/charsets/msg00939.html
Registration of new charset:eucjp-open-19970715-0201
http://mail.apps.ietf.org/ietf/charsets/msg00940.html
Registration of new charset:eucjp-open-19970715-ascii
http://mail.apps.ietf.org/ietf/charsets/msg00941.html
Registration of new charset:iso2022jp-jdk117
http://mail.apps.ietf.org/ietf/charsets/msg00942.html
Registration of new charset:iso2022jp-unicode-09
http://mail.apps.ietf.org/ietf/charsets/msg00943.html
Registration of new charset:iso2022jp-jisx0221-1995
http://mail.apps.ietf.org/ietf/charsets/msg00944.html
Registration of new charset:iso2022jp-cp932 (←)
http://mail.apps.ietf.org/ietf/charsets/msg00945.html
Registration of new charset:iso2022jp-19970715-ascii
http://mail.apps.ietf.org/ietf/charsets/msg00946.html
※矢印を付けたメールがMS系文字コード
| 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
| No.280 | 投稿日時: | 2005/03/11(金) 12:30 <↑親記事:No.279> |
| 投稿者: | 森山 将之 |
> > まず、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 は試したことがありません。
変換表に関して参照した事はあります。
| No.282 | 投稿日時: | 2005/03/16(水) 16:57 <↑親記事:No.280> |
| 投稿者: | 村岡太郎 <E-Mail> |
> GNU libc であれば、gconv-modules の alias 設定で、SJIS を CP932、EUC-JP を eucJP-ms
> ISO-2022-JP を ISO-2022-JP-MS にしてしまう事が可能です。
> ※gconv-modules の設定を有効にするためには、iconvconfig コマンドを実行する必要が
> あります。
先ほどlibiconvをcvsで更新してみたのですが、aliasに近い仕組みが導入されるのかも
しれません。なんかそれっぽいファイルが追加されています。今のままではMSVCでコン
パイルできないので、詳細はまだわかりませんが。
| No.283 | 投稿日時: | 2005/03/20(日) 13:02 <↑親記事:No.282> |
| 投稿者: | 森山 将之 |
確かに iconv_hooks というのが追加になっているようですね。
コードをちょっと見た感じだとどういう事を意図して入れられたものかよくわかりませんでした。
はじめまして、ではないんですが(苦笑)ちょっとMS系文字コードについて幾つか質問
(相談?)したいことがあって書き込みします。よろしくお願いします。
WindowsにおけるCP932とBruno氏のlibiconvにおける定義がズレているのは承知してい
ます。森山さんのlibiconvパッチのうち、CP932とUCSとの変換の実際の動作について
は、実に納得しています。2002年の[sugj-tech]を仲介としたBruno氏とのやりとりで、
一定の理解を得られているところまでは確認しました。にも関わらず、現在に至るまで
その部分に関してlibiconv本家には反映されていませんね。何か、その後に変更を拒否
されるようなやり取りがあったのでしょうか? それとも単にパッチを送っていないため
にBruno氏としても手が出せない、ということなのでしょうか?
次にいわゆるEUCとJISの問題です。これについては何が正しいとか、どうすべきか明確
なビジョンを私はまだ持てていないのですが、MS系文字コードとの変換用にとeucJP-ms
を定義しサポートするというのは妥当だと思っています。となれば当然JISに相当する
MS系エンコードもサポートされてしかるべきでしょうね。ただそうなってくると、OSと
のロケール指定の関係から、やや面倒なことになるんじゃないかなぁという気もしてい
るんです。
というのも日本での使用では、結局のところどうしたってWindowsのCP932との変換がメ
インになってしまうのですから、libiconv本家に統合しないのならば、euc-jpを
eucJP-msと同じ定義にしてしまったほうが余計な混乱はないんじゃないか、そんな誘惑
にも駆られます。実際に自家使用しているiconvはそうしてます(苦笑)。逆にちゃんと
eucJP-msをIANAに登録されるまで持っていく、というのもありだと思うんですが、現状
がどうなっているのか、(まったく0の場合)そうするにはどういうプロセスが必要なの
か、まったく見通しが立たないんですね。
ちょっと散漫になってしまいましたが、私の目的は非常に単純で「libiconvのようなデ
ファクトスタンダードなライブラリに、日本語コードの実情に即した変換ができるよ
う、本家のレベルで実装させたい」ということなのです。その際、できればライブラリ
の利用者に負担や誤解の少ない方法であればベストだと考えますが、それは努力目標と
いうところです(^-^;。で、この目標に対して、何か森山さんの思うところがあればお
聞かせ願いたい次第です。
興味がありましたら、お時間のある時で結構ですので、お考えをお聞かせください。
| No.277 | 投稿日時: | 2005/03/07(月) 01:02 <↑親記事:No.276> |
| 投稿者: | 森山 将之 |
まず、libiconv の本家へのマージに関してですが、他の方にもプッシュしてもらったのですが、あまり芳しくありませんでした。
私が英語で直接やり取りできれば、いろいろと打つ手はあるとは思うのですが、私が直接やりとりしていないため、こちらの意図を十分伝えきれていないのかなという感じです。
eucJP-msに関しては、すでに日本ベンダ協議会により作られたものだったので、それを利用できましたが、JISコード(ISO-2022-JP)に関しては、「XML日本語プロファイル」で、x-iso2022jp-cp932 というものがあるのですが、次の点がネックとなってしまっています。
----------------
参考 2 いったんシフトJIS又は日本語EUCを経由するからといっても， [IETF RFC 1468]が許していない文字が使用できるわけではない。たとえば，x-sjis-cp932は, NEC特殊文字, NEC選定IBM拡張文字, IBM拡張文字, ユーザ外字を表現できるが，x-iso2022jp-cp932がそれらの文字を表現できるわけでははない。
----------------
CP50220/CP50221/CP50222 のいずれかを実装する事も考えた事がありますが、ユーザー定義文字をエンコードできないとか、一般的にあまり実態が知られていないエンコーディングの為、イマイチだと感じています。
仕方が無いので、ISO-2022-JP-MS というものを独自に定義して実装する事を考えています。
iconv(3) では純粋にエンコーディング変換だけを行う事とし、NEC特殊文字, NEC選定IBM拡張文字は JIS X 0208 のエスケープシーケンス、JIS X 0201 片仮名は ESC ( I、ユーザー定義文字は ESC $ ( ? にしたいと考えています。
ESC $ ( ? は、JIS X 0202:1998 (ISO/IEC 2022:1994) の次の規定を利用します。
-----------------------
13.3.3 私用 どのエスケープシーケンスにおいても, 終端バイトの Fp (すなわち, 03 の列) は, 私用のため保留とする。私用のためのエスケープシーケンスは, ISO 2375 の登録対象外とする。これらは, 交換当事者間の合意によって定義する。
-----------------------
ISO-2022-JP-MS は、CP50220/CP50221を受け入れ可能で、CP50220/CP50221 では、考慮外のユーザー定義文字に関しても、ISO-2022-JP-MS の実装を行っていればやりとりが可能となります。
libiconv 用には、お試しパッチを作成してあり、glibc に関しては最近になって、実装を始めた所です。
Linux では、glibc を使っているので、日本語ロケール、iconv(3) での変換で SJIS/EUC-JP/ISO-2022-JP をMS系で統一する事も可能になってきます。
ただ、「Linux における日本語ロケールに関する指針」では次のような事も書かれていて、ja_JP.eucJP の実態を eucJP-ms にする事に対して、好ましい事ではないのかなとも考えてしまいます。
----------------------
補足: この文字コードの定義は「日本語 EUC」以外の文字コードの利用を
禁止するものではない。ユーザの設定により他の文字コードに切り換える
ことができた方が望ましい。あくまでも利便性のために、「文字コードと
して少なくとも日本語 EUC が利用できること」「デフォルトを日本語 EUC
にすること」を推奨するものである。また他の環境との互換性のため外字
を必要とする場合には ja_JP.eucJP ではなく別の名前を使用することが望
ましい。
----------------------
ただ ja_JP.eucJP ではない別の名前を使用するとなると、ロケール名を直接参照しているようなソフトの修正が必要となるなど、いろいろと面倒な事になるので、現実的ではないのではないかという印象を持っています。
個人的には、MS系文字コードで統一した環境を構築できるようにしたいと考えています。
| No.278 | 投稿日時: | 2005/03/07(月) 18:29 <↑親記事:No.277> |
| 投稿者: | 森山 将之 |
http://www.iana.org/assignments/character-sets
ietf-charsets mailing list
http://www.apps.ietf.org/ietf-charsets.html
RFC 2978 - IANA Charset Registration Procedures
http://www.faqs.org/rfcs/rfc2978.html
標準情報(TR) TR X 0015:1999
XML 日本語プロファイル
http://www.y-adagio.com/public/standards/tr_xml_jpf/toc.htm
[XML MOJI 01119] charset登録
http://www2.xml.gr.jp/log.html?MLID=xmlmoji&N=1119
Variations of mapping from Japanese encodings to Unicode
http://mail.apps.ietf.org/ietf/charsets/msg00933.html
Registration of new charset: sjis-unicode-09
http://mail.apps.ietf.org/ietf/charsets/msg00934.html
Registration of new charset:sjis-jisx0221-1995
http://mail.apps.ietf.org/ietf/charsets/msg00935.html
Registration of new charset:sjis-jdk117
http://mail.apps.ietf.org/ietf/charsets/msg00936.html
Registration of new charset:eucjp-unicode-09
http://mail.apps.ietf.org/ietf/charsets/msg00937.html
Registration of new charset:eucjp-jisx0221-1995
http://mail.apps.ietf.org/ietf/charsets/msg00938.html
Registration of new charset:eucjp-open-19970715-ms (← eucJP-ms)
http://mail.apps.ietf.org/ietf/charsets/msg00939.html
Registration of new charset:eucjp-open-19970715-0201
http://mail.apps.ietf.org/ietf/charsets/msg00940.html
Registration of new charset:eucjp-open-19970715-ascii
http://mail.apps.ietf.org/ietf/charsets/msg00941.html
Registration of new charset:iso2022jp-jdk117
http://mail.apps.ietf.org/ietf/charsets/msg00942.html
Registration of new charset:iso2022jp-unicode-09
http://mail.apps.ietf.org/ietf/charsets/msg00943.html
Registration of new charset:iso2022jp-jisx0221-1995
http://mail.apps.ietf.org/ietf/charsets/msg00944.html
Registration of new charset:iso2022jp-cp932 (←)
http://mail.apps.ietf.org/ietf/charsets/msg00945.html
Registration of new charset:iso2022jp-19970715-ascii
http://mail.apps.ietf.org/ietf/charsets/msg00946.html
※矢印を付けたメールがMS系文字コード
| 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
| No.280 | 投稿日時: | 2005/03/11(金) 12:30 <↑親記事:No.279> |
| 投稿者: | 森山 将之 |
> > まず、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 は試したことがありません。
変換表に関して参照した事はあります。
| No.282 | 投稿日時: | 2005/03/16(水) 16:57 <↑親記事:No.280> |
| 投稿者: | 村岡太郎 <E-Mail> |
> GNU libc であれば、gconv-modules の alias 設定で、SJIS を CP932、EUC-JP を eucJP-ms
> ISO-2022-JP を ISO-2022-JP-MS にしてしまう事が可能です。
> ※gconv-modules の設定を有効にするためには、iconvconfig コマンドを実行する必要が
> あります。
先ほどlibiconvをcvsで更新してみたのですが、aliasに近い仕組みが導入されるのかも
しれません。なんかそれっぽいファイルが追加されています。今のままではMSVCでコン
パイルできないので、詳細はまだわかりませんが。
| No.283 | 投稿日時: | 2005/03/20(日) 13:02 <↑親記事:No.282> |
| 投稿者: | 森山 将之 |
確かに iconv_hooks というのが追加になっているようですね。
コードをちょっと見た感じだとどういう事を意図して入れられたものかよくわかりませんでした。