UTF-8

Codificación de ancho variable compatible con ASCII de Unicode, utilizando de uno a cuatro bytes

UTF-8

Estándar	Estándar Unicode
Clasificación	Formato de transformación Unicode , ASCII extendido , codificación de ancho variable
Se extiende	US-ASCII
Transforma / Codifica	ISO 10646 ( Unicode )
Precedido por	UTF-1
v t mi

UTF-8 es una codificación de caracteres de ancho variable que se utiliza para la comunicación electrónica. Definido por el estándar Unicode, el nombre se deriva del formato de transformación Unicode (o juego de caracteres codificados universal ) : 8 bits . ^[1]

UTF-8 es capaz de codificar todos los 1,112,064 ^{[nb 1]} puntos de código de caracteres válidos en Unicode utilizando 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 ocurrir con más frecuencia, se codifican utilizando menos bytes. Fue diseñado para compatibilidad 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 el texto ASCII válido también es Unicode codificado en UTF-8 válido. Dado que los bytes ASCII no ocurren cuando se codifican puntos de código no ASCII en UTF-8, UTF-8 es seguro de usar en la mayoría de los lenguajes de programación y documentos que interpretan ciertos caracteres ASCII de una manera especial, como "/" ( barra ) en nombres de archivo, "\" ( barra invertida ) en secuencias de escape y "%" en printf .

UTF-8 se diseñó como una alternativa superior a UTF-1 , una codificación de ancho variable propuesta con compatibilidad parcial con ASCII que carecía de algunas características, incluida la sincronización automática y el manejo de caracteres totalmente compatible con ASCII, como barras. Ken Thompson y Rob Pike produjeron la primera implementación para el sistema operativo Plan 9 en septiembre de 1992. ^{[2] [3]} Esto llevó a su adopción por X / Open como su especificación para FSS-UTF , que se presentaría oficialmente por primera vez en USENIX. en enero de 1993 y posteriormente adoptado por el Grupo de trabajo de ingeniería de Internet(IETF) en RFC 2277 ( BCP 18 ) para el futuro trabajo de estándares de Internet, reemplazando los conjuntos de caracteres de un solo byte como Latin-1 en RFC más antiguos.

UTF-8 es, con mucho, la codificación más común para la World Wide Web , representando el 97% de todas las páginas web y hasta el 100% para algunos idiomas, a partir de 2021. ^[4]

Nombrar

El código oficial de la Autoridad de Números Asignados de Internet (IANA) para la codificación es "UTF-8". ^[5] Todas las letras están en mayúsculas y el nombre está dividido con guión. Esta ortografía se utiliza en todos los documentos del Consorcio Unicode relacionados con la codificación.

Alternativamente, el nombre " utf-8 " puede ser utilizado por todos los estándares que cumplen con la lista de IANA (que incluyen encabezados CSS , HTML , XML y HTTP ), ^[6] ya que la declaración no distingue entre mayúsculas y minúsculas. ^[5]

Otras descripciones, como las que omiten el guión o lo reemplazan con un espacio, es decir, " utf8 " o " UTF 8 ", no son aceptadas como correctas por las normas vigentes . ^[7] A pesar de esto, la mayoría de los agentes, como los navegadores, pueden comprenderlos, por lo que los estándares destinados a describir la práctica existente (como HTML5) pueden requerir su reconocimiento de manera efectiva. ^[8]

Extraoficialmente, UTF-8-BOM y UTF-8-NOBOM a veces se usan para referirse a archivos de texto que contienen respectivamente (incluso con la BOM no recomendada) o no tienen una marca de orden de bytes (BOM). ^{[ cita requerida ]} En Japón especialmente, la codificación UTF-8 sin BOM a veces se llama " UTF-8N ". ^{[9] [10]}

Windows 7 y posteriores, es decir, todas las versiones compatibles de Windows, tienen la página de códigos 65001 , como sinónimo de UTF-8 (con mejor soporte que en Windows anterior), ^[11] y Microsoft tiene un script para Windows 10 , para habilitarlo de forma predeterminada para su programa Microsoft Notepad . ^[12]

En PCL , UTF-8 se denomina ID de símbolo "18N" (PCL admite 183 codificaciones de caracteres, llamados Conjuntos de símbolos, que potencialmente podrían reducirse a uno, 18N, que es UTF-8). ^[13]

Codificación

Desde la restricción del espacio de código Unicode a valores de 21 bits en 2003, UTF-8 se define para codificar puntos de código en uno a cuatro bytes, dependiendo del número de bits significativos en el valor numérico del punto de código. La siguiente tabla muestra la estructura de la codificación. Los caracteres x se reemplazan por los bits del punto de código.

Conversión de punto de código <-> UTF-8

Primer punto de código	Último punto de código	Byte 1	Byte 2	Byte 3	Byte 4
U + 0000	U + 007F	0xxxxxxx
U + 0080	U + 07FF	110xxxxx	10xxxxxx
U + 0800	U + FFFF	1110xxxx	10xxxxxx	10xxxxxx
U + 10000	[nb 2] U + 10FFFF	11110xxx	10xxxxxx	10xxxxxx	10xxxxxx

Los primeros 128 caracteres (US-ASCII) necesitan un byte. Los siguientes 1.920 caracteres necesitan dos bytes para codificarse, lo que cubre el resto de casi todos los alfabetos de escritura latina , y también los alfabetos griego , cirílico , copto , armenio , hebreo , árabe , siríaco , thaana y N'Ko , así como la combinación de diacríticos. Marcas . Se necesitan tres bytes para los caracteres del resto del plano multilingüe básico , que contiene prácticamente todos los caracteres de uso común, ^[14] incluidos la mayoríaCaracteres chinos, japoneses y coreanos . Se necesitan cuatro bytes para caracteres en los otros planos de Unicode , que incluyen caracteres CJK menos comunes , varios scripts históricos, símbolos matemáticos y emoji (símbolos pictográficos).

Un "carácter" en realidad puede tomar más de 4 bytes, por ejemplo, un carácter de bandera emoji toma 8 bytes ya que está "construido a partir de un par de valores escalares Unicode". ^[15] El recuento de bytes puede llegar hasta al menos 17 para conjuntos válidos de combinación de caracteres. ^[dieciséis]

Ejemplos

Considere la codificación del signo euro , €:

1. El punto de código Unicode para "€" es U + 20AC.
2. Como este punto de código se encuentra entre U + 0800 y U + FFFF, se necesitarán tres bytes para codificarlo.
3. El hexadecimal 20AC es binario 0010 0000 10 10 1100 . Los dos ceros iniciales se agregan porque una codificación de tres bytes necesita exactamente dieciséis bits desde el punto de código.
4. Debido a que la codificación tendrá una longitud de tres bytes, su byte inicial comienza con tres unos, luego un 0 ( 1110 ... )
5. Los cuatro bits más significativos del punto de código se almacenan en los cuatro bits restantes de orden inferior de este byte ( 1110 0010 ), dejando 12 bits del punto de código aún por codificar ( ... 0000 10 10 1100 ).
6. Todos los bytes de continuación contienen exactamente seis bits desde el punto de código. Entonces, los siguientes seis bits del punto de código se almacenan en los seis bits de orden inferior del siguiente byte, y 10 se almacena en los dos bits de orden superior para marcarlo como un byte de continuación (por lo tanto, 10 000010 ).
7. Finalmente, los últimos seis bits del punto de código se almacenan en los seis bits de orden inferior del byte final, y de nuevo 10 se almacenan en los dos bits de orden superior ( 10 101100 ).

Los tres bytes 1110 0010 10 000010 10 101100 pueden escribirse de forma más concisa en hexadecimal , como E2 82 AC .

