[debian-users:37350] Re: Samba "Coding system CAP"

[TAKAHASHI Motonobu <monyo@xxxxxxxxxxxxxx>]

たかはしもとのぶです。

>> 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/