Problema analisi unicode fuga in Java 6 String letterale ...?
Domanda
Perché questo compilazione in Java 6 (Sun 1.6.0_16):
System.out.println("\u000B");
... ma non questa:
System.out.println("\u000A");
In questo programma:
public class Test {
public static void main(String argv[]) {
System.out.println("\u000A");
}
}
ho un
Test.java:3: unclosed string literal
System.out.println("\u000A");
Che cosa sta succedendo qui?
Soluzione
Il problema è che la sostituzione Unicode è fatto molto presto nella compilazione. fughe Unicode non sono solo validi nelle stringhe letterali e di caratteri (come altre sequenze di escape, come \t
sono) - sono validi ovunque nel codice. Sono descritti in una zona diversa della specifica - sezione 3.3 piuttosto che sezione 3.10.6 ; Solo quest'ultimo è relativa a carattere e stringa letterale sequenze di escape.
In sostanza, la sezione di lettura 3 della specifica per maggiori dettagli sulla struttura lessicale:)
Quindi, il codice è stato effettivamente equivalente a:
public class Test {
public static void main(String argv[]) {
System.out.println("
");
}
}
... che non è chiaramente un codice valido. Per ritorno a capo e avanzamento riga, in fondo è meglio utilizzare il "\ r" e "\ n" sequenze di escape.
Personalmente visualizzare questo trattamento dei Unicode sfuggire come un difetto in Java, ma non c'è molto che possiamo fare a questo proposito la società: (
Altri suggerimenti
fugheUnicode vengono espansi prima dell'analisi lessicale. Il fatto che la fuga Unicode appare all'interno di un letterale di stringa è irrilevante. Vedere JLS 3.2.
è perché \ u000a = \ n e il processo di compilazione del sorgente Java al fine di convertirlo in token, quindi non è possibile utilizzare tale carattere Unicode nel codice. Lo stesso vale per \ u000d = \ r
Se non mi sbaglio, per evitare il prepocessing potremmo risolverlo cambiando la riga in:
System.out.println((char)10);
La limitazione è che essendo un CHAR
, esso di estensione sarà da 0 a 255.