UTF-16は有害と見なされるべきですか？

「おそらく最も人気のあるエンコーディングの1つであるUTF-16は有害と見なされるべきですか？」

なぜこの質問をするのですか？

UTF-16が実際に可変長エンコードであるという事実を知っているプログラマーは何人いますか？これにより、サロゲートペアとして表されるコードポイントがあり、複数の要素を取ることができます。

知っている; Javaの文字列、C＃の文字列、Win32 API、Qt GUIライブラリ、ICU Unicodeライブラリなど、多くのアプリケーション、フレームワーク、およびAPIはUTF-16を使用します。しかし、すべての処理には、処理に多くの基本的なバグBMP以外の文字（2つのUTF-16要素を使用してエンコードする必要のある文字）。

たとえば、次の文字のいずれかを編集してみてください。

• 𝄞（U + 1D11E）音楽記号Gクレフ
• U（U + 1D565）数学的なダブルトラックスモールT
• 𝟶（U + 1D7F6）数学的なモノスペースDIGIT ZERO
• 𠂊 （U + 2008A）ハン・キャラクター

インストールしたフォントによっては、見逃す場合があります。これらのキャラクターはすべてBMP（Basic Multilingual Plane）の外部にあります。これらの文字が表示されない場合は、Unicode Character referenceでそれらを確認してみてください。

たとえば、Windowsでこれらの文字を含むファイル名を作成してみてください。「バックスペース」でこれらの文字を削除して、UTF-16を使用するさまざまなアプリケーションでの動作を確認してください。私はいくつかのテストを行いましたが、結果は非常に悪いです：

• Operaでの編集に問題があります（バックスペースで2回押す必要がある削除）
• メモ帳はそれらを正しく処理できません（バックスペースで必要な2つのプレスを削除します）
• ウィンドウダイアログでのファイル名の編集が壊れている（バックスペースで2回押す必要がある削除）
• すべてのQT3アプリケーションはそれらを処理できません-1 つのシンボルではなく2つの空の正方形を表示します。
• u'X'!=unicode('X','utf-16')XがBMPの外の文字である場合、一部のプラットフォームで直接使用すると、Pythonはそのような文字を誤ってエンコードします。
• Python 2.5 unicodedataは、PythonがUTF-16 Unicode文字列でコンパイルされている場合、そのような文字のプロパティを取得できません。
• StackOverflowは、Unicode文字として直接編集された場合、これらの文字をテキストから削除するようです（これらの文字はHTML Unicodeエスケープを使用して表示されます）。
• WinForms TextBoxは、MaxLengthで制限されている場合、無効な文字列を生成する場合があります。

このようなバグは、UTF-16を使用する多くのアプリケーションで非常に簡単に見つけることができるようです。

だから...あなたはUTF-16は有害と見なされるべきだと思いますか？

これは古い答えです。最新の更新については、UTF-8 Everywhereを
参照してください。

意見：はい、UTF-16は有害と見なされるべきです。それが存在するまさにその理由は、以前はワイド文字が現在のUCS-4であるという誤った信念があったためです。

UTF-8の "anglo-centrism"にもかかわらず、テキストの唯一の有用なエンコーディングと見なされるべきです。プログラム、Webページ、XMLファイル、OSファイル名、その他のコンピューター間のテキストインターフェイスのソースコードが存在することはなかったと主張することができます。しかし、そうするとき、テキストは人間の読者だけのものではありません。

一方、UTF-8のオーバーヘッドは、大きな利点がある一方で、支払う代価はわずかです。で文字列を渡すだけの非認識コードとの互換性などの利点char*。これは素晴らしいことです。UTF-8よりもUTF-16の方が短い文字はほとんどありません。

私は他のすべてのエンコーディングが最終的に死ぬと信じています。これには、MS-Windows、Java、ICU、Pythonがお気に入りとしての使用を停止することが含まれます。長い研究と議論の後、私の会社の開発規約では、 OS API呼び出し以外の場所でUTF-16を使用することを禁止しています。これは、アプリケーションのパフォーマンスとWindowsを使用しているという事実にもかかわらずです。変換関数は、always-assumed-UTF8 std::stringをネイティブのUTF-16 に変換するために開発されましたが、Windows自体は適切にサポートしていません。

