NARUSE, Yui
narus****@airem*****
2006年 1月 30日 (月) 08:30:54 JST
成瀬です。 ご意見どうもありがとうございます。 先のメールで書き忘れたのですが、 glibc/libiconvのeucJP-msパッチを作られた方に尋ねたところ、 sjis<->Unicodeのマッピングが由来のようです。 http://www2d.biglobe.ne.jp/~msyk/cgi-bin/charcode/bbs.cgi?c=gr&n=372 sjisはeucJP-0208よりなわけで、どちらかというとeucJP-asciiよりである、 eucJP-msで採用することには疑問もあるのですが、 CP932も同じ変換をするので・・・難しいですね。 Rei FURUKAWA wrote: > 私の意見としては、「文字コードの正しさは、別の変換フィルタに任せたほう がよい」 > です。 わたしも特別正しさを追いかけているつもりはありません。 もともと、eucJP-msだのeucJP-asciiだのといったマッピングを 他から持ってくることに決めたのも、現在のnkfの、 --cp932, --cp932inv, --ms-ucs-mapといった数々のオプションを 駆使するのは利便性が悪いと考えたからですし。 もっとも、他のマッピングを使うことで他と足並みをそろえる必要が生じ、 かえって面倒になった感もありますけれど。 > 他にもいろいろと変換フィルタがある中で、nkf のような古いものを使うのは、 > > それまで nkf を使っていたスクリプトで、nkf を v2 にするだけで > utf を喰わすことができる > > というケースが多いと思っています。 実際にわたしが nkf に関わるようになったのも、 それまで nkf を使っていた Ruby のライブラリを v2 にするだけで〜、 だったので、これはよくわかります。 ただ、そのような老兵にも Microsoft のマッピングにも対応しろだとか、 置換文字を設定できるようにしろだとか、 期待が大きいのも事実だったりするのが悩ましいところではあります。 > 実際にユーザは、どう注意すればよいのでしょうか？という疑問があります。 > 出力結果に '\' が出てきたら、もう一度入力を調べて、元々 '\' だった > のかどうかを見る、ということでしょうか？ そうなります・・・かね。 事前にU+00A5やU+203Eを削除してしまうというのも一つの手かもしれません。 Tadamasa Teranishi wrote: > http://www.opengroup.or.jp/jvc/cde/ucs-conv.html#ch3_1 > > の 3.1.2 コード変換規則 をみると、 > 「Unicode とユーザ定義文字・ベンダ定義文字に関する問題点と解決策」 > に従っていないような気がして、glibc のものに問題があるような気は > します。 eucJP-msにおいては、U+00A5の対応は書かれていないため、 従っていないというわけでもない、と考えます。 3.1.1 (1) a.でUCSからの多対一変換への言及もありますし。 > これはどうしようもないことですし、実際いろいろ問題が起こります。 > http://jvn.jp/jp/JVN%2318282718/index.html > http://qdbm.sourceforge.net/mikio/rbbs.cgi?id=RA11304958080739742137 > > Microsoft が CP932の変換をしっかり考えていなかったのが敗因でしょう。 あ、どこかでCP932関連の前例を見た気はしていたのですが、 Hyper Estraierでしたか。 とりあえず、次のnkfのドキュメントには、 この脆弱性情報へのリンクは入れておこうと思います。 >>「仕様」とし、別途注意を喚起した方がいい気がしてきました。 > > とされても、使う側は相当困るわけです。特にパスの変換には使えない > ことになりますから。 > 「注意」だけで終わられるのは辛いところですね。(eucJP-ascii を使えば > 問題にならないか...。) 思ったことがいくつかあるので番号をつけて、 1. 脆弱性の範囲 ふと思ったのですが、この脆弱性情報を見直すと、 これって任意のUCSからの多対一変換全てが問題になりませんか。 行きと帰りでマッピングが異なっても、JVN#18282718の問題1にかかりますが、 これはマッピングをそろえればいいとして。（揃えられます？） Unicodeで渡されたパスをEUC-JPに変換して格納し、 Shift_JISに変換してWin32APIに渡す、なんてことをしている場合は、 どこまでが問題になるのかわからないのですが・・・。 2. namazu 側について namazu は eucJP-ascii か -e(eucJP-nkf) を用いそうな気もします。 特に変更しなければ -e になるのでしょう。 ただ、Windows移植版についてはわかりません。 3. 変換フィルタの取れる対策 3.1 往復変換保障オプション せっかくEUC-JPに変換できない文字をエスケープする機能をつけたのですし、 往復変換が保障できない文字は変換しない、 （そしてfallbackで拾われてエスケープされるため、 うまく処理すればUnicode全範囲について往復互換性を確保できる） というオプションをつけるのもありかもしれません。 3.2. U+00A5とU+203Eについて とりあえず、U+00A5とU+203Eについては、 eucJP-msマッピングから削除してしまうのもありかな、 とは思っています。 これで解決可能ならばこれが一番問題が少ないでしょう。 JVCの変換規則にない変換は全て削除、という手もありますが、 U+301Cのマッピング等は利便性を考えると残しておきたい気もして。。 -- NARUSE, Yui <narus****@airem*****> DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA
Fork