東アジア言語は通常、UTF-8（通常は3バイトが必要）よりもUTF-16（東アジア言語の文字の99％には2バイトで十分）のストレージが少なくて済みます。
もちろん、欧米の言語の場合、UTF-8は通常小さいです（2バイトではなく1バイト）。HTMLのような混合ファイル（マークアップがたくさんある）の場合、それは非常に重要です。
ユーザーモードアプリケーション用のUTF-16の処理は、 UTF-8の処理よりもわずかに簡単です。これは、サロゲートペアが結合文字の動作とほぼ同じように動作するためです。したがって、UTF-16は通常、固定サイズのエンコーディングとして処理できます。
@オーク：コメントするには長すぎます...
私はC＃について知りません（そして本当に驚かれることでしょう：それは彼らがJavaをコピーしすぎたことを意味します）が、Javaの場合それは単純です：JavaはUnicode3.1が出る前に考案されました。
したがって、65537未満のコードポイントがあり、すべてのUnicodeコードポイントはまだ16ビットに適合していたため、Java文字が生まれました。
もちろん、これは今日でもJavaプログラマー（私のような）に影響を与えているクレイジーな問題につながりました。ここでは、メソッドcharAtがあり、場合によってはUnicode文字もUnicodeコードポイントも返さず、メソッド（Java 5で追加）codePointAtスキップしたいコードポイントの数ではない引数を取ります！（スキップするJava文字の数をcodePointAtに指定する必要があります。これにより、Stringクラスで最も理解されていないメソッドの1つになります）。
だから、うん、これは間違いなくワイルドで、ほとんどのJavaプログラマーを混乱させます（ほとんどはこれらの問題にさえ気づいていません）、そして、うん、それは歴史的な理由によるものです。少なくとも、それはこの問題の後で人々が怒ったときに思いついた言い訳でした：しかしそれはUnicode3.1がまだ出ていなかったからです。
:)
UTF-16を使用するC＃は、内部でUTF-16を使用するオペレーティングシステムのWindowsNTファミリから派生していると思います。
WindowsNTが内部でUTF-16を使用する主な理由は2つあると思います。
他の人が答えたこととは反対に、UTF-16をUCS-2として扱うことはできません。文字列内の実際の文字を正しく反復処理する場合は、Unicode対応の反復関数を使用する必要があります。たとえば、C＃ではを使用する必要がありますStringInfo.GetTextElementEnumerator()。
詳細については、wikiのこのページを読む価値があります：http：//en.wikipedia.org/wiki/Comparison_of_Unicode_encodings
UTF-16は、ほとんどの文字を1つの16ビットワードで表現できる中国語、日本語、韓国語などの一部の言語で文字を表現する場合に、より効率的になります。まれにしか使用されない文字の中には、2つの16ビットワードが必要なものがあります。UTF-8は一般に、西ヨーロッパの文字セットの文字を表すのにはるかに効率的です（UTF-8とASCIIはASCII範囲（0〜127）で同等です）が、アジア言語では効率が低く、文字を表すのに3バイトまたは4バイトが必要です。 UTF-16では2バイトで表すことができます。
UTF-16は、基本多言語面のすべての文字を16ビットで表すことができるという点でJava / C＃のメモリ内形式としての利点があり（ジョーの回答を参照）、UTF-16のいくつかの欠点（たとえば、コードに依存する混乱）があります。 \ 0ターミネータ）はあまり関連性がありません。
予想される文字セットによって異なります。7ビットASCII範囲外のUnicodeコードポイントの多用が予想される場合、一部のUTF-8シーケンスは2バイトを超える長さであるため、UTF-16はUTF-8よりもコンパクトであることがわかる場合があります。
また、効率上の理由から、JavaとC＃は、文字列のインデックスを作成するときにサロゲートペアを考慮しません。これは、奇数バイトを占めるUTF-8シーケンスで表されるコードポイントを使用する場合に完全に機能しなくなります。
多くの (ほとんどの?) アプリケーションでは、Basic Multilingual Planeの文字のみを扱うため、UTF-16 を固定長エンコーディングとして扱うことができます。
したがって、UTF-8 などの可変長エンコーディングの複雑さをすべて回避できます。