Проблема разбора escape-кода Unicode в литерале Java 6 String ...?

Question

Почему этот компилятор в Java 6 (Вс 1.6.0_16):

System.out.println("\u000B");

... но не это:

System.out.println("\u000A");

В этой программе:

public class Test {
  public static void main(String argv[]) {
  System.out.println("\u000A");
  }
}

Я получаю

Test.java:3: unclosed string literal
System.out.println("\u000A");

Что здесь происходит?

Answer 1

Проблема в том, что замена Юникода выполняется очень рано во время компиляции.Экранирование Unicode не только допустимо в строках и символьных литералах (как и другие escape-последовательности, такие как \t) - они действительны в любом месте в коде.Они описаны в другой области спецификации - раздел 3.3 , а не раздел 3.10.6 ;только последний - это символьный и строковый литерал escape-последовательности.

В основном, прочитайте раздел 3 спецификации для получения более подробной информации о лексической структуре:)

Итак, ваш код был фактически эквивалентно:

public class Test {
  public static void main(String argv[]) {
  System.out.println("
");
  }
}

... что явно не является допустимым кодом.Для возврата каретки и перевода строки, в основном, лучше использовать escape-последовательности "\ r" и "\ n".

Лично я рассматриваю эту обработку выхода из Юникода как недостаток в Java, но не так уж многомы можем сделать это сейчас: (

Answer 2

Выходные коды Unicode расширяются до лексического анализа. Тот факт, что экранирование Unicode появляется внутри строкового литерала, не имеет значения. См. JLS 3.2.

• Ресурс

Answer 3

это потому, что \ u000a = \ n и компилятор обрабатывает исходный код java для преобразования его в токены, поэтому вы не можете использовать этот символ юникода в своем коде. То же самое для \ u000d = \ r

Answer 4

Если я не ошибаюсь, чтобы избежать предварительной обработки, мы могли бы решить ее, изменив строку в:

System.out.println((char)10);

Ограничение состоит в том, что, будучи CHAR, его расширение будет от 0 до 255.