蝉は、やがて死ぬる午後に気づいた。ああ、私たち、もっと仕合せになってよかったのだ。:2008年03月18日分

2008/03/18(Tue)

[NetBSD] tech-userlevel

それはttyドxtermが\x00をzero widthで表示してるだけでわ(汗 。

less/LESSCHARSETも

と書き直した方がいいんだろけどな。
ちゅうかUNIXのpipe思想からすると、iconv(1) + CSI more(1) or less -rが正しいような希ガス。

その点を踏まえると、iconv(1)の-tオプションは省略可能な方がいいのだけども
SUSv2の仕様では省略不可なんだよな、GNU libiconvは拡張されてるけど。

うお SUSv3で改定されて省略可能なのな。
じゃぁそのうちに対応しちまおう、 patch
それとiconvが持つ変換テーブルって実装依存だったのだけど
charmapを使う可能性についても言及されてるのね。

charmapをiconv(3)でも使うとなると、やっぱりyamtさんが昔書かれてた
jil(jikken locale、bsd-locale-ja@から探してちょ)みたいな実装が一番いいのだろうね。
charmapはCitrus iconvみたいにCES(esdb)/CSS(csmapper)の分離できてないけども
同じ文字には同じ名前がついてるはずなので

で済むのよな、ある意味今のCitrusよか効率だけは良い可能性がある。

ただcharmapってそもそも

  1. ↓なんかの扱いがムリムリムリムリかたつむりよ!
    • HZ-GB2312のようなlocking shiftするようなstateful encoding
      (ISO-2022はTR14652でなんとか)
    • UTF-7のような7/16という変則的なmultibyte
  2. 包摂規準の異なる文字集合同士とかの変換がヤバイ
    つまり同じ文字に同じ名前がつけられない事もあるわけですよ。 例えば
     CP864とかCP1046のアラビア表示形B <-> ISO-8859-6の同基本形
    
    の変換考えた場合とっても頭が痛い。
    そもそもの話ですまんけど、これlocaledefからcharmap使う場合も微妙だよな。
    それこそJIS2004 <-> UCS4の1:N変換とか考えた場合
    ja_JP.Shift_JIS-2004とja_JP.UTF-8は同じja_JPなlocaledef srcを定義可能なのかとか。
    (まあwchar_t=ucs4のバヤイ1:Nがあること自体が矛盾なので、glibc方面では 無視してるようですが *1)
  3. GNU libiconvの//TRANSLITやUnicode Normalizationのような換字情報どうするよ?
    換字情報をwctrans(3)のuser-defined classで実装できたりするといろいろ矛盾ないのだけど
    //TRANSLITは1:N変換なのにtowctrans(3)は1:1変換だしね。
  4. Unicode Language TagにUnicode Variation Selectorどうするよ
    すでに IVDの登録始まってんのねぇ、 前も書いたRAW変換が必要なら
    iconv -f utf-8 -t adobe-japan1-6
    
    つーのもありうるんだよな、gkbr。

げげげ、今のCitrusってUTF-16/32(endian指定なし)を変換後に指定した場合
動作してるMACHINE_ARCHのendian + BOM無しで出力するんだが
GNU libiconvとかPerl iconv(piconv)はbig endian + BOM有りで吐きよるのな。
glibc2 iconvはMACHINE_ARCHのendian + BOM有りみたいだし、
せめてBOMだけでも吐いといた方がいいのかも知れん、 patch

*1:Unicode Named Character Sequenceとwchar_tの32bit目使うとか考えてたりして、gkbr。