.\" Hey Emacs! This file is -*- nroff -*- source. .\" .\" Copyright (C) Markus Kuhn, 2001 .\" .\" This is free documentation; you can redistribute it and/or .\" modify it under the terms of the GNU General Public License as .\" published by the Free Software Foundation; either version 2 of .\" the License, or (at your option) any later version. .\" .\" The GNU General Public License's references to "object code" .\" and "executables" are to be interpreted as the output of any .\" document formatting or typesetting system, including .\" intermediate and printed output. .\" .\" This manual is distributed in the hope that it will be useful, .\" but WITHOUT ANY WARRANTY; without even the implied warranty of .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the .\" GNU General Public License for more details. .\" .\" You should have received a copy of the GNU General Public .\" License along with this manual; if not, write to the Free .\" Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111, .\" USA. .\" .\" 1995-11-26 Markus Kuhn .\" First version written .\" 2001-05-11 Markus Kuhn .\" Update .\" .\" Translated by Miguel A. Sepulveda .\" Translation revised June 9 1998 by Juan Piernas .\" Traducción revisada por Miguel Pérez Ibars el 14-febrero-2005 .\" .TH UTF-8 7 "11 mayo 2001" "GNU" "Manual del Programador de Linux" .SH NOMBRE UTF-8 \- una codificación Unicode mutibyte compatible con ASCII .SH DESCRIPCIÓN El conjunto de caracteres .B Unicode 3.0 ocupa un espacio de códigos de 16 bits. La codificación Unicode más obvia (conocida como .BR 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 esperan ficheros ASCII y no pueden leer palabras de 16 bits como caracteres sin considerables modificaciones. Por estas razones, .B UCS-2 no es una codificación externa apropiada de .B Unicode en nombres de ficheros, variables de entorno, etc. El .BR "ISO 10646 Universal Character Set (UCS)" , es un superconjunto de Unicode con un espacio de códigos de hasta 31 bits y la codificación obvia para dicho conjunto, .B UCS-4 (una secuencia de palabras de 32 bits), posee los mismos problemas. La codificación .B UTF-8 de .B Unicode y .B UCS carece de estos problemas y es la forma habitual de usar el conjunto de caracteres .B Unicode bajo sistemas operativos al estilo UNIX. .SH PROPIEDADES La codificación .B UTF-8 tiene los siguientes propiedades atractivas: .TP 0.2i * Los caracteres .B UCS 0x00000000 a 0x0000007f (el conjunto clásico de caracteres .B 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 .B ASCII y en .BR UTF-8 . .TP * Todos los caracteres .B UCS > 0x7f se codifican como una secuencia multibyte formada solamente por bytes en el rango 0x80 a 0xfd, por tanto ningún byte ASCII puede aparecer como parte de otro carácter y no hay problemas con, por ejemplo, '\\0' or '/'. .TP * Se preserva la enumeración lexicográfica de las cadenas .B UCS-4 . .TP * Los 2^31 códigos posibles UCS pueden codificarse con .BR UTF-8 . .TP * Los bytes 0xfe y 0xff no se usan nunca en la codificación .B UTF-8 .TP * El primer byte de una secuencia multibyte que represente un carácter no ASCII .B UCS siempre se halla en el rango 0xc0 a 0xfd, e indica la longitud de la secuencia. El resto de los bytes de la secuencia se hallan en el rango 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. .TP * Los caracteres .B UCS codificados en .B UTF-8 pueden llegar a ser de 6 bytes, no obstante el estándar .B Unicode no especifica caracteres por encima de 0x10ffff, por lo tanto los caracteres Unicode sólo pueden ser de 4 bytes como mucho en .BR UTF-8 . .SH 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: .TP 0.4i 0x00000000 - 0x0000007F: .RI 0 xxxxxxx .TP 0x00000080 - 0x000007FF: .RI 110 xxxxx .RI 10 xxxxxx .TP 0x00000800 - 0x0000FFFF: .RI 1110 xxxx .RI 10 xxxxxx .RI 10 xxxxxx .TP 0x00010000 - 0x001FFFFF: .RI 11110 xxx .RI 10 xxxxxx .RI 10 xxxxxx .RI 10 xxxxxx .TP 0x00200000 - 0x03FFFFFF: .RI 111110 xx .RI 10 xxxxxx .RI 10 xxxxxx .RI 10 xxxxxx .RI 10 xxxxxx .TP 0x04000000 - 0x7FFFFFFF: .RI 1111110 x .RI 10 xxxxxx .RI 10 xxxxxx .RI 10 xxxxxx .RI 10 xxxxxx .RI 10 xxxxxx .PP Las posiciones .I xxx se rellenan con los bits del número de código del carcter representado en binario. Sólo se puede usar la secuencia más corta que pueda representar el número de código. .PP Los códigos .B UCS 0xd800\(en0xdfff (sustitutos de UTF-16) así como 0xfffe y 0xffff (caracteres no UCS) no deberían aparecer en flujos conformes con .B UTF-8 . .SH EJEMPLOS El carácter .B Unicode 0xa9 = 1010 1001 (el signo de copyright) se codifica en .B UTF-8 como .PP .RS 11000010 10101001 = 0xc2 0xa9 .RE .PP y el carácter 0x2260 = 0010 0010 0110 0000 (el símbolo de "distinto que") se codifica como: .PP .RS 11100010 10001001 10100000 = 0xe2 0x89 0xa0 .RE .SH "OBSERVACIONES SOBRE APLICACIONES" Los usuarios tiene que seleccionar una localización .B UTF-8 , por ejemplo con .PP .RS export LANG=en_GB.UTF-8 .RE .PP para poder activar el soporte de .B UTF-8 en las aplicaciones. .PP Aquellas aplicaciones que deban ser conscientes de la codificación de caracteres usada deben establecer siempre la localización mediante por ejemplo .PP .RS setlocale(LC_CTYPE, "") .RE .PP y los programadores pueden comprobar la expresión .PP .RS strcmp(nl_langinfo(CODESET), "UTF-8") == 0 .RE .PP para averiguar si se ha seleccionado una localización .B 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 .BR UTF-8 . .PP Los programadores acostumbrados a codificaciones de un sólo byte tales como .B US-ASCII o .B ISO 8859 deben ser conscientes de que dos suposiciones hechas hasta ahora ya no son válidas con localizaciones .B 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 .B UTF-8 soportan también .B caracteres de doble-anchura del chino, japonés y coreano, así como .BR "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 .BR ASCII . En la actualidad se deben usar funciones de biblioteca como .BR mbsrtowcs (3) y .BR wcswidth (3) para contar caracteres y posiciones del cursor. .PP La secuencia de escape oficial para cambiar de un esquema de codificación .B ISO 2022 (como el que se utiliza por ejemplo en las terminales VT100) a .B UTF-8 es ESC % G ("\\x1b%G"). La correspondiente secuencia de retorno de .B 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. .PP Se espera que en un futuro previsible, .B UTF-8 reemplace a .B ASCII y .B ISO 8859 en todos los niveles como la codificación de caracteres común en sistemas POSIX, llevando a un entorno significativamente más enriquecido para manejar texto plano. .SH SEGURIDAD Los estándares .BR Unicode " y " UCS requieren que los fabricantes de .B 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. .B Unicode 3.1 añade el requisito de que los programas conformes 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 .B ASCII de "/../" o ";" o NUL y pasar por alto las diferentes maneras .RB no- ASCII de representar estas situaciones en una codificación .B UTF-8 con formato no reducido. .SH ESTÁNDARES ISO/IEC 10646-1:2000, Unicode 3.1, RFC 2279, Plan 9. .SH AUTOR Markus Kuhn .SH "VÉASE TAMBIÉN" .BR nl_langinfo (3), .BR setlocale (3), .BR charsets (7), .BR unicode (7)