La siguiente tabla resume esta conversión, así como otras con diferentes longitudes en UTF-8. Los colores indican cómo se distribuyen los bits del punto de código entre los bytes UTF-8. Los bits adicionales agregados por el proceso de codificación UTF-8 se muestran en negro.

Ejemplos de codificación UTF-8

Personaje		Punto de código binario	UTF-8 binario	UTF-8 hexagonal
PS	U + 0024	010 0100	0 0100100	24
¢	U + 00A2	000 10 10 0010	110 00010 10 100010	C2 A2
ह	U + 0939	0000 1001 00 11 1001	1110 0000 10 100100 10 111001	E0 A4 B9
€	U + 20AC	0010 0000 10 10 1100	1110 0010 10 000010 10 101100	E2 82 AC
한	U + D55C	1101 0101 01 01 1100	1.11 mil 1,101 mil 10 010.101 10 011 100	ED 95 9C
𐍈	U + 10348	0 00 01 0000 0011 01 00 1000	11110 000 10 010000 10 001101 10 001000	F0 90 8D 88

Octal

El uso de UTF-8 de seis bits por byte para representar los caracteres reales que se codifican, significa que la notación octal (que usa grupos de 3 bits) puede ayudar en la comparación de secuencias UTF-8 entre sí y en la conversión manual. ^[17]

Punto de código octal <-> Conversión octal UTF-8

Primer punto de código	Último punto de código	Byte 1	Byte 2	Byte 3	Byte 4
0	177	xxx
200	3777	3xx	2xx
4000	77777	34x	2xx	2xx
100000	177777	35x	2xx	2xx
200000	4177777	36x	2xx	2xx	2xx

Con la notación octal, los dígitos octales arbitrarios, marcados con x en la tabla, permanecerán sin cambios al convertir hacia o desde UTF-8.

Ejemplo: € = U + 20AC = 02 02 54 está codificado como 342202254 en UTF-8 (E2 82 AC en hexadecimal).

Diseño de página de códigos

La siguiente tabla resume el uso de unidades de código UTF-8 (bytes u octetos individuales) en un formato de página de códigos . La mitad superior ( 0_ a 7_ ) es para bytes usados ​​solo en códigos de un solo byte, por lo que parece una página de códigos normal; la mitad inferior es para los bytes de continuación ( 8_ a B_ ) y los bytes iniciales ( C_ a F_ ), y se explica con más detalle en la leyenda siguiente.

UTF-8

	_0	_1	_2	_3	_4	_5	_6	_7	_8	_9	_A	_B	_C	_D	_MI	_F
