UTF-16 ( formato de transformación Unicode de 16 bits ) es una codificación de caracteres capaz de codificar los 1.112.064 puntos de código válidos de Unicode (de hecho, esta cantidad de puntos de código viene dictada 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 obsoleta anterior de 16 bits de ancho fijo ahora conocida como "UCS-2" (para el conjunto de caracteres universales de 2 bytes), [1] [2] una vez que quedó claro que más de 2 16 (65,536 ) se necesitaban puntos de código, [3] incluidos la mayoría de los emoji y caracteres CJK importantes , como nombres personales y de lugares. [4]
UTF-16 es utilizado por sistemas como la API de Microsoft Windows , el lenguaje de programación Java y JavaScript /ECMAScript. A veces también se utiliza para archivos de texto sin formato y de datos de procesamiento de textos en Microsoft Windows. Es utilizado por implementaciones más modernas de SMS . [5]
UTF-16 es la única codificación (todavía) permitida en la web que es incompatible con ASCII [6] [nb 1] y nunca ganó popularidad en la web, donde se declara en menos del 0,004% 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 deben utilizar UTF-16. [10]
A finales de la década de 1980, se comenzó a trabajar en el desarrollo de una codificación uniforme para un "Conjunto de caracteres universal" ( UCS ) que reemplazaría codificaciones anteriores específicas del idioma con 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 dominios 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, con una codificación que usaba 65,536 (2 16 ) valores, que requeriría 2 bytes (16 bits) por carácter.
Dos grupos trabajaron en esto en paralelo, ISO/IEC JTC 1/SC 2 y el Unicode Consortium , 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 mutuamente compatibles. La codificación inicial de 2 bytes se llamaba originalmente "Unicode", pero ahora se llama "UCS-2". [1] [2] [11]
Cuando se hizo cada vez más claro 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. El Unicode Consortium se resistió a esto , 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 debería considerarse obsoleto. Ya no hace referencia 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 de sincronización automática 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 está codificado como una o dos unidades de código de 16 bits . Los puntos de código inferiores a 2 16 ("en BMP") se codifican con una única 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 de este rango no se utilizan como caracteres y UTF-16 no proporciona ninguna forma legal de codificarlos como puntos de código individuales. Por lo tanto, una secuencia UTF-16 consta de códigos únicos 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 puntos de código en este rango como unidades de código únicas 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 necesaria ] A partir de Unicode 9.0, algunas escrituras modernas asiáticas, del Medio Oriente y africanas no latinas 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 denominadas par sustituto . La primera unidad de código es un sustituto alto y la segunda es un sustituto bajo (también se conocen como sustitutos "principales" y "finales", respectivamente, análogos a los bytes iniciales y finales de UTF-8. [17] ):
Ilustrada visualmente, la distribución de U' entre W1 y W2 es la siguiente: [18]
U' = yyyyyyyyyyxxxxxxxxxx // U - 0x10000W1 = 110110yyyyyyyyyy // 0xD800 + yyyyyyyyyyW2 = 110111xxxxxxxxxx // 0xDC00 + xxxxxxxxxxDado que los rangos para los sustitutos altos ( 0xD800–0xDBFF ), los sustitutos bajos ( 0xDC00–0xDFFF ) y los 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 sustituto legal . Esto simplifica mucho las búsquedas. También significa que UTF-16 se autosincroniza en palabras de 16 bits: se puede determinar si una unidad de código comienza con un carácter sin examinar las 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 se encuentra). caídas). 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 podían sincronizarse 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 están todos en el BMP, el manejo de pares sustitutos a menudo no se prueba exhaustivamente. Esto conduce a errores persistentes y posibles agujeros de seguridad, incluso en aplicaciones de software populares y bien revisadas (por ejemplo, CVE - 2008-2938, CVE-2012-2135).
El estándar oficial Unicode dice que ningún formato UTF, incluido UTF-16, puede codificar los puntos del código sustituto. Dado que a estos 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 archivos [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 maneras 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 sin ambigüedades un sustituto no emparejado (un punto de código sustituto alto no seguido de 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 UTF-16 válido, pero la mayoría de las implementaciones de codificadores y decodificadores UTF-16 hacen esto al traducir entre codificaciones. [ cita necesaria ]
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 mediante 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, por tanto, cada unidad ocupa dos bytes de 8 bits, el orden de los bytes puede depender del endianismo (orden de bytes) de la arquitectura de la computadora.
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 invisible de espacio sin separación de ancho cero /ZWNBSP). [nb 3] Si la arquitectura endian del decodificador coincide con la del codificador, el decodificador detecta el valor 0xFEFF, pero un valor opuesto El decodificador -endian interpreta la lista de materiales como el valor sin carácter U+FFFE reservado para este propósito. Este resultado incorrecto proporciona una pista para realizar el intercambio de bytes para los valores restantes.
Si falta la lista de materiales, 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 forma predeterminada, muchas aplicaciones asumen la codificación little endian. También es confiable detectar el endianness buscando bytes nulos, suponiendo que los caracteres menores que 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 indicar explícitamente el orden de los bytes especificando UTF-16BE o UTF-16LE como tipo de codificación. Cuando el orden de los bytes se especifica explícitamente de esta manera, no se supone que una lista de materiales se anteponga al texto, y un U+FEFF al principio debe manejarse como un carácter ZWNBSP. La mayoría de las aplicaciones ignoran una lista de materiales 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 no ayuda de ninguna manera a "contar caracteres" o a "medir el ancho de una cadena".
A menudo se afirma que UTF-16 ahorra más espacio que UTF-8 para los idiomas de Asia Oriental, 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, marcas (por ejemplo, páginas web) y caracteres de control, que ocupan sólo un byte en UTF-8, esto sólo es cierto para bloques densos de texto construidos artificialmente. [ cita necesaria ] Se puede hacer un reclamo más serio para Devanagari y Bengali , que usan 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 chino Unicode 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 sincronización automática).
UTF-16 se utiliza para el texto en la API del sistema operativo de todas las versiones actualmente compatibles de Microsoft Windows (e incluye al menos 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 superior a U+FFFF en ninguna fuente entregada con Windows para idiomas europeos. [23] [24] Los sistemas Windows NT más antiguos (anteriores a Windows 2000) sólo admiten UCS-2 . [25] Los archivos y datos de red tienden a ser una combinación de codificaciones de bytes UTF-16, UTF-8 y heredadas.
Si bien ha habido cierta compatibilidad con UTF-8 incluso para Windows XP, [26] se mejoró (en particular, la capacidad de nombrar un archivo usando UTF-8) en la compilación interna 17035 de Windows 10 y la actualización de mayo de 2019. A partir de mayo de 2019, Microsoft recomienda que el software utilice UTF-8 , en Windows y Xbox , en lugar de otras codificaciones de 8 bits. [27] No está claro si recomiendan el uso de UTF-8 en lugar de UTF-16, aunque sí afirman que "UTF-16 [...] es una carga única que Windows impone al código dirigido 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 los teléfonos 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 CD-ROM , codifica 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 usó UCS-2 internamente, pero el decodificador UTF-8 para "Unicode" produjo UTF-16 correcto. También existía la posibilidad de compilar Python para que usara UTF-32 internamente, esto a veces se hacía en Unix. Python 3.3 cambió el almacenamiento interno para usar uno de ISO-8859-1 , UCS-2 o UTF-32 según el punto de código más grande de 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 usó originalmente UCS-2 y agregó soporte de caracteres suplementarios UTF-16 en J2SE 5.0 . Recientemente han fomentado el soporte de descarga para cualquier codificación de 8 bits distinta de 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 indicadores de expresión regular que permiten manejar cadenas desde una perspectiva independiente de la codificación.
UEFI usa UTF-16 para codificar cadenas de forma predeterminada.
Swift , el lenguaje de aplicación preferido de Apple, usó UTF-16 para almacenar cadenas hasta la versión 5 que cambió a UTF-8. [35]
Muchos lenguajes hacen que la codificación forme parte del objeto de cadena y, por lo tanto, almacenan y admiten un gran conjunto de codificaciones, incluido 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 internamente un sistema es solicitar la "longitud" de la cadena que contiene un único carácter que no es BMP. Si la longitud es 2, entonces se utiliza UTF-16. 4 indica UTF-8. 3 o 6 pueden indicar CESU-8 . 1 puede indicar UTF-32, pero lo más probable es que indique que el lenguaje decodifica la cadena para codificar puntos antes de medir la "longitud".
En muchos idiomas, las cadenas entre comillas necesitan una nueva sintaxis para citar caracteres que no sean BMP, ya que la "\uXXXX"sintaxis de estilo C se limita explícitamente a 4 dígitos hexadecimales. Los siguientes ejemplos ilustran la sintaxis del carácter no BMP U+1D11E 𝄞 SÍMBOLO MUSICAL G CLEF :
"\U0001D11E". [38]"\x{1D11E}"."\u{1D11E}"."\uD834\uDD1E".[...] 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 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
La idea de esta lista de los diez principales se me ocurrió por primera vez 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 a admitir puntos de código más allá del 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 universal. Por lo tanto, para 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 usa exclusivamente UTF-8, que es una de las muchas razones por las que UTF-8 es ahora la codificación obligatoria para todo el texto en la Web.
[…] el sistema de archivos trata la ruta y los nombres de los archivos 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 appxmanifest para aplicaciones empaquetadas, o el manifiesto de fusión para aplicaciones no empaquetadas, para forzar que un proceso use UTF-8 como página de códigos de 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), lo que requiere conversiones de páginas de códigos mediante el uso de MultiByteToWideChar y WideCharToMultiByte. Esta es una carga única que Windows impone al código destinado 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 cuanto a la orientación o el intercambio de código 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 necesaria para hacerlo bien.