¿En qué codificación está almacenado un carácter Java?

Question

¿Está garantizado que el tipo de caracteres Java se almacene en cualquier codificación en particular?

Editar: He formulado esta pregunta incorrectamente. Lo que quise preguntar es ¿Están los caracteres literales garantizados para usar cualquier codificación particular?

Answer 1

"Almacenado" ¿dónde? Todas las cadenas en Java son represented in UTF-16. Cuando se escribe en un archivo, se envía a través de una red, o lo que sea, se envía utilizando la codificación de caracteres que especifique.

Edición: Específicamente para el tipo char, consulte el Character docs. Específicamente: "El tipo de datos char ... se basa en la especificación original Unicode, que define los caracteres como entidades de 16 bits de ancho fijo". Por lo tanto, fundir char en int siempre le dará un valor UTF-16 si en realidad contiene char un carácter de ese juego de caracteres. Si simplemente introdujo un valor aleatorio en char, obviamente no será necesariamente un carácter UTF-16 válido, y del mismo modo si lee el carácter al usar una codificación incorrecta. Los documentos continúan para analizar cómo los caracteres suplementarios UTF-16 solo pueden representarse con un int, ya que char no tiene espacio suficiente para contenerlos, y si está operando en este nivel, podría ser importante familiarizarse con con esa semántica.

Answer 2

Originalmente, Java usaba UCS-2 internamente; ahora usa UTF-16. Los dos son prácticamente idénticos, a excepción de D800 - DFFF, que se utilizan en UTF-16 como parte de la representación ampliada para caracteres más grandes.

Answer 3

Java char se utiliza convencionalmente para celebrar una Unicode code unit; es decir, una unidad de 16 bits que es parte de una secuencia UTF-16 válida. Sin embargo, no hay nada que impida que una aplicación coloque un valor sin signo de 16 bits en char, independientemente de lo que realmente signifique.

Así que se podría decir que una unidad de código Unicode puede ser representado por un char y una charpuede representan una unidad de código Unicode ... pero ninguno de ellos es necesariamente cierto, en el caso general.

No se puede responder su pregunta sobre cómo se almacena un Java char. Simplemente dicho, depende de lo que entendemos por "almacenado":

• Si se refiere a "representada en un programa en ejecución", entonces la respuesta es la implementación JVM específica. (El tipo de datos char se suele representar como un número entero máquina de 16 bits, aunque puede o no puede ser la palabra máquina de alineado, dependiendo del contexto específico.)

• Si se refiere a "almacenados en un archivo" o algo parecido eso, entonces la respuesta es completamente dependiente sobre cómo la aplicación elige almacenarlo.

---

es el tipo Char Java garantizado para ser almacenados en cualquier codificación particular?

A la luz de lo que dije antes, la respuesta es "No". En una aplicación en ejecución, corresponde a la aplicación decidir qué significa char/contains. Cuando se almacena un archivo char, la aplicación decide cómo quiere almacenarlo y qué representación en disco usará.

---

FOLLOWUP

¿Qué pasa con los literales Char? Por ejemplo, 'c' debe tener algún valor que esté definido por el idioma.

Depende de la forma literal del carácter y del carácter. Por ejemplo, 'c' tendrá el valor de los 16 bits inferiores del punto de código Unicode para 'c' en minúscula. Pero un literal expresado como '\ uxxxx' puede no representar un punto de código Unicode válido. O (dependiendo de lo que signifique la aplicación) puede no representar un personaje en absoluto.

Esto también es (potencialmente) complica por la codificación del archivo de código fuente. Es teóricamente posible representar su código fuente en una codificación de caracteres personalizada en la que (por razones de argumento) las letras mayúsculas se codifican como minúsculas, y viceversa. Si lo ha hecho, y que fueron capaces de registrar el codificador juego de caracteres correspondiente y el decodificador antes de lanzar el compilador, a continuación, un literal que se parece a 'c' (ver la entrada como ASCII o UTF-8) en realidad tendría el valor 67 en el programa compilador en lugar de 99.

Al menos eso creo ...

Y aquí es otro caso extremo:

String s = "\u0001\uxxxx"; 

representa una cadena que contiene dos unidades de código y un punto de código, pero

char c = '\u0001\uxxxx'; 

es (o debería ser) ilegal ... porque aunque el analizador ve un punto de código, ese punto de código no cabe en un char.