08/02/23

・ Unicode
　Windows の Unicode (WideString) は Win9x (多分 NT3x / 4.0 も) に於いては UCS-2、2000 / XP / Vista では UTF-16 で表現される。

　UCS-2 は 「Unicode って、完全 2 バイトだよね？」 と言われるアレ。すべての文字は 16bit で表わされる。よって使える文字数は論理的には 65536 文字。ちなみに UCS は Unicode ではない (後述)。

　UTF-16 は基本エリア　(BMP = Basic Multilingual Plane) は UCS-2 と完全な互換性があり、加えて Shift_JIS での漢字表現や EMS (Expanded Memory Specification) のような方法でプレーンを拡張し、UCS-2 が論理的に扱える文字数以上の文字を格納できる。BMP にある文字コード未割り当て領域 (プレーン拡張用に使われる) を "サロゲート" と呼び、この領域にあるコードを 2 つ (16bit×2) 使って表わされる文字 (或いは領域) を "サロゲートペア" と呼ぶ。

　つまり、UTF-16 は

• 16bit (BMP = UCS-2)
• 16bit×2 (サロゲートペア)

　Shift_JIS 等の漢字領域を DBCS (Double Byte Character Set) / MBCS (Multi Byte Character Set) と言うが、UTF-16 のサロゲートペアははさしずめ "DWCS (Double Word CharacterSet) / MWCS (Multi Word Character Set)" と言ったトコロ。UCS-2 は DBCS ではなく、"SWCS (SingleWord Character Set)" が正解なのだろう。

　勘違いしやすいが、Unicode は最新の規格で 21bit の範囲にある。UCS は Unicode と同列に扱われる文字集合の規格 (Universal Coded-CharacterSet)。UCS-2 は 2byte (固定 2byte = WORD)、UCS-4 は 4byte (固定 4byte = DWORD) の範囲にある...つまり、母集合としては UCS-4 は Unicode よりも大きい。UTF は "Unicode / UCS で表わされる文字の文字コードを変形して扱い易くするための文字符号化方式 (文字エンコーディング) の規格 (Unicode / UCS Transformation Format)" であり、文字集合の規格ではない。すべての Unicode / UCS をフラットに扱うには UTF-32 を使えばいいが、この際には、"1 文字 = DWORD" となってしまう。

・ Windows と UTF-16
　では、UTF-16 を内部処理で使用している Windows ではすべての文字を表示できるかと言えば、そうとも限らない。サロゲートペアはデフォルト状態では Vista でしか表示できないからだ。2000 / XP でサロゲートペアを表示するためには対応するフォントとレジストリの変更が必要となる。

　Windows 9x に於いては W 系の API はほぼ実装されておらず、Microsoft Layer for Unicode (MSLU) でも使わない限り W 系の API を呼び出すことはできない。例え MSLU を使ったとしても、W -> A 変換でロスしたり、内部 UCS-2 の制限を受けるため "完全 Unicode 対応" は限りなく不可能に近い。

・ Windows と UTF-8
　有名な UTF-8 は、Shift_JIS をさらに拡張したようなもので、ASCII 部分は 1 バイトで表現でき、それ以外の文字は最大 6 バイト (最新の定義では 4 バイトが上限らしい) で表現する。これこそまさに MBCS と言える。

