I 最近学習したもの Javaソースコード内でUnicodeがUnicode文字としてのみ許可されないこと(例:double π = Math.PI;
)だけでなく、エスケープシーケンスとしても(例:double \u03C0 = Math.PI;
)。
最初の変形は私には理にかなっています-それはプログラマーが彼らの選択した国際言語で変数とメソッドに名前を付けることを可能にします。しかし、私は2番目のアプローチの実用的なアプリケーションを見ていません。
Java SE6およびNetBeans6.9.1でテストされた使用法を説明するためのコードをいくつか示します。
このコードは3.141592653589793を出力します
public static void main(String[] args) {
double π = Math.PI;
System.out.println(\u03C0);
}
説明:πと\ u03C0は同じUnicode文字です
このコードは何も出力しません
public static void main(String[] args) {
double π = Math.PI; /\u002A
System.out.println(π);
/* a comment */
}
説明:上記のコードは実際にエンコードします:
public static void main(String[] args) {
double π = Math.PI; /*
System.out.println(π);
/* a comment */
}
印刷物をコメントアウトするもの。
私の例から、この言語機能には多くの潜在的な問題があることに気づきました。
まず、悪いプログラマーはそれを使ってコードの一部を密かにコメント化したり、同じ変数を識別する複数の方法を作成したりできます。おそらく、私が考えもしなかったことができる他の恐ろしいことがあります。
第二に、IDE間のサポートが不足しているようです。 NetBeansもEclipseも、例の正しいコード強調表示を提供していませんでした。実際、NetBeansは構文エラーさえマークしていました(コンパイルは問題ではありませんでした)。
最後に、この機能は十分に文書化されておらず、一般に受け入れられていません。プログラマーが自分のコードで、他のプログラマーが認識および理解できないものを使用するのはなぜですか?実際、私はこれについて何かを見つけることさえできませんでした 非表示Java機能の質問 。
私の質問はこれです:
Javaは、エスケープされたUnicodeシーケンスを構文内で使用できるようにするのはなぜですか?多くの「短所」があるにもかかわらず、Javaの一部であり続けることができるこの機能の「長所」は何ですか?
Unicodeエスケープシーケンスを使用すると、ソースコードを純粋なASCIIで保存および送信しながら、Unicode文字の全範囲を使用できます。これには2つの利点があります。
非ASCII文字を処理できないツールによって非ASCII文字が壊れるリスクはありません。これは、Javaが設計された1990年代初頭に、真の懸念事項でした。非ASCII文字を含む電子メールを送信し、それをマングルなしで送信することは、標準ではなく例外でした。
ソースコードの解釈に使用するエンコーディングをコンパイラとエディタ/ IDEに指示する必要はありません。これは依然として非常に有効な懸念事項です。もちろん、はるかに優れた解決策は、(XMLのように)ファイルヘッダーにメタデータとしてエンコードを含めることでしたが、これは当時のベストプラクティスとしてまだ登場していませんでした。
最初の変形は私には理にかなっています-それはプログラマーが彼らの選択した国際言語で変数とメソッドに名前を付けることを可能にします。しかし、私は2番目のアプローチの実用的なアプリケーションを見ていません。
どちらもまったく同じバイトコードになり、言語機能と同じパワーを持ちます。唯一の違いはソースコードです。
まず、悪いプログラマーはそれを使ってコードの一部を密かにコメント化したり、同じ変数を識別する複数の方法を作成したりできます。
プログラマーが心配な場合故意にコードの可読性を妨害する場合、この言語機能は問題の中で最も少ないものです。
第二に、IDE間のサポートが不足しているようです。
これは、機能やその設計者のせいではありません。しかし、その後、「手動」で使用することを意図したものではないと思います。理想的には、IDEには、文字を通常どおりに入力して通常どおりに表示するオプションがありますが、Unicodeエスケープシーケンスとして自動的に保存されます。プラグインや構成オプションがすでに存在する場合もあります。 IDEはそのように動作します。
しかし、一般的に、この機能はほとんど使用されていないようであり、したがっておそらくサポートが不十分です。しかし、Javaを設計した人々は、どうやってそれを知っていたのでしょうか。
\u03C0
エンコーディングの良いところは、エンコーディング設定が間違っているテキストエディタによって変更される可能性がはるかに低いことです。たとえば、私のソフトウェアのバグは、誤って構成されたテキストエディタによってUTF-8 é
からMacRomané
に誤って変換されたことが原因でした。 Unicodeコードポイントを指定することにより、意味が完全に明確になります。
\ uXXXX構文を使用すると、Unicode文字を、直接表現できないエンコーディングを使用してファイル内で明確に表現できます。または、最小公分母、つまり7ビットのASCIIエンコーディング。
あなたcouldすべての文字を\ uXXXXで表し、スペースや文字も含めますが、そうする必要はめったにありません。
まず、質問ありがとうございます。とても面白いと思います。第二に、その理由は、Javaソースファイルはそれ自体でさまざまな文字セットを使用できるテキストであるためです。たとえば、Eclipseのデフォルトの文字セットはCp1255です。このendodingはπのような文字をサポートしていません。彼らは、Unicodeをサポートしないシステムで作業する必要があるプログラマーについて考え、これらのプログラマーがUnicode対応のソフトウェアを作成できるようにしたいと考えていました。これが\ u表記をサポートする理由でした。