Hispanopedia Wiki
Articulo de referencia

UTF-16

• text/plain; charset=utf-16le • text/plain; charset=utf-16be"},"alias":{"wt":""},"image":{"wt":"UTF-16 encoding.svg"},"caption":{"wt":"Example of Unicode character encoding thr...

Hispanopedia WikiContenido en espanolLectura gratuita

UTF-16 ( Formato de Transformación Unicode de 16 bits ) es una codificación de caracteres que admite los 1.112.064 [ a ] puntos de código válidos de Unicode. [ 1 ] 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 ancho fijo de 16 bits, ahora conocida como UCS-2 (por Conjunto de Caracteres Universales de 2 bytes), [ 2 ] [ 3 ] una vez que quedó claro que se necesitaban más de 2¹⁶ (65.536) puntos de código, [ 4 ] incluyendo la mayoría de los emojis y caracteres CJK importantes, como los de nombres propios y de lugares. [ 5 ]

UTF-16 es utilizado por la API de Windows y por muchos entornos de programación como Java y Qt . El carácter de longitud variable de UTF-16, combinado con el hecho de que la mayoría de los caracteres no son de longitud variable (por lo que rara vez se comprueba la longitud variable), ha dado lugar a muchos errores en el software, incluso en el propio Windows. [ 6 ]

UTF-16 es la única codificación (todavía) permitida en la web que es incompatible con ASCII de 8 bits . [ 7 ] [ b ] Nunca ha ganado popularidad en la web, donde se declara en menos del 0,004% de las páginas web públicas (e incluso en ese caso, es muy probable que las páginas web también utilicen UTF-8 ). [ 9 ] UTF-8, en comparación, ganó dominio hace años y representaba el 99% de todas las páginas web para 2025. [ 10 ] El Grupo de Trabajo de Tecnología de Aplicaciones de Hipertexto Web (WHATWG) considera a UTF-8 "la codificación obligatoria para todo [texto]" y que, por razones de seguridad, las aplicaciones de navegador no deberían usar UTF-16. [ 11 ]

Mapa del plano 0 de GNU Unifont 16.0.01 . La franja blanca cerca de la parte inferior es el rango de puntos del código sustituto.

Historia

A finales de la década de 1980, se comenzó 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 anteriores específicas de cada 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 á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, con una codificación que utilizara 65 536 (2¹⁶ ) valores, lo 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 Consorcio Unicode , este último representando principalmente a fabricantes de equipos informáticos. Ambos grupos intentaron sincronizar sus asignaciones de caracteres para que las codificaciones en desarrollo fueran mutuamente compatibles. La primera codificación de 2 bytes se denominó "UCS-2". [ 2 ] [ 3 ] [ 12 ]

Cuando se hizo cada vez más evidente que 2¹⁶ caracteres no serían suficientes, [ 13 ] el IEEE introdujo un espacio de 31 bits más grande y una codificación ( UCS-4 ) que requeriría 4 bytes por carácter. Esto fue rechazado 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. [ 14 ] Está completamente especificado en el RFC 2781, publicado en 2000 por el IETF . [ 15 ] [ 16 ]

UTF-16 se especifica en las versiones más recientes tanto del estándar internacional ISO/IEC 10646 como del estándar Unicode. «UCS-2 debe considerarse obsoleto. Ya no hace referencia a una forma de codificación ni en 10646 ni en el estándar Unicode». [ 2 ] [ 3 ] UTF-16 nunca se extenderá para admitir un mayor número de puntos de código ni 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 los puntos de código de categoría general o sustitutos. [ 17 ] (Cualquier esquema que siga siendo un código autosincronizado requeriría la asignación de 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).