「必要な場所で必要なものを使用する」と言う人には、どこでも同じエンコーディングを使用することには大きな利点があり、そうしない十分な理由はないと思います。特に、wchar_tC ++への追加は間違いであり、C ++ 0xへのUnicodeの追加も間違いだと思います。ただし、STL実装に要求する必要があるのは、すべてstd::stringまたはchar*パラメーターがユニコード互換と見なされることです。

また、「あなたが欲しいものを使う」というアプローチにも反対です。私にはそのような自由の理由はありません。テキストの主題については十分な混乱があり、このすべての壊れたソフトウェアに帰着します。上記で述べたように、私はプログラマーがUTF-8の1つの適切な方法として最終的に合意に達する必要があると確信しています。（私は非アスキー語圏の国から来て、Windowsで育ったので、宗教的根拠に基づいてUTF-16を攻撃することが最後に期待されるでしょう）。

Windowsでのテキストの実行方法、およびコンパイル時にチェックされるユニコードの正確性、使いやすさ、コードのマルチプラットフォーム性の向上のために他の人に推奨することについて、さらに情報を共有したいと思います。この提案は、WindowsでUnicodeを使用する適切な方法として通常推奨されるものとは大きく異なります。しかし、これらの推奨事項を徹底的に調査した結果、同じ結論が得られました。だからここに行きます：

• UTF-16を受け入れるAPIを隣接する場所以外で使用しwchar_tたりstd::wstring、使用したりしないでください。
• 使用しないでください_T("")またはL""UTF-16のリテラル（これらは、IMO UTF-16廃止の一環として、標準から取り出す必要があります）。
• 敏感なタイプ、機能またはそれらの誘導体を使用しないでください_UNICODEなど、定数をLPTSTRかCreateWindow()。
• それでも、_UNICODE常に定義され、char*WinAPIに文字列を渡してサイレントコンパイルされないようにします。
• std::stringsそしてchar*、プログラム内のどこでもUTF-8と見なされます（特に指定がない場合）
• すべての文字列はstd::string、char *または文字列リテラルをに渡すことができますがconvert(const std::string &)。

• widechars（LPWSTR）を受け入れるWin32関数のみを使用してください。LPTSTRまたはを受け入れるものLPSTR。この方法でパラメーターを渡します。

  ::SetWindowTextW(Utils::convert(someStdString or "string litteral").c_str())
  

  （このポリシーは以下の変換関数を使用します。）

• MFC文字列の場合：

  CString someoneElse; // something that arrived from MFC. Converted as soon as possible, before passing any further away from the API call:
  
  std::string s = str(boost::format("Hello %s\n") % Convert(someoneElse));
  AfxMessageBox(MfcUtils::Convert(s), _T("Error"), MB_OK);
  

• Windowsでのファイル、ファイル名、fstreamの操作：

  • ファミリに引数を渡しstd::stringたり、const char*ファイル名を付けたりしないでくださいfstream。MSVC STLはUTF-8引数をサポートしていませんが、次のように使用する必要がある非標準の拡張子があります。

  • 変換std::stringに引数をstd::wstring持ちますUtils::Convert：

    std::ifstream ifs(Utils::Convert("hello"),
                      std::ios_base::in |
                      std::ios_base::binary);
    

    MSVCの姿勢がfstream変化した場合、変換を手動で削除する必要があります。

  • このコードはマルチプラットフォームではないため、将来的には手動で変更する必要があります
  • 詳細については、fstreamUnicodeの調査/議論ケース4215を参照してください。
  • 非UTF8コンテンツのテキスト出力ファイルを作成しない
  • fopen()RAII / OODの理由で使用しないでください。必要に応じて、_wfopen()上記のWinAPI規則を使用します。

