@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を書けば同じこと出来るんだけどなかなかそこまで実装の手が回らないのよね。
そゆのは日本語だけじゃないしねぇ、まだまだ先は長い。

@IBM942

Sunのjdk1.5.0-09だと0xE086(63区70点)はU+7155のはずなのに
U+7199が割り振られてるじゃん。
JIS78からJIS83の改定では字形の変更は行われてないと思うんだが、これはバグ？



右左からUnicode、JIS78、JIS83ね。
お茶椀持つ方が左ですよ orz

@昂

こないだcommitしたIBM942、25区23点が「昂」(U+6602)の新字体のままだった。
「」(U+663B)の旧字体に修正せんとね。

元々「昂」はMS932のIBM拡張文字に含まれてるので、IBM942の場合これと入れ換えになるっぽ。

ぐえ、これnetbsd-4に間に合わんかも。

patch書いた、commitしてくる。
ちなみに漏れは「昴」と「昂」の違いが判らん男です、ダバダー。

@Citrus iconv

こないだのJISX0208:1978の変換表だけど、JIS83改正で字形が変更された文字のうち
何文字かはJIS90改正でJISX0212の補助漢字として復活してるの忘れてた。
という訳で変換表を直してcommit。

IBM942はあくまでJIS78「並び」で、字形はJIS83なのね。
こっちも直さないとなぁ。

iconv dataにまるっと追加して直した。
でもmapper_jis78とかmapper moduleか、encoding module側で解決してやるべき問題だったかもしれない。

@TR 24731-1 Bounds-checking interface

揉　め　て　たんだけど 最新版がUpされてたんで、先には進んでる模様。
2部構成に改められ、新しく オマケ、TR24731-2 Bounds Checking via dynamic allocation がついた。
1と2はあんま関係なくて、後者はstrndup, asprintf, fmemopen, open_memstreamなどの
GNU拡張/LSB拡張をISO-Cにも取り込もうってだけだったり。
気になったのは

fprintf(stream, "good-bye cruel world");

がElvis CostelloなのかPink Floydなのかどっちだ？くらいだな。

対抗馬の CERT Managed Stringの方も実装の一部が公開されてる。 CMU Licenseだね。
この案についてはtheo@が 酷評してたな、そういや。
漏れもこれ使うくらいなら

	シープラ＝デ＝ヤレー[Cpla De Yale]
		（1955～ フランス）

と思うけどね、まあi18n的にはstring_m型にcharacter encoding情報を埋め込んで
multi localeを想定してるのがほんのちょっと面白い。

TR24731の方は以前簡単な奴だけさっくり 書いたんだが放置中だす。
NetBSD的にはgcc -fstack-protector + libssp によるBounds-checkingと
libutilのefun(3)使え、なんで要らない子だからなぁ。

@Makefile

src/share/locale/ctype/ja_JP.ISO-2022-JP.srcはsrc/share/locale/ctype/charset/*をincludeしてるんだけど
後者を触っても前者が再ビルドされないじゃん。

ja_JP.ISO2022-JP.out:	ASCII JISX0201-left JISX0208-1983

とかMakefileに依存関係書くのもダサいしcpp(1)使うからmkdep(1)に任せるべきだと思うんだけど
書き方がよく判らん。

@N-byte Hangul

先日commitしたJOHAB/CP1361なんだけど、こいつはHangulの文字を分解すると
字母(=Jamo)の組み合わせ

	初声(=choseong) + 中声(=jungseong) [ + 終声(=jongseong) ]

となることを利用しそれぞれに5bit + MSBの1bitを割当て16bit(=2byte)で符号化を行っている。
また字母には子音と母音があり、前者は初声および終声、後者は中声に指定可能。

ただし字母はあくまでパーツなので、1文字(つまりwchar_t)は字母29文字ではなく合成済の11,172文字として扱う。
Unicodeとの変換も字母を合成するのではなく、あくまで合成済のグリフと交換になるので
ほとんどの場合こんな知識は不要な訳なんだけどね。

JOHABのような字母の合成による符号化手法は8bitだけでなく7bit系もある。
RFC 1557に名前だけ登場するN-Byte Hangulってやつね。特徴は

• ISO-2022には準拠しない
• ASCII/Hangulの切替にはSI/SOを使用するstateful encoding
• 初声～終声にそれぞれ1byte使うので1文字2～3バイトになる、つまりMB_CUR_MAX = 3
• 子音は0x41(='A')～0x5E(='^')、母音は0x61(='a')～0x7E(='~')で表現する
• 終声の有無(2byte or 3byte)は4byte目まで読み込んでそれが子音か母音かで判断するしかない

といったとこ、いまいち資料がないので他にもなんかあるかも知れんけど。
まあそのうちencoding module書くかね。

@つか

今日本業でtar -CがSolarisで動かないと新人さんに泣きつかれたとこなのでタイムリーだったな。

ちなみにその新人さんは こんなん読んでるからいつかはやると思ってたｗｗｗｗ

だからあれほどdoc.sun.com読めと(ry