Descripción

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 que 2¹⁶ ("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¹⁶ ( "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 válida de codificarlos como puntos de código individuales. Por lo tanto, una secuencia UTF-16 consta de códigos de 16 bits individuales fuera del rango sustituto y pares de valores de 16 bits que están dentro del rango sustituto.

U+0000 a U+D7FF y U+E000 a U+FFFF

Tanto UTF-16 como UCS-2 codifican los puntos de código en este rango como unidades de código únicas de 16 bits, 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 que se pueden representar en UCS-2. A partir de Unicode 9.0, algunos alfabetos modernos no latinos de Asia, Oriente Medio y África quedan fuera de este rango, al igual que la mayoría de los emojis .

Puntos de código desde U+010000 hasta U+10FFFF

Los puntos de código de los otros planos se codifican como dos unidades de código de 16 bits llamadas par subrogado . La primera unidad de código es un subrogado alto y la segunda es un subrogado bajo (estos también se conocen como subrogados "inicial" y "final", respectivamente, análogos a los bytes inicial y final de UTF-8. [ 18 ] ):

  • Se resta 0x10000 del punto de código (U) , dejando un número de 20 bits (U') en el rango de números hexadecimales 0x00000–0xFFFFF.
  • Los diez bits superiores (en el rango 0x000–0x3FF) se suman a 0xD800 para dar la primera unidad de código de 16 bits o sustituto alto (W1) , que estará en el rango 0xD800–0xDBFF .
  • Los diez bits inferiores (también en el rango 0x000–0x3FF) se suman a 0xDC00 para dar la segunda unidad de código de 16 bits o sustituto bajo (W2) , que estará en el rango 0xDC00–0xDFFF .

Ilustrada visualmente, la distribución de U' entre W1 y W2 se ve así: [ 19 ]

U' = yyyyyyyyyyxxxxxxxxxx // U - 0x10000 W1 = 110110yyyyyyyyyy // 0xD800 + yyyyyyyyyy W2 = 110111xxxxxxxxxx // 0xDC00 + xxxxxxxxxx

Dado que los rangos para los caracteres sustitutos altos ( 0xD800–0xDBFF ), los caracteres 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, ni que dos unidades de código adyacentes parezcan un par de sustitutos válidos . Esto simplifica enormemente 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 inicia 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). 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 búsquedas inequívocas y solo podían sincronizarse volviendo a analizar desde el inicio de la cadena. UTF-16 no se autosincroniza si se pierde un byte o si el recorrido comienza en un byte aleatorio.

Debido a que los caracteres más utilizados se encuentran en el formato BMP, el manejo de pares sustitutos a menudo no se prueba exhaustivamente. Esto genera errores persistentes y posibles vulnerabilidades de seguridad, incluso en software de aplicación popular y bien valorado (por ejemplo, CVE - 2008-2938 , CVE- 2012-2135 ).

U+D800 a U+DFFF (sustitutos)

El estándar oficial Unicode establece que ninguna forma UTF, incluida UTF-16, puede codificar los puntos de código subrogados. Dado que a estos nunca se les asignará un carácter, no debería haber motivo para codificarlos. Sin embargo, Windows permite subrogados no emparejados en nombres de archivo [ 20 ] y otros lugares, lo que generalmente implica que el software debe admitirlos 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 forma sencilla y evidente, y gran parte del software lo hace, a pesar de que el estándar indica que tales configuraciones deben considerarse errores de codificación. Es posible codificar sin ambigüedad 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 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 lo hacen al traducir entre codificaciones.

Ejemplos

Para codificar U+10437 (𐐷) a UTF-16:

  • Resta 0x10000 al punto de código, dejando 0x0437.
  • Para el sustituto alto, desplácese a la derecha 10 (divida por 0x400), luego agregue 0xD800, lo que resulta en 0x0001 + 0xD800 = 0xD801.
  • Para el sustituto bajo, tome los 10 bits más bajos (resto de la división por 0x400), luego agregue 0xDC00, lo que resulta en 0x0037 + 0xDC00 = 0xDC37.

Para decodificar U+10437 (𐐷) de UTF-16:

  • Toma el sustituto alto (0xD801) y réstale 0xD800, luego multiplícalo por 0x400, lo que da como resultado 0x0001 × 0x400 = 0x0400.
  • Toma el valor sustituto bajo (0xDC37) y réstale 0xDC00, lo que da como resultado 0x37.
  • Suma estos dos resultados (0x0437) y, finalmente, suma 0x10000 para obtener el punto de código final, 0x10437.

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 añadidos por el proceso de codificación UTF-16 se muestran en negro.

Esquemas de codificación de orden de bytes

UTF-16 y UCS-2 generan una secuencia de unidades de código de 16 bits. Dado que la mayoría de los protocolos de comunicación y almacenamiento se definen para bytes, y cada unidad ocupa dos bytes de 8 bits, el orden de los bytes puede depender del orden de bytes ( endianness ) de la arquitectura del ordenador.

Para facilitar el reconocimiento del 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. [ c ] (U+FEFF es el carácter invisible de espacio sin separación de ancho cero /ZWNBSP). [ d ] Si la arquitectura endian del decodificador coincide con la del codificador, el decodificador detecta el valor 0xFEFF, pero un decodificador endian inverso interpreta la BOM como el valor no carácter 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 BOM, la RFC 2781 recomienda [ e ] asumir la codificación big-endian (BE). En la práctica, debido a que Windows usa el orden little-endian (LE) por defecto, muchas aplicaciones asumen la codificación little-endian. También es fiable detectar el orden de bytes buscando bytes nulos, suponiendo que los caracteres menores que U+0100 son muy comunes. Si hay más bytes pares (empezando por 0) nulos, entonces es big-endian.

El estándar también permite especificar explícitamente el orden de bytes indicando UTF-16BE o UTF-16LE como tipo de codificación. Cuando se especifica el orden de bytes de esta manera, no se debe anteponer una marca de orden de bytes (BOM) al texto, y un carácter U+FEFF al principio debe tratarse como un carácter ZWNBSP. Sin embargo, la mayoría de las aplicaciones ignoran la BOM en todos los casos.

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 sentido 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 .

Eficiencia

Un "carácter" puede usar cualquier número de puntos de código Unicode [ 21 ] y en UTF-16 un punto de código puede usar 1 o 2 valores de 16 bits. Esto significa que UTF-16 no ayuda en absoluto a "contar caracteres" ni a "medir el ancho/largo de una cadena".

Se suele afirmar que UTF-16 es más eficiente en cuanto al uso de espacio que UTF-8 para los idiomas de Asia Oriental, ya que utiliza dos bytes para caracteres que en UTF-8 requieren tres. Dado que el texto real contiene muchos espacios, números, signos de puntuación, marcado (por ejemplo, en páginas web) y caracteres de control, que solo ocupan un byte en UTF-8, esto solo es cierto para bloques de texto densos construidos artificialmente. Una afirmación más seria se puede hacer para el devanagari y el bengalí , que utilizan palabras de varias letras y todas las letras ocupan tres bytes en UTF-8 y solo dos en UTF-16.

Uso

Un método para determinar la codificación que utiliza internamente un sistema consiste en solicitar la longitud de una cadena que contenga un único 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 lo más probable es que indique que el lenguaje decodifica la cadena a puntos de código antes de medir su longitud.

Sistemas operativos

UTF-16 se utiliza para texto en la API del sistema operativo de todas las versiones compatibles actualmente de Microsoft Windows [ 22 ] (e incluyendo al menos Windows CE desde Windows CE 5.0 [ 23 ] y Windows NT desde Windows 2000 [ 24 ] ). Windows NT anterior a Windows 2000 solo admitía UCS-2. [ 25 ] [ 26 ] Windows 9x solo admitía UCS-2, y la compatibilidad con Unicode se limita a interna, como VFAT y WDM . Desde Windows 10 versión 1903 (o compilación Insider 17035) ha sido posible usar UTF-8 en la API, [ 27 ] aunque la mayoría del software, como el Explorador de archivos de Windows , todavía usa la API UTF-16. Microsoft ha declarado que "UTF-16 [...] es una carga única que Windows impone al código que se dirige a múltiples plataformas" [ 28 ] 

El sistema operativo IBM i designa la CCSID ( página de códigos ) 13488 para la codificación UCS-2 y la CCSID 1200 para la codificación UTF-16, aunque el sistema las trata a ambas como UTF-16. [ 29 ]

Plataformas y marcos de aplicación

La plataforma Qualcomm BREW , los entornos .NET y el kit de herramientas de widgets gráficos multiplataforma Qt utilizan UTF-16 .

Sistemas de archivos

El sistema de archivos Joliet , utilizado en los CD-ROM , codifica los nombres de archivo mediante UCS-2BE (hasta sesenta y cuatro caracteres Unicode por nombre de archivo). NTFS y ReFS utilizan UTF-16 para almacenar cadenas. [ 30 ]

Mensajería

Los mensajes de texto SMS utilizan eficazmente UTF-16. Los estándares 3GPP TS 23.038 ( GSM ) e IS-637 ( CDMA ) especifican UCS-2, pero UTF-16 es necesario para que funcionen los emojis. [ 31 ] 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.

Lenguajes de programación

Python versión 2.0 oficialmente solo usaba UCS-2 internamente, pero el decodificador UTF-8 a "Unicode" producía UTF-16 correcto. También existía la posibilidad de compilar Python para que usara UTF-32 internamente, lo que 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 dependiendo del punto de código más grande en la cadena. [ 32 ] Python 3.12 elimina algunas funcionalidades (para extensiones de CPython) para facilitar la migración a UTF-8 para todas las cadenas. [ 33 ]

Java originalmente usaba UCS-2 y agregó soporte para caracteres suplementarios UTF-16 en J2SE 5.0 . Todas las cadenas en memoria son UTF-16 (desde Java 9, las cadenas que contienen solo caracteres ISO-8859-1 se pueden "comprimir" a bytes [ 34 ] ). La E/S de Java usa UTF-8 [ 35 ] o UTF-8 modificado [ 36 ] .

JavaScript puede usar UCS-2 o UTF-16. [ 37 ]

C# utiliza UTF-16 para las cadenas. Recientemente se agregó la capacidad de usar cadenas UTF-8 [ 38 ] , así como algunas funciones .NET [ 39 ] que las utilizan.

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. [ 40 ]

Bastantes lenguajes hacen que la codificación forme parte del objeto de cadena, y por lo tanto almacenan y admiten un amplio conjunto de codificaciones, incluyendo UTF-16. La mayoría considera que UTF-16 y UCS-2 son codificaciones diferentes. Ejemplos de ello son el lenguaje PHP , [ 41 ] MySQL , [ 42 ] y JavaScript desde ES2015.

En algunos idiomas, la única forma de insertar un carácter que no sea BMP en una constante de cadena UTF-16 es escribir ambas mitades sustitutas, por ejemplo, escribir "\uD834\uDD1E"en lugar de "\U0001D11E"para U+1D11E .

Firmware

UEFI utiliza UTF-16 para codificar cadenas de caracteres de forma predeterminada. Desde al menos la versión 2.4 de UEFI, puede utilizar ASCII para codificar cadenas que solo contengan caracteres ASCII.

Véase también

Notas

  1. ↑ Este número es, de hecho, una consecuencia de UTF-16. Hay 2¹⁶ − 2048 + 1024 · 1024 = 1.112.064 puntos de código que pueden codificarse con UTF-16. Unicode se restringió a estos puntos de código cuando se añadió UTF-16 al estándar. Antes de eso, Unicode tenía 2³¹ = 2.147.483.648 puntos de código válidos.
  2. ↑ UTF-32 también es incompatible con ASCII, pero no figura como una codificación web. [ 8 ]
  3. ↑ La codificación UTF-8 produce valores de bytes estrictamente menores que 0xFE, por lo que cualquiera de los bytes en la secuencia BOM también identifica la codificación como UTF-16 (suponiendo que no se espera UTF-32).
  4. ↑ El uso de U+FEFF como carácter ZWNBSP en lugar de como BOM ha sido desaconsejado en favor de U+2060 (WORD JOINER); consulte las preguntas frecuentes sobre marcas de orden de bytes (BOM) en Unicode.org. Sin embargo, si una aplicación interpreta una BOM inicial como un carácter, el carácter ZWNBSP es invisible, por lo que el impacto es mínimo.
  5. ↑ La sección 4.3 de la RFC 2781 establece que, si no hay una BOM, "el texto DEBERÍA interpretarse como big-endian". Según la sección 1.2, el significado del término "DEBERÍA" se rige por la RFC 2119. En ese documento, la sección 3 indica que "...puede haber razones válidas en circunstancias particulares para ignorar un elemento específico, pero deben comprenderse y sopesarse cuidadosamente todas las implicaciones antes de optar por un camino diferente".  

Referencias

  1. ↑ "Conformidad" . El estándar Unicode ( ed. 6.0 ). Mountain View, California, EE. UU.: The Unicode Consortium . 3.9 Formas de codificación Unicode. ISBN  978-1-936213-01-6Cada forma de codificación asigna los puntos de código Unicode U+0000..U+D7FF y U+E000..U+10FFFF .
  2. 1 2 3 "C.2 Codificación de formas en ISO/IEC 10646" (PDF) . El estándar Unicode, versión 6.0 . Mountain View, CA: Consorcio Unicode . Febrero de 2011. pág. 573. ISBN  978-1-936213-01-6[ ...] el término UCS-2 debería considerarse obsoleto. Ya no se refiere a una forma de codificación ni en 10646 ni en el estándar Unicode.
  3. 1 2 3 "Preguntas frecuentes: ¿Cuál es la diferencia entre UCS-2 y UTF-16?" . unicode.org . Archivado del original el 18 de agosto de 2003. Consultado el 19 de marzo de 2024. UCS-2 es una terminología obsoleta que se refiere a una implementación de Unicode hasta Unicode 1.1 [...]
  4. ↑ "¿Qué es UTF-16?" . El Consorcio Unicode . Unicode, Inc. . Consultado el 7 de enero de 2023 . 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.
  5. ↑ Lunde, Ken (09/01/2022). "Lista de los diez mejores de 2022: ¿Por qué admitir puntos de código más allá de BMP?" . Medium . Recuperado el 07/01/2024 . La idea de esta lista de los diez mejores surgió hace más de 10 años, a raíz de algunos entornos que aún solo admitían 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á de BMP, proporcionando una lista enumerada de razones para hacerlo. Y sí, todavía existen algunos entornos que solo admiten puntos de código BMP, como la aplicación VivaDesigner.
  6. ↑ "¿Debería considerarse perjudicial UTF-16?" . Software Engineering Stack Exchange . Consultado el 20/11/2024 . La edición de nombres de archivo en los cuadros de diálogo de Windows está rota (la eliminación requiere 2 pulsaciones de la tecla de retroceso)
  7. ↑ "HTML Living Standard" . w3.org . 10 de junio de 2020. Archivado del original el 8 de septiembre de 2020. Consultado el 15 de junio de 2020. Las codificaciones UTF-16 son las únicas que esta especificación debe tratar como no compatibles con ASCII.
  8. ↑ "Estándar de codificación" . encoding.spec.whatwg.org . Consultado el 22 de abril de 2023 .
  9. ↑ "Estadísticas de uso y cuota de mercado de UTF-16 para sitios web, noviembre de 2025" . w3techs.com . Consultado el 20 de noviembre de 2025 .
  10. ↑ "Estadísticas de uso y cuota de mercado de UTF-8 para sitios web, noviembre de 2025" . w3techs.com . Consultado el 20 de noviembre de 2025 .
  11. ↑ "Estándar de codificación" . encoding.spec.whatwg.org . Consultado el 22/10/2018 . La codificación UTF-8 es la más apropiada para el intercambio de Unicode, el conjunto de caracteres codificados universal. Por lo tanto, para nuevos protocolos y formatos, así como para formatos existentes implementados en nuevos contextos, esta especificación requiere (y define) la codificación UTF-8. [...] Los problemas aquí descritos desaparecen al usar 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.
  12. ↑ "MySQL :: Manual de referencia de MySQL 5.7 :: 10.9.4 El conjunto de caracteres ucs2 (codificación Unicode UCS-2)" . dev.mysql.com . Consultado el 20 de noviembre de 2025 .  
  13. ↑ "¿Qué es UTF-16?" . El Consorcio Unicode . Unicode, Inc. . Consultado el 29 de marzo de 2018 .
  14. ↑ "Preguntas frecuentes - UTF-8, UTF-16, UTF-32 y BOM" . www.unicode.org . Consultado el 20 de noviembre de 2025 .
  15. ↑ ISO/IEC 10646:2014 "Tecnología de la información – Conjunto de caracteres codificados universales (UCS)" secciones 9 y 10.
  16. ↑ "Capítulo 2 Estructura general" (PDF) . El estándar Unicode versión 7.0 . 2014. 2.5 Formas de codificación.
  17. ↑ "Estabilidad de la codificación de caracteres" . unicode.org . Consultado el 20 de noviembre de 2025 .
  18. ↑ Allen, Julie D.; Anderson, Deborah; Becker, Joe ; Cook, Richard, eds. (2014). "3.8 Surrogates" (PDF) . El estándar Unicode, versión 7.0: especificación principal . Mountain View: The Unicode Consortium . pág. 118. Archivado (PDF) del original el 9 de octubre de 2022. Recuperado el 3 de noviembre de 2014 . 
  19. ↑ Yergeau, Francois; Hoffman, Paul (febrero de 2000). "UTF-16, una codificación de ISO 10646" . tools.ietf.org . Consultado el 18 de junio de 2019 .
  20. ↑ "Limitación de longitud máxima de ruta" . Microsoft . 18 de julio de 2022. Consultado el 10 de octubre de 2022. [ ...] el sistema de archivos trata las rutas y los nombres de archivo como una secuencia opaca de WCHAR.
  21. ↑ "No está mal que "🤦🏼‍♂️".length == 7" . hsivonen.fi . Consultado el 20 de noviembre de 2025 .
  22. ↑ "Unicode" . Microsoft Learn . Consultado el 8 de marzo de 2011. Estas funciones utilizan la codificación UTF-16 (caracteres anchos) (…) utilizada para la codificación Unicode nativa en los sistemas operativos Windows.
  23. ↑ Archiveddocs. "Trabajar con sustitutos Unicode (Windows CE 5.0)" . learn.microsoft.com . Consultado el 20 de noviembre de 2025 .
  24. ↑ "Caracteres sustitutos y suplementarios" . Microsoft Learn . 24/05/2022. Windows 2000 introduce compatibilidad con la entrada, salida y ordenación básica de caracteres suplementarios. Sin embargo, no todos los componentes del sistema son compatibles con ellos.
  25. ↑ Karl-Bridge-Microsoft. "Unicode - Aplicaciones Win32" . learn.microsoft.com . Consultado el 20 de noviembre de 2025 .
  26. ↑ Karl-Bridge-Microsoft. "Caracteres sustitutos y suplementarios - Aplicaciones Win32" . learn.microsoft.com . Consultado el 20 de noviembre de 2025 .
  27. ↑ "Usar páginas de códigos UTF-8 en aplicaciones de Windows" . learn.microsoft.com . Recuperado el 6 de junio de 2020. A partir de la versión 1903 de Windows ( actualización de mayo de 2019), puede usar la propiedad ActiveCodePage en el appxmanifest para aplicaciones empaquetadas, o el fusion manifest para aplicaciones no empaquetadas, para forzar a un proceso a usar UTF-8 como 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 heredada. Recomendamos usar explícitamente.  CP_ACPCP_UTF8  CP_UTF8
  28. ↑ "Compatibilidad con UTF-8 en el Kit de desarrollo de juegos de Microsoft (GDK) - Kit de desarrollo de juegos de Microsoft" . learn.microsoft.com . Consultado el 5 de marzo de 2023. 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ágina 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 dirigido o intercambiado con múltiples plataformas y la web. Además, esto resulta en menos problemas de internacionalización en aplicaciones y juegos y reduce la matriz de pruebas que se requiere para hacerlo bien.
  29. ↑ "UCS-2 y su relación con Unicode (UTF-16)" . www.ibm.com . Consultado el 20 de noviembre de 2025 .
  30. ↑ Karl-Bridge-Microsoft. "Conjuntos de caracteres utilizados en nombres de archivo - Aplicaciones Win32" . learn.microsoft.com . Consultado el 11 de octubre de 2025 .
  31. ↑ Chad Selph (8 de noviembre de 2012). "Aventuras en SMS Unicode" . Twilio. Archivado del original el 8 de septiembre de 2015. Consultado el 28 de agosto de 2015 .
  32. ↑ "PEP 393 – Representación flexible de cadenas | peps.python.org" . Propuestas de mejora de Python (PEPs) . Consultado el 20 de noviembre de 2025 .
  33. ↑ "PEP 623 – Eliminar wstr de Unicode | peps.python.org" . Propuestas de mejora de Python (PEPs) . Consultado el 20 de noviembre de 2025 .
  34. ↑ "Notas de la versión de JDK 9 - Nuevas características" .
  35. ↑ "Especificación de la API de la versión 24 del Kit de Desarrollo de Java" . docs.oracle.com . Consultado el 20 de noviembre de 2025 .
  36. ↑ "Documentación de Java SE para la interfaz java.io.DataInput, subsección sobre UTF-8 modificado" . Oracle Corporation . 2015. Consultado el 16 de octubre de 2015 .
  37. ↑ "Codificación interna de caracteres de JavaScript: ¿UCS-2 o UTF-16? · Mathias Bynens" . mathiasbynens.be . Consultado el 20 de noviembre de 2025 .
  38. ↑ BillWagner. "Literales de cadena UTF-8: especificaciones de características de C#" . learn.microsoft.com . Consultado el 22 de marzo de 2026 .
  39. ↑ "Clase Utf8Parser (System.Buffers.Text)" . learn.microsoft.com . Consultado el 16 de abril de 2026 .
  40. ↑ "Cadena UTF-8" . Swift.org . 2019-03-20 . Consultado el 2020-08-20 .
  41. ↑ "PHP: Codificaciones de caracteres compatibles - Manual" . php.net .
  42. ↑ "MySQL :: Manual de referencia de MySQL 8.0 :: 10.9.2 El conjunto de caracteres utf8mb3 (codificación Unicode UTF-8 de 3 bytes)" . dev.mysql.com . Consultado el 24 de febrero de 2023 .  
  • Un algoritmo muy corto para determinar el par sustituto para cualquier punto de código.
  • Nota técnica Unicode n.º 12: UTF-16 para procesamiento
  • Preguntas frecuentes sobre Unicode: ¿Cuál es la diferencia entre UCS-2 y UTF-16?
  • Índice de nombres de caracteres Unicode
  • RFC 2781 : UTF-16, una codificación de ISO 10646 
  • Documentación de java.lang.String, que trata sobre el manejo de sustitutos.
Obtenido de " https://en.wikipedia.org/w/index.php?title=UTF-16&oldid=1360713761 "
Lecturas relacionadas
6 articulos
UnicodeUnicodeUnicode , formalmente el Estándar Unicode , [nota 1] es un estándar de codificación de texto mantenido por el Consorcio Unicode diseñado para admit...Computación de 16 bitsComputación de 16 bitsEn arquitectura informática , los números enteros de 16 bits , las direcciones de memoria u otras unidades de datos son aquellas que tienen 16 bits...Codificación de caracteresCodificación de caracteresLa codificación de caracteres es el proceso de asignar números a caracteres gráficos , especialmente a los caracteres escritos del lenguaje humano ...Punto de códigoPunto de códigoUn punto de código , punto de código o posición de código es una posición particular en una tabla , a la que se le ha asignado un significado. La t...Codificación de ancho variableUna codificación de ancho variable es un tipo de esquema de codificación de caracteres en el que se utilizan códigos de diferentes longitudes para ...Caracteres CJKCaracteres CJKEn el ámbito de la internacionalización , los caracteres CJK son un término colectivo para los grafemas utilizados en los sistemas de escritura chi...