UTF-8(7) Miscellaneous Information Manual UTF-8(7) NOMBRE UTF-8 - una codificacion Unicode multi-byte compatible con ASCII DESCRIPCION El conjunto de caracteres Unicode 3.0 ocupa un espacio de codigos de 16 bits. La codificacion Unicode mas 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. Ademas, la mayoria 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 codificacion 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 codigos aun mayor, de hasta --31 bits-- y la codificacion obvia para dicho conjunto, UCS-4 (una secuencia de palabras de 32 bits), posee los mismos problemas. La codificacion 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 codificacion UTF-8 tiene los siguientes propiedades atractivas: * Los caracteres UCS 0x00000000 a 0x0000007f (el conjunto clasico 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 codificacion 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 ningun byte ASCII puede aparecer como parte de otro caracter y no hay inconenientes con (por ejemplo): '\0' or '/'. * Se preserva la enumeracion lexicografica de las cadenas UCS-4. * Los 2^31 codigos posibles UCS pueden codificarse con UTF-8. * Los bytes 0xc0, 0xc1, 0xfe y 0xff no se usan nunca en la codificacion UTF-8. * El primer byte de una secuencia multibyte que represente un caracter 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 facil resincronizacion y resulta en una codificacion sin estado y robusta frente a la perdida de bytes. * Los caracteres UCS codificados en UTF-8 pueden llegar a ser de 6 bytes, no obstante el estandar Unicode no especifica caracteres por encima de 0x10ffff, por lo tanto los caracteres Unicode solo pueden ser de 4 bytes como mucho en UTF-8. Codificacion Las siguientes secuencias de bytes se usan para representar un caracter. La secuencia a usar depende del codigo UCS correspondiente al caracter: 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 representacion binaria del numero de codigo del caracter, con el bit mas importante primero (big-endian). Solo se puede usar la secuencia mas corta que pueda representar el numero de codigo. Los valores del codigo UCS 0xd800-xdfff (sustitutos de UTF-16) asi como 0xfffe y 0xffff (caracteres no UCS) no deberian aparecer en flujos conformes con UTF-8. Segun el RFC 3629, no deberia emplearse ningun valor mas alla de U+10FFFF lo que limita los caracteres a cuatro bytes. Ejemplo El caracter Unicode 0xa9 = 1010 1001 (el signo de copyright) se codifica en UTF-8 como 11000010 10101001 = 0xc2 0xa9 y el caracter 0x2260 = 0010 0010 0110 0000 (el simbolo de "distinto que") se codifica como: 11100010 10001001 10100000 = 0xe2 0x89 0xa0 Observaciones sobre aplicaciones Los usuarios tiene que seleccionar una localizacion 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 codificacion de caracteres usada deben establecer siempre la localizacion mediante por ejemplo setlocale(LC_CTYPE, "") y los programadores pueden comprobar la expresion strcmp(nl_langinfo(CODESET), "UTF-8") == 0 para averiguar si se ha seleccionado una localizacion UTF-8 y por tanto toda la entrada y salida en texto plano, la comunicacion con la terminal, el contenido de ficheros con texto plano, los nombres de fichero y las variables de entorno estan codificadas en UTF-8. Los programadores acostumbrados a codificaciones de un solo byte tales como US-ASCII o ISO/IEC 8859 deben ser conscientes de que dos suposiciones hechas hasta ahora ya no son validas con localizaciones UTF-8. En primer lugar, un byte ya no se corresponde necesariamente con un solo caracter. En segundo lugar, puesto que los modernos emuladores de terminal en modo UTF-8 soportan tambien caracteres de doble ancho del chino, japones y coreano, asi como caracteres combinantes de no espaciado, escribir en la salida un caracter individual no implica necesariamente avanzar el cursor una posicion como sucedia 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 codificacion ISO/IEC 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/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 estandares Unicode y UCS requieren que los fabricantes de UTF-8 usen la forma mas corta posible, p.ej: producir una secuencia de dos bytes que tenga como primer byte 0xc0 no se ajustaria al estandar. Unicode 3.1 anade el requisito de que los programas no deben aceptar en su entrada formas que no cumplan la condicion anterior. Esto es por motivos de seguridad: si un programa desea comprobar posibles violaciones de seguridad en la entrada del usuario, este podria verificar solamente la version ASCII de "/../" o ";" o NUL y pasar por alto las diferentes maneras no-ASCII de representar estas situaciones en una codificacion UTF-8 con formato no reducido. Estandares ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9. VEASE TAMBIEN locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7) TRADUCCION La traduccion al espanol de esta pagina del manual fue creada por Miguel Angel Sepulveda , Juan Piernas , Miguel Perez Ibars y Marcos Fouces Esta traduccion es documentacion libre; lea la GNU General Public License Version 3 o posterior con respecto a las condiciones de copyright. No existe NINGUNA RESPONSABILIDAD. Si encuentra algun error en la traduccion de esta pagina del manual, envie un correo electronico a . Paginas de manual de Linux 6.06 28 Enero 2024 UTF-8(7)