　これも勘違いしやすいが、"UTF-8 にサロゲートペアは存在しないが、それ以上にややこしい構造になっている" と言うこと。それと、Windows に於いては UTF-16 を内部処理で利用している関係で "間接的にサロゲートペアの影響を受けてしまう" という事。Windows で UTF-8 の話をしている時にサロゲートペアの事を持ち出されても、脊髄反射で 「UTF-8 には関係ねーよ、バーカ」 とか罵ってはいけない。ちなみに、Delphi 2007 にも UTF-8 とサロゲートペアに関する問題が存在する (QC#58386)。

08/02/24

・ Delphi と Unicode
　昨日の続きで、ここからが本題。

• String (短い文字列=ShortString / 長い文字列=AnsiString)
  Pascal の String 型はいわゆる"短い文字列"である。String 型を文字の配列としてアクセスする場合、添え字は 1 からとなる。Copy(S,1,1) と S[1] は同じ内容を得られる (正確には前者は "長さ 1 の String" で後者は Char / AnsiChar 型)。

  では、S[0] にアクセスするとどうなるのか？実は文字列の長さが得られる。短い文字列では、Length(S) と Byte(S[0]) は同じ処理を指す。このため、Pascal 文字列 (ShortString) の文字列長の最大は 255 に制限される。明示的に短い文字列を使いたい場合には

  S: String[255];

  のように添え字を伴って指定する事になる。

  Delphi での String 型は特に何も指定しなければ AnsiString と考えればいい。文字列長の最大は Integer の正の最大数である 2GB となる。String 型はヌル終端でないので、実際にはどのような文字コードを入れても構わないのだが、サポートする文字列処理関数や VCL の関係上、ASCII (ANSI) または、Shift_JIS のように ASCII を符号化して各国の文字を扱えるようにした方式に限定される。

• WideString
  Unicode を扱う文字列型...のハズなのだけれども、実際には内部処理で UTF-16 を使用する Windows であっても、BMP しか扱えないと思われる。つまり、"Win9x = UCS-2"、"2000 / XP / Vista = UTF-16 の BMP" となる。ヘルプには

  WideString は COM の BSTR 型と互換性があります

  とあるのだが、"BSTR が USC-2 の範囲しか扱えない" のか、"互換性とは UCS-2 / UTF-16 の BMP の事を言っている" のかがはっきりしないが、ヘルプに

  WideString 型は、16 ビット Unicode 文字からなる動的に割り当てられた文字列を表します。

  と明示してある以上、どんな Unicode / UTF / UCS 関連の関数であろうが、内部処理に WideString を利用しているのであればサロゲートが無視される可能性が高い (WideStringToUCS4String() 関数とかはそういった意味では眉唾物)。

・ Delphi の使い分け？
　総合的に考えるに、

• Win9x を動作環境に含める事がある → Delphi 7
• 2000 / XP / Vista で Shift_JIS メインの開発 (他システムとの連動等) を行う -> Delphi 2007
• 2000 / XP / Vista で Unicode メイン (多言語化等) の開発を行う -> Tiburón 以降

　この辺をユーザにちゃんと説明した上であれば "Delphi 7 の再販はアリ" だと思っている...需要がないとは言い切れないのだから。加えて言えば Delphi 2007 の長期的なサポートも一考の価値はあると思う。

• Delphi for Classic Windows (7 ベース/CLX 抜き)
• Delphi for ANSI Windows (2007 ベース)
• Delphi for Unicode Windows (Tiburón 以降の最新版ベース)
• Delphi for Unicode Win64 (Commodore 以降の最新版ベース)

・ ちょっと擁護
　CodeGear がヘタレなのではない。ASCII 圏の人間の作ったものは、どうしても非 ASCII 圏の事は後回しになる (或いは ASCII 圏の利便を図ろうとする)。

　例えば UTF-8。これは 1 バイトの範囲にある文字は ASCII と完全互換だ。ASCII の範囲にある文字だけならば、ASCII だろうが Shift_JIS だろうが、EUC だろうが UTF-8 だろうが同じ処理で済む。「俺らの文字は 1 バイト (或いは 7bit) で済むんだよ、何で Unicode (UCS-2 / UTF-16) で 2 バイトも使わなきゃならんのだ？」 という理屈が見え隠れする。 UTF-8 はサイズの縮小という意味では非 ASCII 圏の人間にも有効ではあるが、他の文字コードセットへの変換時に面倒を伴う...「しわ寄せは全部こっちかよ？」 と言いたくなるのが人情ってもんだ。

　MS だって例外ではない。

• 日本語文字セットが Vista 最大の問題として急浮上 (ITPro)
• Vista で Unicode 以外の選択肢はなかったのか？─京大の安岡助教授が語る (ITPro)
• Vista で化ける字，化けない字 (ITPro)
• Vista で化ける字，化けない字(続報) (ITPro)
• SQL Server 7.0 または 2000 を使用する ASP.NET プロバイダにおける Unicode サロゲートの動作 (Microsoft)
  ※.NET プロバイダでサロゲートペアの文字列比較はできない、って話。

・ コードページとロケール。
　さて、文字コードに関わるもう一つの話をしなくてはならない。コードページとロケールについてだ。

　コードページってのは断りがない限り、"Unicode 対応でないアプリケーションに用いる ANSI 文字列の文字符号化方式(文字エンコーディング)" の事で、文字集合を指すのではない。日本語な ANSI 文字列は Shift_JIS だけれども、Windows の日本語 ANSI 文字列は厳密には "Shift_JIS を拡張した CP932" が正しい。プログラミングするなら GetACP() 或いは GetOEMCP() という API で取得できる。

　ロケールというのはお住まいの地域の事。国 / 地域番号とでも言えばいいか。日本のロケール ID は 0x0409 プログラミングするなら GetUserDefaultLCID() という API で取得できる。実はロケールには複数あるのだが (システム / ユーザ / スレッド...)、話がまたややこしくなるので一般に言う所の "現在のロケール" という前提にしておく。

　もう、お分かりかとは思うけど、ロケールとコードページは "関係はあるけど別物"。同じ国の中に異なる言語が存在する事だってあるのだから、ロケールからコードページは特定できない事になる。ややこしいのは OEM コードページという奴。これは Microsoft が管理していないコードページで、日本の CP932 だって元々は OEM コードページだった。MS-DOS の頃、PC / AT と PC-98 で "同じ Shift_JIS なのに違う文字 (機種依存)" だったのは、OEM コードページだったため。Microsoft が管理していないコードページは、同じコードでもベンダによって表示される文字が違う事がある。それと、日本の場合 GetOEMCP() では CP932 が返らないかといえばそうではなく、ちゃんと CP932 が返ってくる。

　さて、そろそろ Delphi にまつわる話をしよう。"[Delphi-ML:90290] Delphi 2007 の TLabel の文字化け" でフォントの Charset の話をしているけれど、中村さんも僕もロケールには言及していない。先に書いたように、この話でロケールとコードページには因果関係はないからだ。それに、DEFAULT_CHARSET が正しく動作しないのはある意味仕方がないのだ...別に日本語の事だけを考えている訳じゃない。

　最近の Delphi でオブジェクトインスペクタに列挙される Charset は OEM コードページ となっているので (<- これは勘違いであり嘘。実際のトコロは後述) は、例えば韓国なんかだと HANGEUL_CHARSET (CP949) と JOHAB_CHARSET (CP1361) という 2 つのコードページが使える事になる。

　特別な処理が無い場合にはコンポーネント等の Font の初期値は "Delphi のデフォルトフォント" を参考にしている (多分)。では、Delphi のデフォルトフォントはどうやって求められているのか？

　普通の考え方なら、

1. GetACP() / GetOEMCP() でコードページを取得。
2. デフォルトフォントにはそのコードページを持つフォントと Charset を指定する (コードページによって決め打ちで)。

1. デフォルトフォントの初期値を "MS Sans Serif"、DEFAULT_CHARSET とする。
2. ロケールが "FarEast" 以外なら抜ける。
   なお、ここではロケールの取得に GetSystemMetrics (SM_DBCSENABLED) を使っている。
3. システムフォント情報を GetTextMetrics() で取得。
4. フォント情報から Charset を取得。これをデフォルトの Charset とする。
5. もし、Charset が SHIFTJIS_CHARSET なら、デフォルトフォントを "ＭＳ Ｐゴシック"、SHIFTJIS_CHARSET に。

1. デフォルトフォントの初期値を "MS Sans Serif"、DEFAULT_CHARSET とする。
2. プラットフォームが Win32 でシステムフォント情報で Charset が SHIFTJIS_CHARSET ならばデフォルトフォント名を "Tahoma" に設定。
3. [HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes] を参照、
   デフォルトフォント名を "MS Shell Dlg 2" で示されるフォント (XP 日本語版等では "Tahoma") に設定。

• 思いっきり環境依存してしまう。
• SHIFTJIS_CHARSET の時に日本語を表示できない "Tahoma" に設定している。
• 2. でデフォルトの Charset を設定していない。
• 2. で正しく指定しても、NT 系 Windows ではデフォルトフォントが "Tahoma" になってしまう。
  デフォルトの Charset を設定していないので、Charset は初期値の DEFAULT_CHARSET のまま。

　そして重要なのは、日本に於いては僕の示した "普通の考え方" でいいのだろうが、"一つの国で複数のコードページを持つ場合" にはそうとばかりも言えない、という事だ。現状では、「リポジトリを用いて回避しろ」 としか言えない...もちろんこれは日本国内に限った話ではない。

　なお、この話題は "[delphi.japanese:TFont.Charset の DEFAULT_CHARSET の扱いについて]" として NG に問題提起してあるので、「実際のトコロどうすべきなのか？」というアイデアをお持ちの方には是非議論に加わって頂きたいと思っている。

08/02/26

・ コードページとフォントの Charset の関係。
　ちょっと訂正。

　うは、TFont.Charset はGetACP()/GetOEMCP()だけじゃ処理できないじゃん。

• 基本、GetACP() で取得できるものが TFont.Charset に指定できる。
• GetOEMCP() でしか取れないコードページで CP1361 (韓国語 - JOHAB_CHARSET) が唯一、TFont.Charset に指定できる。
• windows.pas で定義されている Charset で VIETNAMESE_CHARSET が唯一、オブジェクトインスペクタから指定できない。

case GetACP of
  874: 
    begin
      DefFont.Name := '？？？';
      DefFont.Charset := THAI_CHARSET;
    end;  
  932: 
    begin
      DefFont.Name := 'ＭＳ Ｐゴシック';
      DefFont.Charset := SHIFTJIS_CHARSET;
    end;  
  936:
    begin
      DefFont.Name := '？？？';
      DefFont.Charset := GB2312_CHARSET;
    end;  
  949:
    begin
      DefFont.Name := '？？？';
      DefFont.Charset := HANGEUL_CHARSET;
    end;  
  950:
    begin
      DefFont.Name := '？？？';
      DefFont.Charset := CHINESEBIG5_CHARSET;
    end;  
  1250:
    begin
      DefFont.Name := '？？？';
      DefFont.Charset := EASTEUROPE_CHARSET;
    end;  
  1251:
    begin
      DefFont.Name := '？？？';
      DefFont.Charset := RUSSIAN_CHARSET;
    end;  
  // LATIN (Include ANSI)
  1252:
    begin
      DefFont.Name := '？？？';
      DefFont.Charset := ANSI_CHARSET;
    end;  
  1253:
    begin
      DefFont.Name := '？？？';
      DefFont.Charset := GREEK_CHARSET;
    end;  
  1254:
    begin
      DefFont.Name := '？？？';
      DefFont.Charset := TURKISH_CHARSET;
    end;  
  1255:
    begin
      DefFont.Name := '？？？';
      DefFont.Charset := HEBREW_CHARSET;
    end;  
  1256:
    begin
      DefFont.Name := '？？？';
      DefFont.Charset := ARABIC_CHARSET;
    end;  
  1257:
    begin
      DefFont.Name := '？？？';
      DefFont.Charset := BALTIC_CHARSET;
    end;  
else
  case GetOEMCP of
    // KOREA(JOHAB)
    1361:
      begin
        DefFont.Name := '？？？';
        DefFont.Charset := JOHAB_CHARSET;
      end;
  else
    case GetUserDefaultLCID of
      // VIETNAM
      $042A:
        begin
          DefFont.Name := 'Tahoma';
          DefFont.Charset := VIETNAMESE_CHARSET;
        end;
    else
      DefFont.Name := 'MS Sans Serif';
      DefFont.Charset := GetDefFontCharset;
    end;  
  end;
end;  

　それじゃ、こんな感じになるのかな？これで、ベトナムも(殆ど)ＯＫだね...gặp sau nhè。

・ ちなみに。
　Tiburón とかの ó のように声調記号のある文字の入力には "UniKey" を使っています。以前、ベトナムへ出張した際には重宝しました。以下、実際の使い方です。

1. UniKey をインストール。
2. ダブルクリックで起動して常駐させる。
3. 〔Mở rộng〕ボタンを押す。
4. "Hệ thống" にある "Vietnamese interface" のチェックを外すとインターフェイスが英語になる。
5. 〔Default〕ボタンを押す (3～5 は初回時のみの設定)。

　ベトナム語の入力方式にはイロイロありますが、ここでは TELTEX 方式を紹介しています。"ặ" なんて文字もある訳で、これは "awj" または "ajw" とタイプします。「Tiburón のóだけのために UniKey をインストールするのは大袈裟すぎる」 って方は "Online Keyboard for Vietnamese" で適当にキーを押してコピペして下さい...まぁ、このページからコピペするってのもアリなんですが (^^;A

　なお、正しくベトナム語と日本語を混在できるフォントは

• Arial
• Courier New
• Palatino Linotype
• Tahoma
• Times New Roman
• Verdana

　...ですが、実際にやってみると "ＭＳ ゴシック" 等でも表示できるように見えます。しかし (詳しい理由は述べませんが) 一部の文字だけがボールドになります。日本語とベトナム語を混在させる場合にはできるだけ "Arial" や "Tahoma" を使うようにして下さい。または、ベトナム語の箇所だけフォントを変更するようにして下さい (Word や Excel の場合)。

08/02/28

・ パンが無ければお菓子を(以下略)
　雑談にコメントできなきゃ、掲示板を(以下略)。専用スレッドを用意してみましたので、昨今の雑談にツッコミを入れたい方はどうぞ (メアドは必須ではありません)。目印としてフサを置いておきました。掲示板の注意書きにもありますが、REMOTE_HOST が見えますので自演したい場合には充分注意を払ってからやって下さいね。

　荒れない程度にマターリやれれば、よろしいかと...。

08/02/29

・ "デベロッパーキャンプ、ご参加ありがとうございました。" を検証する。
　私は先のデブキャンに参加する事が叶いませんでしたが、こうして資料の提示があるのは喜ばしい事です...地方に居ながらにして、重要な情報が得られるのですから。

　[String は UnicodeString にマップ]

• バイトサイズの要素のかわりに UTF16 (word サイズ) の要素を使用
  これは 24 日の雑談で書いた通りですね。これをもって VCL で W 系の API を使えるようになります。弊害としては Win9x の切り捨てがあります。
• AnsiString を使うことはできるが、string は AnsiString にマップされないので注意が必要
  これも 24 日の雑談にあったように、"String = UnicodeString" になり、従来の String である AnsiString は傍流となるという事です。現在の Delphi で言う WideString みたいな扱いになる、という事になります。
• Delphi .NET の文字列型は、すでに Unicode 文字列型
  .NET 上ですからね。当然と言えば当然です。
• SizeOf(Char) は Sizeof(Byte) と同等ではなくなる
  UTF-16 ですから、額面通りなら SizeOf(Char) は 2 ですね。これが SizeOf('????') の場合で、'????' にサロゲートペアの文字が入った場合だと 4、BMP なら 2 になります。サロゲートペアの文字は見掛け上は 1 文字でも、それを 1Char と考えてはいけません。

　[文字のインデックス化と通常の文字列処理に変更はない]

• UnicodeString は、引き続き 1 ベースインデックス、リファレンスカウント型のライフタイム管理型エンティティ
  1 ベースインデックス...という事は Copy(S,1,1) と S[1] は同じという事ですね。WORD(S[0]) も、文字列長 (WORD 配列の最大値) を返してくれそうです。リファレンスカウント型...という事で String がガベージコレクションの対象になるって事でしょう。 現行の Delphi の WideString はリファレンスカウント (参照カウント) で管理されていません。
• 文字列割り当て、インデックス、暗黙的変換などは、引き続き期待通りに動作する
  文字列割り当て、インデックスに関しては額面通りでしょう。暗黙的変換は、Windows の機能を使う限りはサロゲートペアに関して心配する必要はないと思います。
• Length(UnicodeStringVar) は、Length(AnsiStringVar) と同様、文字数を返す
  ASCII 圏のヒトならね。現行の Delphi は Length(AnsiStringVar) はバイト数 (BYTE 配列数) を返しますから、MBCS 圏に対しては嘘です。これが本当であれば、SetLength() の意味合いも異なってきますので、Tiburón でもワード数　(WORD 配列数) を返すものと思われます。

・ 彼からの Mail
　溜まってますねー。

　織姫と彦星でもいいのではないでしょうか？

　エロゲのやり過ぎだ...もう、お互いいい歳なんだからさ。

　通販の奴は、「今ならもう 2 個」とか言ってなかったか？

　脈絡のない最後の一行に悪意しか感じない私は何かがおかしいのでしょうか、それとも単なる被害妄想でしょうか？

　オマイの苗字は"日本の苗字 7000 傑"でも最低ランクなのだから、自重せよ。

　"日清のラーメン屋さん" みたいだな。「行ったつもりで我が家で...」 ま、こっちは腹は膨れるのだがな。

　何の事か解らなかったのでググったら、すげぇストーリーだな、オイ！

　夜中にガラガラッって音がするので (多分)、"かなり巨大なゴキブリが台所で這いずり回ってる" のだと妄想すると、夜も眠れなくなると思う。

　"ケツァルコワトル" の事かー！って、ネタ元を説明しないと意味不明なネタって、ネタとしての存在意義を疑われても仕方がないと思う。

　そういや、お子様が生まれたのだったな...おめでとう。願わくば、この子が親父或いは叔父 (1) や叔父 (2) のようなヲタに育ちませんように。

　人生イロイロ...男もイロイロ...さ。

　"渡辺信一郎" と "ワタナベシンイチ" と "ナベシン" と "スパイク" と "ダンス☆マン" と "ダソヌ☆マソ" みたいなものか。ぶっちゃ毛、一見さんにはよくわからないけどね。