Articulo de referencia

UTF-8

UTF-8 es un estándar de codificación de caracteres utilizado para la comunicación electrónica. Definido por el estándar Unicode , su nombre deriva de Unicode Transformation Form...

UTF-8 es un estándar de codificación de caracteres utilizado para la comunicación electrónica. Definido por el estándar Unicode , su nombre deriva de Unicode Transformation Format 8-bit  . [ 1 ] A partir de 2026, casi todas las páginas web (99 % ) se transmiten como UTF-8. [ 2 ]

UTF-8 admite los 1.112.064 [ 3 ] puntos de código Unicode válidos mediante una codificación de ancho variable de una a cuatro unidades de código de un byte (8 bits).

Los puntos de código con valores numéricos más bajos, que tienden a aparecer con mayor frecuencia, se codifican utilizando menos bytes. Se diseñó para ser compatible con versiones anteriores de ASCII : los primeros 128 caracteres de Unicode, que se corresponden uno a uno con ASCII, se codifican utilizando un solo byte con el mismo valor binario que ASCII, de modo que un archivo codificado en UTF-8 que utilice solo esos caracteres es idéntico a un archivo ASCII. La mayoría del software diseñado para cualquier ASCII extendido puede leer y escribir UTF-8, lo que resulta en menos problemas de internacionalización que cualquier otra codificación de texto alternativa. [ 4 ] [ 5 ]

UTF-8 es el sistema de codificación dominante en todos los países e idiomas de Internet, se utiliza en la mayoría de los estándares, a menudo es la única codificación permitida y es compatible con todos los sistemas operativos y lenguajes de programación modernos.

Historia

La Organización Internacional de Normalización (ISO) se propuso crear un conjunto de caracteres multibyte universal en 1989. El borrador de la norma ISO 10646 contenía un anexo opcional llamado UTF-1 que proporcionaba una codificación de flujo de bytes de sus puntos de código de 32 bits . Esta codificación no era satisfactoria en términos de rendimiento, entre otros problemas, y el mayor problema probablemente era que no tenía una separación clara entre ASCII y no ASCII: las nuevas herramientas UTF-1 serían retrocompatibles con texto codificado en ASCII, pero el texto codificado en UTF-1 podía confundir el código existente que esperaba ASCII (o ASCII extendido ), porque podía contener bytes de continuación en el rango 0x210x7E que significaban algo diferente en ASCII, por ejemplo, 0x2F para , el separador de directorios de ruta de Unix ./

En julio de 1992, el comité XoJIG de X/Open buscaba una mejor codificación. Dave Prosser, de Unix System Laboratories, presentó una propuesta para una que tenía características de implementación más rápidas e introdujo la mejora de que los caracteres ASCII de 7 bits solo se representarían a sí mismos; las secuencias de varios bytes solo incluirían bytes con el bit más significativo activado. El nombre File System Safe UCS Transformation Format ( FSS-UTF ) [ 6 ] y la mayor parte del texto de esta propuesta se conservaron posteriormente en la especificación final. [ 7 ] [ 8 ] [ 9 ] En agosto de 1992, esta propuesta fue distribuida por un representante de IBM X/Open a las partes interesadas.

Una modificación realizada por Ken Thompson del grupo del sistema operativo Plan 9 en Bell Labs lo hizo autosincronizable , permitiendo que un lector comenzara en cualquier lugar y detectara inmediatamente los límites de los caracteres, a costa de ser algo menos eficiente en bits que la propuesta anterior. También abandonó el uso de sesgos que impedían codificaciones demasiado largas . [ 9 ] [ 10 ] El diseño de Thompson fue esbozado el 2 de septiembre de 1992, en un mantel individual en un restaurante de Nueva Jersey con Rob Pike . En los días siguientes, Pike y Thompson lo implementaron y actualizaron Plan 9 para usarlo en todo, [ 11 ] y luego comunicaron su éxito a X/Open, que lo aceptó como la especificación para FSS-UTF . [ 9 ] UTF-8 se presentó oficialmente por primera vez en la conferencia USENIX en San Diego , del 25 al 29 de enero de 1993. [ 12 ] El Grupo de Trabajo de Ingeniería de Internet adoptó UTF-8 en su Política sobre Conjuntos de Caracteres e Idiomas en RFC  2277 ( BCP 18) para futuros trabajos de estándares de Internet en enero de 1998, reemplazando los Conjuntos de Caracteres de Byte Único como Latin-1 en RFC más antiguos. [ 13 ]

Los estándares anteriores para UTF-8, como RFC 2279 , podían codificar hasta 31 bits en seis bytes. En noviembre de 2003, RFC 3629 restringió UTF-8 para que coincidiera con las restricciones de la codificación de caracteres UTF-16 : la prohibición explícita de los puntos de código correspondientes a los caracteres sustitutos alto y bajo eliminó más del 3 % de las secuencias de tres bytes, y el final en U+10FFFF eliminó más del 48 % de las secuencias de cuatro bytes y todas las secuencias de cinco y seis bytes. [ 14 ]  

Descripción

UTF-8 codifica los puntos de código en uno a cuatro bytes, dependiendo del valor del punto de código. En la siguiente tabla, los caracteres u a z , cada uno de los cuales representa un dígito hexadecimal, se reemplazan por sus cuatro bits constituyentes uuuu a zzzz , desde las posiciones U+ uvwxyz :

