New I18N API?

  1. New I18N API?
  2. 続 New I18N API?

iconv_open("WCHAR_T")的なもので行きたい模様

とりあえず、iconv はバイト列同士での変換だと思うから、それを widechar にしちゃうのは気に入らないなぁとか。

あとエラーハンドリングは、そもそも文字コード変換に失敗した場合アプリは処理継続しちゃダメ、絶対なのよな。
処理継続しようとがっつくと、つまらない セキュリティホールを生むわけでして。

新規に受け付けるというか、すぐそこにそのデータを作ったユーザがいるなら変なデータは即突っぱねた方がユーザのためだと思います。けれども、旧システムからの移行等で、そのデータを作ったユーザが今生きてるかどうかすら分からないような場合、悩ましいですよねぇ。

fopen(3)のccs= flag拡張

Ruby 1.9 にも open("hoge.txt", "r:utf-8") みたいな記法はありますな、これはこれであるといいのでしょうが。おそらくのざきさんは、プログラム内は基本的にすでに wchar_t になっているから変換は必要ない。変換が必要なバイト列は基本的に外部のファイルであり、ゆえに fopen に変換を仕込めば解決、ってロジックだと予想。で、これがjoerg氏には伝わっていないとみた。

mbrtowc_enc

木を隠すなら森の中、ゴミを隠すならゴミの山と申しまして。。。

fmemopen(3)とopen_memstream(3)

こっちは上記を前提とした上で、万が一プログラム内にバイト列が紛れ込んだ時も、同じ方法で扱えるというメリットがあると。しかし、前提が共有できていないとメリットは伝わらないし、ファイル以外からもバイト列が飛び込んでくる場合は煩雑なだけとか。それでもiconvが隠蔽できるのはメリットなのでしょうけれど。

本気でやるなら CERT managed Stringのstring_mのように 文字コード情報埋め込みの文字列型を用意するべき

ついでにGCまでしてくれれば完璧ですね。それなんてRubyのC API?

iconv(3)に指定すべき文字コードはISO-8859-1ではなくてISO-8859-1@XML1.0といった別の何かを指定してしまえばいいんでね?

それだと用意されているオプション「何か」しか使えないような。libcの外の人には置換文字の選択肢が増える程度ですよね。(まぁ、XML文字参照を増やすだけでもだいぶ変わるとは思いますけれど)