パスワードを忘れた? アカウント作成
173819 journal

A7Mの日記: 誰か、UTF-16を設計した奴を叱ってやってください 4

日記 by A7M

('A`)

Unicodeへ移行するんだったらエンコーディングはUTF-8のほうが移行しやすいと思うけど、どうだろ。UTF-16はサロゲートペアや合成文字の件でハナっから破綻しているし。だけど、エンコーディング云々よりも、文字列操作APIをDOMのように規格か何かで制定して欲しいと思っているのは、おいらだけ? ただ、Unicode自体も正規化の問題があるしな・・・。極端な話、検索とかで「ガ」と「カ」+「゛」の合成文字を判別しなければならない訳で。あとは、人名外字とか。ああ、やっぱり、Unicodeは頭が痛い。

そんなことを言っているから、なんだかんだ言って10年後くらいもShift-JISを使っていそうな気が。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2009年12月11日 18時12分 (#1687478)
    ユニコードは固定長だからCharNextなど使わなくても文字列ポインタが操作できる
    そんな風に思っていた時期が俺にもありました
    • ユニコードは固定長だからCharNextなど使わなくても文字列ポインタが操作できる そんな風に思っていた時期が俺にもありました

      同じく。ノシ
      その上、昔はバイト数==文字幅と思っていてEUCの半角カタカナや3バイトを使用する漢字でドツボった経験もあります。
      さらには、文字を扱うのであればTRONコードがベストではないかと思っていた時期もありました。

      親コメント
      • by oku (4610) on 2009年12月12日 1時40分 (#1687737) 日記

        昔の wchar_t ってまさに固定長で (エンコーディングは EUC-JP なり何なりのまま) 文字を処理する仕組みでしたよね。 商用 Unices の wchar_t は今でもそうかも。

        ユニコードは固定長だからCharNextなど使わなくても文字列ポインタが操作できる そんな風に思っていた時期が俺にもありました

        今でも UTF-32 を使えば、一応「ユニコードは固定長」と強弁できなくもないのですが...

        で、閑話休題すると、UTF-16 は UCS-2 から「真っ当な今風の Unicode」への橋渡しをするためのもの (だと自分は理解している) なので、UTF-16 を考えた人を叱っちゃイヤンです。 「未来は Unicode (UCS-2) なのだぁ」とナイーブに走ってしまった Windows の人とか Java の人とかが困るではありませんか (してみると、Plan9 の人が賢かったということなのかしらん)。

        親コメント
        • 確かに、折衷案としてUTF-16は悪い方法とは言えないんですけど、「固定長のつもりだったけど、結局、可変長になっちゃったサーセンwwwww」と言う中途半端さが好きでないです。charからwchar_tへの移行も結構面倒ですし。MSがDrawTextをマクロでDrawTextAとDrawTextWとで切り替えるってのも、今となってはおかしな実装な気もします。当時はそれがベストと判断したからでしょうけど。

          これからは、文字列を単なるバイト列ではなく、「文字列オブジェクト」として扱う方向に行くはずですから、遅かれ早かれローレベルなAPIは見た目上では駆逐されるでしょうね。もちろん、誰かがローレベルなAPIを書かなければならないのは事実ですが。そうなると、エンコーディングとかもあまり気にしないで済むかもしれません。

          親コメント
typodupeerror

Stableって古いって意味だっけ? -- Debian初級

読み込み中...