Provided by: manpages-es_4.26.0-1_all 
NOMBRE
UTF-8 - una codificación Unicode multi-byte compatible con ASCII
DESCRIPCIÓN
El conjunto de caracteres Unicode 3.0 ocupa un espacio de códigos de 16 bits. La codificación Unicode más
obvia (conocida como UCS-2) consiste en una secuencia de palabras de 16 bits. Tales cadenas pueden
contener —como parte de muchos caracteres de 16 bits—, bytes como '\0' or '/', que tienen un significado
especial en nombres de archivos y en otras variables de funciones de la biblioteca C. Además, la mayoría
de las herramientas de UNIX cuenta con archivos en formato ASCII y no pueden interpretar palabras de 16
bits como caracteres sin considerables modificaciones. Por estas razones, UCS-2 no es una codificación
externa apropiada de Unicode en nombres de ficheros, variables de entorno, etc. El 'ISO/IEC 10646
Universal Character Set' (UCS), es un superconjunto de Unicode con un espacio de códigos aún mayor, de
hasta —31 bits— y la codificación obvia para dicho conjunto, UCS-4 (una secuencia de palabras de 32
bits), posee los mismos problemas.
La codificación UTF-8 de Unicode y UCS carece de estos problemas y es la forma habitual de usar el
conjunto de caracteres Unicode bajo sistemas operativos al estilo UNIX.
Propiedades
La codificación UTF-8 tiene los siguientes propiedades atractivas:
• Los caracteres UCS 0x00000000 a 0x0000007f (el conjunto clásico de caracteres US-ASCII se codifican
simplemente como los bytes 0x00 a 0x7f (compatibilidad con ASCII) Esto significa que los ficheros y
cadenas que contengan solamente caracteres ASCII de 7 bits tienen la misma codificación en ASCII y en
UTF-8.
• Todos los caracteres UCS mayores que 0x7f se codifican como una secuencia multibyte formada solamente
por bytes en el intervalo 0x80 a 0xfd, por tanto ningún byte ASCII puede aparecer como parte de otro
carácter y no hay inconenientes con (por ejemplo): '\0' or '/'.
• Se preserva la enumeración lexicográfica de las cadenas UCS-4.
• Los 2^31 códigos posibles UCS pueden codificarse con UTF-8.
• Los bytes 0xc0, 0xc1, 0xfe y 0xff no se usan nunca en la codificación UTF-8.
• El primer byte de una secuencia multibyte que represente un carácter no ASCII UCS siempre se halla en
el intervalo 0xc0 a 0xfd, e indica la longitud de la secuencia. El resto de los bytes de la secuencia
se hallan en el intervalo 0x80 a 0xbf. Esto permite una fácil resincronización y resulta en una
codificación sin estado y robusta frente a la pérdida de bytes.
• Los caracteres UCS codificados en UTF-8 pueden llegar a ser de 6 bytes, no obstante el estándar
Unicode no especifica caracteres por encima de 0x10ffff, por lo tanto los caracteres Unicode sólo
pueden ser de 4 bytes como mucho en UTF-8.
Codificación
Las siguientes secuencias de bytes se usan para representar un carácter. La secuencia a usar depende del
código UCS correspondiente al carácter:
0x00000000 - 0x0000007F:
0xxxxxxx
0x00000080 - 0x000007FF:
110xxxxx 10xxxxxx
0x00000800 - 0x0000FFFF:
1110xxxx 10xxxxxx 10xxxxxx
0x00010000 - 0x001FFFFF:
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
0x00200000 - 0x03FFFFFF:
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0x04000000 - 0x7FFFFFFF:
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
Las posiciones xxx se rellenan con los bits de la representación binaria del número de código del
carácter, con el bit más importante primero (big-endian). Sólo se puede usar la secuencia más corta que
pueda representar el número de código.
Los valores del código UCS 0xd800–xdfff (sustitutos de UTF-16) así como 0xfffe y 0xffff (caracteres no
UCS) no deberían aparecer en flujos conformes con UTF-8. Según el RFC 3629, no debería emplearse ningún
valor más allá de U+10FFFF lo que limita los caracteres a cuatro bytes.
Ejemplo
El carácter Unicode 0xa9 = 1010 1001 (el signo de copyright) se codifica en UTF-8 como
11000010 10101001 = 0xc2 0xa9
y el carácter 0x2260 = 0010 0010 0110 0000 (el símbolo de "distinto que") se codifica como:
11100010 10001001 10100000 = 0xe2 0x89 0xa0
Observaciones sobre aplicaciones
Los usuarios tiene que seleccionar una localización UTF-8, por ejemplo con
export LANG=en_GB.UTF-8
para poder activar el soporte de UTF-8 en las aplicaciones.
Aquellas aplicaciones que deban ser conscientes de la codificación de caracteres usada deben establecer
siempre la localización mediante por ejemplo
setlocale(LC_CTYPE, "")
y los programadores pueden comprobar la expresión
strcmp(nl_langinfo(CODESET), "UTF-8") == 0
para averiguar si se ha seleccionado una localización UTF-8 y por tanto toda la entrada y salida en texto
plano, la comunicación con la terminal, el contenido de ficheros con texto plano, los nombres de fichero
y las variables de entorno están codificadas en UTF-8.
Los programadores que están habituados a la codificación de un solo byte como US-ASCII o ISO/IEC 8859
deben ser conscientes de que dos suposiciones hechas hasta ahora ya no son válidas en las localizaciones
UTF-8. En primer lugar, un solo byte ya no corresponde necesariamente a un único carácter. En segundo
lugar, dado que los emuladores de terminales modernos en el modo UTF-8 también admiten caracteres chinos,
japoneses y coreanos de doble ancho, así como caracteres de combinación no espaciados, la salida de un
único carácter no necesariamente avanza el cursor una posición como se hace en ASCII. Actualmente,
deberían utilizarse funciones de biblioteca, como mbsrtowcs(3) y wcswidth(3), para contar los caracteres
y las posiciones del cursor.
La secuencia oficial de ESC para cambiar de un esquema de codificación ISO/IEC 2022 (como se usa por
ejemplo en terminales VT100) a UTF-8 es ESC % G ('\x1b%G'). La secuencia de retorno correspondiente de
UTF-8 a ISO/IEC 2022 es ESC % @ ('\x1b%@'). Otras secuencias ISO/IEC 2022 (como para cambiar los
conjuntos G0 y G1) no son aplicables en el modo UTF-8.
Seguridad
Los estándares Unicode y UCS requieren que los fabricantes de UTF-8 usen la forma más corta posible,
p.ej: producir una secuencia de dos bytes que tenga como primer byte 0xc0 no se ajustaría al estándar.
Unicode 3.1 añade el requisito de que los programas no deben aceptar en su entrada formas que no cumplan
la condición anterior. Ésto es por motivos de seguridad: si un programa desea comprobar posibles
violaciones de seguridad en la entrada del usuario, éste podría verificar solamente la versión ASCII de
"/../" o ";" o NUL y pasar por alto las diferentes maneras no-ASCII de representar estas situaciones en
una codificación UTF-8 con formato no reducido.
Estándares
ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9.
VÉASE TAMBIÉN
locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7)
TRADUCCIÓN
La traducción al español de esta página del manual fue creada por Miguel Angel Sepulveda
<angel@vivaldi.princeton.edu>, Juan Piernas <piernas@ditec.um.es>, Miguel Pérez Ibars
<mpi79470@alu.um.es> y Marcos Fouces <marcos@debian.org>
Esta traducción es documentación libre; lea la GNU General Public License Version 3 o posterior con
respecto a las condiciones de copyright. No existe NINGUNA RESPONSABILIDAD.
Si encuentra algún error en la traducción de esta página del manual, envíe un correo electrónico a
debian-l10n-spanish@lists.debian.org.
Páginas de Manual de Linux 6.9.1 15 Junio 2024 UTF-8(7)