UTF-7 - UTF-7

UTF-7

Línguas)	Internacional
Padrão	RFC  2152
Classificação	Formato de transformação Unicode , armadura ASCII , codificação de largura variável , codificação stateful
Transformações / Codificações	Unicode
Precedido por	HZ-GB-2312
Sucedido por	UTF-8 sobre 8BITMIME
v t e

UTF-7 ( Formato de Transformação Unicode de 7 bits ) é uma codificação de caracteres de comprimento variável obsoleta para representar texto Unicode usando um fluxo de caracteres ASCII . A intenção original era fornecer um meio de codificação de texto Unicode para uso em mensagens de e-mail da Internet que fosse mais eficiente do que a combinação de UTF-8 com impressão entre aspas .

UTF-7 (de acordo com seu RFC) não é um " Formato de Transformação Unicode ", já que a definição só pode codificar pontos de código no BMP (os primeiros 65536 pontos de código Unicode, que não incluem emojis e muitos outros caracteres). No entanto, se um tradutor UTF-7 for de / para UTF-16 , ele pode (e provavelmente o faz) codificar cada metade substituta como se fosse um ponto de código de 16 bits e, portanto, pode codificar todos os pontos de código. Não está claro se outro software UTF-7 (como tradutores para UTF-32 ou UTF-8) suporta isso.

UTF-7 nunca foi um padrão oficial do Unicode Consortium . É conhecido por ter problemas de segurança, razão pela qual o software foi alterado para desativar seu uso. É proibido em HTML 5 .

Motivação

MIME , o padrão moderno de formato de e-mail, proíbe a codificação de cabeçalhos usando valores de bytes acima da faixa ASCII. Embora o MIME permita a codificação do corpo da mensagem em vários conjuntos de caracteres (mais amplos do que ASCII), a infraestrutura de transmissão subjacente ( SMTP , o principal padrão de transferência de e-mail) ainda não é garantida como limpa de 8 bits . Portanto, uma codificação de transferência de conteúdo não trivial deve ser aplicada em caso de dúvida. Infelizmente, base64 tem a desvantagem de tornar ilegíveis até caracteres US-ASCII em clientes não MIME. Por outro lado, UTF-8 combinado com impressão entre aspas produz um formato muito ineficiente em tamanho, exigindo de 6 a 9 bytes para caracteres não ASCII do BMP e 12 bytes para caracteres fora do BMP.

Desde que certas regras sejam seguidas durante a codificação, o UTF-7 pode ser enviado por e-mail sem usar uma codificação de transferência MIME subjacente , mas ainda deve ser explicitamente identificado como o conjunto de caracteres de texto. Além disso, se usado em cabeçalhos de e-mail como "Assunto:", o UTF-7 deve estar contido em palavras codificadas em MIME que identifiquem o conjunto de caracteres. Uma vez que as palavras codificadas forçam o uso de quoted-printable ou base64 , o UTF-7 foi projetado para evitar o uso do sinal = como um caractere de escape para evitar escape duplo quando ele é combinado com quoted-printable (ou sua variante, o RFC 2047/1522 ? Q? - codificação de cabeçalhos).

O UTF-7 geralmente não é usado como uma representação nativa nos aplicativos, pois é muito difícil de processar. Apesar de sua vantagem de tamanho em relação à combinação de UTF-8 com cotação para impressão ou base64, o agora extinto Internet Mail Consortium recomendou contra seu uso.

O 8BITMIME também foi introduzido, o que reduz a necessidade de codificar o corpo das mensagens em um formato de 7 bits.

Uma forma modificada de UTF-7 (às vezes chamada de 'mUTF-7') é usada atualmente no protocolo de recuperação de e-mail IMAP para nomes de caixas de correio.

Descrição

O UTF-7 foi proposto pela primeira vez como um protocolo experimental no RFC 1642, A Mail-Safe Transformation Format of Unicode . Este RFC tornou-se obsoleto pelo RFC 2152, um RFC informativo que nunca se tornou um padrão. Como a RFC 2152 afirma claramente, a RFC "não especifica um padrão da Internet de nenhum tipo". Apesar disso, a RFC 2152 é citada como a definição de UTF-7 na lista de conjuntos de caracteres da IANA. O UTF-7 também não é um padrão Unicode. O Unicode Standard 5.0 lista apenas UTF-8, UTF-16 e UTF-32. Também existe uma versão modificada, especificada na RFC 2060, que às vezes é identificada como UTF-7.

Alguns caracteres podem ser representados diretamente como bytes ASCII únicos. O primeiro grupo é conhecido como "caracteres directas" e contém 62 caracteres alfanuméricos e 9 símbolos: ' ( ) , - . / : ?. Os caracteres diretos podem ser incluídos literalmente com segurança. O outro grupo principal, conhecido como "caracteres diretos opcionais", contém todos os outros caracteres imprimíveis no intervalo U + 0020 –U + 007E, exceto ~ \ +e espaço (os caracteres \e ~sendo excluídos devido a serem redefinidos em "variantes de ASCII", como JIS- Romano ). Usar os caracteres diretos opcionais reduz o tamanho e melhora a legibilidade humana, mas também aumenta a chance de quebra por coisas como gateways de correio mal projetados e pode exigir escape extra quando usado em palavras codificadas para campos de cabeçalho.