Como ejemplo, el carácter 桁 tiene el punto de código hexadecimal U+6841 , que es 0110 1000 0100 0001 en binario, lo que hace que su codificación UTF-8 sea 11100110 10100001 10000001 .

Los primeros 128  puntos de código (ASCII) necesitan un byte. Los siguientes 1920  puntos de código necesitan dos bytes para su codificación, lo que cubre el resto de casi todos los alfabetos de escritura latina , así como las extensiones del AFI , los alfabetos griego , cirílico , copto , armenio , hebreo , árabe , siríaco , thaana y n'ko , y también los signos diacríticos combinatorios . Se necesitan tres bytes para los 61 440  puntos de código restantes del Plano Multilingüe Básico (BMP), que incluyen la mayoría de los caracteres chinos, japoneses y coreanos . Se necesitan cuatro bytes para los 1 048 576  puntos de código que no pertenecen al BMP, que incluyen emojis , caracteres CJK menos comunes y otros caracteres útiles. [ 15 ]

UTF-8 es un código de prefijo y no es necesario leer más allá del último byte de un punto de código para decodificarlo. A diferencia de muchas codificaciones de texto multibyte anteriores, como Shift-JIS , es autosincronizable, por lo que es posible buscar cadenas o caracteres cortos; además, el inicio de un punto de código se puede encontrar desde una posición aleatoria retrocediendo como máximo tres bytes. Los valores elegidos para los bytes iniciales hacen que ordenar una lista de cadenas UTF-8 las coloque en el mismo orden que ordenar cadenas UTF-32 .

Codificaciones excesivamente largas

Utilizar una fila de la tabla anterior para codificar un punto de código menor que el "Primer punto de código" (utilizando así más bytes de los necesarios) se denomina codificación excesivamente larga . Esto representa un problema de seguridad, ya que permite que las secuencias de caracteres eludan otras validaciones de seguridad, como el bloqueo de../ JavaScript malicioso . Se han reportado numerosas vulnerabilidades de alto perfil relacionadas con codificaciones excesivamente largas en productos como el servidor web IIS de Microsoft [ 16 ] y el contenedor de servlets Tomcat de Apache [ 17 ] . Por lo tanto, las codificaciones excesivamente largas deben considerarse un error y nunca deben decodificarse.

Manejo de errores

No todas las secuencias de bytes son UTF-8 válidas. Se debe preparar un decodificador UTF-8 para:

  • Un "byte de continuación" ( 0x80 0xBF ) al inicio de un carácter.
  • Un byte que no es de continuación (o el final de la cadena) antes del final de un carácter.
  • Una codificación demasiado larga ( 0xC0 , 0xC1 , 0xE0 seguido de menos de 0xA0 , o 0xF0 seguido de menos de 0x90 )
  • Una secuencia de varios bytes que se decodifica a un valor mayor que U+10FFFF ( 0xF4 seguido de 0x90 o mayor, 0xF5 0xFF )

Muchos de los primeros decodificadores UTF-8 decodificaban estas secuencias, ignorando los bits incorrectos. Una secuencia UTF-8 inválida cuidadosamente elaborada podía hacer que omitieran o crearan caracteres ASCII como NUL , barra o comillas, lo que generaba vulnerabilidades de seguridad. El RFC 3629 establece que "las implementaciones del algoritmo de decodificación DEBEN proteger contra la decodificación de secuencias inválidas". [ 18 ] El estándar Unicode exige que los decodificadores: "... traten cualquier secuencia de unidad de código mal formada como una condición de error. Esto garantiza que no interpretarán ni emitirán una secuencia de unidad de código mal formada". 

Era común lanzar una excepción o truncar la cadena en caso de error [ 19 ] , pero esto convierte lo que de otro modo serían errores inofensivos (es decir, "archivo no encontrado") en una denegación de servicio ; por ejemplo, las primeras versiones de Python 3.0 salían inmediatamente si la línea de comandos o las variables de entorno contenían UTF-8 no válido. [ 20 ] La mayoría del código ahora reemplaza cada error con un único punto de código (como U+FFFD - CARÁCTER DE REEMPLAZO ) y continúa la decodificación.

Algunos decodificadores consideran la secuencia E1,A0,20 (un código truncado de 3 bytes seguido de un espacio) como un solo error. Esto no es una buena idea, ya que una búsqueda de un carácter de espacio encontraría el que está oculto en el error. Desde Unicode 6 (octubre de 2010) [ 1 ], el estándar (capítulo 3) ha recomendado una "mejor práctica" en la que el error es un byte de continuación o termina en el primer byte que no está permitido, por lo que E1,A0,20 es un error de dos bytes seguido de un espacio. Un error no tiene más de tres bytes de longitud, nunca contiene el inicio de un carácter válido y hay   21.952  errores posibles diferentes. Muchos decodificadores hacen que cada byte sea un error, en cuyo caso E1,A0,20 son dos errores seguidos de un espacio; ahora solo hay 128 errores diferentes, lo que hace práctico almacenar los errores en la cadena de salida, [ 20 ] o reemplazarlos con caracteres de una codificación heredada.