// For interface to win32 API functions
std::string convert(const std::wstring& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

std::wstring convert(const std::string& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

// Interface to MFC
std::string convert(const CString &mfcString)
{
#ifdef UNICODE
    return Utils::convert(std::wstring(mfcString.GetString()));
#else
    return mfcString.GetString();   // This branch is deprecated.
#endif
}

CString convert(const std::string &s)
{
#ifdef UNICODE
    return CString(Utils::convert(s).c_str());
#else
    Exceptions::Assert(false, "Unicode policy violation. See W569"); // This branch is deprecated as it does not support unicode
    return s.c_str();   
#endif
}

Unicodeコードポイントは文字ではありません！ 場合によっては、グリフ（視覚形式）でさえありません。

いくつかの例：

• 「ⅲ」のようなローマ数字のコードポイント。（「iii」のように見える単一の文字。）
• 「á」のようなアクセント付き文字。単一の結合文字「\ u00e1」または発音区別記号「\ u0061 \ u0301」で区切られた文字として表すことができます。
• ギリシャ語の小文字シグマのような文字。単語の位置の中央（ "σ"）と末尾（ "ς"）の形式は異なりますが、検索の同義語と見なされる必要があります。
• Unicode随意ハイフンU + 00AD。コンテキストに応じて視覚的に表示される場合とされない場合があり、セマンティック検索では無視されます。

Unicodeを正しく編集する唯一の方法は、専門家が作成したライブラリを使用するか、専門家になって自分で作成することです。コードポイントを数えるだけなら、あなたは罪の状態に生きています。

使用するUnicode変換フォーム（UTF）には、簡単な経験則があります。-ストレージと通信用のutf-8-データ処理用のutf-16-使用するプラットフォームAPIのほとんどがutf-32の場合utf-32（UNIXの世界では一般的）。

現在、ほとんどのシステムはutf-16（Windows、Mac OS、Java、.NET、ICU、Qt）を使用しています。このドキュメントも参照してください：http : //unicode.org/notes/tn12/

「有害なものとしてのUTF-16」に戻って、私は言うだろう：間違いなくそうだ。

サロゲート（Unicodeを可変長エンコーディングに変換すると考えている）を恐れる人は、文字とUnicodeコードポイント間のマッピングを非常に複雑にする他の（かなり大きい）複雑さを理解していません：文字、合字、バリエーションセレクターの組み合わせ、制御文字など

このシリーズhttp://www.siao2.com/2009/06/29/9800913.aspxを読んで、UTF-16が簡単な問題になる方法をご覧ください。

そのとおり。

どうして？それはコードの行使に関係しています。

Tom Christiansenによる大規模なコーパスのこれらのコードポイント使用統計を見ると、非BMPコードポイントよりも大きければトランス8ビットBMPコードポイントが数桁使用されていることがわかります。

 2663710 U+002013 ‹–›  GC=Pd    EN DASH
 1065594 U+0000A0 ‹ ›  GC=Zs    NO-BREAK SPACE
 1009762 U+0000B1 ‹±›  GC=Sm    PLUS-MINUS SIGN
  784139 U+002212 ‹−›  GC=Sm    MINUS SIGN
  602377 U+002003 ‹ ›  GC=Zs    EM SPACE

 544 U+01D49E ‹𝒞›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL C
 450 U+01D4AF ‹𝒯›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL T
 385 U+01D4AE ‹𝒮›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL S
 292 U+01D49F ‹𝒟›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL D
 285 U+01D4B3 ‹𝒳›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL X

「テストされていないコードは壊れたコードです」というTDDの原則を取り、「実行されていないコードは壊れたコード」と言い換え、プログラマーが非BMPコードポイントに対処しなければならない頻度を考えます。

UTF-16を可変幅エンコーディングとして処理しないことに関連するバグは、UTF-8の同等のバグよりも気付かれることはほとんどありません。プログラミング言語の中には、UCS-2の代わりにUTF-16を提供することを保証しないものもあります。また、一部のいわゆる高レベルプログラミング言語は、コードポイントではなくコードユニットへのアクセスを提供します（Cでさえ、wchar_t一部のプラットフォームが何をするかに関係なく、を使用する場合のコードポイント）。

UTF-16が有害であると考えられるかもしれないということは、Unicodeをより深く理解する必要があると言うことをお勧めします。

私は主観的な質問について私の意見を述べたことに落胆しているので、詳しく説明させてください。UTF-16についてあなたを悩ませているのは正確には何ですか？すべてがUTF-8でエンコードされている場合はどうでしょうか？UTF-7？または、UCS-4はどうですか？もちろん、特定のアプリケーションは、単一の文字コードをすべて処理するようには設計されていませんが、特に今日のグローバル情報ドメインでは、国境を越えた通信に必要です。

しかし、実際には、UTF-16が混乱したり、不適切に実装されたりする可能性があるため（Unicodeは間違いなくそうであるため）、UTF-16が有害であると考えられる場合、文字エンコードのどの方法が無害と見なされますか？

編集：明確にするために：なぜ標準の不適切な実装を標準自体の品質の反映と考えるのですか？他の人が後で指摘しているように、アプリケーションがツールを不適切に使用しているからといって、ツール自体に欠陥があることを意味するわけではありません。その場合は、「varキーワードが有害と見なされる」や「スレッドが有害と見なされる」などと言えるでしょう。この質問は、標準の品質と性質を、多くのプログラマーが適切に実装および使用するのに苦労していると混同していると思います。

Utf-16エンコーディングに問題はありません。ただし、16ビット単位を文字として扱う言語は、設計が不適切であると考えられる可能性があります。char常に文字を表すとは限らない「」という名前の型があると、かなり混乱します。ほとんどの開発者はchar型がコードポイントまたは文字を表すことを期待するため、BMPの近くの文字にさらされると多くのコードが破損する可能性があります。

ただし、utf-32を使用しても、各32ビットコードポイントが常に文字を表すわけではないことに注意してください。文字を組み合わせるため、実際の文字は複数のコードポイントで構成される場合があります。Unicodeは決して簡単ではありません。

ところで。Utf-8が供給される文字が8ビットであると想定するプラットフォームとアプリケーションには、おそらく同じクラスのバグがあります。

私の個人的な選択は、常にUTF-8を使用することです。Linuxのほぼすべての標準です。多くのレガシーアプリとの後方互換性があります。非ラテン文字と他のUTF形式に使用される余分なスペースに関しては、オーバーヘッドが非常に小さく、ラテン文字のスペースが大幅に節約されます。ウェブ上では、ラテン語の言語が最高であり、近い将来にそれらが使用されると思います。そして、元の投稿の主な議論の1つに対処するために、ほぼすべてのプログラマーは、UTF-8にマルチバイト文字が含まれることがあることに気付いています。誰もがこれを正しく処理するわけではありませんが、通常、UTF-16で言うことができる以上のことを認識しています。ただし、もちろん、アプリケーションに最適なものを選択する必要があります。そのため、そもそも複数あります。

まあ、固定サイズのシンボルを使用するエンコーディングがあります。確かにUTF-32を意味します。しかし、各シンボルの4バイトは無駄なスペースが多すぎるため、日常の状況で使用するのはなぜですか？

私の考えでは、ほとんどの問題は、一部のソフトウェアがUnicode標準に遅れをとっていたが、状況を素早く修正できなかったという事実から現れています。Opera、Windows、Python、Qt-それらはすべて、UTF-16が広く知られるようになる前、または存在するようになる前に登場しました。ただし、Opera、Windows Explorer、およびメモ帳では、BMP以外の文字に問題はもうない（少なくとも私のPCでは）ことを確認できます。しかし、とにかく、プログラムがサロゲートペアを認識しない場合、UTF-16は使用されません。そのようなプログラムを扱うことから生じる問題が何であれ、それらはUTF-16自体とは何の関係もありません。

ただし、BMPのみをサポートするレガシーソフトウェアの問題は、いくぶん誇張されていると思います。BMPの外側の文字は、非常に特定のケースおよび領域でのみ発生します。Unicodeの公式FAQによると、「東アジアのテキストであっても、サロゲートペアの発生率は、平均してすべてのテキストストレージの1％未満であるはずです」。もちろん、プログラムはUnicodeに準拠していないため、BMP以外の文字を無視するべきではありませんが、ほとんどのプログラムはそのような文字を含むテキストを操作するためのものではありません。それが彼らがそれをサポートしないなら、それは不快であるが、大惨事ではない理由です。

次に、代替案を考えてみましょう。UTF-16が存在しなかった場合、非ASCIIテキストに適したエンコーディングが得られず、UCS-2用に作成されたすべてのソフトウェアは、Unicode準拠を維持するために完全に再設計する必要があります。後者は、おそらくUnicodeの採用を遅らせるだけです。また、UTF-8がASCIIに関連して行うように、UCS-2のテキストとの互換性を維持することもできませんでした。

さて、すべてのレガシー問題を別にすると、エンコーディング自体に対する議論は何ですか？UTF-16が可変長であることを今日の開発者が知らないことは本当に疑わしい。誰かが問題の可能性として複雑性を指摘した場合、UTF-16はUTF-8よりも解析がはるかに難しくありません。また、UTF-16でのみ文字列の長さを決定するのは簡単に台無しになると考えるのは間違っています。UTF-8またはUTF-32を使用する場合、1つのUnicodeコードポイントが必ずしも1文字を意味するわけではないことに注意する必要があります。それ以外は、エンコーディングに対して実質的な何かがあるとは思わない。

したがって、エンコーディング自体が有害であると考えられるべきではないと思います。UTF-16は単純さとコンパクトさの間の妥協であり、必要な場所で必要なものを使用しても害はありません。場合によってはASCIIとの互換性を維持し、UTF-8が必要です。場合によっては漢字表意文字で作業し、UTF-16を使用してスペースを節約したい場合があります。長さエンコード。より適切なものを使用し、適切に実行してください。

特に東アジア言語での長年のWindows国際化作業は私を傷つけたかもしれませんが、文字列の内部からプログラムへの表現にはUTF-16を、プレーンテキストのようなドキュメントのネットワークまたはファイルストレージにはUTF-8を好みます。ただし、通常、WindowsではUTF-16をより高速に処理できるため、WindowsでUTF-16を使用する主な利点があります。

UTF-16への飛躍により、国際的なテキストを処理する平均的な製品の妥当性が劇的に向上しました。サロゲートペアを考慮する必要がある場合（基本的には削除、挿入、改行）がいくつかあり、平均的なケースはほとんど直線的なパススルーです。また、JISバリアントのような以前のエンコーディングとは異なり、UTF-16はサロゲートペアを非常に狭い範囲に制限しているため、チェックは非常に迅速で前後に機能します。

確かに、正しくエンコードされたUTF-8でもほぼ同じくらい高速です。しかし、サロゲートペアを2つのUTF-8シーケンスとして誤ってエンコードする壊れたUTF-8アプリケーションも多数あります。したがって、UTF-8は救いも保証しません。

IEは、通常、UTF-8ページから内部UTF-16表現に変換しているにもかかわらず、2000年以降、サロゲートペアを適切に処理します。Firefoxでも正しく機能していると確信しているので、Operaが何をするかはあまり気にしません。

UTF-32（別名UCS4）はスペースを非常に必要とするため、ほとんどのアプリケーションにとって意味がありません。

UTF-8は間違いなく進むべき道であり、おそらく、高性能のランダムアクセスを必要とする（ただし、文字の組み合わせを無視する）アルゴリズムで内部的に使用するUTF-32を伴います。

UTF-16とUTF-32（およびそのLE / BEバリアント）の両方がエンディアンの問題に悩まされているため、外部で使用しないでください。

UTF-16？間違いなく有害です。ここに私の目玉はありますが、プログラム内のテキストには3つの許容されるエンコードがあります。

• ASCII：より良いものを買う余裕のない低レベルのもの（例：マイクロコントローラー）を扱う場合
• UTF8：ファイルなどの固定幅メディアでのストレージ

• 整数コードポイント（「CP」？）：プログラミング言語およびプラットフォームに便利な最大整数の配列（低リソースの制限でASCIIに減衰）。古いコンピューターではint32であり、64ビットアドレス指定の場合はint64である必要があります。

• 明らかに、レガシーコードへのインターフェースは、古いコードを正しく機能させるために必要なエンコーディングを使用します。

Unicodeはコードポイントを最大0x10FFFF（1,114,112コード）まで定義します。文字列/ファイル名などを扱う多言語環境で実行されるすべてのアプリケーションは、それを正しく処理する必要があります。

UTF-16：1,112,064コードのみをカバーします。ユニコードの終わりにあるものは、プレーン15-16（プライベート使用領域）からのものです。Utf-16の概念を破る以外は、これ以上成長することはできません。

UTF-8：理論的には2,216,757,376コードをカバーしています。現在のUnicodeコードの範囲は、最大4バイトのシーケンスで表すことができます。バイトオーダーの問題はなく、asciiと「互換性」があります。

UTF-32：理論的には2 ^ 32 = 4,294,967,296コードをカバーします。現在、可変長のエンコードは行われておらず、おそらく今後も使用されないでしょう。

これらの事実は自明です。Utf-16の一般的な使用を推奨することを理解していません。可変長エンコード（インデックスでアクセスできない）で、現在でもUnicodeの範囲全体をカバーするのに問題があり、バイトオーダーを処理する必要があるなど。Windowsおよび他の場所。マルチプラットフォームコードを記述する場合でも、Utf-8をネイティブで使用し、プラットフォームに依存する方法でエンドポイントでのみ変換を行うことをお勧めします（既に提案したとおり）。インデックスによる直接アクセスが必要で、メモリに問題がない場合は、Utf-32を使用する必要があります。

主な問題は、Windows Unicode = Utf-16を扱う多くのプログラマーが、可変長エンコードされているという事実さえ知らない、または無視しないことです。

通常は* nixプラットフォームでの方法はかなり良く、c文字列（char *）はUtf-8エンコードとして解釈され、ワイドc文字列（wchar_t *）はUtf-32として解釈されます。

これをリストに追加します。

提示されたシナリオは単純です（ここで説明するのは元よりもさらに単純です！）：1. WinForms TextBoxは空のフォーム上にあります。MaxLengthが20に設定されています。

2.ユーザーはTextBoxに入力するか、テキストを貼り付けます。

3. TextBoxに入力または貼り付けても、20に制限されますが、20を超えるテキストで共感的にビープ音が鳴ります（ここではYMMV。サウンドスキームを変更してその効果を実現しました！）。

4.エキサイティングな冒険を始めるために、小さなテキストのパケットが別の場所に送信されます。

これは簡単なシナリオであり、空き時間に誰でも作成できます。退屈して以前は試したことがないので、WinFormsを使用して複数のプログラミング言語で自分で書きました。そして、複数の実際の言語のテキストを使用しているのは、私がそのように配線されており、恐ろしい宇宙全体の誰よりも多くのキーボードレイアウトを持っているからです。

私は退屈を改善するために、Magic Carpet Rideという名前を付けました。

これは価値がありましたが、うまくいきませんでした。

代わりに、次の20 文字をMagic Carpet Rideフォームに入力しました。

0123401234012340123𠀀

ええとああ。

その最後のキャラクターは、Unicodeの最初の拡張B表意文字であるU + 20000です（別名U + d840 U + dc00、親しい友人であり、彼が前に姿を消したことを恥じていない）。

そして今、私たちは球技をしています。

TextBox.MaxLengthが話すとき

テキストボックスに手動で入力できる最大文字数を取得または設定します。

それが本当に意味することは

テキストボックスに手動で入力できるUTF-16 LEコードユニットの最大数を取得または設定し、誰かに夢中になっているだけの言語的文字概念でキュートなゲームをプレイしようとする文字列から生きているがらくたを容赦なく切り捨てますカプランの仲間は攻撃的だと思うだろう（彼はもっと外に出なければならない！）。

私は、ドキュメントの更新....得ることについて試してみて参照してくださいよ
、私の覚えている正規の読者UTF-16にUCS-2のシリーズは、単純化の概念と私の不幸に注意しますTextBox.MaxLengthを、どのようにそれは最低でもこのケースを処理する必要がありますその厳格な動作が違法なシーケンスを作成する場合、.Net Frameworkの他の部分は

• System.Text.EncoderFallbackException：インデックス0のUnicode文字\ uD850を指定されたコードページに変換できません。*

この文字列を.Net Frameworkの別の場所に渡す場合は例外です（同僚のダントンプソンが行っていたように）。

大丈夫、おそらくUCS-2からUTF-16への完全なシリーズは、多くの人の手の届かないところにあります。
しかし、TextBox.TextがSystem.Stringを生成しないと予想するのは合理的ではありません それにより、.Net Frameworkの別の部分がスローされなくなりますか？つまり、コントロール上で何らかのイベントという形で、スマートな検証を簡単に追加できる、今後の切り捨てを通知するような機会はありません。つまり、コントロール自体が実行しても構わないという検証です。このパンクコントロールは、予期せぬ例外を引き起こしてアプリケーションを粗野なサービス拒否として終了させる可能性がある場合、セキュリティ上の問題につながる可能性がある安全契約を破っていると言っても過言ではありません。WinFormsのプロセス、メソッド、アルゴリズム、または手法が無効な結果を生成するのはなぜですか？

ソース：Michael S. Kaplan MSDNブログ

UTF-16が有害であるとは必ずしも言えません。エレガントではありませんが、GB18030がGB2312で、UTF-8がASCIIで行うように、UCS-2との後方互換性の目的を果たします。

しかし、MicrosoftとSunが16ビット文字の周りに巨大なAPIを構築した後、ミッドストリームでUnicodeの構造に根本的な変更を加えることは有害でした。変化に対する認識を広められなかったことは、より有害でした。

UTF-16は、処理とスペースの最適な妥協点です。そのため、ほとんどの主要プラットフォーム（Win32、Java、.NET）は、文字列の内部表現にUTF-16を使用しています。

UTF-16のポイントを理解したことはありません。最もスペース効率の良い表現が必要な場合は、UTF-8を使用してください。テキストを固定長として処理できるようにする場合は、UTF-32を使用します。どちらも必要ない場合は、UTF-16を使用します。さらに悪いことに、UTF-16の一般的な（基本的な多言語プレーン）文字はすべて単一のコードポイントに収まるため、UTF-16が固定長であると想定しているバグは微妙で見つけにくいですが、 UTF-8を使用すると、国際化を試みるとすぐにコードが高速かつ大音量で失敗します。

_{私はまだコメントできないので、これを回答として投稿しutf8everywhere.orgます。他のスタックエクスチェンジで十分な評判を得ているので、コメント権限を自動的に取得できないのは残念です。}

これは意見へのコメントとして意図されています。はい、UTF-16は有害な回答と見なされるべきです。

ちょっとした修正：

誤ってUTF-8 char*をWindows-API関数のANSI文字列バージョンに渡さUNICODEないようにするには、ではなくを定義する必要があります_UNICODE。にではなくに_UNICODE関数をマップします。代わりに、後者が定義します。証拠として、これはMS Visual Studio 2005のヘッダーからのものです。_tcslenwcslenMessageBoxMessageBoxWUNICODEWinUser.h

#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif // !UNICODE

最低限、このエラーはで修正する必要がありますutf8everywhere.org。

提案：

おそらく、このガイドには、データ構造のワイド文字列バージョンの明示的な使用例が含まれている必要があります。これにより、見逃したり忘れたりしにくくなります。関数のワイド文字列バージョンの使用に加えてデータ構造の文字列ワイドバージョンを使用すると、そのような関数のANSI文字列バージョンを誤って呼び出す可能性がさらに低くなります。

例の例：

WIN32_FIND_DATAW data; // Note the W at the end.
HANDLE hSearch = FindFirstFileW(widen("*.txt").c_str(), &data);
if (hSearch != INVALID_HANDLE_VALUE)
{
    FindClose(hSearch);
    MessageBoxW(nullptr, data.cFileName, nullptr, MB_OK);
}

誰かがUCS4とUTF-32は同じだと言った。いいえ、しかし、私はあなたが何を意味するか知っています。ただし、一方は他方のエンコードです。ここでエンディアンネスの戦いが起こらないように、最初からエンディアンネスを指定したいと思っていたらと思います。彼らはそれが来るのを見ていなかっただろうか？少なくともUTF-8はどこでも同じです（誰かが6バイトで元の仕様に従っていない限り）。

UTF-16を使用する場合は、マルチバイト文字の処理を含める必要があります。2Nをバイト配列にインデックス付けしてN番目の文字に移動することはできません。あなたはそれを歩くか、文字インデックスを持っている必要があります。それ以外の場合は、バグを作成しました。

C ++の現在のドラフト仕様では、UTF-32およびUTF-16はリトルエンディアン、ビッグエンディアン、および不特定のバリアントを持つことができると述べています。本当に？誰もが最初からリトルエンディアンを実行する必要があるとUnicodeが指定していた場合、それはすべて単純でした。（ビッグエンディアンでも大丈夫だったでしょう。）その代わりに、一部の人々はそれをある方法で実装し、別の方法で実装しました。ソフトウェアエンジニアになるのは恥ずかしいことです。

開発者が十分に注意を払っていれば有害だとは思いません。
そして、彼らもよく知っているなら、彼らはこのトレードオフを受け入れるべきです。

日本のソフトウェア開発者として、UCS-2は十分に大きく、スペースを制限するとロジックが明らかに簡素化され、ランタイムメモリが削減されるため、UCS-2の制限下でutf-16を使用するだけで十分です。

コードポイントとバイトが比例していることを前提とするファイルシステムまたは他のアプリケーションがあります。そのため、生のコードポイント番号が固定サイズのストレージに適合することが保証されます。

1つの例は、ファイル名ストレージエンコーディングとしてUCS-2を指定するNTFSおよびVFATです。

それらの例が本当にUCS-4をサポートするために拡張したい場合、とにかくすべてにutf-8を使用することに同意できますが、固定長には次のような良い点があります：

1. 長さによってサイズを保証できます（データサイズとコードポイントの長さは比例します）
2. ハッシュルックアップにエンコード番号を使用できます
3. 非圧縮データは適切なサイズです（utf-32 / UCS-4と比較）

埋め込みデバイスでもメモリ/処理能力が安い将来、余分なキャッシュミスやページフォールト、余分なメモリ使用のためにデバイスが少し遅いことを受け入れるかもしれませんが、これは近い将来起こりません...

「最も人気のあるエンコーディングの1つであるUTF-16は有害と見なされますか？」

かなり可能性がありますが、代替案が必ずしもはるかに優れていると見なされるべきではありません。

基本的な問題は、グリフ、文字、コードポイント、バイトシーケンスに関する多くの異なる概念があることです。これらのそれぞれの間のマッピングは、正規化ライブラリを使用しても簡単ではありません。（たとえば、ラテン語ベースのスクリプトで書かれたヨーロッパ言語の一部の文字は、単一のUnicodeコードポイントで書かれていません。そして、それは複雑さのより単純な終わりにあります！）難しい; 奇妙なバグが予想されます（ここでそれらについてうめくのではなく、関連するソフトウェアのメンテナーに伝えてください）。

UTF-8とは対照的に、UTF-16が有害と見なされる唯一の方法は、BMPの外側のコードポイントを（サロゲートのペアとして）異なる方法でエンコードすることです。コードがコードポイントにアクセスしたり、コードポイントごとに反復したい場合は、その違いに注意する必要があります。OTOH、「文字」を前提とする既存のコードの大部分は常に2バイトの量に収まることを意味します。かなり一般的で、間違っていれば、少なくともすべてを再構築せずに動作し続けることができます。言い換えれば、少なくとも、正しく処理されていないキャラクターを見ることができます！

私はあなたの質問に頭を向けて、ユニコードのいまいましいシバン全体が有害であると考えられるべきであり、誰もが8ビットエンコーディングを使用するべきだと言います。さまざまなISO 8859エンコーディング、さらにキリル文字に使用される一連のエンコーディング、およびEBCDICスイートに対する混乱、そして…そのすべての欠点に対するUnicodeはそれを打ち負かしています。異なる国の誤解の間のそれほど厄介な妥協ではなかった場合に限ります。