UTF-8

Editar artículo

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.

UTF-8 es capaz de codificar todos los 1,112,064 puntos de código de caracteres válidos en Unicode usando 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 ser compatible con versiones anteriores de ASCII : los primeros 128 caracteres de Unicode, que 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 es UTF-8 válido -codificado Unicode también. 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. 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 se adoptó por el Grupo de trabajo de ingeniería de Internet (IETF) en RFC 2277 ( BCP 18) para el trabajo futuro 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, ya que representa más del 97% de todas las páginas web y hasta el 100% para algunos idiomas, a partir de 2021.

Contenido

1 Nombramiento
2 codificación
- 2.1 Ejemplos
- 2.2 Octal
- 2.3 Diseño de página de códigos
- 2.4 Codificaciones demasiado largas
- 2.5 Secuencias no válidas y manejo de errores
- 2.6 Marca de orden de bytes
3 Adopción
4 Historia
- 4.1 FSS-UTF
5 Estándares
6 Comparación con otras codificaciones
- 6.1 de un solo byte
- 6.2 Otro multibyte
- 6.3 UTF-16
7 Derivados
- 7.1 CESU-8
- 7.2 MySQL utf8mb3
- 7.3 UTF-8 modificado
- 7.4 WTF-8
- 7.5 PEP 383
8 Véase también
9 notas
10 referencias
11 Enlaces externos

Nombrar

El código oficial de la Autoridad de Números Asignados de Internet (IANA) para la codificación es "UTF-8". 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 ), ya que la declaración no distingue entre mayúsculas y minúsculas.

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

Extraoficialmente, UTF-8-BOM y UTF-8-NOBOM a veces se usan para archivos de texto que contienen o no contienen una marca de orden de bytes (BOM), respectivamente. En Japón, especialmente, la codificación UTF-8 sin una lista de materiales a veces se denomina " UTF-8N ".

Windows XP y posteriores, incluidas todas las versiones compatibles de Windows, tienen la página de códigos 65001, como sinónimo de UTF-8 (ya que el soporte de Windows 7 para UTF-8 es mejor), y Microsoft tiene un script para Windows 10, para habilitarlo de forma predeterminada para su programa Microsoft Notepad.

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

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 lt;-gt; 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	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 las extensiones IPA, los alfabetos griego, cirílico, copto, armenio, hebreo, árabe, siríaco, thaana y N'Ko. como Signos diacríticos para combinar. 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, incluida la mayoría de los caracteres 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".

Ejemplos de

Considere la codificación del signo euro, €:

El punto de código Unicode para "€" es U + 20AC.
Como este punto de código se encuentra entre U + 0800 y U + FFFF, se necesitarán tres bytes para codificarlo.
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.
Debido a que la codificación tendrá una longitud de tres bytes, su byte inicial comienza con tres unos, luego un 0 ( 1110...)
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).
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).
Finalmente, los últimos seis bits del punto de código se almacenan en los seis bits de orden inferior del byte final, y nuevamente 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	1 110 0.000 10 100,100 10 111.001 mil	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 1101 10 010101 10 011,1 mil	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.

Punto de código octal lt;-gt; Conversión octal UTF-8
Primer punto de código	Último punto de código	Punto de código	Byte 1	Byte 2	Byte 3	Byte 4
000	177	xxx	xxx
0200	3777	xxyy	3xx	2aa
04000	77777	xyyzz	34x	2aa	2zz
100000	177777	1xyyzz	35x	2aa	2zz
0200000	4177777	xyyzzww	36 veces	2aa	2zz	2ww

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

Ejemplo: Á = U + 00C1 = 0301 (en octal) se codifica como 303201 en UTF-8 (C3 81 en hexadecimal).

Ejemplo: € = U + 20AC = 20254 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	y 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	lt; 003C	= 003D	gt; 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	América 0080	Latina 00C0	América 0100	América 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	NKo 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	PUA. .. F000
(4) F_	SMP… 10000	40000񀀀	80000򀀀	SSP... C0000	SPUA-B 100000	4 140000	4 180000	4 1C0000	5 200,000	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.

Las celdas naranjas con un punto grande son un byte de continuación. 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, 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. 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 ). FE y FF no coinciden con ningún patrón de caracteres permitido y, por lo tanto, no son bytes de inicio válidos.

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.

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 y el contenedor de servlets Tomcat de Apache. RFC 3629 establece "Las implementaciones del algoritmo de decodificación DEBEN proteger contra la decodificación de secuencias inválidas". 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, mientras que es posible con WTF-8.

Algunas implementaciones de decodificadores arrojan excepciones a los errores. 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. Una práctica alternativa es reemplazar los errores con un carácter de reemplazo. Desde Unicode 6 (octubre de 2010), el estándar (capítulo 3) ha recomendado una "mejor práctica" en la que el error termina tan pronto como se encuentra un byte no permitido. En estos decodificadores E1, A0, C0 son 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. 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 Unicode UTF-16 (BOM, U + FEFF) 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. 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).

Algunos lenguajes de programación y formatos de archivo tienen su propia forma de marcar el uso de codificaciones como UTF-8 en el código fuente. Los ejemplos incluyen HTML lt;meta charset="UTF-8"/gt; y Python 2.7 # coding: utf-8

Adopción