Solo un pequeño subconjunto de las posibles cadenas de bytes son UTF-8 sin errores: no pueden aparecer varios bytes a la vez, un byte con el bit más significativo activado no puede estar solo, y en una cadena verdaderamente aleatoria, un byte con el bit más significativo activado tiene solo una probabilidad de 1/15 de iniciar un carácter UTF-8 válido. Esto facilita la detección si se utiliza accidentalmente una codificación de texto antigua en lugar de UTF-8, simplificando la conversión de un sistema a UTF-8 y evitando la necesidad de requerir una marca de orden de bytes o cualquier otro metadato.

Madres sustitutas

Desde RFC 3629 (noviembre  de 2003), los sustitutos altos y bajos utilizados por UTF-16 ( U+D800 a U+DFFF ) no son valores Unicode válidos, y sus codificaciones UTF-8 deben tratarse como una secuencia de bytes no válida. [ 18 ] Todas estas codificaciones comienzan con 0xED seguido de 0xA0 o superior. Esta regla a menudo se ignora ya que se permiten sustitutos en los nombres de archivo de Windows y esto significa que debe haber una forma de almacenarlos en una cadena. [ 21 ] UTF-8 que permite estas mitades de sustituto se ha llamado (informalmente) WTF-8 , por "formato de transformación tambaleante", [ 22 ] mientras que otra variación que también codifica todos los caracteres que no son BMP como dos sustitutos (seis bytes en lugar de cuatro) se llama CESU-8 .

Mapa de bytes

La tabla que aparece a continuación ofrece el significado detallado de cada byte en una secuencia codificada en UTF-8.

Marca de orden de bytes

Si la marca de orden de bytes Unicode U+FEFF está al principio de un archivo UTF-8, los tres primeros bytes serán 0xEF , 0xBB , 0xBF .

El estándar Unicode no exige ni recomienda el uso de la BOM para UTF-8, pero advierte que puede encontrarse al inicio de un archivo transcodificado desde otra codificación. [ 23 ] Si bien el texto ASCII codificado con UTF-8 es retrocompatible con ASCII, esto no es cierto cuando se ignoran las recomendaciones del estándar Unicode y se agrega una BOM. Una BOM puede confundir al software que no está preparado para ella, pero que puede aceptar UTF-8, por ejemplo, lenguajes de programación que permiten bytes no ASCII en literales de cadena , pero no al inicio del archivo. Sin embargo, existía y aún existe software que siempre inserta una BOM al escribir UTF-8 y se niega a interpretar correctamente UTF-8 a menos que el primer carácter sea una BOM (o que el archivo solo contenga ASCII).

Comparación con UTF-16

Durante mucho tiempo hubo un debate considerable sobre si era mejor procesar texto en UTF-16 o en UTF-8. La principal ventaja de UTF-16 es que la API de Windows lo requería para acceder a todos los caracteres Unicode (UTF-8 no fue totalmente compatible con Windows hasta mayo de 2019). Esto provocó que varias bibliotecas, como Qt, también utilizaran cadenas UTF-16, lo que extendió este requisito a plataformas que no son Windows.

En los inicios de Unicode, no existían caracteres mayores que U+FFFF y la combinación de caracteres se usaba raramente, por lo que la codificación de 16 bits era, en la práctica, de tamaño fijo. Algunos creían que la codificación de tamaño fijo podía hacer que el procesamiento fuera más eficiente, pero tales ventajas se perdieron tan pronto como UTF-16 también se convirtió en una codificación de ancho variable.

Los puntos de código U+0800U+FFFF ocupan tres bytes en UTF-8, pero solo dos en UTF-16. Esto dio lugar a la idea de que el texto en chino y otros idiomas ocuparía más espacio en UTF-8. Sin embargo, el texto solo es más grande si hay más de estos puntos de código que puntos de código ASCII de un byte, y esto rara vez ocurre en documentos reales debido al marcado , [ 24 ] junto con espacios, saltos de línea, dígitos, puntuación, palabras en inglés, etc.

UTF-8 tiene las ventajas de ser muy fácil de adaptar a cualquier sistema que pueda manejar un ASCII extendido , no tener problemas de orden de bytes y ocupar aproximadamente la mitad del espacio para cualquier idioma que utilice principalmente letras latinas .

Implementaciones y adopción

Conjunto de caracteres declarado para los 10  millones de sitios web más populares entre 2010 y 2021.
Uso de las principales codificaciones en la web desde 2001 hasta 2012, según los datos de Google, [ 25 ] con UTF-8 superando a todas las demás en 2008 y abarcando más del 60 % de la web en 2012. UTF-8 es la única codificación de Unicode que aparece (explícitamente) en la lista, y las demás solo proporcionan subconjuntos de Unicode. La cifra que incluye únicamente caracteres ASCII abarca todas las páginas web que solo contienen caracteres ASCII, independientemente del encabezado declarado.

UTF-8 ha sido la codificación más común para la World Wide Web desde 2008. [ 26 ] A partir de enero de 2026 UTF-8 es utilizado por el 98,9% de los sitios web encuestados. [ 2 ] Aunque muchas páginas solo utilizan caracteres ASCII para mostrar contenido, muy pocos sitios web ahora declaran que su codificación es solo ASCII en lugar de UTF-8. [ 27 ] Prácticamente todos los países e idiomas tienen un uso del 95% o más de codificaciones UTF-8 en la web.

