UTF-8(7)

NOME
UTF-8 - uma codificação Unicode multibyte compatível com ASCII

DESCRIÇÃO
O conjunto de caracteres Unicode 3.0 ocupa um espaço de código de 16 bits. A codificação Unicode mais óbvia (conhecida como UCS-2) consiste de uma seqüência de palavras de 16 bits. Tais palavras podem conter, em sua maior parte, bytes de caracteres de 16 bits, como '\0' ou '/', que têm um significado especial em nomes de arquivos e outros parâmetros de funções em bibliotecas C. Além disso, a maioria das ferramentas UNIX esperam arquivos ASCII e não podem ler palavras de 16 bits como caracteres sem modificações maiores. Por essas razões, UCS-2 não é uma codificação externa disponível de Unicode em nomes de arquivos, arquivos-texto, variáveis de ambiente, etc. O ISO 10646 Universal Character Set (UCS), um superconjunto de Unicode, ocupa ainda um espaço de código de 31 bits e a óbvia codificação UCS-4 para ele (uma seqüência de palavras de 32 bits) tem o mesmo problema. A codificação UTF-8 de Unicode e UCS não tem esses problemas e é a maneira mais comum de usar o conjunto de caracteres Unicode sob sistemas operacionais do estilo Unix.

PROPIEDADES
A codificação UTF-8 tem as seguintes belas propriedades:

*   UCS de 0x00000000 a 0x0000007f (os clássicos caracteres US-ASCII) são codificadas simplesmente como bytes de 0x00 a 0x7f (compatibilidade com ASCII). Isto significa que os arquivos e strings que contêm somente caracteres ASCII de 7 bits têm a mesma codificação tanto sob ASCII quanto sob UTF-8.

*   Todos os caracteres UCS> 0x7f são codificados como uma seqüência multibyte, consistindo somente de bytes na faixa de 0x80 a 0xfd, de forma que nenhum byte ASCII apareça como parte de outro caractere e não haja problemas com, por exemplo, '\0' ou '/'.

*   A ordenação lexicográfica das strings UCS-4 é preservada.

*   Todos os 2^31 códigos UCS possíveis podem ser codificados usando-se UTF-8.

*   Os bytes 0xfe e 0xff nunca são usados na codificação UTF-8.

*   O primeiro byte de uma seqüência multibyte que representa um único caractere UCS não-ASCII está sempre na faixa 0xc0 a 0xfd, e indica o tamanho desta seqüência multibyte. Todos os bytes seguintes na seqüência multibyte estão na faixa de 0x80 a 0xbf. Isto permite um ressincronismo fácil e torna a codificação independente de estado, e robusta contra perda de bytes.

*   UTF-8 codificados em UCS podem ter até seis bytes de comprimento, porém os caracteres Unicode padrão específica nenhum caractere acima de 0x10ffff, assim caracteres Unicode somento podem ter mais de 4 bytes de comprimento em UTF-8.

CODIFICAÇÃO
As seguintes seqüências de bytes são usadas para representar um caractere. A seqüência a ser usada depende do número de código UCS do caractere:

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

As posições de bit xxx são preenchidas com os bits do número do código de caractere na representação binária. Somente a seqüência de multibyte mais curta possível que pode representar o número do código do caractere pode ser usada.

O código UCS 0xd800–0xdfff (substituto UTF-16) assim como 0xfffe e 0xffff (caracteres não UCS) não deveria aparecer de acordo com o fluxo UTF-8.

EXEMPLOS
O caractere Unicode 0xa9 = 1010 1001 (o sinal de copyright) é codificado em UTF-8 como

    11000010 10101001 = 0xc2 0xa9

e o caractere 0x2260 = 0010 0010 0110 0000 (o símbolo de "diferente") é codificado como:

    11100010 10001001 10100000 = 0xe2 0x89 0xa0

NOTAS DE APLICAÇÕES
Usuários tem que selecionar uma localização UTF-8, por exemplo, com

    export LANG=en_GB.UTF-8

para ordenar a ativação do suporte UTF-8 nas aplicações.

Aplicações que tem sido usuárias prevenidas de codificação de caractere sempre deveriam selecionar a localização com, por exemplo,

    setlocale(LC_CTYPE, "")

e programadores podem, então, testar a expressão

    strcmp(nl_langinfo(CODESET), "UTF-8") == 0

para determinar se uma localização UTF-8 já foi selecionado e se todo texto plano da entrada e saída padrão, comunicação de terminal, conteúdo de texto plano, nomes de arquivos e variáveis de ambiente são codificadas em UTF-8.

Programadores acostumados com codificações de byte simples como US-ASCII e ISO 8859 tem de estar cientes que duas suposições não são mais válidas na localização UTF-8. Primeiramente, um byte simples não corresponde necessariamente a um caractere simples. Em segundo lugar, desde os modernos emuladores de terminal em UTF-8 também podem suportar chinês, japonês e koreano caracteres de tamanho duplo como sem espaçamento caracteres combinantes, saindo um caractere simples que necessariamente não avança o cursor por uma posição como é feito em ASCII. Bibliotecas de funções como mbsrtowcs(3) e wcswidth(3) devem ser usadas nestes dias para contar caracteres e posições de cursor.

A seqüencia oficial ESC para alternar, oriunda do esquema de codificação ISO 2022 ( como usada, por exemplo, pelo terminais VT100) para UTF-8 é ESC % G ("\x1b%G"). O seqüencia de retorno correspondente da UTF-8 para ISO 2022 é ESC % @ ("x1b%@"). Outras seqüencias ISO 2022 (tais como para trocar o conjunto G0 e G1) não são aplicadas no modo UTF-8.

Pode ter esperança que em um futuro próximo UTF-8 substitua ASCII e ISO 8859 em todos os níveis com a codificação de caractere comum em sistemas POSIX, iniciando um significante e rico ambiente para tratamento de texto plano.

SEGURANÇA
A especificação Unicode e UCS requerem que produtores de UTF-8 usem a menor forma possível, isto é, produzindo uma seqüencia de dois bytes sendo o primeiro 0xc0. Unicode 3.1 foi adicionada um requisição que programas não devem aceitar formas não-reduzidas em suas entradas. Por razões de segurança: se a entrada do usuário for verificada, contra violações de segurança, um programa poderia verificar somente pelas versões ASCII de "/../" ou ";" ou NUL e negar que há muitas maneiras non-ASCII de representar isto nas formas não-reduzidas UTF-8.

DE ACORDO COM
ISO/IEC 10646-1:2000, Unicode 3.1, RFC 2279, Plan 9.

AUTORES
Markus Kuhn <mgk25@cl.cam.ac.uk>

VEJA TAMBÉM
nl_langinfo(3), setlocale(3), charsets(7), unicode(7).

TRADUZIDO POR LDP-BR em 21/08/2000.

  Tradução:
Rubens de Jesus Nogueira <darkseid99@usa.net>

  Revisão.:
André Luiz Fassone <lonely_wolf@ig.com.br>