(1 byte) 0_	NUL 0000	SOH 0001	STX 0002	ETX 0003	EOT 0004	ENQ 0005	ACK 0006	BEL 0007	BS 0008	HT 0009	LF 000A	VT 000B	FF 000C	CR 000D	SO 000E	SI 000F
(1) 1_	DLE 0010	DC1 0011	DC2 0012	DC3 0013	DC4 0014	NAK 0015	SYN 0016	ETB 0017	PUEDE 0018	EM 0019	SUB 001A	ESC 001B	FS 001C	GS 001D	RS 001E	US 001F
(1) 2_	SP 0020	! 0021	" 0022	# 0023	$ 0024	% 0025	& 0026	« 0027	( 0028	) 0029	* 002A	+ 002B	, 002C	- 002D	. 002E	/ 002F
(1) 3_	0 0030	1 0031	2 0032	3 0033	4 0034	5 0035	6 0036	7 0037	8 0038	9 0039	: 003A	; 003B	< 003C	= 003D	> 003E	? 003F
(1) 4_	@ 0040	A 0041	B 0042	C 0043	D 0044	E 0045	F 0046	G 0047	H 0048	Yo 0049	J 004A	K 004B	L 004C	M 004D	N 004E	O 004F
(1) 5_	P 0050	Q 0051	R 0052	S 0053	T 0054	U 0055	V 0056	W 0057	X 0058	Y 0059	Z 005A	[ 005B	\ 005C	] 005D	^ 005E	_ 005F
(1) 6_	` 0060	un 0061	b 0062	c 0063	d 0064	e 0065	f 0066	g 0067	h 0068	yo 0069	j 006A	k 006B	l 006C	m 006D	n 006E	o 006F
(1) 7_	p 0070	q 0071	r 0072	s 0073	t 0074	u 0075	v 0076	w 0077	x 0078	y 0079	z 007A	{ 007B	| 007C	} 007D	~ 007E	DEL 007F
8_	• +00	• +01	• +02	• +03	• +04	• +05	• +06	• +07	• +08	• +09	• + 0A	• + 0B	• + 0C	• + 0D	• + 0E	• + 0F
9_	• +10	• +11	• +12	• +13	• +14	• +15	• +16	• +17	• +18	• +19	• + 1A	• + 1B	• + 1C	• + 1D	• + 1E	• + 1F
A_	• +20	• +21	• +22	• +23	• +24	• +25	• +26	• +27	• +28	• +29	• + 2A	• + 2B	• + 2C	• + 2D	• + 2E	• + 2F
B_	• +30	• +31	• +32	• +33	• +34	• +35	• +36	• +37	• +38	• +39	• + 3A	• + 3B	• + 3C	• + 3D	• + 3E	• + 3F
(2) C_	2 0000	2 0040	Latina 0080	Latina 00C0	Latina 0100	Latina 0140	Latina 0180	Latina 01C0	Latina 0200	IPA 0240	IPA 0280	IPA 02C0	acentos 0300	acentos 0340	Griega 0380	Griego 03C0
(2) D_	Cirilo 0400	Cirilo 0440	Cirilo 0480	Cirilo 04C0	Cirilo 0500	Armeni 0540	Hebreo 0580	Hebreo 05C0	Árabe 0600	Árabe 0640	Árabe 0680	Árabe 06C0	Siríaco 0700	Árabe 0740	Thaana 0780	N'Ko 07C0
(3) E_	Indic 0800	Misc. 1000	Símbolo 2000	Kana … 3000	CJK 4000	CJK 5000	CJK 6000	CJK 7000	CJK 8000	CJK 9000	Asiático A000	Hangul B000	Hangul C000	Hangul D000	PUA E000	Formularios F000
(4) F_	SMP… 10000	40000 񀀀	80000 򀀀	SSP… C0000	SPU… 100000	4 140000	4 180000	4 1C0000	5 200000	5 1000000	5 2000000	5 3000000	6 4000000	6 40000000

  Las celdas azules son secuencias de 7 bits (de un solo byte). No deben ir seguidos de un byte de continuación. ^[18]

  Las celdas naranjas con un punto grande son un byte de continuación. ^[19] El número hexadecimal que se muestra después del símbolo + es el valor de los 6 bits que agregan. Este carácter nunca aparece como el primer byte de una secuencia de varios bytes.

  Las celdas blancas son los bytes iniciales de una secuencia de varios bytes, ^[20] la longitud que se muestra en el borde izquierdo de la fila. El texto muestra los bloques Unicode codificados por secuencias que comienzan con este byte, y el punto de código hexadecimal que se muestra en la celda es el valor de carácter más bajo codificado usando ese byte inicial.

  Los glóbulos rojos nunca deben aparecer en una secuencia UTF-8 válida. Los dos primeros glóbulos rojos ( C0 y C1 ) solo se pueden utilizar para una codificación de 2 bytes de un carácter ASCII de 7 bits que debe codificarse en 1 byte; como se describe a continuación, tales secuencias "demasiado largas" no están permitidas. ^[21] Para entender por qué es así, considere el carácter 128, hexadecimal 80 , binario 1000 0000 . Para codificarlo como 2 caracteres, los seis bits inferiores se almacenan en el segundo carácter como 128 en sí mismo 10 000000 , pero los dos bits superiores se almacenan en el primer carácter como 110 00010 , lo que hace que el primer carácter mínimo sea C2. Los glóbulos rojos en la fila F_ ( F5 a FD) indican bytes iniciales de secuencias de 4 bytes o más que no pueden ser válidas porque codificarían puntos de código mayores que el límite U + 10FFFF de Unicode (un límite derivado del punto de código máximo codificable en UTF-16 ^[22] ). FE y FF no coinciden con ningún patrón de caracteres permitido y, por lo tanto, no son bytes de inicio válidos. ^[23]

  Las celdas rosadas son los bytes iniciales de una secuencia de varios bytes, de los cuales algunas, pero no todas, las posibles secuencias de continuación son válidas. E0 y F0 podrían iniciar codificaciones demasiado largas, en este caso se muestra el punto de código no demasiado largo más bajo. F4 puede iniciar puntos de código superiores a U + 10FFFF que no son válidos. ED puede iniciar la codificación de un punto de código en el rango U + D800 – U + DFFF; estos no son válidos ya que están reservados para mitades sustitutas UTF-16 . ^[24]

Codificaciones demasiado largas

En principio, sería posible aumentar el número de bytes en una codificación rellenando el punto de código con ceros a la izquierda. Para codificar el signo euro € del ejemplo anterior en cuatro bytes en lugar de tres, podría rellenarse con ceros a la izquierda hasta que tuviese 21 bits de longitud - 000 000010 000010 101100 , y codificado como 11110 000 10 000010 10 000010 10 101100 (o F0 82 82 AC en hexadecimal). Esto se denomina codificación demasiado larga .

El estándar especifica que la codificación correcta de un punto de código utiliza solo el número mínimo de bytes necesarios para contener los bits significativos del punto de código. Las codificaciones más largas se denominan demasiado largas y no son representaciones UTF-8 válidas del punto de código. Esta regla mantiene una correspondencia uno a uno entre los puntos de código y sus codificaciones válidas, de modo que hay una codificación válida única para cada punto de código. Esto asegura que las comparaciones y búsquedas de cadenas estén bien definidas.

Secuencias no válidas y manejo de errores

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

• bytes inválidos
• un byte de continuación inesperado
• un byte de no continuación antes del final del carácter
• la cadena que termina antes del final del carácter (lo que puede ocurrir en un simple truncamiento de cadena)
• una codificación demasiado larga
• una secuencia que decodifica a un punto de código no válido

Muchos de los primeros decodificadores UTF-8 los decodificarían, ignorando los bits incorrectos y aceptando resultados demasiado largos. UTF-8 no válido cuidadosamente diseñado podría hacer que se salten o creen caracteres ASCII como NUL, barra o comillas. Se ha utilizado UTF-8 no válido para eludir las validaciones de seguridad en productos de alto perfil, incluido el servidor web IIS de Microsoft ^[25] y el contenedor de servlets Tomcat de Apache. ^[26] RFC 3629 establece "Las implementaciones del algoritmo de decodificación DEBEN proteger contra la decodificación de secuencias inválidas". ^[7] El estándar Unicode requiere que los decodificadores "... traten cualquier secuencia de unidad de código mal formada como una condición de error. Esto garantiza que no interpretará ni emitirá una secuencia de unidad de código mal formada".

Desde RFC 3629 (noviembre de 2003), las mitades sustitutas alta y baja utilizadas por UTF-16 (U + D800 a U + DFFF) y los puntos de código no codificables por UTF-16 (aquellos después de U + 10FFFF) no son valores Unicode legales, y su codificación UTF-8 debe tratarse como una secuencia de bytes no válida. No decodificar las mitades sustitutas no emparejadas hace que sea imposible almacenar UTF-16 no válido (como nombres de archivo de Windows o UTF-16 que se ha dividido entre los sustitutos) como UTF-8. ^{[ cita requerida ]}

Algunas implementaciones de decodificadores arrojan excepciones a los errores. ^[27] Esto tiene la desventaja de que puede convertir lo que de otro modo serían errores inofensivos (como un error "no existe tal archivo") en una denegación de servicio . Por ejemplo, las primeras versiones de Python 3.0 se cerrarían inmediatamente si la línea de comandos o las variables de entorno contenían UTF-8 no válido. ^[28] Una práctica alternativa es reemplazar los errores con un carácter de reemplazo. Desde Unicode 6 ^[29] (octubre de 2010), el estándar (capítulo 3) ha recomendado una "mejor práctica" en la que el error finaliza tan pronto como se encuentra un byte no permitido. En estos decodificadores E1, A0, C0son dos errores (2 bytes en el primero). Esto significa que un error no tiene más de tres bytes de longitud y nunca contiene el comienzo de un carácter válido, y hay 21.952 errores posibles diferentes. ^[30] El estándar también recomienda reemplazar cada error con el carácter de reemplazo " " (U + FFFD).

Marca de orden de bytes

Si el carácter de marca de orden de bytes (BOM) UTF-16 Unicode está al comienzo de un archivo UTF-8, los primeros tres bytes serán 0xEF , 0xBB , 0xBF .

El estándar Unicode no requiere ni recomienda el uso de la lista de materiales para UTF-8, pero advierte que puede encontrarse al comienzo de un archivo transcodificado de otra codificación. ^[31] Si bien el texto ASCII codificado con UTF-8 es compatible con versiones anteriores de ASCII, esto no es cierto cuando se ignoran las recomendaciones del estándar Unicode y se agrega una lista de materiales. Una lista de materiales puede confundir al software que no está preparado para ello, pero de lo contrario puede aceptar UTF-8, por ejemplo, lenguajes de programación que permiten bytes no ASCII en cadenas literales pero no al principio del archivo. Sin embargo, existía y sigue habiendo software que siempre inserta una lista de materiales al escribir UTF-8 y se niega a interpretar correctamente UTF-8 a menos que el primer carácter sea una lista de materiales (o el archivo solo contenga ASCII). ^{[ cita requerida ]}

Adopción

Uso de las principales codificaciones en la web de 2001 a 2012 según lo registrado por Google, ^[32] con UTF-8 superando a todas las demás en 2008 y más del 60% de la web en 2012 (desde entonces acercándose al 100%). El ASCII cifra -sólo incluye todas las páginas web que sólo contienen caracteres ASCII, independientemente de la cabecera declarado.

UTF-8 es la recomendación del WHATWG para las especificaciones HTML y DOM , ^[33] y el Consorcio de correo de Internet recomienda que todos los programas de correo electrónico puedan mostrar y crear correo utilizando UTF-8. ^{[34] [35]} El World Wide Web Consortium recomienda UTF-8 como la codificación predeterminada en XML y HTML (y no solo usando UTF-8, también indicándolo en 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 ". ^[36] Muchos otros estándares solo admiten UTF-8, por ejemplo, el intercambio JSON abierto lo requiere.^[37] Microsoft ahora recomienda el uso de UTF-8 para aplicaciones que usan la API de Windows , mientras continúa manteniendo una interfaz heredada "Unicode" (que significa UTF-16). ^[38]

Ver también: Popularidad de codificaciones de texto

UTF-8 ha sido la codificación más común para la World Wide Web desde ^[39] 2009. En marzo de 2021 ^[actualizar], UTF-8 representa en promedio el 96,6% de todas las páginas web; y 974 de las 1.000 páginas web mejor clasificadas. ^[4] Esto tiene en cuenta que ASCII es UTF-8 válido. ^[40]

Para los archivos de texto locales, el uso de UTF-8 es menor y muchas codificaciones heredadas de un solo byte (y CJK de varios bytes) permanecen en uso. La causa principal son los editores que no muestran ni escriben UTF-8 a menos que el primer carácter en un archivo sea una marca de orden de bytes , lo que hace imposible que otro software use UTF-8 sin ser reescrito para ignorar la marca de orden de bytes en la entrada y agréguelo en la salida. ^{[41] [42]} Recientemente ha habido algunas mejoras, el Bloc de notas ahora escribe UTF-8 sin una lista de materiales de forma predeterminada. ^[43]

Internamente, el uso del software es aún menor, con UCS-2 , UTF-16 y UTF-32 en uso, particularmente en la API de Windows, pero también por Python , ^[44] JavaScript , Qt y muchas otras bibliotecas de software multiplataforma. . Esto se debe a la creencia de que la indexación directa de puntos de código es más importante que la compatibilidad de 8 bits ^{[ cita requerida ]}(UTF-16 en realidad no tiene indexación directa, pero es compatible con el obsoleto UCS-2 que sí lo tenía). En software reciente, el uso interno de UTF-8 se ha vuelto mucho mayor, ya que esto evita la sobrecarga de convertir de / a UTF-8 en E / S y lidiar con errores de codificación UTF-8: la primitiva de cadena predeterminada utilizada en Go , ^{[45 ]} Julia , Rust , Swift 5 , ^[46] y PyPy ^[47] son UTF-8.

Historia

Consulte también: Conjunto de caracteres codificados universales § Historial

La Organización Internacional de Normalización (ISO) se propuso componer un conjunto de caracteres universal de varios bytes en 1989. El borrador de la norma ISO 10646 contenía un anexo no obligatorio 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 fue satisfactoria por motivos de rendimiento, entre otros problemas, y el mayor problema probablemente fue que no tenía una separación clara entre ASCII y no ASCII: las nuevas herramientas UTF-1 serían compatibles con el texto codificado en ASCII, pero El texto codificado en UTF-1 podría confundir el código existente esperando ASCII (o ASCII extendido), porque podría contener bytes de continuación en el rango 0x21–0x7E que significaba algo más en ASCII, por ejemplo, 0x2F para '/', el separador de directorio de ruta de Unix , y este ejemplo se refleja en el nombre y el texto introductorio de su reemplazo. La siguiente tabla se obtuvo a partir de una descripción textual en el anexo.

UTF-1

Número de bytes	Primer punto de código	Último punto de código	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5
1	U + 0000	U + 009F	00–9F
2	U + 00A0	U + 00FF	A0	A0 – FF
2	U + 0100	U + 4015	A1 – F5	21–7E, A0 – FF
3	U + 4016	U + 38E2D	F6 – FB	21–7E, A0 – FF	21–7E, A0 – FF
5	U + 38E2E	U + 7FFFFFFF	FC – FF	21–7E, A0 – FF	21–7E, A0 – FF	21–7E, A0 – FF	21–7E, A0 – FF

En julio de 1992, el comité X / Open XoJIG buscaba una mejor codificación. Dave Prosser de Unix System Laboratories presentó una propuesta para uno que tuviera 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; todas las secuencias de varios bytes incluirían solo los bytes en los que se estableció el bit alto. El nombre Formato de transformación UCS seguro del sistema de archivos (FSS-UTF) y la mayor parte del texto de esta propuesta se conservaron posteriormente en la especificación final. ^{[48] [49] [50] [51]}

FSS-UTF

Propuesta FSS-UTF (1992)

Número de bytes	Primer punto de código	Último punto de código	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5
1	U + 0000	U + 007F	0xxxxxxx
2	U + 0080	U + 207F	10xxxxxx	1xxxxxxx
3	U + 2080	U + 8207F	110xxxxx	1xxxxxxx	1xxxxxxx
4	U + 82080	U + 208207F	1110xxxx	1xxxxxxx	1xxxxxxx	1xxxxxxx
5	U + 2082080	U + 7FFFFFFF	11110xxx	1xxxxxxx	1xxxxxxx	1xxxxxxx	1xxxxxxx

En agosto de 1992, un representante de IBM X / Open distribuyó esta propuesta a las partes interesadas. Una modificación de Ken Thompson del grupo de sistema operativo Plan 9 en Bell Labs lo hizo algo menos eficiente en términos de bits que la propuesta anterior, pero de manera crucial permitió que se sincronizara automáticamente., lo que permite que un lector comience en cualquier lugar y detecte inmediatamente los límites de la secuencia de bytes. También abandonó el uso de sesgos y en su lugar agregó la regla de que solo se permite la codificación más corta posible; la pérdida adicional de compacidad es relativamente insignificante, pero los lectores ahora deben buscar codificaciones no válidas para evitar la confiabilidad y especialmente los problemas de seguridad. El diseño de Thompson se describió 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 momento, y luego comunicaron su éxito a X / Open, que lo aceptó como la especificación para FSS-UTF. ^[50]

FSS-UTF (1992) / UTF-8 (1993) ^[2]

Número de bytes	Primer punto de código	Último punto de código	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6
1	U + 0000	U + 007F	0xxxxxxx
2	U + 0080	U + 07FF	110xxxxx	10xxxxxx
3	U + 0800	U + FFFF	1110xxxx	10xxxxxx	10xxxxxx
4	U + 10000	U + 1FFFFF	11110xxx	10xxxxxx	10xxxxxx	10xxxxxx
5	U + 200000	U + 3FFFFFF	111110xx	10xxxxxx	10xxxxxx	10xxxxxx	10xxxxxx
6	U + 4000000	U + 7FFFFFFF	1111110x	10xxxxxx	10xxxxxx	10xxxxxx	10xxxxxx	10xxxxxx

UTF-8 se presentó oficialmente por primera vez en la conferencia USENIX en San Diego , del 25 al 29 de enero de 1993. 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 Internet en el futuro. Los estándares funcionan, reemplazando los conjuntos de caracteres de un solo byte como Latin-1 en RFC más antiguos. ^[52]

En noviembre de 2003, UTF-8 fue restringido por RFC 3629 para coincidir con las restricciones de la codificación de caracteres UTF-16 : prohibir explícitamente los puntos de código correspondientes a los caracteres sustitutos altos y bajos eliminó más del 3% de las secuencias de tres bytes, y terminando en U + 10FFFF eliminó más del 48% de las secuencias de cuatro bytes y todas las secuencias de cinco y seis bytes.

Estándares

Hay varias definiciones actuales de UTF-8 en varios documentos de estándares:

• RFC 3629 / STD 63 (2003), que establece UTF-8 como un elemento de protocolo de Internet estándar
• RFC 5198 define UTF-8 NFC para Network Interchange (2008)
• ISO / IEC 10646: 2014 §9.1 (2014) ^[53]
• El estándar Unicode, versión 11.0 (2018) ^[54]

Reemplazan las definiciones dadas 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 Corrigendum # 1: Forma más corta UTF-8 (2000)
• Estándar Unicode Anexo # 27: Unicode 3.1 (2001) ^[55]
• El estándar Unicode, versión 5.0 (2006) ^[56]
• El estándar Unicode, versión 6.0 (2010) ^[57]

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

Comparación con otras codificaciones

Ver también: Comparación de codificaciones Unicode

Algunas de las características importantes de esta codificación son las siguientes:

• Compatibilidad con versiones anteriores:La compatibilidad con versiones anteriores de ASCII y la enorme cantidad de software diseñado para procesar texto codificado en ASCII fue la principal fuerza impulsora detrás del diseño de UTF-8. En UTF-8, los bytes individuales con valores en el rango de 0 a 127 se asignan directamente a puntos de código Unicode en el rango ASCII. Los bytes individuales en este rango representan caracteres, como lo hacen en ASCII. Además, los bytes de 7 bits (bytes donde el bit más significativo es 0) nunca aparecen en una secuencia de varios bytes y ninguna secuencia de varios bytes válida se descodifica en un punto de código ASCII. Una secuencia de bytes de 7 bits es ASCII válido y UTF-8 válido, y bajo cualquier interpretación representa la misma secuencia de caracteres. Por lo tanto, los bytes de 7 bits en un flujo UTF-8 representan todos y solo los caracteres ASCII en el flujo. Por lo tanto, muchos procesadores de texto, analizadores sintácticos, protocolos, formatos de archivo, programas de visualización de texto, etc.que utilizan caracteres ASCII con fines de formato y control, seguirán funcionando según lo previsto al tratar el flujo de bytes UTF-8 como una secuencia de caracteres de un solo byte, sin decodificar las secuencias de varios bytes. Los caracteres ASCII en los que gira el procesamiento, como la puntuación, los espacios en blanco y los caracteres de control, nunca se codificarán como secuencias de varios bytes. Por lo tanto, es seguro para tales procesadores simplemente ignorar o pasar a través de las secuencias de múltiples bytes, sin decodificarlas. Por ejemplo, los espacios en blanco ASCII se pueden utilizar paray los caracteres de control nunca se codificarán como secuencias de varios bytes. Por lo tanto, es seguro para tales procesadores simplemente ignorar o pasar a través de las secuencias de múltiples bytes, sin decodificarlas. Por ejemplo, los espacios en blanco ASCII se pueden utilizar paray los caracteres de control nunca se codificarán como secuencias de varios bytes. Por lo tanto, es seguro para tales procesadores simplemente ignorar o pasar a través de las secuencias de múltiples bytes, sin decodificarlas. Por ejemplo, los espacios en blanco ASCII se pueden utilizar paraconvertir un flujo UTF-8 en palabras; Las alimentaciones de línea ASCII se pueden utilizar para dividir un flujo UTF-8 en líneas; y los caracteres ASCII NUL se pueden utilizar para dividir datos codificados en UTF-8 en cadenas terminadas en nulo. De manera similar, muchas cadenas de formato utilizadas por funciones de biblioteca como "printf" manejarán correctamente los argumentos de entrada codificados en UTF-8.
• Retorno y detección automática: solo un pequeño subconjunto de posibles cadenas de bytes es una cadena UTF-8 válida: los bytes C0, C1 y F5 a FF no pueden aparecer, y los bytes con el conjunto de bits alto deben estar en pares, y otros requisitos . Es muy poco probable que un texto legible en cualquier ASCII extendido sea ​​UTF-8 válido. Parte de la popularidad de UTF-8 se debe a que también proporciona una forma de compatibilidad con versiones anteriores. Un procesador UTF-8 que recibe erróneamente ASCII extendido como entrada puede, por tanto, "detectar automáticamente" esto con una fiabilidad muy alta. Los errores de respaldo serán falsos negativos y serán poco frecuentes. Además, en muchas aplicaciones, como la visualización de texto, la consecuencia de un retroceso incorrecto suele ser leve. ^{[ investigación original? ]}Un flujo UTF-8 simplemente puede contener errores, lo que da como resultado que el esquema de detección automática produzca falsos positivos; pero la autodetección tiene éxito en la mayoría de los casos, especialmente con textos más largos, y se usa ampliamente. También funciona para "retroceder" o reemplazar bytes de 8 bits utilizando el punto de código apropiado para una codificación heredada solo cuando se detectan errores en UTF-8, lo que permite la recuperación incluso si UTF-8 y la codificación heredada están concatenados en el mismo expediente.
• Código de prefijo : el primer byte indica el número de bytes en la secuencia. La lectura de un flujo puede decodificar instantáneamente cada secuencia individual completamente recibida, sin tener que esperar primero el primer byte de una secuencia siguiente o una indicación de fin de flujo. Los seres humanos determinan fácilmente la longitud de las secuencias de varios bytes, ya que es simplemente el número de 1 de orden superior en el byte inicial. Un carácter incorrecto no se decodificará si una secuencia finaliza en mitad de la secuencia.
• Sincronización automática : los bytes iniciales y los bytes de continuación no comparten valores (los bytes de continuación comienzan con los bits 10, mientras que los bytes individuales comienzan con 0 y los bytes iniciales más largos comienzan con 11 ). Esto significa que una búsqueda no encontrará accidentalmente la secuencia de un carácter que comience en el medio de otro carácter. También significa que el inicio de un carácter se puede encontrar desde una posición aleatoria haciendo una copia de seguridad de 3 bytes como máximo para encontrar el byte inicial. Un carácter incorrecto no se decodificará si una secuencia comienza a mitad de la secuencia, y una secuencia más corta nunca aparecerá dentro de una más larga.
• Orden de clasificación: los valores elegidos de los bytes iniciales significan que una lista de cadenas UTF-8 se puede clasificar en orden de puntos de código clasificando las secuencias de bytes correspondientes.

Un byte

• UTF-8 puede codificar cualquier carácter Unicode , evitando la necesidad de averiguar y establecer una " página de códigos " o indicar de otro modo qué juego de caracteres está en uso, y permitiendo la salida en múltiples scripts al mismo tiempo. Para muchos scripts, se ha utilizado más de una codificación de un solo byte, por lo que incluso conocer el script no era información suficiente para mostrarlo correctamente.
• Los bytes 0xFE y 0xFF no aparecen, por lo que una secuencia UTF-8 válida nunca coincide con la marca de orden de bytes UTF-16 y, por lo tanto, no se puede confundir con ella. La ausencia de 0xFF (0377) también elimina la necesidad de escapar de este byte en Telnet (y conexión de control FTP).
• El texto codificado en UTF-8 es más grande que las codificaciones especializadas de un solo byte, excepto en los caracteres ASCII sin formato. En el caso de los scripts que utilizan conjuntos de caracteres de 8 bits con caracteres no latinos codificados en la mitad superior (como la mayoría de las páginas de códigos del alfabeto cirílico y griego ), los caracteres en UTF-8 tendrán el doble de tamaño. Para algunas escrituras, como el tailandés y el devanagari (que se usa en varios idiomas del sur de Asia), los caracteres triplicarán su tamaño. Incluso hay ejemplos en los que un solo byte se convierte en un carácter compuesto en Unicode y, por lo tanto, es seis veces más grande en UTF-8. Esto ha provocado objeciones en India y otros países.
• Es posible en UTF-8 (o cualquier otra codificación de longitud variable) dividir o truncar una cadena en medio de un carácter. Si las dos piezas no se vuelven a agregar más tarde antes de la interpretación como caracteres, esto puede introducir una secuencia no válida tanto al final de la sección anterior como al comienzo de la siguiente, y algunos decodificadores no conservarán estos bytes y provocarán la pérdida de datos. Debido a que UTF-8 se sincroniza automáticamente, esto nunca introducirá un carácter válido diferente, y también es bastante fácil mover el punto de truncamiento hacia atrás al comienzo de un carácter.
• Si los puntos de código son todos del mismo tamaño, es fácil medir un número fijo de ellos. Debido a la documentación de la era ASCII donde "carácter" se usa como sinónimo de "byte", esto a menudo se considera importante. Sin embargo, midiendo las posiciones de las cadenas usando bytes en lugar de "caracteres", la mayoría de los algoritmos se pueden adaptar fácil y eficientemente para UTF-8. La búsqueda de una cadena dentro de una cadena larga se puede realizar, por ejemplo, byte a byte; la propiedad de sincronización automática evita falsos positivos.

Otro multibyte

• UTF-8 puede codificar cualquier carácter Unicode . Los archivos en diferentes secuencias de comandos se pueden mostrar correctamente sin tener que elegir la página de códigos o la fuente correcta. Por ejemplo, el chino y el árabe se pueden escribir en el mismo archivo sin marcas especializadas o configuraciones manuales que especifiquen una codificación.
• UTF-8 se sincroniza automáticamente : los límites de los caracteres se identifican fácilmente mediante la exploración de patrones de bits bien definidos en cualquier dirección. Si se pierden bytes debido a un error o corrupción , siempre se puede localizar el siguiente carácter válido y reanudar el procesamiento. Si es necesario acortar una cadena para que se ajuste a un campo específico, se puede encontrar fácilmente el carácter válido anterior. Muchas codificaciones de varios bytes, como Shift JIS, son mucho más difíciles de resincronizar. Esto también significa que los algoritmos de búsqueda de cadenas orientados a bytes se puede usar con UTF-8 (ya que un carácter es lo mismo que una "palabra" compuesta por tantos bytes), las versiones optimizadas de búsquedas de bytes pueden ser mucho más rápidas debido al soporte de hardware y las tablas de búsqueda que tienen solo 256 entradas. Sin embargo, la autosincronización requiere que se reserven bits para estos marcadores en cada byte, aumentando el tamaño.
• Eficiente para codificar mediante operaciones simples a nivel de bits . UTF-8 no requiere operaciones matemáticas más lentas como multiplicación o división (a diferencia de Shift JIS , GB 2312 y otras codificaciones).
• UTF-8 ocupará más espacio que una codificación multibyte diseñada para un script específico. Las codificaciones heredadas de Asia oriental generalmente usaban dos bytes por carácter, pero toman tres bytes por carácter en UTF-8.

UTF-16

• Las codificaciones de bytes y UTF-8 se representan mediante matrices de bytes en los programas y, a menudo, no es necesario hacer nada en una función al convertir el código fuente de una codificación de bytes a UTF-8. UTF-16 está representado por matrices de palabras de 16 bits, y la conversión a UTF-16 mientras se mantiene la compatibilidad con los programas existentes basados ​​en ASCII (como se hizo con Windows) requiere que cada API y estructura de datos que requiera una cadena se duplique, una versión que acepta cadenas de bytes y otra versión que acepta UTF-16. Si no se necesita compatibilidad con versiones anteriores, toda la gestión de cadenas debe modificarse.
• El texto codificado en UTF-8 será más pequeño que el mismo texto codificado en UTF-16 si hay más puntos de código por debajo de U + 0080 que en el rango U + 0800..U + FFFF. Esto es válido para todos los idiomas europeos modernos. A menudo es cierto incluso para idiomas como el chino, debido a la gran cantidad de espacios, líneas nuevas, dígitos y marcado HTML en los archivos típicos.
• La mayor parte de la comunicación (por ejemplo, HTML e IP) y el almacenamiento (por ejemplo, para Unix) se diseñaron para un flujo de bytes . Una cadena UTF-16 debe usar un par de bytes para cada unidad de código:
  • El orden de esos dos bytes se convierte en un problema y debe especificarse en el protocolo UTF-16, como con una marca de orden de bytes .
  • Si falta un número impar de bytes en UTF-16, el resto de la cadena será texto sin sentido. Los bytes que falten en UTF-8 aún permitirán que el texto se recupere con precisión comenzando con el siguiente carácter después de los bytes que faltan.

Derivados

Las siguientes implementaciones muestran ligeras diferencias con la especificación UTF-8. Son incompatibles con la especificación UTF-8 y pueden ser rechazadas por aplicaciones UTF-8 conformes.

CESU-8

Artículo principal: CESU-8

El Informe técnico Unicode # 26 ^[58] asigna el nombre CESU-8 a una variante no estándar de UTF-8, en la que los caracteres Unicode en planos suplementarios se codifican utilizando seis bytes, en lugar de los cuatro bytes requeridos por UTF-8. La codificación CESU-8 trata cada mitad de un par sustituto UTF-16 de cuatro bytes como un carácter UCS-2 de dos bytes, lo que produce dos caracteres UTF-8 de tres bytes, que juntos representan el carácter suplementario original. Los caracteres Unicode dentro del plano multilingüe básico aparecen como lo harían normalmente en UTF-8. El Informe se redactó para reconocer y formalizar la existencia de datos codificados como CESU-8, a pesar del Consorcio Unicode desalentando su uso, y señala que una posible razón intencional para la codificación CESU-8 es la preservación de la intercalación binaria UTF-16.

La codificación CESU-8 puede resultar de la conversión de datos UTF-16 con caracteres suplementarios a UTF-8, utilizando métodos de conversión que asumen datos UCS-2, lo que significa que desconocen los caracteres suplementarios UTF-16 de cuatro bytes. Es principalmente un problema en los sistemas operativos que usan UTF-16 internamente, como Microsoft Windows . ^{[ cita requerida ]}

En Oracle Database , el UTF8juego de caracteres usa codificación CESU-8 y está en desuso. El AL32UTF8juego de caracteres utiliza codificación UTF-8 compatible con los estándares y es el preferido. ^{[59] [60]}

CESU-8 está prohibido para su uso en documentos HTML5 . ^{[61] [62] [63]}

MySQL utf8mb3

En MySQL , el utf8mb3conjunto de caracteres se define como datos codificados en UTF-8 con un máximo de tres bytes por carácter, lo que significa que solo se admiten caracteres Unicode en el plano multilingüe básico (es decir, de UCS-2 ). Los caracteres Unicode en planos suplementarios no se admiten explícitamente. utf8mb3está en desuso en favor del utf8mb4juego de caracteres, que utiliza codificación UTF-8 compatible con los estándares. utf8es un alias de utf8mb3, pero está destinado a convertirse en un alias de utf8mb4en una versión futura de MySQL. ^[64] Es posible, aunque no se admite, almacenar datos codificados en CESU-8 utf8mb3, manejando datos UTF-16 con caracteres suplementarios como si fuera UCS-2.

UTF-8

UTF-8 modificado (MUTF-8) se originó en el lenguaje de programación Java . En UTF-8 modificado, el carácter nulo (U + 0000) utiliza la codificación demasiado larga de dos bytes 110 00000 10 000000 (hexadecimal C0 80 ), en lugar de 00000000 (hexadecimal 00 ). ^[65] Las cadenas UTF-8 modificadas nunca contienen bytes nulos reales, pero pueden contener todos los puntos de código Unicode, incluido U + 0000, ^{[66] lo} que permite que dichas cadenas (con un byte nulo agregado) sean procesadas por una cadena tradicional terminada en nulo funciones. Todas las implementaciones de UTF-8 modificadas conocidas también tratan los pares sustitutos como en CESU-8 .

En uso normal, el lenguaje admite UTF-8 estándar al leer y escribir cadenas a través de InputStreamReadery OutputStreamWriter(si es el juego de caracteres predeterminado de la plataforma o según lo solicite el programa). Sin embargo, utiliza UTF-8 modificado para la serialización de objetos ^[67] entre otras aplicaciones de DataInputy DataOutput, para la interfaz nativa de Java , ^[68] y para incrustar cadenas constantes en archivos de clase . ^[69]

El formato dex definido por Dalvik también usa el mismo UTF-8 modificado para representar valores de cadena. ^[70] Tcl también usa el mismo UTF-8 modificado ^[71] que Java para la representación interna de datos Unicode, pero usa CESU-8 estricto para datos externos.

WTF-8

Esta sección contiene una lista de información diversa . Por favor, trasladar toda la información pertinente a otras secciones o artículos. ( Agosto de 2020 )

En WTF-8 (formato de transformación oscilante, 8 bits ) se permiten mitades sustitutas no emparejadas (U + D800 a U + DFFF). ^[72] Esto es necesario para almacenar UTF-16 posiblemente no válido, como nombres de archivo de Windows. Muchos sistemas que tratan con UTF-8 funcionan de esta manera sin considerarlo una codificación diferente, ya que es más simple. ^[73]

(El término "WTF-8" también se ha utilizado con humor para referirse a UTF-8 erróneamente codificado doblemente ^{[74] [75] a} veces con la implicación de que los bytes CP1252 son los únicos codificados) ^[76]

PEP 383

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 (vea también los cambios con el nuevo modo UTF-8 en Python 3.7 ^[77] ); esto da 128 posibles errores diferentes. Se han creado extensiones para permitir que cualquier secuencia de bytes que se asume que es UTF-8 se transforme sin pérdidas a UTF-16 o UTF-32, traduciendo los 128 bytes de error posibles en puntos de código reservados y transformando esos puntos de código de nuevo en error. bytes 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", tal como lo usa el PEP 383 de Python (o "escape sustituto") Acercarse. ^[78] Otra codificación llamada MirBSDOPTU-8/16 los convierte a U + EF80 ... U + EFFF en un área de uso privado . ^[79] En cualquier enfoque, el valor del byte se codifica en los ocho bits más bajos del punto de código de salida.

Estas codificaciones son muy útiles porque evitan la necesidad de tratar con cadenas de bytes "no válidas" hasta mucho más tarde, si es que lo hacen, y permiten que las matrices de bytes de "texto" y "datos" sean el mismo objeto. Si un programa quiere usar UTF-16 internamente, estos son necesarios para preservar y usar nombres de archivo que pueden usar UTF-8 no válido; ^[80] como la API del sistema de archivos de Windows usa UTF-16, la necesidad de admitir UTF-8 no válido es menor. ^[78]

Para que la codificación sea reversible, las codificaciones UTF-8 estándar de los puntos de código utilizados para bytes erróneos deben considerarse inválidas. Esto hace que la codificación sea incompatible con WTF-8 o CESU-8 (aunque solo para 128 puntos de código). Al volver a codificar, es necesario tener cuidado con las secuencias de puntos de código de error que se vuelven a convertir en UTF-8 válido, que puede ser utilizado por software malintencionado para obtener caracteres inesperados en la salida, aunque esto no puede producir caracteres ASCII, por lo que se considera comparativamente seguro, ya que las secuencias maliciosas (como las secuencias de comandos entre sitios ) generalmente se basan en caracteres ASCII. ^[80]

Ver también

• Código alternativo
• Codificaciones de caracteres en HTML
• Comparación de clientes de correo electrónico # Características
• Comparación de codificaciones Unicode
  • GB 18030
  • UTF-EBCDIC
• Iconv
• Especiales (bloque Unicode)
• Unicode y correo electrónico
• Unicode y HTML
• Codificación porcentual # Estándar actual

Notas

1. 17 planos por 2 ¹⁶ puntos de código por plano, menos 2 ¹¹ sustitutos técnicamente inválidos.
2. Puede esperar que se puedan expresar puntos de código más grandes que U + 10FFFF, pero en RFC3629 §3 UTF-8 está limitado para coincidir con los límites de UTF-16. (Comoseñala §12 , esto se cambia de RFC 2279 ).

Referencias

1. "Capítulo 2. Estructura general" . El estándar Unicode (6.0 ed.). Mountain View, California, EE. UU .: The Unicode Consortium . ISBN 978-1-936213-01-6.
2. Pike, Rob (30 de abril de 2003). "Historia UTF-8" .
3. Pike, Rob; Thompson, Ken (1993). "Hola mundo o Καλημέρα κόσμε o こ ん に ち は 世界" (PDF) . Actas de la Conferencia de USENIX de invierno de 1993 .
4. "Encuesta de uso de codificaciones de caracteres desglosadas por clasificación" . w3techs.com . Consultado el 24 de marzo de 2021 .
5. "Juegos de caracteres" . Autoridad de Números Asignados de Internet . 2013-01-23 . Consultado el 8 de febrero de 2013 .
6. Dürst, Martin. "Configuración del parámetro de juego de caracteres HTTP" . W3C . Consultado el 8 de febrero de 2013 .
7. Yergeau, F. (2003). UTF-8, un formato de transformación de ISO 10646 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487 / RFC3629 . RFC 3629 . Consultado el 3 de febrero de 2015 .
8. "Estándar de codificación § 4.2. Nombres y etiquetas" . WHATWG . Consultado el 29 de abril de 2018 .
9. "BOM" . suikawiki (en japonés) . Consultado el 26 de abril de 2013 .
10. Davis, Mark . "Formas de Unicode" . IBM . Archivado desde el original el 6 de mayo de 2005 . Consultado el 18 de septiembre de 2013 .
11. Liviu (7 de febrero de 2014). "Página de códigos UTF-8 65001 en Windows 7 - parte I" . Consultado el 30 de enero de 2018 .
12. "Script Cómo establecer la codificación predeterminada en UTF-8 para el bloc de notas de PowerShell" . gallery.technet.microsoft.com . Consultado el 30 de enero de 2018 .
13. "Juegos de símbolos HP PCL | Blog de soporte de lenguaje de control de impresora (PCL y PXL)" . 2015-02-19. Archivado desde el original el 19 de febrero de 2015 . Consultado el 30 de enero de 2018 .
14. Allen, Julie D .; Anderson, Deborah; Becker, Joe; Cook, Richard, eds. (2012). "El estándar Unicode, versión 6.1". Mountain View, California: Consorcio Unicode.
15. "Documentación para desarrolladores de Apple" . developer.apple.com . Consultado el 15 de marzo de 2021 .
16. "No está mal que" 🤦🏼‍♂️ ".length == 7" . hsivonen.fi . Consultado el 15 de marzo de 2021 .
17. "BinaryString (flink 1.9-SNAPSHOT API)" . ci.apache.org . Consultado el 24 de marzo de 2021 .
18. "Capítulo 3" (PDF) , El estándar Unicode , p. 54
19. "Capítulo 3" (PDF) , El estándar Unicode , p. 55
20. "Capítulo 3" (PDF) , El estándar Unicode , p. 55
21. "Capítulo 3" (PDF) , El estándar Unicode , p. 54
22. Yergeau, F. (noviembre de 2003). UTF-8, un formato de transformación de ISO 10646 . IETF . doi : 10.17487 / RFC3629 . STD 63. RFC 3629 . Consultado el 20 de agosto de 2020 .
23. "Capítulo 3" (PDF) , El estándar Unicode , p. 55
24. Yergeau, F. (noviembre de 2003). UTF-8, un formato de transformación de ISO 10646 . IETF . doi : 10.17487 / RFC3629 . STD 63. RFC 3629 . Consultado el 20 de agosto de 2020 .
25. Marin, Marvin (17 de octubre de 2000). "Web Server Folder Traversal MS00-078" .
26. "Resumen de CVE-2008-2938" . Base de datos nacional de vulnerabilidad .
27. "Entrada de datos (Java Platform SE 8)" . docs.oracle.com . Consultado el 24 de marzo de 2021 .
28. "Bytes no decodificables en interfaces de caracteres del sistema" . python.org . 2009-04-22 . Consultado el 13 de agosto de 2014 .
29. "Unicode 6.0.0" .
30. 128 1 byte, (16 + 5) × 64 2 bytes y 5 × 64 × 64 3 bytes. Puede haber algo menos si se realizan pruebas más precisas para cada byte de continuación.
31. "Capítulo 2" (PDF) , El estándar Unicode , p. 30
32. Davis, Mark (3 de febrero de 2012). "Unicode más del 60 por ciento de la web" . Blog oficial de Google . Archivado desde el original el 9 de agosto de 2018 . Consultado el 24 de julio de 2020 .
33. "Estándar de codificación" . encoding.spec.whatwg.org . Consultado el 15 de abril de 2020 .
34. "Uso de caracteres internacionales en correo de Internet" . Consorcio de correo de Internet. 1998-08-01. Archivado desde el original el 26 de octubre de 2007 . Consultado el 8 de noviembre de 2007 .
35. "Estándar de codificación" . encoding.spec.whatwg.org . Consultado el 15 de noviembre de 2018 .
36. "Especificación de la codificación de caracteres del documento" . HTML5.2 . Consorcio World Wide Web . 14 de diciembre de 2017 . Consultado el 3 de junio de 2018 .
37. "El formato de intercambio de datos de notación de objetos JavaScript (JSON)" . IETF. Diciembre de 2017 . Consultado el 16 de febrero de 2018 .
38. "Utilice la página de códigos UTF-8 de Windows" . Aplicaciones para UWP . docs.microsoft.com . Consultado el 6 de junio de 2020 .
39. Davis, Mark (5 de mayo de 2008). "Pasando a Unicode 5.1" . Consultado el 19 de febrero de 2021 .
40. "Estadísticas de uso y cuota de mercado de US-ASCII para sitios web, agosto de 2020" . w3techs.com . Consultado el 28 de agosto de 2020 .
41. "¿Cómo puedo hacer que el Bloc de notas guarde texto en UTF-8 sin la lista de materiales?" . Desbordamiento de pila . Consultado el 24 de marzo de 2021 .
42. Galloway, Matt. "Codificación de caracteres para desarrolladores de iOS. ¿O UTF-8 y ahora?" . www.galloway.me.uk . Consultado el 2 de enero de 2021 . en realidad, normalmente asume UTF-8 ya que es, con mucho, la codificación más común.
43. "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 está guardando de forma predeterminada los nuevos archivos de texto como UTF-8 sin BOM, como se muestra a continuación.
44. "PEP 623 - Eliminar wstr de Unicode" . Python.org . Consultado el 21 de noviembre de 2020 . Hasta que eliminemos el objeto Unicode heredado, es muy difícil probar otra implementación Unicode como la implementación basada en UTF-8 en PyPy
45. "La especificación del lenguaje de programación Go" . Consultado el 10 de febrero de 2021 .
46. Tsai, Michael J. "Michael Tsai - Blog - Cadena UTF-8 en Swift 5" . Consultado el 15 de marzo de 2021 .
47. Mattip (24 de marzo de 2019). "PyPy Status Blog: PyPy v7.1 lanzado; ahora usa utf-8 internamente para cadenas Unicode" . Blog de estado de PyPy . Consultado el 21 de noviembre de 2020 .
48. "Apéndice F. FSS-UTF / Formato de transformación UCS segura del sistema de archivos" (PDF) . El estándar Unicode 1.1 . Archivado (PDF) desde el original el 7 de junio de 2016 . Consultado el 7 de junio de 2016 .
49. Whistler, Kenneth (12 de junio de 2001). "FSS-UTF, UTF-2, UTF-8 y UTF-16" . Archivado desde el original el 7 de junio de 2016 . Consultado el 7 de junio de 2006 .
50. Pike, Rob (30 de abril de 2003). "Historia UTF-8" . Consultado el 7 de septiembre de 2012 .
51. Pike, Rob (6 de septiembre de 2012). "UTF-8 cumplió 20 años ayer" . Consultado el 7 de septiembre de 2012 .
52. Alvestrand, Harald (enero de 1998). Política de IETF sobre juegos de caracteres e idiomas . doi : 10.17487 / RFC2277 . BCP 18.
53. ISO / IEC 10646: 2014 §9.1 , 2014.
54. El estándar Unicode, versión 11.0 §3.9 D92, §3.10 D95 , 2018.
55. Anexo del estándar Unicode n. ° 27: Unicode 3.1 , 2001.
56. El estándar Unicode, versión 5.0 §3.9 – §3.10 cap. 3 de 2006.
57. El estándar Unicode, versión 6.0 §3.9 D92, §3.10 D95 , 2010.
58. McGowan, Rick (19 de diciembre de 2011). "Esquema de codificación de compatibilidad para UTF-16: 8 bits (CESU-8)" . Consorcio Unicode . Informe técnico Unicode n. ° 26.
59. "Soporte de juego de caracteres" . Documentación de Oracle Database 19c, Referencia del lenguaje SQL . Oracle Corporation .
60. "Soporte de bases de datos multilingües con Unicode § Soporte para el estándar Unicode en la base de datos Oracle" . Guía de soporte para la globalización de bases de datos . Oracle Corporation .
61. "8.2.2.3. Codificaciones de caracteres" . Estándar HTML 5.1 . W3C .
62. "8.2.2.3. Codificaciones de caracteres" . Estándar HTML 5 . W3C .
63. "12.2.3.3 Codificaciones de caracteres" . Estándar de vida HTML . WHATWG .
64. "El juego de caracteres utf8mb3 (codificación Unicode UTF-8 de 3 bytes)" . Manual de referencia de MySQL 8.0 . Oracle Corporation .
65. "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 .
66. "La especificación de la máquina virtual Java, sección 4.4.7:" La estructura CONSTANT_Utf8_info " " . Oracle Corporation . 2015 . Consultado el 16 de octubre de 2015 .
67. "Especificación de serialización de objetos Java, capítulo 6: Protocolo de secuencia de serialización de objetos, sección 2: Elementos de secuencia" . Oracle Corporation . 2010 . Consultado el 16 de octubre de 2015 .
68. "Especificación de la interfaz nativa de Java, capítulo 3: tipos de JNI y estructuras de datos, sección: cadenas UTF-8 modificadas" . Oracle Corporation . 2015 . Consultado el 16 de octubre de 2015 .
69. "La especificación de la máquina virtual Java, sección 4.4.7:" La estructura CONSTANT_Utf8_info " " . Oracle Corporation . 2015 . Consultado el 16 de octubre de 2015 .
70. "ARTE y Dalvik" . Proyecto de código abierto de Android . Archivado desde el original el 26 de abril de 2013 . Consultado el 9 de abril de 2013 .
71. "Wiki de Tcler: UTF-8 bit a bit (revisión 6)" . 2009-04-25 . Consultado el 22 de mayo de 2009 .
72. Sapin, Simon (11 de marzo de 2016) [25 de septiembre de 2014]. "La codificación WTF-8" . Archivado desde el original el 24 de mayo de 2016 . Consultado el 24 de mayo de 2016 .
73. Sapin, Simon (25 de marzo de 2015) [25 de septiembre de 2014]. "La codificación WTF-8 § Motivación" . Archivado desde el original el 24 de mayo de 2016 . Consultado el 26 de agosto de 2020 .
74. "WTF-8.com" . 2006-05-18 . Consultado el 21 de junio de 2016 .
75. Speer, Robyn (21 de mayo de 2015). "ftfy (corrige el texto por ti) 4.0: cambiando menos y arreglando más" . Archivado desde el original el 30 de mayo de 2015 . Consultado el 21 de junio de 2016 .
76. "WTF-8, un formato de transformación de la página de códigos 1252" . Archivado desde el original el 13 de octubre de 2016 . Consultado el 12 de octubre de 2016 .
77. "PEP 540 - Agregar un nuevo modo UTF-8" . Python.org . Consultado el 24 de marzo de 2021 .
78. von Löwis, Martin (22 de abril de 2009). "Bytes no decodificables en interfaces de caracteres del sistema" . Fundación de software Python . PEP 383.
79. "RTFM optu8to16 (3), optu8to16vis (3)" . www.mirbsd.org .
80. Davis, Mark ; Suignard, Michel (2014). "3.7 Habilitación de la conversión sin pérdidas" . Consideraciones de seguridad Unicode . Informe técnico Unicode n. ° 36.

Enlaces externos

• Documento UTF-8 original ( o pdf ) para el Plan 9 de Bell Labs
• Páginas de prueba UTF-8:
  • Andreas Prilop
  • Jost Gippert
  • Consorcio Mundial de la red
• Unix / Linux: UTF-8 / Unicode FAQ , Linux Unicode HOWTO , 8.xml UTF-8 y Gentoo
• Personajes, símbolos y el milagro Unicode en YouTube