Muchos estándares solo admiten UTF-8, por ejemplo, el intercambio JSON lo requiere (sin una marca de orden de bytes (BOM)). [ 28 ] El WHATWG también requiere UTF-8 para las especificaciones HTML y DOM , que afirma que "la codificación UTF-8 es la codificación más apropiada para el intercambio de Unicode ", [ 5 ] y el Consorcio de Correo de Internet recomienda que todos los programas de correo electrónico puedan mostrar y crear correo utilizando UTF-8. [ 29 ] [ 30 ] El Consorcio World Wide Web recomienda UTF-8 como codificación predeterminada en XML y HTML (y no solo usar UTF-8, sino también declararlo en los metadatos), "incluso cuando todos los caracteres están en el rango ASCII... El uso de codificaciones que no sean UTF-8 puede tener resultados inesperados". La versión 5.3 de la especificación HTML del W3C y el Living Standard actual del WHATWG requieren UTF-8. [ 31 ] [ 32 ]

Muchos programas informáticos tienen la capacidad de leer y escribir UTF-8. Puede que el usuario tenga que modificar las opciones de la configuración predeterminada o que se requiera una marca de orden de bytes (BOM) como primer carácter para leer el archivo. Algunos ejemplos de software que admiten UTF-8 son Microsoft Word , [ 33 ] [ 34 ] Microsoft Excel ( Office 2003 y versiones posteriores), [ 35 ] Google Drive , LibreOffice [ 36 ] y la mayoría de las bases de datos.

El software que "por defecto" usa UTF-8 (es decir, lo escribe sin que el usuario cambie la configuración y lo lee sin BOM) se ha vuelto más común desde 2010. [ 37 ] El Bloc de notas de Windows , en todas las versiones de Windows actualmente compatibles, escribe UTF-8 por defecto sin BOM (un cambio con respecto al Bloc de notas de Windows 7 ), lo que lo alinea con la mayoría de los demás editores de texto. [ 38 ] Algunos archivos del sistema en Windows 11 requieren UTF-8 [ 39 ] sin necesidad de BOM, y casi todos los archivos en macOS y la mayoría de las distribuciones de Linux deben ser UTF-8 sin BOM. Los lenguajes de programación que usan UTF-8 por defecto para E/S incluyen Ruby 3.0, [ 40 ] [ 41 ] R 4.2.2, [ 42 ] Raku y Java 18. [ 43 ] Python 3.15 hace que UTF-8 sea el valor predeterminado para E/S; [ 44 ] [ 45 ] Las versiones anteriores requieren una opción para leer/escribir UTF-8. [ 46 ] C++23 adoptó UTF-8 como el único formato de archivo de código fuente portable. [ 47 ]    open()

La retrocompatibilidad es un serio impedimento para cambiar el código y las API que usan UTF-16 a UTF-8, pero esto está sucediendo. En mayo de 2019, Microsoft agregó la capacidad para que una aplicación establezca UTF-8 como la "página de códigos" para la API de Windows, eliminando la necesidad de usar UTF-16; y más recientemente ha recomendado a los programadores que usen UTF-8, [ 48 ] e incluso afirma que "UTF-16 [...] es una carga única que Windows impone al código que se dirige a múltiples plataformas". [ 4 ] La primitiva de cadena predeterminada en Go , [ 49 ] Julia , Rust , Swift (desde la versión 5), [ 50 ] y PyPy [ 51 ] usa UTF-8 internamente en todos los casos. Python (desde la versión 3.3) utiliza UTF-8 internamente para las extensiones de la API de Python C [ 52 ] [ 53 ] y a veces para cadenas [ 52 ] [ 54 ] y se planea que una futura versión de Python almacene cadenas como UTF-8 por defecto. [ 55 ] [ 56 ] Las versiones modernas de Microsoft Visual Studio utilizan UTF-8 internamente. [ 57 ] Todas las versiones actualmente compatibles de Microsoft SQL Server admiten UTF-8 para importar y exportar, y además todas las que cuentan con soporte principal, es decir, desde SQL Server 2019, admiten UTF-8 internamente, y su uso resulta en un aumento de velocidad del 35 % y una reducción de casi el 50 % en los requisitos de almacenamiento. [ 58 ]

Java internamente usa UTF-16 para el chartipo de datos y, en consecuencia, las clases Character, String, y , [ 59 ] pero para E/S usa "UTF-8 modificado" , que es lo mismo que CESU-8, excepto que el carácter nulo U+0000 usa la codificación de dos bytes extralarga 0xC0 0x80 en lugar de solo 0x00 . [ 60 ] Las cadenas UTF-8 modificadas nunca contienen bytes nulos reales, pero pueden contener todos los puntos de código Unicode, incluido U+0000 , [ 61 ] lo que permite que dichas cadenas (con un byte nulo añadido) sean procesadas por funciones de cadena terminadas en nulo tradicionales . Java lee y escribe UTF-8 normal en archivos y flujos, [ 62 ] pero utiliza UTF-8 modificado para la serialización de objetos , [ 63 ] [ 64 ] para la interfaz nativa de Java , [ 65 ] y para incrustar cadenas constantes en archivos de clase de Java . [ 61 ] El formato dex definido por Dalvik también utiliza el mismo UTF-8 modificado para representar valores de cadena. [ 66 ] Tcl también utiliza el mismo UTF-8 modificado [ 67 ] que Java para la representación interna de datos Unicode, pero utiliza CESU-8 estricto para datos externos.StringBuffer 