Uso de las principales codificaciones en la web de 2001 a 2012 según lo registrado por Google, 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, y el Consorcio de correo de Internet recomienda que todos los programas de correo electrónico puedan mostrar y crear correo utilizando UTF-8. 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 estableciéndolo en metadatos), "incluso cuando todos los caracteres están en el rango ASCII. . Usando no UTF- 8 codificaciones pueden tener resultados inesperados ". Muchos otros estándares solo admiten UTF-8, por ejemplo, el intercambio JSON abierto lo requiere.

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 2008. En octubre de 2021, UTF-8 representa en promedio el 97,3% de todas las páginas web; y 988 de las 1.000 páginas web mejor clasificadas. UTF-8 incluye ASCII como un subconjunto; casi ningún sitio web declara que solo se utiliza ASCII. Varios idiomas tienen un uso 100.0% UTF-8.

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 (BOM), 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 a la salida. Recientemente ha habido algunas mejoras, el Bloc de notas en Windows 10 escribe UTF-8 sin una lista de materiales de forma predeterminada, y algunos archivos del sistema en Windows 11 requieren UTF-8, y casi todos los archivos en macOS y Linux deben ser UTF-8 (sin una lista de materiales). Java, con su API NIO por defecto, lee y escribe archivos UTF-8, y se está moviendo para hacerlo para todas las demás API de archivos. Ya lo hace para todas las API en la mayoría de las plataformas, excepto Windows. "La elección de UTF-8 se aplica solo a las API estándar de Java y no al lenguaje Java, que seguirá utilizando UTF-16". Muchos otros lenguajes de programación utilizan UTF-8 de forma predeterminada para E / S; o planea migrar a UTF-8, como Python, que se está preparando para "cambiar la codificación predeterminada a UTF-8 [ya que] se ha convertido en la codificación de texto estándar de facto". La mayoría de las bases de datos admiten UTF-8 (a veces la única opción como con algunos formatos de archivo), incluida la de Microsoft desde SQL Server 2019, lo que resulta en un aumento de la velocidad del 35% y una "reducción de casi el 50% en los requisitos de almacenamiento".

Internamente, el uso del software es menor, con UTF-16 o UCS-2 en uso, particularmente en Windows, pero también por JavaScript, Python, Qt y muchas otras bibliotecas de software multiplataforma. La compatibilidad con la API de Windows es la razón principal de esto, aunque la creencia de que la indexación directa de BMP mejora la velocidad también fue un factor. El software más reciente ha comenzado a usar UTF-8: la primitiva de cadena predeterminada utilizada en Go, Julia, Rust, Swift 5 y PyPy es UTF-8, una versión futura de Python tiene la intención de almacenar cadenas como UTF-8 y versiones modernas de Microsoft Visual Studio usan UTF-8 internamente (sin embargo, todavía requieren un modificador de línea de comandos para leer o escribir UTF-8). UTF-8 es la "única codificación de texto que debe ser compatible con el estándar C ++", a partir de C ++ 20. A partir de mayo de 2019, Microsoft invirtió su curso de solo admitir UTF-16 para la API de Windows, brindando la capacidad de configurar UTF-8 como la "página de códigos" para la API de varios bytes (anteriormente esto era imposible), y ahora Microsoft recomienda (a los programadores) que utilicen UTF-8 para las aplicaciones de la Plataforma universal de Windows (UWP), sin dejar de mantener una interfaz "Unicode" (que significa UTF-16) heredada.

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 múltiples 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 fue probablemente 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 que espera ASCII (o ASCII extendido ), porque podría contener bytes de continuación en el rango 0x21–0x7E que significan 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 una 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.

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 problemas de confiabilidad y especialmente 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.

FSS-UTF (1992) / UTF-8 (1993)
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.

En noviembre de 2003, RFC 3629 restringió UTF-8 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)
El estándar Unicode, versión 11.0 (2018)

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)
El estándar Unicode, versión 5.0 (2006)
El estándar Unicode, versión 6.0 (2010)

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 para 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 únicos. caracteres de bytes, sin decodificar las secuencias multibyte. 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 puede usar para tokenize una corriente 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.
Retraso 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. 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.
Autosincronización : 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 un máximo de 3 bytes 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.

De un solo 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 tailandés y devanagari (que se utiliza 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 pueden 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 hardware tablas de soporte y 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 cierto 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 de Unicode n. ° 26 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 fue escrito para reconocer y formalizar la existencia de datos codificados como CESU-8, a pesar de que el Consorcio Unicode desalienta 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.

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.

CESU-8 está prohibido para su uso en documentos HTML5.

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. Es posible, aunque no es compatible, almacenar datos codificados en CESU-8 utf8mb3, manejando datos UTF-16 con caracteres suplementarios como si fuera UCS-2.

UTF-8 modificado

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). Las cadenas UTF-8 modificadas nunca contienen bytes nulos reales, pero pueden contener todos los puntos de código Unicode, incluido U + 0000, lo que permite que dichas cadenas (con un byte nulo agregado) sean procesadas por las funciones tradicionales de cadenas terminadas en nulo. 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 InputStreamReader y 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 entre otras aplicaciones de DataInput y DataOutput , para la interfaz nativa de Java, y para incrustar cadenas constantes en archivos de clase.

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

WTF-8

En WTF-8 (formato de transformación oscilante, 8 bits) se permiten mitades sustitutas no emparejadas (U + D800 a U + DFFF). 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.

(El término "WTF-8" también se ha utilizado con humor para referirse a UTF-8 erróneamente codificado doblemente, a veces con la implicación de que los bytes CP1252 son los únicos codificados).

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); 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", como lo usa el PEP 383 de Python (o "escape sustituto") Acercarse. Otra codificación llamada MirBSD OPTU-8/16 los convierte a U + EF80... U + EFFF en un área de uso privado. En cualquier enfoque, el valor del byte se codifica en los ocho bits inferiores 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; como la API del sistema de archivos de Windows usa UTF-16, la necesidad de admitir UTF-8 no válido es menor.

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.