A7Mの日記: 誰か、UTF-16を設計した奴を叱ってやってください 4
日記 by
A7M
Unicodeへ移行するんだったらエンコーディングはUTF-8のほうが移行しやすいと思うけど、どうだろ。UTF-16はサロゲートペアや合成文字の件でハナっから破綻しているし。だけど、エンコーディング云々よりも、文字列操作APIをDOMのように規格か何かで制定して欲しいと思っているのは、おいらだけ? ただ、Unicode自体も正規化の問題があるしな・・・。極端な話、検索とかで「ガ」と「カ」+「゛」の合成文字を判別しなければならない訳で。あとは、人名外字とか。ああ、やっぱり、Unicodeは頭が痛い。
そんなことを言っているから、なんだかんだ言って10年後くらいもShift-JISを使っていそうな気が。
マルチワード文字列 (スコア:0)
そんな風に思っていた時期が俺にもありました
Re:マルチワード文字列 (スコア:2)
ユニコードは固定長だからCharNextなど使わなくても文字列ポインタが操作できる そんな風に思っていた時期が俺にもありました
同じく。ノシ
その上、昔はバイト数==文字幅と思っていてEUCの半角カタカナや3バイトを使用する漢字でドツボった経験もあります。
さらには、文字を扱うのであればTRONコードがベストではないかと思っていた時期もありました。
Re:マルチワード文字列 (スコア:1)
昔の wchar_t ってまさに固定長で (エンコーディングは EUC-JP なり何なりのまま) 文字を処理する仕組みでしたよね。 商用 Unices の wchar_t は今でもそうかも。
今でも UTF-32 を使えば、一応「ユニコードは固定長」と強弁できなくもないのですが...
で、閑話休題すると、UTF-16 は UCS-2 から「真っ当な今風の Unicode」への橋渡しをするためのもの (だと自分は理解している) なので、UTF-16 を考えた人を叱っちゃイヤンです。 「未来は Unicode (UCS-2) なのだぁ」とナイーブに走ってしまった Windows の人とか Java の人とかが困るではありませんか (してみると、Plan9 の人が賢かったということなのかしらん)。
Re:マルチワード文字列 (スコア:2)
確かに、折衷案としてUTF-16は悪い方法とは言えないんですけど、「固定長のつもりだったけど、結局、可変長になっちゃったサーセンwwwww」と言う中途半端さが好きでないです。charからwchar_tへの移行も結構面倒ですし。MSがDrawTextをマクロでDrawTextAとDrawTextWとで切り替えるってのも、今となってはおかしな実装な気もします。当時はそれがベストと判断したからでしょうけど。
これからは、文字列を単なるバイト列ではなく、「文字列オブジェクト」として扱う方向に行くはずですから、遅かれ早かれローレベルなAPIは見た目上では駆逐されるでしょうね。もちろん、誰かがローレベルなAPIを書かなければならないのは事実ですが。そうなると、エンコーディングとかもあまり気にしないで済むかもしれません。