2006/12/01(Fri)
○ iconvネタ
@nkfでiconv(3)
現nkfメンテナの
なるせさんのところ読んでコーヒー吹いた。
やっちゃいますか:D ネタだったのに。
@元々は
http://mail-index.netbsd.org/tech-userlevel/2006/04/02/0000.html
で始まるスレッドで GNU libiconvの作者 Bruno Haible氏が↓のメールで
http://mail-index.netbsd.org/tech-userlevel/2006/04/03/0000.html
POSIXに準拠していない動作を"broken"でなく"useful"と主張してた件が頭にあったのですよ。
んでiconv(1)はnkfに比べて「使い辛い」といわれる話も(MIME encodeなどの便利機能が無いという部分を除けば)
根っこの部分はこれと同じでiconv(3)レベルでも考慮すべき問題があるのかな、とふと頭をよぎった訳で。
最悪GNU libiconvのiconvctl(3)のような抜け道もありなのかなーと。
@あるべき論
をいうとDragonFlyBSDのCitrusメンテナでもあるjoerg@氏が指摘している通りPOSIX locale使え、が正しいのよね。
iconv(3)はそのシステムのlocaleのnl_langinfo(CODESET)に変換するまでしか想定してないものだと思うし。
だからそれ以外の仕事はwchar_tで処理しろってのが"理想"。ただしPOSIX localeは制約が多く正直使い物にならんのも"現実"。
だからiconv使ってUCS4 Normalizationで処理するアプリが増えるし、wchar_tで処理するにしても__STDC_ISO_10646__に依存したりすんのよね。
@最適化
それと今のCitrusのiconv_std moduleだとどうしてもShift_JIS → EUC-JPの変換にも
multibyte → wchar_t → _csid_t/_index_t → wchar_t → multibyte
という冗長な変換をするんで、どうしても速度的に不利(qkc速えー)、多分nkfとかqkcは
multibyte → multibyte
と最適化してあると思うけど。
まあCitrusの設計は柔軟なんでpluginを書けば同じこと出来るんだけどなかなかそこまで実装の手が回らないのよね。
そゆのは日本語だけじゃないしねぇ、まだまだ先は長い。