ユニコードが全然ユニじゃない件

仕事の話です。
開発が一段落して保守フェーズに入ったので、ずーと以前から頼まれていたものの、嫌な感じがするんで先延ばしにしていた開発フレームワークの Unicode 対応に、とりかかってみたわけですが...

「なんじゃこりゃ～」いやマジで、という感じです。(^^;;;;;;;;

特に、「WAVE DASH 問題」
機種依存文字でもなく、利用頻度も高い「～」を JIS から変換したときに、Windows と、標準 (とされている仕様) で、変換されるコードが違うってのは...

はっきりいって、私は M$ 嫌いです。
M$ のわがままに自分のコードを合わせるのは、可能であれば絶対却下なのですが...これは...これはやむを得ない。仕事でプログラムを書いている以上、この場合は M$ の実装の方を採用するしかありません。無念です...

次に「BOM」
これも扱いに困ります。
入力のときは、まぁ読み捨てればいいのでしょうが、出力するときは付けるの？付けないの？アプリによって、要求バラバラだったり、挙動が変わったりするらしいので最悪です。てか、文字数の数え方とかどうするんだ？

サロゲートペア
まだライブラリの仕様検討段階だけど、どう扱えばいいんだ？ MBCS みたいに、文字単位 vs バイト単位みたいに 2 通りのメソッドを用意するしかないのか？

wchar_t
gcc の wchar_t が、4バイトがデフォって...
かと思えば Apache の Xerces の API は、文字は wchar_t ではなく、2バイト固定みたいだし。
いったい何を信じれば良いんだろう...orz

UTF-7
ってなんすか？使われているの？サポートした方がいいの？
だいたい UTF-xx て大杉

絵文字
携帯の絵文字。機種依存文字扱いなんですね。DoCoMo は、CP932 の外字のマッピングに準拠しているから扱えるけど、au はなんじゃありゃ。あんなにたくさん絵文字って要るのか？使いこなせるのか？
付き合いきれない...まぁうちの会社に携帯の絵文字をサポートする必要がある案件なんかこない気がするから、とりあえずは深く考えないことにしよう。(^^;;;;;;

JISX0213
こいつのシフトJIS は、誰も見向きもしない哀れな仕様なんだけど、94区以降を合法的にEUC にマッピングする唯一の方法ではあるので、今まで自作の漢字変換処理では微妙にサポートしていたりしたんだけど、Unicode のマッピングまで持つのはやりすぎだろうなぁ。やっぱり。

さて、収集つける自信がなくなってきたよ。どうするかなぁ...