UTF-8(7) | Manual del Programador de Linux | UTF-8(7) |
UTF-8 - una codificación Unicode multi-byte compatible con ASCII
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 ficheros 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 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.
La codificación UTF-8 tiene los siguientes propiedades atractivas:
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:
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–0xdfff (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.
El carácter Unicode 0xa9 = 1010 1001 (el signo de copyright) se codifica en UTF-8 como
y el carácter 0x2260 = 0010 0010 0110 0000 (el símbolo de "distinto que") se codifica como:
Los usuarios tiene que seleccionar una localización UTF-8, por ejemplo con
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
y los programadores pueden comprobar la expresión
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 un fichero con texto plano, los nombres de fichero y las variables de entorno están codificadas en UTF-8.
Los programadores acostumbrados a codificaciones de un sólo byte tales como US-ASCII o ISO 8859 deben ser conscientes de que dos suposiciones hechas hasta ahora ya no son válidas con localizaciones UTF-8. En primer lugar, un byte ya no se corresponde necesariamente con un sólo carácter. En segundo lugar, puesto que los modernos emuladores de terminal en modo UTF-8 soportan también caracteres de doble ancho del chino, japonés y coreano, así como caracteres combinantes de no espaciado, escribir en la salida un carácter individual no implica necesariamente avanzar el cursor una posición como sucedía en ASCII. En la actualidad se deben usar funciones de biblioteca como mbsrtowcs(3) y wcswidth(3) para contar caracteres y posiciones del cursor.
La secuencia de escape oficial para cambiar de un esquema de codificación ISO 2022 (como el que se utiliza por ejemplo en las terminales VT100) a UTF-8 es ESC % G ("\x1b%G"). La correspondiente secuencia de retorno de UTF-8 a ISO 2022 es ESC % @ ("\x1b%@"). Otras secuencias ISO 2022 (como para cambiar los conjuntos G0 y G1) no son aplicables en el modo UTF-8.
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.
ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9.
locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7)
Esta página es parte de la versión 5.10 del proyecto Linux man-pages. Puede encontrar una descripción del proyecto, información sobre cómo informar errores y la última versión de esta página en https://www.kernel.org/doc/man-pages/.
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>..
6 Marzo 2019 | GNU |