2

現在のプロジェクトでは、ワイド文字（utf16）を使用しています。しかし、ユーザーからの私の唯一の入力は、とにかくASCIIになってしまうURLと、もう1つの文字列になるので、プログラム全体をASCIIに切り替えることを考えています。

私の質問は、文字列をWindows API関数に渡す前に文字列をutf16に変換することに何か利点はありますか？

オンラインで調査を行った後、WindowsでUTF-16を使用していない場合は、多くの人がこれを推奨しているようです。

4

2 に答える 2

5

Windows APIでは、次のような関数を呼び出すと

int SomeFunctionA(const char*);

次に、文字列を自動的にUTF-16に変換し、実際のUnicodeバージョンの関数を呼び出します。

int SomeFunctionW(const wchar_t*);

キャッチは、 ANSIコードページから文字列をUTF-16に変換することです。実際にANSIコードページに文字列がエンコードされている場合は、これで問題ありません。UTF-8でエンコードされた文字列がある場合は機能しません。これは、最近ますます一般的になり（たとえば、Webページの約70％）、ANSIコードページとしてサポートされていません。

また、AAPIを使用すると、名前に非ANSI文字（任意のUTF-16文字列）が含まれるファイルを（簡単に）開くことができないなどの制限が発生します。また、Windowsの新しい機能の一部にアクセスできなくなります。

そのため、私は常にW関数を呼び出します。これは、（ソフトウェアのWindows固有ではない部分で使用されるUTF-8文字列からの）煩わしい明示的な変換を意味しますが。

于 2012-04-18T05:25:06.700 に答える
4

重要な点は、WindowsではUTF-16がネイティブエンコーディングであり、最後に終わるすべてのAPI関数はAそれらのラッパーにすぎないということWです。これらのA関数は、Windows 9x / ME用に作成されたプログラムとの互換性として持ち運ばれているだけであり、実際、新しいプログラムでそれらを使用することはできません（私の意見では）。

何十億もの大きな文字列を大量に処理しているのでない限り、それらを別の（おそらくよりスペースを節約する）エンコーディングに格納することを考えることにメリットがあるとは思えません。さらに、IDNについて考えると、URIにもUni​​codeを含めることができます。したがって、ユーザーがプログラムに渡すデータについて事前に確信しすぎないでください。

于 2012-04-18T05:06:56.753 に答える