>HaskellNet 用に、
>以前にさかいさんが書かれた JSON パーサ
>を大幅に改造したものを
>取り込んだ
>。でまぁライセンスとかの話もあるんでさかいさんに見せたんだけどそのときに言われたのが「サロゲートペアに対応した方がいいのでは」という指摘。なるほど、それは考えていなかったというか存在を忘れていた。
>
>で、 JSON の仕様とかを見たんだけど、 json.org は単に Unicode としか書いてないのね。どうしたものかと思ったけど RFC4627 にはちゃんとサロゲートペアのことが書いてありました。 UTF-16 ではないが(=BOMは考慮しなくて良いが)サロゲートペアはやりましょうという感じか。知らんかった。
>
>というわけで書いてみたのだが、この処理はどう書いた方が効率的なのかというのがわかりづらい。そもそも文字列からバイト列への変換というのは Haskell ではかなり書きづらい部類のコードだと思うけど、まあそんなわけでけっこう適当。おれはあんまり利用しないと思うので、問題視するほど利用する人間が出て問題になってから考慮することにする。
>
>また、 stringify のところでエスケープするかどうかの判定に isControl を使っていたのをちょっと修正。ここで isControl を採用したのも RFC4627 をもとにしているのだと思うが、 GHC の isControl の判定がどこまで信頼できるのかというか、逆に正しく判定できてしまうのが問題。たとえば JSON では、 UTF-8 の文字列が平然と混ざっているという用途が多く、これが問題の邪魔をしてしまう。たとえば、 0×80-0x9f の範囲は制御文字が割当てられているため、 isControl は正しく True を返す。しかし、利用したいのは単独の Unicode 文字ではなく UTF-8 エンコードの一部なのでエスケープしてしまうのはまずい、という場合がある。そこで、 0×20 より小さい文字コードと、 0x7f をエスケープし、 0xff を越えるコードポイントはエスケープ(0xffffを越えているとサロゲートペアで出力)、残りはそのまま出力としている。この辺が現実的な妥協点だと思う。
>
>そういえば Unicode 文字は出力時にはぜんぶ UTF-8 にエンコードしてしまうという手も考えられたかな。 GHC-6.6 のプログラム中に書かれた文字列はすべて適切な Unicode 文字として解釈されるため、それを JSON で出力するとエスケープされた出力になって美しくない、というケースもあるかも。その辺はプログラマが自分でなんとかするという方針で……うーん上手くないかなあ。だいたい UTF-8 文字列と Unicode のコードポイントを参照するのと両方を混在させているのがいかんのだろうか。まあ、そんな気もする。
>
>RFC には文字コードの話も記載されているんだよね。 JSON を読み出したときにはその辺の文字コードを調べ(どうせ UTF-8 と UTF-16類と UTF-32類しかないことになっているので楽チンだ)、ちゃんと Unicode 文字に変換するという方がいいのかな。でも、 Unicode でないやつ(あるのか？)が来たときに狂うかなぁー。
>
>ふむ。
>
