誰かがC#でUnicode文字列を処理するときに知っておくべきいくつかの重要な側面を教えてもらえますか?
7 に答える
C# 文字列は Char、UTF-16 コード単位のシーケンスであることに注意してください。それらはUnicode コードポイントではありません。一部の Unicode コード ポイントでは 2 つの Char が必要であり、これらの Char 間で文字列を分割しないでください。
さらに、Unicode コード ポイントを組み合わせて単一の言語「文字」を形成することもできます。たとえば、「u」Char の後に umlat Char が続きます。そのため、任意のコード ポイント間で文字列を分割することもできません。
基本的に、これは問題の寄せ集めであり、特定の問題が実際には知らない言語にのみ影響を与える可能性があります。
C#(および一般的には.Net)はUnicode文字列を透過的に処理し、アプリケーションが特定のエンコーディングでファイルを読み書きする必要がない限り、特別なことをする必要はありません。このような場合、System.Text.Encodings名前空間のクラスを使用して、管理対象文字列を選択したエンコーディングのバイト配列に変換できます。
System.String はすでに内部で unicode を処理しているため、ここで説明します。ベスト プラクティスは、ファイルの読み取りおよび書き込み時に System.Text.Encoding.UTF8Encoding を使用することです。ただし、ファイルの読み取り/書き込みだけではありません。ネットワーク接続を含むデータをストリーミングするものはすべて、エンコーディングに依存します。WCF を使用している場合、ほとんどのバインドでデフォルトで UTF8 になります (実際、ほとんどのバインドでは ASCII はまったく許可されません)。
UTF8 は、依然として Unicode 文字セット全体をサポートしている一方で、ASCII 文字セットの大部分に対してバイトの類似性があるため、適切な選択です。したがって、Unicode をサポートしない単純なアプリケーションは、アプリケーション データを読み書きする可能性があります。これらのアプリケーションは、拡張文字の使用を開始したときにのみ失敗し始めます。
System.Text.Encoding.Unicode は、1 文字あたり最低 2 バイトの UTF-16 を書き込みます。これにより、サイズが大きくなり、ASCII と完全に互換性がなくなります。ご想像のとおり、 System.Text.Encoding.UTF32 はさらに大きくなっています。UTF-16 と 32 の実際の使用例についてはよくわかりませんが、拡張文字が多数ある場合にパフォーマンスが向上する可能性があります。これは単なる理論にすぎませんが、もしそれが本当なら、主にそれらの言語で使用される製品を作成している日本/中国の開発者は、UTF-16/32 がより良い選択であると考えるかもしれません.
ストリームの読み取りと書き込みを行うときは、エンコードについてのみ考えてください。TextReaderとTextWritersを使用して、さまざまなエンコーディングでテキストを読み書きします。選択肢がある場合は、常にutf-8を使用してください。
言語や文化に惑わされないでください。これは、Unicodeとはまったく別の問題です。
.Netは比較的優れたi18nサポートを備えています。すべての.Net文字列と組み込みの文字列関数がUnicodeで正しいことを行うので、Unicodeについて考える必要はありません。覚えておくべき唯一のことは、DateTime.ToString()などのほとんどの文字列関数は、デフォルトでスレッドのカルチャ(デフォルトではWindowsカルチャ)を使用することです。現在のスレッドまたは各メソッド呼び出しのいずれかで、フォーマットに異なるカルチャを指定できます。
Unicodeが問題になるのは、文字列をバイトにエンコード/デコードするときだけです。
前述のように、.NET 文字列は Unicode を透過的に処理します。ファイル I/O の他に、データベース レイヤーで考慮すべき点があります。たとえば、SQL Server は VARCHAR (非ユニコード) と NVARCHAR (ユニコードを処理する) を区別します。また、ストアド プロシージャのパラメーターにも注意を払う必要があります。
詳細については、次のスレッドを参照してください。
http://discuss.joelonsoftware.com/default.asp?dotnet.12.189999.12