24

私は Windows で「Unicode 文字列」を長い間使用してきました... Unicode について学びました (卒業後など)。しかし、Win32API が "unicode" について大まかに言及していることに、いつも当惑していました。特に、MSN で言及されている「ユニコード」バリアントは UTF-16 です (ただし、「ワイド文字」という用語は、以前は Unicode ではない UCS-2 であったことに由来します)。ただし、Unicode の正規化についてはほとんど言及されていません。

MSN には、UnicodeおよびUnicode 正規化フォームと正規化フォームを変更する関数に関するページがいくつかあります。正規化に関するページには、次のようにも書かれています。

Win32 と .NET Framework は、4 つの正規化形式すべてをサポートしています。

ただし、Win32 API で使用される (または理解される) 正規化形式がドキュメントのどこにも見つかりませんでした。

質問 1 : ユーザー入力 (エディット コントロールなど) および を介した変換に既定で使用される正規化形式はMultiByteToWideChar()どれですか?

質問 2 : Win32API 関数に渡される文字列は、特定の正規化形式である必要がありますか? それとも、カーネルとファイル システムが正規化に依存していませんか?

4

3 に答える 3

13

MSDNの記事「Unicode正規化を使用した文字列の表現」から。

Windows、Microsoftアプリケーション、および.NET Frameworkは通常、通常の入力方法を使用してフォームCで文字を生成します。Windowsでのほとんどの目的では、フォームCが推奨されるフォームです。たとえば、フォームCの文字は、Windowsのキーボード入力によって生成されます。ただし、Webおよび他のプラットフォームからインポートされた文字は、他の正規化フォームをデータストリームに導入する可能性があります。

更新：質問2に関連する特定の詳細をいくつか含めました。

ファイルシステムに関しては、ファイルの命名、パス、および名前空間の記事に基づいて、正規化は必要ありません。

ファイルシステムはパスとファイル名をWCHARの不透明なシーケンスとして扱うため、WindowsファイルI /OAPI関数で使用するためにパスとファイル名の文字列に対してUnicode正規化を実行する必要はありません。アプリケーションに必要な正規化は、関連するWindowsファイルI / O API関数の呼び出しの外部で、これを念頭に置いて実行する必要があります。

SQL Serverに関しては、正規化は必要ありません。また、データベースに保存するときにデータを正規化する必要もありません。とはいえ、文字列を比較する場合、SQLServer2000はインデックス内で独自の文字列正規化メカニズムを使用します。しかし、それが何であるかについての具体的な詳細を見つけることができません。SQL Server 2005の記事には、同じことが記載されています。

SQL Server 7.0での重要な変更の1つは、文字列比較用のオペレーティングシステムに依存しないモデルの提供でした。これにより、Windows95からWindows2000までのすべてのオペレーティングシステム間の照合が一貫します。この文字列比較コードは、Windows 2000が独自の文字列正規化に使用するのと同じコードに基づいており、すべてのコンピューターとすべてのバージョンのSQLServerで同じになるようにカプセル化されています。

于 2011-08-13T05:21:47.923 に答える
9
于 2011-08-13T13:13:14.427 に答える
2

まず、素晴らしい質問をありがとう。Michael Kaplan のブログで答えを見つけました。

しかし、Windows でのテキスト入力のすべての方法は、すでに同じ正規化フォーム (フォーム C) を使用する傾向があるため、...

于 2011-08-12T15:36:18.763 に答える