WWWなどで英語以外のテキストにUTF-8を使用することはどの程度広く行われていますか？統計データと特定の国の状況の両方に興味があります。
ISO-8859-1（または15）がドイツにしっかりと定着していることを私は知っています - しかし、日本や中国のように、とにかくマルチバイトエンコーディングを使わなければならない言語はどうですか？数年前、日本はまださまざまなJISエンコーディングをほぼ独占的に使用していたことを私は知っています。
これらの観察を考えると、UTF-8が最も一般的なマルチバイトエンコーディングであることさえ本当ですか？それとも、特に国際市場をターゲットにしている、または多言語テキストを扱わなければならない新しいアプリケーションで内部的にしか使用されていないと言うのがより正しいでしょうか。今日では、その出力にUTF-8のみを使用するアプリ、または他のアプリで使用できるようにするために各国の市場で出力ファイルが異なるレガシーエンコーディングになっていることを想定しているアプリはありますか。
編集する 私は、UTF-8が有用であるのか、それともなぜそれが機能するのかを尋ねません。私はそれをすべて知っています。私はそれが実際に広く採用されているのか、そして古いエンコーディングを置き換えているのかを尋ねています。
私たちはサービス指向のWebサービスの世界ではほぼ排他的にUTF-8を使用しています - たとえ西欧諸国の言語でさえ、頭を回転させるのに十分な "奇妙なこと"があります。 8は本当に完全にそれを解決します。
だから私は大きいいたるところでいつでもUTF-8の使用に投票してください！ :-)私は、サービス指向の世界、そして.NETとJavaの環境ではあると思いますが、それはもう問題ではなく潜在的な問題でもありません。
それはただあなたが本当にいつも対処する必要がないように多くの問題を解決するだけです......
マーク
UTF-8だけを受け入れることは受け入れられないと思います - あなたはUTF-8を受け入れている必要があります。
良いニュースは、8859-1 / 15とASCIIがほとんどあるドイツの状況から来ているのであれば、さらに8859-1を受け入れてそれをUTF-8に変換することは基本的にゼロコストであるということです。検出は簡単です。たとえば、8859-1でエンコードされたöまたはüを使用することは、簡単に検出できる無効なペアに入らずに、無効なUTF-8です。 128-159の文字を使用しても8859-1は有効ではありません。最初の上位バイトから数バイト以内で、どのエンコーディングが使用されているかについて、一般的に非常に優れた考えを持つことができます。仕様がわかっているかどうかにかかわらず、エンコーディングを知っていれば、8859-1をUnicodeに変換するための変換テーブルは不要です。U+ 0080からU + 00FFまでは、8859-1の0x80-0xFFとまったく同じです。 。
私は訪問しがちですルーネットウェブサイトはかなり頻繁に。それらの多くはまだ使用していますWindows-1251エンコーディング。また、Yandex MailとMail.ru（CIS諸国で最大の2つのWebメールサービス）のデフォルトのエンコーディングです。また、ロシアのIPアドレスからダウンロードすると、Operaブラウザのデフォルトのコンテンツエンコーディング（この地域で人気のFirefoxの2番目）としても設定されています。私は他のブラウザについてはよくわかりません。
その理由は非常に簡単です。UTF-8では、キリル文字をエンコードするのに2バイトが必要です。非Unicodeエンコードは1バイトのみを必要とします（ほとんどの東部アルファベットのキリル文字とは異なり）。それらは固定長でもあり、古いASCIIのみのツールで簡単に処理できます。
それは今日では許容されますか その中でUTF-8のみを使用するアプリ 出力、または各国内市場か 出力ファイルが するための異なるレガシーエンコーディング 他のアプリで使えるようにする
うーん、私たちが話しているアプリや出力の種類に依存します...多くの場合（例えば、ほとんどのWebベースのもの）あなたは確かにUTF-8だけで行くことができますが、例えば許可するデスクトップアプリケーションでは一部のデータをプレーンテキストファイルに保存するためには、UTF-8だけが必要だと思いますではない十分な。
Mac OS Xは広くUTF-8を使用しています、そしてそれはユーザのファイルのためのデフォルトのエンコーディングです、そしてこれは大部分の（すべての？）主要なLinuxディストリビューションでもそうです。しかし、Windowsでは... Windows-1252（ISO-8859-1に近いが同じではありません）は、依然として多くの言語のデフォルトのエンコード方式ですか？少なくともWindows XPではそうでしたが、これが変わったかどうかはわかりませんか？いずれにせよ、かなりの数の（大部分がWindows）ユーザーがWindows-1252（またはそれに近いもの）でエンコードされたコンピューター上のファイルを持っている限り、UTF-8のみをサポートすることは多くの人にとって悲しみと混乱を引き起こすでしょう。
いくつかの国固有の情報：フィンランドではISO-8859-1（または15）も同様にまだしっかりしています。一例として、フィンランドのIRCチャンネルは、afaik、いまだにLatin-1を使用しています。 （これはLinuxがテキストベースのクライアント（例えばirssi）を使用するシステムデフォルトとしてUTF-8を使用している人たちがいくつかの回避策をするか、設定を微調整する必要があることを意味します。）
これが私が見つけたいくつかの統計です：
どちらのページも重大な問題を抱えているようです。
さらに重要なことに、統計はWebでアクセス可能なコンテンツ専用です。より広い統計（例えば、ユーザのハードドライブ上の文書の符号化について）は入手可能であるようには思われない。 （多くの国で必要とされる研究を行うことがどれほど困難で費用がかかるかを考えると、これは私を驚かせない。）
つまり、あなたの質問は客観的に答えられるものではありません。あなたは、UTF-8のみのアプリケーションが特定の国でどの程度「許容可能」であるかに関する研究をどこかに見つけることができるかもしれませんが、私は見つけることができませんでした。
私にとっては、アプリケーションが文字エンコーディングにとらわれずにドキュメントを保存するためにどの文字エンコーディングを使用するかをユーザーに決定させることをお勧めします。これはJavaやC#のような現代の言語では比較的簡単です。
CJK文字のユーザーは、2文字ではなくそれぞれ3バイトになるため、当然UTF-8に対してバイアスがかけられます。明らかに、中国ではUTF-16ではなく、独自の2バイトGBKエンコーディングが優先されます。
編集する@Joshuaのコメントに返信：
HTMLとJavaScriptの文字は1バイトにエンコードされるため、ほとんどのWeb作業では、いずれにせよページはUTF-8で小さくなります。
応答：
GB。+エンコーディングおよびその他の東アジアエンコーディングは可変長エンコーディングです。最大0x7Fまでの値を持つバイトは、ほとんどASCIIにマッピングされます（時々マイナーなバリエーションがあります）。上位ビットが設定されたバイトの中には、2から4バイトのシーケンスの先頭バイトであるものもあれば、違法なものもあります。 UTF-8と同じです。
「HTMLとJavascriptの文字」もASCII文字なので、それらのエンコーディングでもUTF-8でも、常に1バイトになっています。
UTF-8は一般的にUTF-16よりもコンパクトで、忠実度が高いため人気があります。また、UTF-16のエンディアンの問題もありません。
これは交換フォーマットとしては最適な選択ですが、文字はさまざまなバイトラン（1文字あたり1〜4バイト）にエンコードされるため、必ずしも使用するのがあまり良いとは言えません。そのため、データ交換のためにUTF-8を予約し、開始点と終了点で変換を使用する方が通常はクリーンです。
システムの内部ストレージ（ディスクファイルやデータベースを含む）では、ネイティブのUTF-16、他の圧縮を使ったUTF-16、あるいは8ビットの "ANSI"エンコーディングを使う方がおそらくきれいです。後者はもちろんあなたを特定のコードページに限定し、あなたが多言語テキストを扱っているならあなたは苦しむことができます。データをローカルで処理するには、おそらく "ANSI"エンコーディングかネイティブのUTF-16が必要です。文字処理はずっとそのように簡単な問題。
それで、私はUTF-8が普及していることを示唆します外的にしかし、内部的には稀です。内部的には、UTF-8は静的テキストBLOB以外には悪夢のようです。
一部のDBMSは、テキストBLOBを常にUTF-8として保存することを選択しているようです。これは、別の圧縮方式を考案しようとせずに（UTF-16を格納するよりも）圧縮の利点を提供します。 UTF-8との間の変換は非常に一般的なので、それらはおそらく効率的かつ確実に機能することが知られているシステムライブラリを利用します。
「ANSI」方式の最大の問題は、単一の小さな文字セットに限られており、大きなアルファベットを持つ言語のマルチバイト文字セットシーケンスを処理する必要があることです。
統計的に興味があります データと具体的な状況 国です。
W3Techでは、これらすべてのデータがありますが、おそらく見つけるのは簡単ではありません。
たとえば、最初に言語を選択して日本語のWebサイトの文字エンコード分布を取得します。コンテンツの言語>日本語を選択し、次にSegmentation> Character Encodingsを選択します。それはこのレポートにあなたをもたらします：日本語を使用するWebサイト間での文字エンコーディングの分布。ご覧のとおり、日本のサイトでは49％のSHIFT-JISと38％のUTF-8が使用されています。トップレベルドメインごとに同じことができます。すべての.jpサイトを言います。
JavaとC#はどちらも内部でUTF-16を使用しており、他のエンコーディングに簡単に変換できます。それらは企業の世界にかなり定着しています。
入力としてUTFだけを受け入れることは、最近それほど大きな問題ではないと思います。頑張れ。
統計的に興味があります データと具体的な状況 国です。
私はこれが問題領域とその歴史にもっと依存していると思います、そしてアプリケーションが使用される国に依存します。
競合他社のすべてが出力しているアプリケーションを作成している場合。 ISO-8859-1（または過去10年間の大半の間行われてきた）、私はあなたの（潜在的な）すべてのクライアントがあなたがそれほど苦労せずにそのようなファイルを開くことを期待すると思います。
そうは言っても、私はUTF-8でエンコードされたファイル以外は何も出力する必要があるとはほとんど考えていません。ほとんどのプログラムは最近対応していますが、繰り返しますが、YMMVはターゲット市場によって異なります。