この文字列の長さが、その中の文字数よりも長いのはなぜですか? 質問する

この文字列の長さが、その中の文字数よりも長いのはなぜですか? 質問する

このコード:

string a = "abc";
string b = "A��C";
Console.WriteLine("Length a = {0}", a.Length);
Console.WriteLine("Length b = {0}", b.Length);

出力:

Length a = 3
Length b = 4

なぜでしょうか? 私が想像できるのは、中国語の文字の長さが 2 バイトであり、メソッド.Lengthがバイト数を返すということだけです。

ベストアンサー1

他の誰もが表面的な答えを述べていますが、より深い根拠もあります。つまり、「文字」の数は定義が難しい質問であり、計算に驚くほどコストがかかる可能性がありますが、長さのプロパティは高速であるはずです。

なぜ定義するのが難しいのでしょうか? いくつかの選択肢があり、どれが他よりも有効であるのかは、実際にはわかりません。

  • コード単位の数(バイトまたは他の固定サイズのデータ​​ チャンク。C# と Windows は通常 UTF-16 を使用するため、2 バイトのピースの数を返します)は確かに関連しています。これは、コンピューターが多くの目的でその形式でデータを処理する必要があるためです(たとえば、ファイルへの書き込みでは、文字ではなくバイトが考慮されます)。

  • Unicode コードポイントの数は計算がかなり簡単で (ただし、サロゲート ペアの文字列をスキャンする必要があるため、O(n) です)、テキスト エディターにとっては重要かもしれませんが、画面に印刷される文字数 (グラフィムと呼ばれる) とは実際には同じではありません。たとえば、アクセント付きの文字は、2 つの形式で表現できます。1 つは単一のコードポイント、もう 1 つは文字を表し、もう 1 つは「パートナーの文字にアクセントを追加する」という意味の 2 つのポイントのペアです。ペアは 2 つの文字でしょうか、それとも 1 つの文字でしょうか。文字列を正規化してこれを支援できますが、すべての有効な文字が単一のコードポイント表現を持つわけではありません。

  • グラフィムの数でさえ、印刷された文字列の長さと同じではありません。これはフォントなどの要因に依存し、多くのフォントでは一部の文字が重なって印刷されるため (カーニング)、画面上の文字列の長さは、グラフィムの長さの合計と必ずしも等しくなるわけではありません。

  • 一部の Unicode ポイントは、従来の意味での文字ではなく、むしろ何らかの制御マーカーです。バイト順序マーカーや右から左へのインジケータなどです。これらはカウントされますか?

つまり、文字列の長さは実際には途方もなく複雑な問題であり、それを計算するには、データ テーブルだけでなく CPU 時間も大量にかかる可能性があります。

さらに、ポイントは何でしょうか。これらのメトリックがなぜ重要なのでしょうか。まあ、あなたのケースについてはあなただけが答えることができますが、個人的には、それらは一般的に無関係だと思います。データ入力を制限することは、バイト制限によってより論理的に行われると思います。なぜなら、それはとにかく転送または保存する必要があるものだからです。表示サイズの制限は、表示側のソフトウェアで行う方がよいでしょう。メッセージに 100 ピクセルがある場合、収まる文字数はフォントなどによって異なりますが、これはデータ層ソフトウェアではわかりません。最後に、Unicode 標準の複雑さを考えると、他の方法を試しても、エッジ ケースでバグが発生する可能性があります。

したがって、これは一般的な用途があまりない難しい質問です。コード ユニットの数は計算が簡単で、基礎となるデータ配列の長さに過ぎません。また、一般的なルールとして最も意味があり、役に立ち、定義も簡単です。

だからこそ、「ドキュメントにそう書いてあるから」という表面的な説明を超えたb長さがあるのです。4

おすすめ記事