・Delphi の Tips なかなか片付かないので、Delphi 5～2007 に最新版の Indy10 をインストールする を追加しておきました。マスターんとこの Tips が増えていった理由が解ったような気がした今日この頃。
今日は出張(現在、AM6:30)なので、留守中何かありましたらお願いしときます＞各位。
・Delphi 2009 に於ける AnsiString の扱い方 totonica氏がいい事言ってるので紹介。
"その通り(Exactly)でございます"
RawByteString を使ってトリッキーなコードを書かなくてはならない状況の殆どは、"元ネタに問題がある場合" に限られます。SetCodePage() も同様です。殆どは TBytes & TEncoding の組み合わせで事足ります。.NET みたいな記述がどうしても馴染めないのなら、RawByteString & SetCodePage() を使う事を否定はしませんが、可読性を下げる(何やってんだかわからなくなる)可能性は高くなります。
RawByteString をオススメしないもう一つの理由は "RawByteString = ANSIのバリアント型" 的な間違った考え方になってしまう事です。あくまで、"暗黙のコードページ変換をしないだけ" ですから。何でもかんでも RawByteString にすりゃいいってもんじゃありません。
いつぞやのセッションでも言った通り、そもそも Delphi 2009 での AnsiString は局所的な利用に留めるべきで、内部実装を UTF-8 でやるとか "狂気の沙汰" です。
・Windows と UTF-8 Windows は UTF-16 です。W系API も UTF-16 ですね。UTF-8 がANSI/Unicode互換なのは 0x00～0x7F の 128文字でしかありません。Unicode のコードポイントは、U+0000～U+10FFFF..."1,114,112文字分" ですね。つまり、どういう事かと言うと、"8,703/8,704は文字コード変換が必要" って事です。BMPに限っても "128/65,536" ですから、"511/512は文字コード変換が必要" です。UTF-16 なら、BMP は無変換、全体で見ても文字コード変換が必要なのは "16/17" でしかありません。しかも、APIに渡すときの文字コード変換のオーバーヘッドが無い訳ですから、パフォーマンスの差は歴然です。
EAW や 結合文字の判定にはコードポイントを算出しなくてはなりませんが、コードポイントを算出するには UTF-16 で最高で2回の演算、UTF-8 だと最高で4回の演算が必要になります。演算しなくてはならない確率は、文字コード変換の場合と同じですよね？他の文字コードに変換するにはコードポイントを算出しなくてはならないのですから。
Webスクリプト言語で UTF-8 が用いられるのは、"エンディアンを考えなくていい" のと、"入出力されるファイルが比較的小さくて済む(日本語の比率が大きいと、このメリットはない)" という2点からです。Webスクリプト言語 と Windowsネイティブアプリケーション ではやるべき事も、優先しなきゃいけない事も違います。Marts氏の言葉を鵜呑みにしないように。氏の発言には "適材適所" というのが抜け落ちているのですから。
・Delphi 2009 と Unicode 繰り返しになりますが、以下の資料を熟読する事をオススメします。
| BACK | 古いのを読む | 新しいのを読む |