El lenguaje de programación Raku (anteriormente Perl 6) utiliza utf-8codificación por defecto para E/S ( Perl 5 también la admite ) ; aunque esa elección en Raku también implica "normalización a Unicode NFC (forma normalizada canónica)" . En algunos casos, el usuario querrá asegurarse de que no se realice ninguna normalización; para ello utf8-c8se puede utilizar " ". [ 68 ] Esa variante UTF-8 Clean-8 , implementada por Raku, es un codificador/decodificador que conserva los bytes tal cual (incluso secuencias UTF-8 ilegales) y permite la síntesis de grafemas en forma normal. [ 69 ]

La versión 3 del lenguaje de programación Python trata cada byte de una secuencia de bytes UTF-8 no válida como un error (ver también cambios con el nuevo modo UTF-8 en Python 3.7 [ 70 ] ); esto da 128 errores posibles diferentes. Se han creado extensiones para permitir que cualquier secuencia de bytes que se supone es UTF-8 se transforme sin pérdida a UTF-16 o UTF-32, traduciendo los 128 bytes de error posibles a 128 puntos de código reservados y transformando esos puntos de código de nuevo en bytes de error para generar UTF-8. El enfoque más común es traducir los códigos a U+DC80 ... U+DCFF que son valores sustitutos bajos (finales) y por lo tanto UTF-16 "no válido", como lo usa el enfoque PEP 383 de Python (o "surrogateescape"). [ 20 ] La versión 2.0 de NumPy y sus formatos de archivo admiten UTF-8 (añadiendo StringDType para ello). [ 71 ] Otra codificación llamada MirBSD OPTU-8/16 los convierte a U+EF80 ... U+EFFF en un área de uso privado . [ 72 ] En ambos enfoques, el valor del byte se codifica en los ocho bits inferiores del punto de código de salida. Estas codificaciones son necesarias para que el UTF-8 no válido sobreviva a la traducción hacia y desde el UTF-16 utilizado internamente por Python, y como los nombres de archivo de Unix pueden contener UTF-8 no válido, es necesario que esto funcione. [ 73 ]

La mayoría de los sistemas de archivos en sistemas tipo Unix pueden usar UTF-8 para codificar nombres de archivo, ya que la búsqueda de nombres de archivo se realiza comparando los bytes de los nombres de archivo. Los sistemas de archivos ext4 de Linux y APFS de macOS admiten búsquedas de nombres de archivo que no distinguen entre mayúsculas y minúsculas, lo que requiere que se especifique la codificación de los nombres de archivo; ext4 admite UTF-8 y lo usa por defecto, [ 74 ] y APFS requiere UTF-8. [ 75 ] El antiguo HFS Plus de Apple usa UTF-16 para los nombres de archivo, pero usa UTF-8 en los enlaces simbólicos . [ 76 ] El sistema de archivos de Windows, NTFS , usa UTF-16 para los nombres de archivo.

Estándares

El nombre oficial de la codificación es UTF-8, la ortografía utilizada en todos los documentos del Consorcio Unicode. Se requiere el guion y no se permiten espacios. Otros nombres utilizados son:

Existen varias definiciones actuales de UTF-8 en diversos documentos de estándares:

  • RFC 3629 / STD 63 (2003), que establece UTF-8 como un elemento estándar del protocolo de Internet. 
  • RFC 5198 define UTF-8 NFC para intercambio de redes (2008) 
  • ISO/IEC 10646:2020/Amd 1:2023 [ 87 ]
  • El estándar Unicode, versión 17.0.0 (2025)

Sustituyen las definiciones que figuran en las siguientes obras obsoletas:

  • El estándar Unicode, versión 2.0 , apéndice A (1996)
  • ISO/IEC 10646-1:1993 Enmienda 2 / Anexo R (1996)
  • RFC 2044 (1996) 
  • RFC 2279 (1998) 
  • El estándar Unicode, versión 3.0 , §2.3 (2000) más la corrección n.° 1  : UTF-8 forma más corta (2000)
  • Anexo estándar Unicode n.º 27: Unicode 3.1 (2001) [ 88 ]
  • El estándar Unicode, versión 5.0 (2006) [ 89 ]
  • El estándar Unicode, versión 6.0 (2010) [ 1 ]

En su mecánica general, todos son iguales, y las principales diferencias radican en cuestiones como el rango permitido de valores de puntos de código y el manejo seguro de entradas no válidas.

Véase también

