2012-04-28 21 views
13

Algunos compiladores fallaron en caracteres no ASCII en JavaDoc y comentarios de código fuente. ¿Cuáles son las prácticas actuales (Java 7) y futuras (Java 8 y posteriores) con respecto a Unicode en los archivos fuente de Java? ¿Hay diferencias entre IcedTea, OpenJDK y otros entornos Java, y qué se dicta la especificación del lenguaje? Deberían escapar todos los caracteres que no sean ASCII en JavaDoc con HTML & escape; -como códigos? Pero ¿cuál sería el Java // comment equivalente?Unicode en javadoc y comentarios?

Actualización: los comentarios indican que se puede usar cualquier conjunto de caracteres, y que al compilar uno debe indicar qué conjunto de caracteres se utiliza en el archivo fuente. Analizaré esto y buscaré detalles sobre cómo configurar esto a través de Ant, Eclipse y Maven.

+1

Eche un vistazo a [esto] (http://en.wikibooks.org/wiki/Java_Programming/Syntax/Unicode_Source) (estoy seguro de que esto lo especifica JLS). –

+5

En realidad, puede usar cualquier codificación que desee en sus archivos fuente, solo necesita indicar cuál eligió para el compilador Java y la línea de comandos javadoc. –

+0

OK, ¡este es el tipo de información que estoy buscando! Primero, esto es genial, y no estaba enterado de esto. Entonces, ahora solo necesito averiguar cómo hacer que el compilador sepa qué conjunto de caracteres usar ... por ejemplo, el CDK se compila usando Ant, Maven y Eclipse ... –

Respuesta

12

Algunos compiladores fallaron en caracteres no ASCII en JavaDoc y el código fuente de los comentarios.

Esto es probable porque el compilador supone que la entrada es UTF-8, y hay secuencias UTF-8 no válidas en el archivo de origen. Que estos aparecen en los comentarios en el editor de código fuente es irrelevante porque el lexer (que distingue los comentarios de otros tokens) nunca se ejecuta. La falla ocurre mientras la herramienta intenta convertir bytes en caracteres antes de que se ejecute el lexer.


La página man para javac y javadoc dicen

-encoding name 
      Specifies the source file encoding name, such as 
      EUCJIS/SJIS. If this option is not specified, the plat- 
      form default converter is used. 

lo que la ejecución javadoc con la bandera de codificación

javadoc -encoding <encoding-name> ... 

después de reemplazar <encoding-name> con la codificación que ha utilizado para sus archivos de origen debería hacer que use la codificación correcta.

Si tiene más de una codificación utilizada dentro de un grupo de archivos de origen que necesita compilar a la vez, debe arreglarla primero y establecer una única codificación uniforme para todos los archivos fuente. Realmente debería usar UTF-8 o apegarse a ASCII.


Cuál es la corriente (Java 7) y el futuro (Java 8 y más allá) prácticas con respecto a Unicode en los archivos fuente de Java?

El algoritmo para resolver un archivo de código fuente en Java es

  1. bytes Collect
  2. Convertir bytes de caracteres (UTF-16) unidades de código utilizando alguna de codificación.
  3. Reemplace todas las secuencias de '\\''u' seguidas de cuatro dígitos hexadecimales con la unidad de código correspondiente a esos dígitos hexadecimales. Error al salir si hay un "\u" no seguido por cuatro dígitos hexadecimales.
  4. Lex los caracteres en tokens.
  5. Analiza los tokens en clases.

La práctica actual y anterior es que el paso 2, la conversión de bytes a 16 UTF-unidades de código, depende de la herramienta que se está cargando la unidad de compilación (archivo de origen), pero el estándar de facto para las interfaces de línea de comandos es para usar la bandera -encoding.

Después de que ocurra la conversión, el lenguaje exige que las secuencias de estilo \uABCD se conviertan a unidades de código UTF-16 (paso 3) antes de leer y analizar.

Por ejemplo:

int a; 
\u0061 = 42; 

es un par válido de sentencias Java. Cualquier herramienta de código fuente de Java deben, después de convertir bytes a caracteres, pero antes de analizar, buscar secuencias \ uABCD y convertirlos lo que este código se convierte en

int a; 
a = 42; 

antes de analizar. Esto sucede independientemente de dónde se produce la secuencia \ uABCD.

Este proceso se ve algo como

  1. Obtener bytes: [105, 110, 116, 32, 97, 59, 10, 92, 117, 48, 48, 54, 49, 32, 61, 32, 52, 50, 59]
  2. Convertir bytes de caracteres: ['i', 'n', 't', ' ', 'a', ';', '\n', '\\', 'u', '0', '0', '6', '1', ' ', '=', ' ', '4', '2', ';']
  3. Reemplazar Unicode escapa: ['i', 'n', 't', ' ', 'a', ';', '\n', a, ' ', '=', ' ', '4', '2', ';']
  4. Lex: ["int", "a", ";", "a", "=", "42", ";"]
  5. de análisis: (Block (Variable (Type int) (Identifier "a")) (Assign (Reference "a") (Int 42)))

caso de todos los caracteres no ASCII se escaparon en JavaDoc con HTML y escapar; -como los códigos?

No es necesario, excepto caracteres HTML especiales como '<' que desea que aparezcan literalmente en la documentación. Puede usar las secuencias \uABCD dentro de los comentarios de javadoc. proceso de Java \u.... antes de analizar el archivo fuente para que puedan aparecer dentro de las cadenas, comentarios, en cualquier lugar realmente.Es por eso que

System.out.println("Hello, world!\u0022); 

es una declaración válida de Java.

/** @return \u03b8 in radians */ 

es equivalente a

/** @return θ in radians */ 

como lo que se refiere javadoc.


Pero lo que sería el equivalente de Java // comentario?

Puede utilizar // comentarios en java, pero sólo se ve de Javadoc dentro /**...*/ comentarios para documentación. // comentarios no son portadores de metadatos.

Una ramificación de manejo de \uABCD secuencias de Java es que aunque

// Comment text.\u000A System.out.println("Not really comment text"); 

se parece a una sola línea de comentario, y muchos entornos de desarrollo pondrá de relieve que, como tal, no lo es.

+0

¿Las herramientas java respetan emacs/vim? metadatos sobre la codificación? – Marcin

+0

@Marcin, si se refiere a un comentario como '// - * - codificación: UTF-8 - * -' al comienzo del archivo, una herramienta podría elegir hacerlo, pero las herramientas de Sun no son AFAIK. –

+0

Decepcionante, gracias. – Marcin

4

Como indicaron los comentaristas, la codificación de los archivos fuente se puede pasar a (al menos algunos) compiladores. En esta respuesta, resumiré cómo pasar esta información.

Eclipse

Eclipse (3,7 marcada) no requiere ninguna configuración especial, y se puede usar sin problemas el código fuente de Java como:

double π = Math.PI; 

Ant

<javac encoding="UTF-8" ... > 
</javac> 

Java

javac -encoding UTF-8 src/main/Foo.java