java - u00e9 - unicode accented characters
¿Por qué Java permite escapar caracteres unicode en el código fuente? (4)
La sintaxis / uXXXX permite que los caracteres Unicode se representen de manera inequívoca en un archivo con una codificación que no los puede expresar directamente, o si desea una representación garantizada para ser utilizada incluso en el mínimo común denominador, es decir, una codificación ASCII de 7 bits.
Puede representar a todos sus personajes con / uXXXX, incluso espacios y letras, pero rara vez es necesario.
Recientemente descubrí que Unicode está permitido dentro del código fuente de Java no solo como caracteres Unicode (por ejemplo, double π = Math.PI; ) sino también como secuencias escapadas (por ejemplo, double /u03C0 = Math.PI; ).
La primera variante tiene sentido para mí: permite a los programadores nombrar variables y métodos en un idioma internacional de su elección. Sin embargo, no veo ninguna aplicación práctica del segundo enfoque.
Aquí hay algunas piezas de código para ilustrar el uso, probado con Java SE 6 y NetBeans 6.9.1:
Este código se imprimirá 3.141592653589793
public static void main(String[] args) {
double π = Math.PI;
System.out.println(/u03C0);
}
Explicación: π y / u03C0 son el mismo carácter Unicode
Este código no imprimirá nada
public static void main(String[] args) {
double π = Math.PI; //u002A
System.out.println(π);
/* a comment */
}
Explicación: el código anterior en realidad codifica:
public static void main(String[] args) {
double π = Math.PI; /*
System.out.println(π);
/* a comment */
}
Lo cual comenta el estado impreso.
Solo por mis ejemplos, veo una serie de posibles problemas con esta función de idioma.
En primer lugar, un programador malo podría usarlo para comentar en secreto bits de código, o crear múltiples formas de identificar la misma variable. Quizás hay otras cosas horribles que se pueden hacer que no he pensado.
En segundo lugar, parece haber una falta de apoyo entre los IDEs. Ni NetBeans ni Eclipse proporcionaron el resaltado de código correcto para los ejemplos. De hecho, NetBeans incluso marcó un error de sintaxis (aunque la compilación no fue un problema).
Finalmente, esta función está poco documentada y no es comúnmente aceptada. ¿Por qué un programador usaría algo en su código que otros programadores no podrían reconocer y comprender? De hecho, ni siquiera pude encontrar algo sobre esto en la pregunta sobre Características ocultas de Java .
Mi pregunta es esta:
¿Por qué Java permite que las secuencias Unicode escapadas se usen dentro de la sintaxis? ¿Cuáles son algunos de los "pros" de esta característica que le han permitido mantenerse como parte de Java, a pesar de sus muchos "contras"?
Las secuencias de escape Unicode le permiten almacenar y transmitir su código fuente en ASCII puro y aún así usar todo el rango de caracteres Unicode. Esto tiene dos ventajas:
No hay riesgo de que los caracteres no ASCII se rompan por herramientas que no pueden manejarlos. Esta fue una preocupación real a principios de la década de 1990 cuando se diseñó Java. Enviar un correo electrónico que contenga caracteres que no sean ASCII y que llegue sin protección fue la excepción más que la norma.
No es necesario indicarle al compilador y editor / IDE qué codificación usar para interpretar el código fuente. Esta sigue siendo una preocupación muy válida. Por supuesto, una solución mucho mejor habría sido tener la codificación como metadatos en un encabezado de archivo (como en XML), pero esto aún no había surgido como una mejor práctica en ese entonces.
La primera variante tiene sentido para mí: permite a los programadores nombrar variables y métodos en un idioma internacional de su elección. Sin embargo, no veo ninguna aplicación práctica del segundo enfoque.
Ambos darán como resultado exactamente el mismo código de bytes y tendrán la misma potencia que una función de idioma. La única diferencia está en el código fuente.
En primer lugar, un programador malo podría usarlo para comentar en secreto bits de código, o crear múltiples formas de identificar la misma variable.
Si le preocupa que un programador sabotee deliberadamente la legibilidad de su código, esta característica del idioma es el menor de sus problemas.
En segundo lugar, parece haber una falta de apoyo entre los IDEs.
Eso no es culpa de la característica o sus diseñadores. Pero entonces, no creo que alguna vez fue pensado para ser usado "manualmente". Idealmente, el IDE tendría una opción para que ingrese los caracteres normalmente y los muestre normalmente, pero los guarde automáticamente como secuencias de escape Unicode. Incluso puede haber complementos o opciones de configuración que hagan que los IDE se comporten de esa manera.
Pero, en general, esta característica parece ser muy poco utilizada y, por lo tanto, mal respaldada. Pero, ¿cómo pudieron saberlo las personas que diseñaron Java en 1993?
Lo bueno de la codificación /u03C0 es que es mucho menos probable que sea grabada por un editor de texto con una configuración de codificación incorrecta. Por ejemplo, un error en mi software fue causado por la transformación accidental de UTF-8 é en una MacRoman é por un editor de texto mal configurado. Al especificar el punto de código Unicode, es completamente inequívoco lo que quiere decir.
Primero, gracias por la pregunta. Creo que es muy interesante. En segundo lugar, la razón es que el archivo fuente java es un texto que puede usar varios conjuntos de caracteres. Por ejemplo, el juego de caracteres predeterminado en Eclipse es Cp1255. Este endoding no admite caracteres como π. Creo que pensaron en los programadores que tienen que trabajar en sistemas que no son compatibles con Unicode y querían permitir que estos programadores crearan software habilitado para Unicode. Esta fue la razón para apoyar la notación.