UTF-16 ( 16-bit Unicode Transformation Format) es una codificación de caracteres capaz de codificar los 1.112.064 puntos de código válidos de Unicode (de hecho, este número de puntos de código está determinado por el diseño de UTF-16). La codificación es de longitud variable , ya que los puntos de código se codifican con una o dos unidades de código de 16 bits . UTF-16 surgió de una codificación anterior obsoleta de 16 bits de ancho fijo ahora conocida como "UCS-2" (para 2-byte Universal Character Set), [1] [2] una vez que quedó claro que se necesitaban más de 216 (65.536) puntos de código, [3] incluyendo la mayoría de los emoji y caracteres CJK importantes como los nombres personales y de lugares. [4]
El UTF-16 se utiliza en sistemas como la API de Microsoft Windows , el lenguaje de programación Java y JavaScript /ECMAScript. También se utiliza a veces para archivos de datos de procesamiento de texto y texto sin formato en Microsoft Windows. Se utiliza en implementaciones más modernas de SMS . [5]
UTF-16 es la única codificación (aún) permitida en la web que es incompatible con ASCII [6] [nb 1] y nunca ganó popularidad en la web, donde es declarada por menos del 0,003% de las páginas web. [8] UTF-8 , en comparación, representa más del 98% de todas las páginas web. [9] El Grupo de Trabajo de Tecnología de Aplicaciones de Hipertexto Web (WHATWG) considera que UTF-8 es "la codificación obligatoria para todo [texto]" y que por razones de seguridad las aplicaciones de navegador no deberían usar UTF-16. [10]
A finales de los años 1980, se empezó a trabajar en el desarrollo de una codificación uniforme para un "conjunto universal de caracteres" ( UCS , por sus siglas en inglés) que reemplazaría las codificaciones específicas de cada idioma por un sistema coordinado. El objetivo era incluir todos los caracteres necesarios de la mayoría de los idiomas del mundo, así como símbolos de ámbitos técnicos como la ciencia, las matemáticas y la música. La idea original era reemplazar las codificaciones típicas de 256 caracteres, que requerían 1 byte por carácter, por una codificación que utilizara 65.536 (2 16 ) valores, lo que requeriría 2 bytes (16 bits) por carácter.
Dos grupos trabajaron en este tema en paralelo: ISO/IEC JTC 1/SC 2 y el Consorcio Unicode , este último representando principalmente a fabricantes de equipos informáticos. Los dos grupos intentaron sincronizar sus asignaciones de caracteres para que las codificaciones en desarrollo fueran compatibles entre sí. La primera codificación de 2 bytes se llamó originalmente "Unicode", pero ahora se llama "UCS-2". [1] [2] [11]
Cuando se hizo cada vez más evidente que 2 16 caracteres no serían suficientes, [12] IEEE introdujo un espacio más grande de 31 bits y una codificación ( UCS-4 ) que requeriría 4 bytes por carácter. Esto fue resistido por el Consorcio Unicode , tanto porque 4 bytes por carácter desperdiciaban mucha memoria y espacio en disco, como porque algunos fabricantes ya habían invertido mucho en la tecnología de 2 bytes por carácter. El esquema de codificación UTF-16 se desarrolló como un compromiso y se introdujo con la versión 2.0 del estándar Unicode en julio de 1996. [13] Está completamente especificado en RFC 2781, publicado en 2000 por el IETF . [14] [15]
UTF-16 se especifica en las últimas versiones tanto del estándar internacional ISO/IEC 10646 como del estándar Unicode. "UCS-2 ahora debe considerarse obsoleto. Ya no se refiere a una forma de codificación ni en 10646 ni en el estándar Unicode". [1] [2] UTF-16 nunca se ampliará para admitir una mayor cantidad de puntos de código o para admitir los puntos de código que fueron reemplazados por sustitutos, ya que esto violaría la Política de estabilidad de Unicode con respecto a la categoría general o los puntos de código sustitutos. [16] (Cualquier esquema que siga siendo un código autosincronizado requeriría asignar al menos un punto de código del Plano multilingüe básico (BMP) para iniciar una secuencia. No se permite cambiar el propósito de un punto de código).
Cada punto de código Unicode se codifica como una o dos unidades de código de 16 bits . Los puntos de código menores de 2 16 ("en el BMP") se codifican con una sola unidad de código de 16 bits igual al valor numérico del punto de código, como en el antiguo UCS-2. Los puntos de código mayores o iguales a 2 16 ("por encima del BMP") se codifican utilizando dos unidades de código de 16 bits. Estas dos unidades de código de 16 bits se eligen del rango sustituto UTF-16 0xD800–0xDFFF que no se había asignado previamente a caracteres. Los valores en este rango no se utilizan como caracteres y UTF-16 no proporciona una forma legal de codificarlos como puntos de código individuales. Por lo tanto, una secuencia UTF-16 consta de códigos individuales de 16 bits fuera del rango sustituto y pares de valores de 16 bits que están dentro del rango sustituto.
Tanto UTF-16 como UCS-2 codifican los puntos de código en este rango como unidades de código de 16 bits que son numéricamente iguales a los puntos de código correspondientes. Estos puntos de código en el Plano Multilingüe Básico (BMP) son los únicos puntos de código que se pueden representar en UCS-2. [ cita requerida ] A partir de Unicode 9.0, algunos alfabetos asiáticos, de Oriente Medio y africanos modernos no latinos quedan fuera de este rango, al igual que la mayoría de los caracteres emoji .
Los puntos de código de los otros planos se codifican como dos unidades de código de 16 bits llamadas par sustituto . La primera unidad de código es un sustituto alto y la segunda es un sustituto bajo (estos también se conocen como sustitutos "principales" y "finales", respectivamente, análogos a los bytes principales y finales de UTF-8. [17] ):
Ilustrada visualmente, la distribución de U' entre W1 y W2 se ve así: [18]
U' = yyyyyyyyyyxxxxxxxxxx // U - 0x10000W1 = 110110yyyyyyyyyy // 0xD800 + yyyyyyyyyyW2 = 110111xxxxxxxxxx // 0xDC00 + xxxxxxxxxxDado que los rangos para los sustitutos altos ( 0xD800–0xDBFF ), sustitutos bajos ( 0xDC00–0xDFFF ) y caracteres BMP válidos (0x0000–0xD7FF, 0xE000–0xFFFF) son disjuntos , no es posible que un sustituto coincida con un carácter BMP, o que dos unidades de código adyacentes parezcan un par de sustitutos legales . Esto simplifica mucho las búsquedas. También significa que UTF-16 se sincroniza automáticamente en palabras de 16 bits: se puede determinar si una unidad de código comienza un carácter sin examinar unidades de código anteriores (es decir, el tipo de unidad de código se puede determinar por los rangos de valores en los que cae). UTF-8 comparte estas ventajas, pero muchos esquemas de codificación multibyte anteriores (como Shift JIS y otras codificaciones multibyte asiáticas) no permitían una búsqueda inequívoca y solo se podían sincronizar volviendo a analizar desde el principio de la cadena. UTF-16 no se sincroniza automáticamente si se pierde un byte o si el recorrido comienza en un byte aleatorio.
Debido a que los caracteres más utilizados se encuentran todos en el BMP, el manejo de pares sustitutos no suele probarse exhaustivamente. Esto genera errores persistentes y posibles agujeros de seguridad, incluso en aplicaciones de software populares y bien evaluadas (por ejemplo , CVE - 2008-2938, CVE-2012-2135).
El estándar oficial Unicode dice que ningún formato UTF, incluido el UTF-16, puede codificar los puntos de código sustitutos. Dado que nunca se les asignará un carácter, no debería haber ninguna razón para codificarlos. Sin embargo, Windows permite sustitutos no emparejados en nombres de archivo [19] y otros lugares, lo que generalmente significa que deben ser compatibles con el software a pesar de su exclusión del estándar Unicode.
UCS-2, UTF-8 y UTF-32 pueden codificar estos puntos de código de formas triviales y obvias, y una gran cantidad de software lo hace, aunque el estándar establece que tales disposiciones deben tratarse como errores de codificación.
Es posible codificar de forma inequívoca un sustituto no emparejado (un punto de código sustituto alto no seguido por uno bajo, o uno bajo no precedido por uno alto) en el formato UTF-16 utilizando una unidad de código igual al punto de código. El resultado no es un código UTF-16 válido, pero la mayoría de las implementaciones de codificadores y decodificadores UTF-16 lo hacen al traducir entre codificaciones. [ cita requerida ]
Para codificar U+10437 (𐐷) a UTF-16:
Para decodificar U+10437 (𐐷) de UTF-16:
La siguiente tabla resume esta conversión, así como otras. Los colores indican cómo se distribuyen los bits del punto de código entre los bytes UTF-16. Los bits adicionales agregados por el proceso de codificación UTF-16 se muestran en negro.
UTF-16 y UCS-2 producen una secuencia de unidades de código de 16 bits. Dado que la mayoría de los protocolos de comunicación y almacenamiento están definidos para bytes y cada unidad ocupa dos bytes de 8 bits, el orden de los bytes puede depender del orden de bytes de la arquitectura informática.
Para ayudar a reconocer el orden de bytes de las unidades de código, UTF-16 permite que una marca de orden de bytes (BOM), un punto de código con el valor U+FEFF, preceda al primer valor codificado real. [nb 2] (U+FEFF es el carácter de espacio invisible de ancho cero no divisible /ZWNBSP). [nb 3] Si la arquitectura endian del decodificador coincide con la del codificador, el decodificador detecta el valor 0xFEFF, pero un decodificador endian opuesto interpreta la BOM como el valor no caracter U+FFFE reservado para este propósito. Este resultado incorrecto proporciona una pista para realizar un intercambio de bytes para los valores restantes.
Si falta la lista de materiales, la RFC 2781 recomienda [nb 4] que se asuma la codificación big-endian (BE). En la práctica, debido a que Windows utiliza el orden little-endian (LE) de manera predeterminada, muchas aplicaciones asumen la codificación little-endian. También es confiable detectar el orden de bytes nulos, suponiendo que los caracteres menores a U+0100 son muy comunes. Si más bytes pares (comenzando en 0) son nulos, entonces es big-endian.
El estándar también permite que el orden de bytes se indique explícitamente especificando UTF-16BE o UTF-16LE como el tipo de codificación. Cuando el orden de bytes se especifica explícitamente de esta manera, no se supone que se anteponga una BOM al texto, y un U+FEFF al principio se debe manejar como un carácter ZWNBSP. La mayoría de las aplicaciones ignoran una BOM en todos los casos a pesar de esta regla.
Para los protocolos de Internet , la IANA ha aprobado "UTF-16", "UTF-16BE" y "UTF-16LE" como nombres para estas codificaciones (los nombres no distinguen entre mayúsculas y minúsculas). Los alias UTF_16 o UTF16 pueden tener significado en algunos lenguajes de programación o aplicaciones de software, pero no son nombres estándar en los protocolos de Internet.
Se utilizan designaciones similares, UCS-2BE y UCS-2LE , para mostrar versiones de UCS-2 .
Un "carácter" puede utilizar cualquier número de puntos de código Unicode. [20] Por ejemplo, un carácter de bandera emoji ocupa 8 bytes, ya que está "construido a partir de un par de valores escalares Unicode" [21] (y esos valores están fuera del BMP y requieren 4 bytes cada uno). UTF-16 de ninguna manera ayuda a "contar caracteres" o a "medir el ancho de una cadena".
A menudo se afirma que UTF-16 es más eficiente en cuanto al espacio que UTF-8 para los idiomas del este asiático, ya que utiliza dos bytes para caracteres que ocupan 3 bytes en UTF-8. Dado que el texto real contiene muchos espacios, números, puntuación, marcado (por ejemplo, páginas web) y caracteres de control, que ocupan solo un byte en UTF-8, esto solo es cierto para bloques de texto densos construidos artificialmente. [ cita requerida ] Se puede hacer una afirmación más seria para Devanagari y Bengali , que utilizan palabras de varias letras y todas las letras ocupan 3 bytes en UTF-8 y solo 2 en UTF-16.
Además, el estándar de codificación Unicode chino GB 18030 siempre produce archivos del mismo tamaño o más pequeños que UTF-16 para todos los idiomas, no sólo para el chino (lo hace sacrificando la autosincronización).
UTF-16 se utiliza para texto en la API del sistema operativo de todas las versiones actualmente compatibles de Microsoft Windows (y al menos incluidas todas desde Windows CE / 2000 / XP / 2003 / Vista / 7 [22] ), incluido Windows 10. En Windows XP, no se incluye ningún punto de código por encima de U+FFFF en ninguna fuente entregada con Windows para idiomas europeos. [23] [24] Los sistemas Windows NT más antiguos (anteriores a Windows 2000) solo admiten UCS-2 . [25] Los archivos y los datos de red tienden a ser una mezcla de UTF-16, UTF-8 y codificaciones de bytes heredadas.
Si bien ha habido cierto soporte para UTF-8 incluso para Windows XP, [26] se mejoró (en particular, la capacidad de nombrar un archivo usando UTF-8) en la compilación 17035 de Windows 10 Insider y la actualización de mayo de 2019. A partir de mayo de 2019, Microsoft recomienda que el software use UTF-8 , en Windows y Xbox , en lugar de otras codificaciones de 8 bits. [27] No está claro si están recomendando el uso de UTF-8 en lugar de UTF-16, aunque afirman que "UTF-16 [...] es una carga única que Windows coloca en el código que apunta a múltiples plataformas". [28]
El sistema operativo IBM i designa CCSID ( página de códigos ) 13488 para codificación UCS-2 y CCSID 1200 para codificación UTF-16, aunque el sistema los trata a ambos como UTF-16. [29]
UTF-16 es utilizado por los sistemas operativos Qualcomm BREW , los entornos .NET y el kit de herramientas de widgets gráficos multiplataforma Qt .
El sistema operativo Symbian utilizado en los teléfonos Nokia S60 y Sony Ericsson UIQ utiliza UCS-2. Los teléfonos iPhone utilizan UTF-16 para el servicio de mensajes cortos en lugar de UCS-2 descrito en los estándares 3GPP TS 23.038 ( GSM ) e IS-637 ( CDMA ). [30]
El sistema de archivos Joliet , utilizado en medios CD-ROM , codifica los nombres de archivos utilizando UCS-2BE (hasta sesenta y cuatro caracteres Unicode por nombre de archivo).
La versión 2.0 de Python oficialmente solo usaba UCS-2 internamente, pero el decodificador UTF-8 a "Unicode" producía UTF-16 correcto. También existía la capacidad de compilar Python para que usara UTF-32 internamente, esto se hacía a veces en Unix. Python 3.3 cambió el almacenamiento interno para usar uno de ISO-8859-1 , UCS-2 o UTF-32 dependiendo del punto de código más grande en la cadena. [31] Python 3.12 elimina algunas funciones (para extensiones CPython) para facilitar la migración a UTF-8 para todas las cadenas. [32]
Java originalmente utilizaba UCS-2 y agregó compatibilidad con caracteres suplementarios UTF-16 en J2SE 5.0 . Recientemente, han fomentado la eliminación de la compatibilidad con cualquier codificación de 8 bits que no sea UTF-8 [33], pero internamente todavía se utiliza UTF-16.
JavaScript puede utilizar UCS-2 o UTF-16. [34] A partir de ES2015, se han agregado al lenguaje métodos de cadena y marcas de expresión regular que permiten manejar cadenas desde una perspectiva independiente de la codificación.
UEFI utiliza UTF-16 para codificar cadenas de forma predeterminada.
Swift , el lenguaje de aplicación preferido de Apple, utilizó UTF-16 para almacenar cadenas hasta la versión 5, que cambió a UTF-8. [35]
Un gran número de lenguajes hacen que la codificación forme parte del objeto de cadena y, por lo tanto, almacenan y admiten un gran conjunto de codificaciones, incluida UTF-16. La mayoría considera que UTF-16 y UCS-2 son codificaciones diferentes. Algunos ejemplos son el lenguaje PHP [36] y MySQL . [37]
Un método para determinar qué codificación utiliza un sistema internamente es preguntar por la "longitud" de una cadena que contiene un solo carácter que no sea BMP. Si la longitud es 2, se está utilizando UTF-16. 4 indica UTF-8. 3 o 6 pueden indicar CESU-8 . 1 puede indicar UTF-32, pero es más probable que indique que el lenguaje decodifica la cadena en puntos de código antes de medir la "longitud".
En muchos idiomas, las cadenas entrecomilladas necesitan una nueva sintaxis para entrecomillar caracteres que no sean BMP, ya que la sintaxis de estilo C "\uXXXX"se limita explícitamente a 4 dígitos hexadecimales. Los siguientes ejemplos ilustran la sintaxis para el carácter que no es BMP U+1D11E 𝄞 SÍMBOLO MUSICAL CLAVE DE SOL :
"\U0001D11E". [38]"\x{1D11E}"."\u{1D11E}"."\uD834\uDD1E".[...] el término UCS-2 debería considerarse obsoleto. Ya no hace referencia a una forma de codificación ni en 10646 ni en el estándar Unicode.
UCS-2 es una terminología obsoleta que se refiere a una implementación de Unicode hasta Unicode 1.1 [...]
UTF-16 utiliza una única unidad de código de 16 bits para codificar más de 60.000 de los caracteres más comunes en Unicode.
Se me ocurrió la idea de esta lista de los diez principales hace más de 10 años, impulsada por algunos entornos que todavía admitían solo puntos de código BMP. La idea, por supuesto, era motivar a los desarrolladores de dichos entornos para que admitieran puntos de código más allá de BMP proporcionando una lista enumerada de razones para hacerlo. Y sí, todavía hay algunos entornos que solo admiten puntos de código BMP, como la aplicación VivaDesigner.
Las codificaciones UTF-16 son las únicas codificaciones que esta especificación debe tratar como codificaciones no compatibles con ASCII.
La codificación UTF-8 es la codificación más adecuada para el intercambio de Unicode, el conjunto de caracteres codificados universales. Por lo tanto, para los nuevos protocolos y formatos, así como para los formatos existentes implementados en nuevos contextos, esta especificación requiere (y define) la codificación UTF-8. [..] Los problemas descritos aquí desaparecen cuando se utiliza exclusivamente UTF-8, que es una de las muchas razones por las que UTF-8 es ahora la codificación obligatoria para todos los textos en la Web.
[…] el sistema de archivos trata los nombres de ruta y de archivo como una secuencia opaca de WCHAR
A partir de la versión 1903 de Windows (actualización de mayo de 2019), puede usar la propiedad ActiveCodePage en el manifiesto appxmanifest para aplicaciones empaquetadas, o el manifiesto de fusión para aplicaciones no empaquetadas, para forzar a un proceso a usar UTF-8 como la página de códigos del proceso. [...]
equivale a
solo si se ejecuta en la versión 1903 de Windows (actualización de mayo de 2019) o superior y la propiedad ActiveCodePage descrita anteriormente está configurada en UTF-8. De lo contrario, respeta la página de códigos del sistema heredado. Recomendamos usar
explícitamente.
CP_ACPCP_UTF8CP_UTF8
Al operar en UTF-8, puede garantizar la máxima compatibilidad [..] Windows opera de forma nativa en UTF-16 (o WCHAR), que requiere conversiones de páginas de códigos mediante MultiByteToWideChar y WideCharToMultiByte. Esta es una carga única que Windows impone al código que se dirige a múltiples plataformas. [..] El Kit de desarrollo de juegos de Microsoft (GDK) y Windows en general están avanzando para admitir UTF-8 para eliminar esta carga única de Windows en el código que se dirige o intercambia con múltiples plataformas y la web. Además, esto da como resultado menos problemas de internacionalización en aplicaciones y juegos y reduce la matriz de prueba que se requiere para hacerlo bien.