Espaço, tabulação, retorno de carro e avanço de linha também podem ser representados diretamente como bytes ASCII únicos. No entanto, se o texto codificado for usado em e-mail, é necessário ter cuidado para garantir que esses caracteres sejam usados ​​de maneiras que não exijam codificação de transferência de conteúdo adicional para serem adequados para e-mail. O sinal de mais ( +) pode ser codificado como +-.

Outros caracteres devem ser codificados em UTF-16 (portanto, U + 10000 e superior seriam codificados em dois substitutos) e, em seguida, em Base64 modificada . O início destes blocos de UTF-16 codificado em Base64 modificado é indicado por um +sinal. O fim é indicado por qualquer caractere que não esteja no conjunto Base64 modificado. Se o caractere após o Base64 modificado for um -(ASCII hífen-menos ), ele será consumido pelo decodificador e a decodificação será retomada com o próximo caractere. Caso contrário, a decodificação continuará com o caractere após base64.

Exemplos

• " Hello, World!" está codificado como " Hello, World+ACE-"
• " 1 + 1 = 2" está codificado como " 1 +- 1 +AD0- 2"
• " £1" está codificado como " +AKM-1". O ponto de código Unicode para o sinal de sustenido é U + 00A3, que se converte em Base64 modificado como na tabela abaixo. Existem dois bits restantes, que são preenchidos com 0.

Dígito hexadecimal	0				0				UMA				3
Padrão de bits	0	0	0	0	0	0	0	0	1	0	1	0	0	0	1	1	0	0
Índice	0						10						12
Codificado em Base64	UMA						K						M

Algoritmo para codificação e decodificação

Codificação

Primeiro, um codificador deve decidir quais caracteres representar diretamente no formato ASCII, quais +devem ser escapados como +-, e quais colocar em blocos de caracteres Unicode. Um codificador simples pode codificar todos os caracteres que considera seguros para codificação direta diretamente. No entanto, o custo de terminar uma sequência Unicode, produzindo um único caractere diretamente em ASCII e, em seguida, iniciando outra sequência Unicode é de 3 a 3+2 ⁄ 3 bytes. Isso é mais do que 2+2 ⁄ 3 bytes necessários para representar o caractere como parte de uma sequência Unicode. Cada sequência Unicode deve ser codificada usando o procedimento a seguir e, a seguir, cercada pelos delimitadores apropriados.

Usando a sequência de caracteres £ † (U + 00A3 U + 2020) como exemplo:

Decodificação

Primeiro, os dados codificados devem ser separados em blocos de texto ASCII simples (incluindo + es seguidos de um traço) e blocos Unicode não vazios, conforme mencionado na seção de descrição. Feito isso, cada bloco Unicode deve ser decodificado com o seguinte procedimento (usando o resultado do exemplo de codificação acima como nosso exemplo)

1. Expresse cada código Base64 como a sequência de bits que ele representa:
   AKMgIA → 000000 001010 001100 100000 001000 000000
2. Reagrupe o binário em grupos de dezesseis bits, começando da esquerda:
   000000 001010 001100 100000 001000 000000 → 0000000010100011 0010000000100000 0000
3. Se houver um grupo incompleto no final contendo apenas zeros, descarte-o (se o grupo incompleto contiver algum, o código é inválido):
   0000000010100011 0010000000100000
4. Cada grupo de 16 bits é o número Unicode (UTF-16) de um caractere e pode ser expresso em outras formas:
   0000 0000 1010 0011 ≡ 0x00A3 ≡ 163 ₁₀

Marca de ordem de byte

Uma marca de ordem de byte (BOM) é uma sequência de bytes especial opcional no início de um fluxo ou arquivo que, sem ser dados em si, indica a codificação usada para os dados que se seguem; ele pode ser usado na ausência de metadados que denotem a codificação. Para um determinado esquema de codificação, é a representação desse esquema do ponto de código Unicode U+FEFF.

Embora seja normalmente uma sequência de byte fixo único, no UTF-7 podem aparecer quatro variações, porque os últimos 2 bits do 4º byte da codificação UTF-7 U+FEFFpertencem ao caractere seguinte , resultando em 4 padrões de bits possíveis e, portanto, 4 diferentes bytes possíveis na 4ª posição. Consulte a entrada UTF-7 na tabela de marcas de ordem de bytes Unicode .

Segurança

UTF-7 permite várias representações da mesma string de origem. Em particular, os caracteres ASCII podem ser representados como parte de blocos Unicode. Dessa forma, se processos de validação ou escape baseados em ASCII padrão forem usados ​​em strings que podem ser interpretadas posteriormente como UTF-7, os blocos Unicode podem ser usados ​​para passar strings maliciosas por eles. Para atenuar esse problema, os sistemas devem realizar a decodificação antes da validação e devem evitar a tentativa de detecção automática do UTF-7.

As versões mais antigas do Internet Explorer podem ser induzidas a interpretar a página como UTF-7. Isso pode ser usado para um ataque de script entre sites , já que as marcas <e >podem ser codificadas como +ADw-e +AD4-em UTF-7, que a maioria dos validadores deixa passar como texto simples.

O UTF-7 é considerado obsoleto, pelo menos para o software Microsoft (.NET), com caminhos de código que anteriormente o suportavam intencionalmente quebrado (para evitar problemas de segurança) no .NET 5, em 2020.

Referências

Veja também

• Comparação de codificações Unicode