「char変数はUnicode形式ですが、ASCIIにもうまく対応しています」と出くわしました。それについて言及する必要は何ですか？もちろん、ASCIIは1バイトで、Unicodeは2です。Unicode自体にはASCIIコードが含まれています（デフォルトでは、その標準です）。charでは、変数がUNICODEをサポートしているが、ASCIIはサポートしていない言語はありますか？
また、文字フォーマット（Unicode / ASCII）は、使用するプラットフォームによって決まりますよね？（UNIX、Linux、Windowsなど）。それで、私のプラットフォームがASCIIを使用したとすると、Unicodeに切り替えることはできませんか、またはその逆はできませんか？
Javaは内部でUnicodeを使用します。いつも。実際には、ほとんどの場合UTF-16を使用していますが、現時点では詳細すぎます。
内部でASCIIを使用することはできませんString（たとえば）。UnicodeでASCIIで表現できる任意の文字列を表現できるため、問題はありません。
プラットフォームが機能する唯一の場所は、エンコーディングを指定しなかったときにJavaがエンコーディングを選択する必要がある場合です。たとえば、文字列に値FileWriterを書き込むためにを作成する場合String：その時点で、Javaはエンコーディングを使用して、特定の文字をバイトにマップする方法を指定する必要があります。指定しない場合は、プラットフォームのデフォルトのエンコーディングが使用されます。そのデフォルトのエンコーディングはほとんどASCIIではありません。ほとんどのLinuxプラットフォームはUTF-8を使用し、WindowsはISO-8859- *派生物（または他の文化固有の8ビットエンコーディング）を使用することがよくありますが、現在のOSはASCIIを使用していません（ASCIIは多くの重要な文字を表すことができないため） 。
実際、最近では純粋なASCIIはほとんど関係ありません。誰もそれを使用していません。ASCIIは、ほとんどの8ビットエンコーディング（UTF-8を含む）のマッピングの一般的なサブセットとしてのみ重要です。下位128のUnicodeコードポイントは、多くのエンコーディングで数値0〜127に1：1でマッピングされます。ただし、純粋なASCII（値128〜255は未定義）はアクティブに使用されなくなりました。
ちなみに、Java 9には「コンパクト文字列」と呼ばれる内部最適化があり、Latin-1で表現可能な文字のみを含む文字列は、2ではなく文字ごとに1バイトを使用します。この最適化はあらゆる種類の「コンピュータスピーク」に非常に役立ちます。テキストの大部分がASCII範囲にあるXMLや同様のプロトコルのように。Stringただし、すべての処理はクラスの内部で行われ、外部からは見えないため、開発者には完全に透過的です。