Microsoft WindowsのUnicode

マイクロソフトは、製品にUnicode（UTC-16に進化したUCS-2を遡る）を実装した最初の企業の1つでしたが、2019年にはまだUTF-8のオペレーティングシステムサポートを改善しています。 Windows NTは、システムコールで「ワイド文字」を使用した最初のオペレーティングシステムでした。最初にUCS-2エンコーディングスキームを使用して、Windows 2000からUTF-16にアップグレードされ、サロゲートペアを持つ追加のプレーンの表現が可能になりました。

さまざまなWindowsファミリで

Windows NTベースのシステム

現在のWindowsバージョンと、すべてWindows XPおよび以前のWindows NT（3.x、4.0）に戻るものには、16ビット「Unicode」（Windows 2000以降のUTF-16）と（「コードページ」（またはANSIコードページと呼ばれる）と呼ばれるエンコード。 16ビット関数の名前には、SetWindowTextWなどの-W（「ワイド」から）の接尾辞が付いています。コードページ指向の関数は、SetWindowTextAなどの「ANSI」に接尾辞-Aを使用します（_wfopen / fopenやwcslen / strlenなどの他のシステムからコピーされたAPIには他の規則が使用されました）。 Cを含む多くの言語では、8ビットと16ビットの両方の文字列を同じ関数に渡す明確な方法が提供されていないため、この分割が必要でした。

ほとんどの「A」関数は、現在のコードページを使用してテキストをUTF-16に変換し、「W」関数を呼び出すラッパーとして実装されます。文字列を返す「A」関数は逆の変換を行い、明らかに「？」を入れます現在のロケールに存在しない文字の場合。

マイクロソフトは、「UNICODE」スイッチをコンパイラに提供することにより、ユニコードを「ポータブルに」サポートしようとしました。。これは、文字列定数の外側のUTF-8を変換しないため、実際には機能しません。その結果、コンパイルしないだけでファイルを開こうとするコードが生成されます。

以前の「UNICODE」スイッチとは別に、Windowsは「MBCS」APIスイッチも提供します。これにより、strrevなどのMBCSで機能しない一部の関数が、_mbsrevなどのMBCS対応のものに変更されます。

マイクロソフトのドキュメントの多くは、「Unicode」という用語を「8ビットテキストではない」という意味で使用していることに注意してください。

Windows CE

Windows CEでは、UTF-16がほぼ独占的に使用されていましたが、「A」APIはほとんどありませんでした。 Windows CE 5.0では、限られたセットのANSI APIを使用して、ランタイムイメージに選択的に構築できるロケールの限定セットで使用できます。

Windows 9x

2001年に、MicrosoftはMicrosoftの古いWindows 9xシステムの特別なサプリメントをリリースしました。これには、Windows APIのすべての基本機能の16ビットフレーバー（末尾にWが付いたもの）を含むダイナミックリンクライブラリunicows.dll（240 KBのみ）が含まれています。

UTF-8

Microsoft Windowsには、UTF-8、コードページ65001に指定されたコードページがあります。Windows10 Insiderビルド17035（2017年11月）より前は、ロケールコードページを65001に設定することはできませんでした。

MultiByteToWideCharなどの明示的な変換関数
UTF-8とUTF-16の間でstdin / outを変換するWin32コンソールコマンドchcp 65001。

マイクロソフトは、UTF-8ロケールが一部の機能（ 可能性のある例は_mbsrev）を破壊する可能性があると主張しました。 -8をロケールとして設定できませんでした。

つまり、「狭い」関数、特にfopen（ファイルを開く）はUTF-8文字列では呼び出せず、実際、ロケールの設定に関係なく、fopenを使用してすべての可能なファイルを開く方法はありません。または、使用可能なロケールのいずれもUTF-16文字をすべて生成できないため、文字列に何バイトを入れるか。この問題は、SetWindowTextなどのWindowsを含む8ビット文字列を取得または返す他のすべてのAPIにも適用されます。

現代のすべての非Windowsプラットフォームでは、fopenに渡される文字列は事実上UTF-8です。これにより、他のプラットフォームとWindowsの間に非互換性が生じます。通常の回避策は、MultiByteToWideCharを使用してUTF-8をUTF-16に変換するWindows固有のコードを追加し、「ワイド」関数を呼び出すことです。別の一般的な回避策は、名前を8.3形式のファイル名に変換することです。これは、fopenが文字列ファイル名を取り、変更できないライブラリ関数内にある場合に必要です。

ファイルを開いて名前を変更するための新しい関数を追加することにより、必要な変換を行うために、Boostなどのポータブルライブラリに新しいAPIを追加する提案がありました。これらの関数は、Unixではファイル名を変更せずに渡しますが、WindowsではUTF-16に変換します。これにより、コードは「移植可能」になりますが、ワイド関数を呼び出すのと同じ数のコード変更が必要になります。

Windows 10のインサイダービルド17035および2018年4月の更新（公称ビルド17134）では、ロケールコードページをUTF-8に設定するための「ベータ：ワールドワイド言語サポートにUnicode UTF-8を使用する」チェックボックスが表示されました。これにより、fopenやSetWindowTextAなどの「狭い」関数をUTF-8文字列で呼び出すことができます。

プログラミングプラットフォーム

Microsoftのコンパイラは、UTF-8ソースファイルからのUTF-8文字列定数の生成に失敗することがよくあります。最も確実な方法は、UTF-8（すなわちBOMを使用しない）であるとして、入力ファイルをマークし、UTF-8バイトを持つように文字列定数を配置しないで 、UNICODEをオフにすることです。 BOMが追加された場合、Microsoftコンパイラは文字列をUTF-8として解釈し、UTF-16に変換してから、現在のロケールに変換して、UTF-8を破棄します。 BOMがなく、シングルバイトロケールを使用している場合、Microsoftコンパイラは、引用符で囲まれた文字列のバイトを変更しません。