Provided by:
manpages-es_1.55-10_all 
NOMBRE
UTF-8 - una codificacion Unicode mutibyte compatible con ASCII
DESCRIPCI'ON
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 ficheros y en otras
variables de funciones de la biblioteca C. Ademas, la mayoria de las
herramientas de UNIX esperan ficheros ASCII y no pueden leer 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 10646 Universal
Character Set (UCS), es un superconjunto de Unicode con un espacio de
codigos 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
> 0x7f se codifican como una secuencia multibyte formada solamente
por bytes en el rango 0x80 a 0xfd, por tanto ningun byte ASCII puede
aparecer como parte de otro caracter y no hay problemas 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 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 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 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.
CODIFICACI'ON
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 del numero de codigo del
carcter representado en binario. Solo se puede usar la secuencia mas
corta que pueda representar el numero de codigo.
Los codigos UCS 0xd800-0xdfff (sustitutos de UTF-16) asi como 0xfffe y
0xffff (caracteres no UCS) no deberian aparecer en flujos conformes con
UTF-8 .
EJEMPLOS
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 un fichero 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 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-anchura 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 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.
Se espera que en un futuro previsible, UTF-8 reemplace a ASCII y ISO
8859 en todos los niveles como la codificacion de caracteres comun en
sistemas POSIX, llevando a un entorno significativamente mas
enriquecido para manejar texto plano.
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 conformes 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.
EST'ANDARES
ISO/IEC 10646-1:2000, Unicode 3.1, RFC 2279, Plan 9.
AUTOR
Markus Kuhn <mskuhn@cip.informatik.uni-erlangen.de>
V'EASE TAMBI'EN
nl_langinfo(3), setlocale(3), charsets(7), unicode(7)