Referencias

  1. 1 2 3 Unicode® 6.0.0: Publicado: 11 de octubre de 2010 (Anuncio) ( ed. 6.0.0 ). Mountain View, California, EE. UU.: The Unicode Consortium . ISBN  978-1-936213-01-6Archivado del original el 28/07/2025 . Consultado el 23/08/2025 .
  2. 1 2 "Encuesta de uso de codificaciones de caracteres desglosada por clasificación" . W3Techs . Enero de 2026. Recuperado el 3 de enero de 2026 .
  3. "Conformidad" . Unicode 16.0.0: Especificación principal / Capítulo 3 ( ed. 6.0.0 ). Mountain View, California, EE. UU.: The Unicode Consortium . 3.9 Formas de codificación Unicode. ISBN  978-1-936213-34-4Archivado del original el 1 de julio de 2025. Consultado el 23 de agosto de 2025. Cada forma de codificación asigna los puntos de código Unicode U+0000..U+D7FF y U+E000..U+10FFFF .
  4. 1 2 "Compatibilidad con UTF-8 en Microsoft GDK" . Microsoft Learn . Microsoft Game Development Kit (GDK) . Consultado el 5 de marzo de 2023 .
  5. 1 2 "Estándar de codificación" . encoding.spec.whatwg.org . Consultado el 20 de noviembre de 2025 .
  6. "Formato de transformación UCS seguro para sistemas de archivos (FSS-UTF) - Especificación preliminar X/Open" (PDF) . unicode.org . 
  7. "Apéndice F. Formato de transformación UCS seguro para sistemas de archivos FSS-UTF" (PDF) . El estándar Unicode 1.1 . Archivado (PDF) del original el 7 de junio de 2016. Consultado el 7 de junio de 2016 .
  8. Whistler, Kenneth (12 de junio de 2001). "FSS-UTF, UTF-2, UTF-8 y UTF-16" . Lista de correo Unicode (Lista de correo). Archivado del original el 7 de junio de 2016. Consultado el 20 de noviembre de 2025 .
  9. 1 2 3 Pike, Rob (30-04-2003). "Historia de UTF-8" . Recuperado el 07-09-2012 .
  10. En aquel entonces, la resta era más lenta que la lógica de bits en muchos ordenadores, y la velocidad se consideraba necesaria para su aceptación.
  11. ^ Lucio, Rob; Thompson, Ken (1993). "Hola mundo o Καλημέρα κόσμε o こんにちは 世界" (PDF) . Actas de la conferencia USENIX de invierno de 1993 .
  12. "ACTAS DE LA CONFERENCIA DE INVIERNO DE USENIX DE 1993" . www.usenix.org . Consultado el 20 de noviembre de 2025 .
  13. Alvestrand, Harald T. (enero de 1998). Política del IETF sobre conjuntos de caracteres e idiomas . IETF . doi : 10.17487/RFC2277 . BCP 18. RFC 2277 .
  14. Pike, Rob (6 de septiembre de 2012). "UTF-8 cumplió 20 años ayer" . Archivado del original el 30 de noviembre de 2012. Recuperado el 7 de septiembre de 2012 .
  15. Lunde, Dr. Ken (09/01/2022). "Lista de los diez mejores de 2022: ¿Por qué apoyar los puntos de código más allá de BMP?" . Medium . Recuperado el 20/11/2025 .
  16. Marin, Marvin (17 de octubre de 2000). Análisis de vulnerabilidades UNICODE en Windows NT . Recorrido de carpetas en servidores web. SANS Institute (Informe). Preguntas frecuentes sobre malware. MS00-078. Archivado del original el 27 de agosto de 2014.
  17. "CVE-2008-2938" . Base de datos nacional de vulnerabilidades (nvd.nist.gov) . Instituto Nacional de Estándares y Tecnología de EE. UU . 2008. Consultado el 20 de noviembre de 2025 .
  18. 1 2 Yergeau, F. (noviembre de 2003). UTF-8, un formato de transformación de ISO 10646. IETF . doi : 10.17487 /RFC3629 . STD 63. RFC 3629. Recuperado el 20 de agosto de 2020 .
  19. "DataInput (Java Platform SE 8)" . docs.oracle.com . Consultado el 20 de noviembre de 2025 .
  20. 1 2 3 von Löwis, Martin (22 de abril de 2009). "Bytes no decodificables en interfaces de caracteres del sistema" . Python Software Foundation . PEP 383. Recuperado el 20 de noviembre de 2025 .
  21. "PEP 529 – Cambiar la codificación del sistema de archivos de Windows a UTF-8 | peps.python.org" . Propuestas de mejora de Python (PEPs) . Consultado el 20 de noviembre de 2025 .
  22. "La codificación WTF-8" . wtf-8.codeberg.page . Consultado el 30/11/2025 .
  23. "Capítulo 2" (PDF) , El estándar Unicode — Versión 15.0.0 , pág. 39  
  24. Radzivilovsky, Pavel; Galka, Yakov; Nóvgorodov, Slava. "Manifiesto UTF-8 en todas partes" . UTF-8 en todas partes . Consultado el 25 de marzo de 2026 .
  25. Davis, Mark (3 de febrero de 2012). "Unicode en más del 60 por ciento de la web" . Blog oficial de Google . Archivado del original el 9 de agosto de 2018. Consultado el 24 de julio de 2020 . 
  26. Davis, Mark (5 de mayo de 2008). "Transición a Unicode 5.1" . Blog oficial de Google . Consultado el 13 de marzo de 2023 . 
  27. "Estadísticas de uso y cuota de mercado de ASCII para sitios web" . W3Techs . Diciembre de 2025. Consultado el 17 de diciembre de 2025 .
  28. Bray, Tim (diciembre de 2017). Bray, Tim (ed.). El formato de intercambio de datos JSON (JavaScript Object Notation) . IETF. doi : 10.17487/RFC8259 . RFC 8259. Consultado el 16 de febrero de 2018 .
  29. "Uso de caracteres internacionales en el correo electrónico por Internet" . Consorcio de Correo Electrónico por Internet. 1 de agosto de 1998. Archivado del original el 26 de octubre de 2007. Consultado el 8 de noviembre de 2007 .
  30. "Estándar de codificación" . encoding.spec.whatwg.org . Consultado el 20 de noviembre de 2025 .
  31. 1 2 "Especificar la codificación de caracteres del documento" . HTML 5.3 (Informe). Consorcio World Wide Web . 28 de enero de 2021. Recuperado el 6 de enero de 2026 . 
  32. "Especificar la codificación de caracteres del documento" . Estándar HTML . WHATWG . 17 de diciembre de 2025. Consultado el 6 de enero de 2026 .
  33. "Elija la codificación de texto al abrir y guardar archivos" . Soporte técnico de Microsoft . Consultado el 1 de noviembre de 2021 .
  34. "Exportar un archivo UTF-8 desde Word " . support.3playmedia.com . 14 de marzo de 2023..txt
  35. Abhinav, Ankit; Xu, Jazlyn (13 de abril de 2020). "¿Cómo abrir un archivo UTF-8 en Excel sin que se produzcan errores de conversión de caracteres en japonés y chino, tanto en Mac como en Windows?" . Comunidad de soporte de Microsoft . Consultado el 1 de noviembre de 2021 .CSV
  36. "Guardar un archivo CSV como UTF-8" . RO CSVI . LibreOffice . Consultado el 20 de mayo de 2025 .
  37. Galloway, Matt (octubre de 2012). "Codificación de caracteres para desarrolladores de iOS; o, ¿UTF-8 y ahora qué?" . www.galloway.me.uk . Consultado el 2 de enero de 2021. ... en realidad, normalmente se asume UTF-8, ya que es, con mucho, la codificación más común. 
  38. " El Bloc de notas de Windows 10 está mejorando la compatibilidad con la codificación UTF-8" . BleepingComputer . Consultado el 24 de marzo de 2021. Microsoft ahora guarda por defecto los nuevos archivos de texto como UTF-8 sin BOM, como se muestra a continuación. 
  39. "Personalizar el menú Inicio de Windows 11 " . docs.microsoft.com . Consultado el 29/06/2021 . Asegúrese de que su archivo LayoutModification.json utilice la codificación UTF-8. 
  40. "Establecer como valor predeterminado para Encoding.default_external a UTF-8 en Windows" . Sistema de seguimiento de incidencias de Ruby (bugs.ruby-lang.org) . Ruby master. Característica n.º 16604. Consultado el 1 de agosto de 2022 . 
  41. "Característica n.º 12650: Usar codificación UTF-8 para ENV en Windows" . Sistema de seguimiento de incidencias de Ruby . Ruby master . Consultado el 1 de agosto de 2022 .
  42. "Nuevas características en R 4.2.0" . Blogueros de R. El blog Jumping Rivers. 1 de abril de 2022. Consultado el 1 de agosto de 2022 .  
  43. "UTF-8 por defecto" . openjdk.java.net . JEP 400. Consultado el 30 de marzo de 2022 .
  44. "Novedades de Python 3.15" . Documentación de Python . Consultado el 23 de diciembre de 2025 .
  45. "Hacer que el modo UTF-8 sea el predeterminado" . peps.python.org . PEP 686. Consultado el 26 de julio de 2023 . 
  46. "Agregar un nuevo modo UTF-8" . peps.python.org . PEP 540. Consultado el 23 de septiembre de 2022 . 
  47. Compatibilidad con UTF-8 como codificación de archivos fuente portátiles (PDF) . open-std.org (Informe). 2022. p2295r6.
  48. "Usar páginas de códigos UTF-8 en aplicaciones de Windows" . Microsoft Learn . 20 de agosto de 2024. Consultado el 24 de septiembre de 2024 .
  49. "Representación del código fuente" . Especificación del lenguaje de programación Go . golang.org (Informe) . Consultado el 10 de febrero de 2021 .
  50. Tsai, Michael J. (21 de marzo de 2019). "Cadena UTF-8 en Swift 5" (entrada de blog) . Recuperado el 15 de marzo de 2021 . 
  51. Mattip (24-03-2019). "PyPy v7.1 lanzado; ahora usa utf-8 internamente para cadenas unicode" . Blog de estado de PyPy . Consultado el 20-11-2025 .
  52. 1 2 "Representación flexible de cadenas" . Python.org . PEP 393. Consultado el 18 de mayo de 2022 . 
  53. "Estructuras de objetos comunes" . Documentación de Python . Consultado el 20 de noviembre de 2025 .
  54. "Objetos y códecs Unicode" . Documentación de Python . Consultado el 19 de agosto de 2023. La representación UTF-8 se crea bajo demanda y se almacena en caché en el objeto Unicode.
  55. "PEP 623 – eliminar wstr de Unicode" . Python.org . Consultado el 21 de noviembre de 2020 .  
  56. Wouters, Thomas (11 de julio de 2023). "Python 3.12.0 beta 4 lanzado" . Python Insider (entrada de blog) . Consultado el 26 de julio de 2023. Los miembros obsoletos de la implementación C de objetos Unicode fueron eliminados, según PEP 623.wstrwstr_length
  57. "validate-charset (validar para caracteres compatibles)" . docs.microsoft.com . Consultado el 19/07/2021 . Visual Studio utiliza UTF-8 como codificación interna de caracteres durante la conversión entre el conjunto de caracteres de origen y el conjunto de caracteres de ejecución.
  58. "Presentación de la compatibilidad con UTF-8 para SQL Server" . techcommunity.microsoft.com . 2 de julio de 2019. Consultado el 24 de agosto de 2021 .
  59. "Character (Java SE 24 y JDK 24)" . Oracle Corporation . 2025. Consultado el 8 de abril de 2025 .
  60. "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 .
  61. 1 2 "Especificación de la máquina virtual Java, sección 4.4.7: La estructura CONSTANT_Utf8_info" . Oracle Corporation . 2015. Recuperado el 16 de octubre de 2015 .
  62. InputStreamReader yOutputStreamWriter
  63. "Especificación de serialización de objetos Java, capítulo 6: Protocolo de flujo de serialización de objetos, sección 2: Elementos de flujo" . Oracle Corporation . 2010. Consultado el 16 de octubre de 2015 .
  64. DataInput yDataOutput
  65. "Especificación de la interfaz nativa de Java, capítulo 3: Tipos y estructuras de datos JNI, sección: Cadenas UTF-8 modificadas" . Oracle Corporation . 2015. Consultado el 16 de octubre de 2015 .
  66. "ART y Dalvik" . Proyecto de código abierto de Android . Archivado del original el 26 de abril de 2013. Consultado el 9 de abril de 2013 .
  67. "UTF-8 bit by bit" . Wiki de Tcler . 28 de febrero de 2001. Consultado el 3 de septiembre de 2022 .
  68. "codificación" . Documentación de Raku . Consultado el 20 de noviembre de 2025 .
  69. "Unicode" . Documentación de Raku . Consultado el 20 de noviembre de 2025 .
  70. "PEP 540 – Agregar un nuevo modo UTF-8" . Propuestas de mejora de Python (PEPs) . Consultado el 20 de noviembre de 2025 .
  71. "NEP 55 – Agregar un DType de cadena de ancho variable UTF-8 a NumPy" . Propuestas de mejora de NumPy . Consultado el 20 de noviembre de 2025 .
  72. ^ "RTFM optu8to16(3), optu8to16vis(3)" . MirBSD . Consultado el 20 de noviembre de 2025 .
  73. Davis, Mark ; Suignard, Michel (2014). "3.7 Habilitación de la conversión sin pérdidas" . Consideraciones de seguridad de Unicode . Informe técnico de Unicode n .° 36. Recuperado el 20 de noviembre de 2025 .
  74. "Información general de Ext4" . Documentación del kernel de Linux . Consultado el 20 de noviembre de 2025 .
  75. "Preguntas frecuentes" . Guía del sistema de archivos de Apple . Apple . Consultado el 20 de noviembre de 2025 .
  76. "Nota técnica TN1150: Formato de volumen HFS Plus" . Apple . Consultado el 20 de noviembre de 2025 .
  77. "Estándar de codificación § 4.2. Nombres y etiquetas" . WHATWG . Consultado el 29 de abril de 2018 .
  78. "Conjuntos de caracteres" . Autoridad de Números Asignados de Internet . 23 de enero de 2013. Consultado el 8 de febrero de 2013 .
  79. "BOM" . suikawiki (en japonés). Archivado del original el 17 de enero de 2009.
  80. Davis, Mark . "Formas de Unicode" . IBM . Archivado del original el 6 de mayo de 2005. Consultado el 18 de septiembre de 2013 .
  81. Liviu (07/02/2014). "Página de códigos UTF-8 65001 en Windows 7 - parte I" . Recuperado el 30/01/2018 . Anteriormente, en XP (y, sin verificar, probablemente también en Vista), los bucles for simplemente no funcionaban mientras la página de códigos 65001 estaba activa.
  82. "MySQL :: Manual de referencia de MySQL 8.0 :: 10.9.1 El conjunto de caracteres utf8mb4 (codificación Unicode UTF-8 de 4 bytes)" . Manual de referencia de MySQL 8.0 . Oracle Corporation . Consultado el 14 de marzo de 2023 .  
  83. "MySQL :: Manual de referencia de MySQL 8.0 :: 10.9.2 El conjunto de caracteres utf8mb3 (codificación Unicode UTF-8 de 3 bytes)" . Manual de referencia de MySQL 8.0 . Oracle Corporation . Consultado el 24 de febrero de 2023 .  
  84. "Guía de soporte para la globalización de bases de datos" . docs.oracle.com . Consultado el 16 de marzo de 2023 .
  85. Hood, Doug (10 de julio de 2025). "Por qué importa el conjunto de caracteres de la base de datos" . blogs.oracle.com . Consultado el 20 de noviembre de 2025 .
  86. "Conjuntos de símbolos HP PCL | Blog de soporte del lenguaje de control de impresora (PCL y PXL)" . 19 de febrero de 2015. Archivado del original el 19 de febrero de 2015. Consultado el 30 de enero de 2018 .
  87. "ISO/IEC 10646:2020/Amd 1:2023" . ISO . Consultado el 20 de noviembre de 2025 .
  88. "UAX #27: Unicode 3.1" . www.unicode.org . Consultado el 20 de noviembre de 2025 .
  89. El estándar Unicode, versión 5.0 §3.9–§3.10 cap. 3 , 2006.
  • Documento original en UTF-8 ( o PDF ) sobre el Plan 9 de Bell Labs.
  • Historia de UTF-8 por Rob Pike
  • Caracteres, símbolos y el milagro de Unicode en YouTube
Obtenido de " https://en.wikipedia.org/w/index.php?title=UTF-8&oldid=1362373512#Modified_UTF-8 "