Un poco de fondo: cuando Java apareció en 1995, el tipo char
se basaba en la especificación original "Unicode 88", que estaba limitada a 16 bits. Un año después, cuando se implementó Unicode 2.0, se introdujo el concepto de caracteres sustitutos para ir más allá del límite de 16 bits.
Java internamente representa todos String
s en formato UTF-16. Para los puntos de código que exceden U + FFFF, el punto de código está representado por un par sustituto, es decir, dos char
s; el primero es la unidad de código de subrogación alta (en el rango \ uD800- \ uDBFF), el segundo es el bajo unidad de código sustituto (en el rango \ uDC00- \ uDFFF).
Desde los primeros días, todos los métodos básicos de Character
se basaban en la suposición de que un punto de código se podía representar en un char
, de modo que así son las firmas de método. Supongo que para preservar la compatibilidad con versiones anteriores que no se modificó cuando llegó Unicode 2.0 y se necesita precaución al tratar con ellos. Para citar de Java documentation:
- Los métodos que solo aceptan un valor de char no pueden admitir caracteres suplementarios. Tratan los valores de char de los rangos de sustitución como caracteres indefinidos. Por ejemplo, Character.isLetter ('\ uD840') devuelve false, aunque este valor específico si es seguido por cualquier valor de bajo sustituto en una cadena representaría una letra.
- Los métodos que aceptan un valor int admiten todos los caracteres Unicode, incluidos los caracteres suplementarios. Por ejemplo, Character.isLetter (0x2F81A) devuelve verdadero porque el valor del punto de código representa una letra (un ideograma CJK).
Lanzamiento de la char
a un int
, como lo hace en su muestra, aunque funciona bien.
http://java.sun.com/developer/technicalArticles/Intl/Supplementary/ explica las decisiones de diseño detrás de los puntos de código en Java. – Gili