[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:37350] Re: Samba "Coding system CAP"
たかはしもとのぶです。
>> 2. 符合化方式の変換ロジックが内蔵から iconv() を利用する形式に変更され
>> た。これによって、いわゆる文字コード関連の問題を扱う時は、Samba だけ
>> では解決できず、iconv() が関連するようになってしまった。
>
>バギーな(失礼) iconv()を持つOSのために、間接的にiconv()を
>コールするような形(ラッパー)にすれば解決でしょうか? まあ、
>それで解決するのであればすでにやっているのでしょうけど…。
別に iconv() が buggy かどうかの問題ではありません。
各 iconv() の実装が保持する変換テーブルに Windows と完全な互換性がない
ことが Samba からみた場合の問題です。
# それから、いわゆる文字コード関連で必要な機能は、変換関数だけではない
のですが、そのあたりの周辺機能がごっそり削られてしまっているという問
題もありますが。
かといって、各々の iconv() の実装が誤っているわけではありません。そも
そも Unicode ではレガシーな文字集合との間の文字(スクリプト)のマッピン
グについては定義はしていない(参考例としては提示している)ので、どのよう
な実装を行っても誤りとはいえないためです。
とはいえ、Unicode.org の参考例に従って実装した文字集合の変換テーブルは、
Windows では使いものになりませんので、おそらく事実上今の日本では使い物
にならないでしょう。
わたしが、GNU libiconv の maintainer にお願いしていたのは、CP932 を
Windows と完全互換にすることと、符号化形式が EUC で、文字集合としては
Windows と同じ新たなロケールを作成することの2点です。これができれば、
少なくとも GNU libiconv については、現状 Samba で利用する上での問題点
はクリアされます。
>あ、libiconvって、OSのではなくて、別にあるものを使うのですか?
各OSの各バージョンのiconv()の実装をすべて確認すれば良いのでしょうが、
とてもそこまで確認し切れません。なので、現状一番ポータビリティがあると
思われる libiconv-1.8 での確認を行っています。
-----
TAKAHASHI, Motonobu (たかはしもとのぶ) monyo@xxxxxxxxxxxxxx
http://www.monyo.com/