NARUSE, Yui
narus****@airem*****
2006年 5月 19日 (金) 06:14:39 JST
成瀬です。
Tomoyuki Asakawa wrote:
>> iconv はそのような処理を提供するためのプログラムでは無いように
>> 感じます。
> iconvを、コード変換アプリケーションとしてみた場合のことでしょう？
違います。
>> 例えば改行コードの変換は、iconvは提供していませんしね。
>> # 提供している実装もありますけれど
>
> 改行コードとコード変換は、別の次元です。
> 異なる環境への、変換コマンドとしてなら必須でしょうけど。
ずれているのは承知ですが、全く異なるとは考えません。
SJIS(CR) -> SJIS(LF)のように、
* 同じ文字コード
* しかし実際に用いる文字集合が異なる
という点で同じ問題と考えます。
>> それは iconv 以外の何かが行うべきでしょう。
>
> iconvは、APIのレイヤ(libiconv)としての、存在でもあり
> ます。
> この時、APIとしては、柔軟な仕様がもとめられるとおもいます。
iconv_t iconv_open(const char *tocode, const char *fromcode);
size_t iconv(iconv_t cd,
char **inbuf, size_t *inbytesleft,
char **outbuf, size_t *outbytesleft);
int iconv_close(iconv_t cd);
という関数群が、およそそのような柔軟な存在になりうるとは考えられません。
そのようなiconvが存在したとしたら、
それはiconvでは無い可能性のほうが高いでしょう。
> 標準的な変換は、APIを使い、非標準になったとたんに、たった
> 数文字の対応表の違い
> の為に、まったく別のものを書かないとならないなんてのは、ナンセン
> スだと思うのです。
>
> そういう意味では、WindowsのAPIも酷い。
標準なAPIを使った後、正規化のAPIを用いることになるかと思います。
>> ICUで言えば、それは iconv に相当する UConverter で
>> なく、
>> Transforms の管轄ですし。
>> http://icu.sourceforge.net/userguide/Transform.html
>
> いやー、このレイヤでするというのも違う気がする。
> もう一つ下ですよ。やはり。
SJIS->Unicodeを念頭に置けば、
iconvレイヤーでという考えになるのかもしれませんが、
Unicode->Unicodeで用いる文字を変えると考えれば、
それは文字コード変換というより正規化の領域だと考えます。
> でも、日本以外では（日本でも）理解されないのだから
> このレイヤでするしかないかもしれませんね。
>
> でも、できないよりできるならICUになればすばらしいかも
>
> ただ、ICUの基本のレベルで、そんなコードに対応する物は無い！
> と、やられてしまったらやはり、別の変換を書く必要になってしまう。
>
> IBMが作ってるからそんなことはないと期待したいが。。。。
> （IBM自身がそういうニーズに直面してるはず)
Transform Rule をちょろちょろと書けば言いだけの話に感じます。
極端な話、s/\x{301C}/\x{FF5E}/gすればいいことですしね。
--
NARUSE, Yui <narus****@airem*****>
DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA