5

JavaSpecialists ニュースレターの最新版で、著者は Java でコンパイルできないコードについて言及しています。

public class A1 {
  Character aChar = '\u000d';
}

コンパイルしてみると、次のようなエラーが表示されます。

A1.java:2: 文字リテラルの不正な行末
              文字 aChar = '\u000d';
                                ^

同等の C# コードがこのような問題を示さないのはなぜですか?

public class CharacterFixture
{
  char aChar = '\u000d';
}

何か不足していますか？

編集: 私の当初の質問の意図は、c# コンパイラがどのようにして Unicode ファイルを正しく解析したか (もしそうなら)、なぜ Java が正しくない (もしそうなら) 解析に固執する必要があるかということでした。編集:また、元の質問のタイトルを復元したいですか? なぜそんなに重い編集をしたのか、それが私の意図を大幅に変更したのではないかと強く疑っています.

4

1 に答える 1

12

Java のコンパイラ\uxxxxは、トークナイザーがコードを解読する前であっても、最初のステップの 1 つとしてエスケープ シーケンスを変換します。実際にトークン化を開始するまでには、\uxxxxシーケンスはもうありません。それらはすでに文字に変換されているため、コンパイラにとっては、Java の例は、実際にキャリッジ リターンを何らかの方法で入力した場合と同じように見えます。これは、ソース ファイルのエンコーディングに関係なく、ソース内で Unicode を使用する方法を提供するために行われます。ASCII テキストでさえ、必要に応じて (読みやすさを犠牲にして) Unicode 文字を完全に表すことができます。これは非常に早い段階で行われるため、コードのほとんどどこにでも含めることができます。( と言う\u0063\u006c\u0061\u0073\u0073\u0020\u0053\u0074\u0075\u0066\u0066\u0020\u007b\u007dと、コンパイラはそれを次のように読み取ります。class Stuff {}、迷惑をかけたり、自分を苦しめたりしたい場合。）

C# はそうしません。 \uxxxx後でプログラムの残りの部分とともに変換され、特定の種類のトークン (つまり、識別子と文字列/文字リテラル) でのみ有効です。これは、Java で使用できる特定の場所では使用できないことを意味します。 cl\u0061ssたとえば、キーワードではありません。

于 2012-10-29T06:12:01.743 に答える