Javaのchar型は、特定のエンコーディングに格納されることが保証されていますか?Javaのcharがどのエンコーディングに格納されていますか?
編集:私はこの質問を誤って言いました。私が尋ねる意味は、は、特定のエンコーディングを使用することが保証されているcharリテラルですか?
Javaのchar型は、特定のエンコーディングに格納されることが保証されていますか?Javaのcharがどのエンコーディングに格納されていますか?
編集:私はこの質問を誤って言いました。私が尋ねる意味は、は、特定のエンコーディングを使用することが保証されているcharリテラルですか?
「保存済み」はどこですか? Javaのすべての文字列はrepresented in UTF-16です。ファイルに書き込まれたり、ネットワーク経由で送信されたり、他のものが送信されたときは、指定した文字エンコードを使用して送信されます。
編集:具体的にはchar
タイプの場合は、Character docsを参照してください。具体的には次のとおりです。「charデータ型...は元のUnicode仕様に基づいており、文字は固定幅の16ビットエンティティとして定義されています。したがって、char
〜int
をキャストすると、char
に実際にその文字セットの文字が含まれている場合、UTF-16の値は常にになります。 char
にランダムな値を入れただけでは、必ずしも有効なUTF-16文字であるとは限りません。同様に、不正なエンコーディングを使用して文字を読み取った場合も同様です。ドキュメントでは、char
に十分なスペースがないため、補助UTF-16文字がint
でしか表現できないことについて議論しています。このレベルで操作している場合、よく知っておくことが重要ですそれらのセマンティクスで。
元々、JavaはUCS-2を内部的に使用していました。現在はUTF-16を使用しています。この2つは、D800-DFFFを除き、実質的に同一です。これは、大文字の拡張表現の一部としてUTF-16で使用されます。
Java char
は、通常、aを保持するために使用されます。Unicode code unit;すなわち、有効なUTF-16シーケンスの一部である16ビット単位である。しかし、アプリケーションが実際に何を意味するかにかかわらず、16ビットの符号なしの値をchar
に入れることをアプリケーションが防止するものは何もありません。
ですから、Unicodeコード単位はchar
で表すことができるとchar
はUnicodeコード単位を表すことができます...しかし、これらのいずれも一般的なケースでは、必ずしも真実であることを言うことができます。
Java char
がどのように保存されているかについてのご質問にはお答えできません。単純に、それはあなたが「保存」で何を意味するかに依存して、言った:あなたは「実行中のプログラムで表現」を意味するならば、答えはJVMの実装固有のもの
。あなたが意味する場合(それがまたは特定のコンテキストに応じて、整列機械語であってもなくてもよいけれどもchar
データ型は、通常、16ビットマシンの整数として表されます。)
「ファイルに保存されている」か何かのようにその答えは、アプリケーションがそれをどのように保存するかについて、に完全に依存するです。
任意の特定のエンコーディングで保存されることが保証のJava char型ですか?
私が上記の答えに照らして、答えは「いいえ」です。実行中のアプリケーションでは、char
が何を意味するのかは、アプリケーションによって決まります。 char
がファイルに保存されると、アプリケーションはそのファイルの保存方法と使用するディスク上の表現を決定します。
フォロー
何文字リテラルは?たとえば、 'c'には言語で定義された値が必要です。
これは文字のリテラルの形式とその文字に依存します。たとえば、 'c'は小文字の 'c'のUnicodeコードポイントの下位16ビットの値を持ちます。しかし、 '\ uxxxx'として表現されたリテラルは、有効なUnicodeコードポイントを表すことはできません。または(アプリケーションの意味に応じて)文字を全く表さないかもしれません。
これは、ソースコードファイルのエンコーディングによって(潜在的に)複雑になります。理論的には、(大文字のために)大文字が小文字でエンコードされ、その逆も同様であるカスタム文字エンコードでソースコードを表現することは可能です。これを実行し、コンパイラを起動する前に対応するCharsetエンコーダとデコーダを登録できた場合、'c'
(ASCIIまたはUTF-8として入力を表示)のようなリテラルは、実際にはコンパイラプログラムの値67
99
ではなく
少なくとも私はそう...ここ
とは別のエッジケースだと思う:
String s = "\u0001\uxxxx";
は2つのコード単位と一つのコードポイントを含む文字列を表すが、
char c = '\u0001\uxxxx';
ですパーサーは1つのコードポイントを認識しますが、そのコードポイントはchar
に収まりません。
あなたの質問への簡単な回答は、**いいえ保証されていません** –
はい、あります。内部表現は非常によく定義されています。 –
@Ernest - そうではありません。標準のJavaライブラリクラスの多くは、 'char'にUnicodeコードユニットが含まれていると仮定して動作するように設計されていますが、アプリケーションは基本的に16ビットの符号なし整数値を' char'に入れます。この値は、特定の方法でエンコードする必要はありません。完全な(または部分的な) "文字"を表す必要はありません。 –