私は Delphi 2009 を入手したばかりで、以前に、Unicode 文字列への切り替えのために必要になる可能性のある変更に関する記事をいくつか読みました。ほとんどの場合、sizeof(char) はもはや 1 であるとは保証されていません。しかし、なぜこれは文字列操作に関して興味深いのでしょうか?
たとえば、AnsiString:='Test' を使用し、String (現在は Unicode) で同じことを行うと、両方のケースで正しい Length() = 4 が得られます。テストしていなくても、他のすべての文字列操作関数は同じように動作し、引数が Unicode 文字列かそれ以外かを内部的に決定していると確信しています。
文字列操作を行う場合、char の実際のサイズが重要になるのはなぜですか? (もちろん、文字列を文字列として使用し、他のデータを保存しない場合)
助けてくれてありがとう！ホルガー
Unicodeの場合SizeOf（SomeChar）<> Length（SomeChar）。基本的に、文字列の長さは、文字のサイズの合計よりも短くなります。SizeOf（Char）= 1、またはSizeOf（SomeString [x]）= 1（両方ともFALSEであるため）を想定しない限り、またはバイトをcharと交換しようとしない限り、問題は発生しません。 。バイトを文字または文字列にクリエイティブに詰め込む何かをしている場所では、 AnsiStringを使用する必要があります。
（SizeOf（SomeString）は、本質的にコンパイラーの魔法を使ったポインターであるため、長さに関係なく4のままです。）
多くの場合、古い Delphi コードでは、深く考えずに暗黙のうちに文字からバイトに変換されます。たとえば、ストリームに書き込むとき。文字列をストリームに書き込むときは、書き込むバイト数を指定する必要がありますが、代わりに文字数を渡すことがよくあります。別の例については、Chris Bensen のこの投稿を参照してください。
この暗黙的な変換と古いコードを行う別の方法として、「文字列」を使用してバイナリ データを格納する方法があります。この場合、実際にはバイトが必要ですが、データ型は文字を想定しています。D2009 には、これに適した型があります。
Delphi 2009は試していませんが、ユニコードへの切り替えが遅いfpcを使用しています。以下のすべてがDelphi2009にも当てはまると95％確信しています
fpc（ユニコードをサポートする場合）では、「長さ」のような関数がコードページを考慮に入れるようになります。したがって、「人間」が見るように文字列の長さを返します。たとえば、2つの漢字があり、どちらもUnicodeで2バイトのメモリを使用する場合、文字列には2つの文字があるため、長さは2を返します。ただし、文字列には4バイトのメモリが必要です。（+参照カウントと先行＃0のメモリ、ただしそれは別として）
もうできないことはこれです：
var p : pchar;
begin
p := s[1];
for i := 0 to length(string)-1 do
begin
write(p);
inc(p);
end;
end;
このコードは、2つの漢字の例では、間違った2つの文字を書き込むためです。つまり、最初の「実際の」文字の一部である2バイト。
つまり、Length（）は、文字列に割り当てられたバイト数ではなく、文字数を返します。（Unicodeに切り替える前は、これら2つの値は互いに等しいものでした）
バイト レベルで操作を行う場合を除き、文字の実際のサイズは重要ではありません。
(もちろん、文字列を文字列として使用し、他のデータを保存しない場合)
それが重要なポイントです。他の目的で文字列を使用することはありませんが、使用する人もいます。彼らは配列と同じように文字列を使用するので、彼ら (そして私を含む) は、そのような使用をすべてチェックして、何も壊れていないことを確認する必要があります...
この変換が実際には望ましくない場合があることを忘れないでください。たとえば、レコードに GUID を格納するとします。guid には、16 進文字と - および角かっこのみを含めることができます...それらが 2 倍のスペースを占めるようにすると、既存のコードに大きな影響を与える可能性があります。確かに簡単な解決策は、それらを AnsiString に変更し、文字列操作を行った場合にコンパイラの警告に対処することです。
Windows API 呼び出しを行う場合、問題になる可能性があります。または、 str[0]のincまたはdecを実行して長さを変更するレガシー コードがある場合。