Resumo

  • A RFC 2152 reservou + para iniciar Modified Base64 sem =, sobre quantidades Unicode de 16 bits em ordem de byte mais significativo; a sequência terminava fora do alfabeto e nunca podia cruzar uma quebra de linha.
  • O Set O permitia pontuação direta apesar do risco de gateway, e qualquer sequência Unicode podia ser deslocada. Decodificar os caracteres não reconstituía necessariamente os bytes, as linhas, o percurso ou a intenção originais.

Uma migração de arquivo pode preservar tudo o que é fácil de olhar e perder o que seria necessário provar. Assuntos em letras latinas continuam legíveis; fragmentos UTF-7 abrem sem erro. Se o objeto bruto foi substituído pela projeção Unicode, porém, já não se sabe qual pontuação viajou direta, onde um relay refez as linhas ou quais bytes estavam sob assinatura.

David Goldsmith e Mark Davis publicaram a RFC 2152 em maio de 1997 como documento Informational, substituindo a RFC 1642. Não era Internet Standard. O problema era o correio US-ASCII de sete bits. UTF-8 combinado com outra codificação MIME podia impor duas transformações e grande expansão ao texto não ASCII. O UTF-7 produzia só octetos ASCII e mantinha legível o caso dominado por esse repertório.

A própria RFC limitou seu uso normal a transportes de sete bits, como correio; fora deles, Unicode direto ou UTF-8 eram preferíveis.

Direto não significava igualmente seguro

O Set D reunia letras, dígitos e nove sinais diretos, excluindo + e =. O Set O continha outra pontuação que podia ser enviada diretamente, mas a RFC avisava que parte dela era ilegal em cabeçalhos ou não passava corretamente por alguns gateways. Barra invertida e til foram omitidos porque variantes de ASCII frequentemente os redefiniam.

O Apêndice A oferecia duas versões do mesmo texto chinês. A que usava o Set O opcional era mais exposta a gateways; a outra evitava essa escolha. A representação mais visível não era uma promessa de preservação.

Um mais abria estado

Depois de +, o receptor lia o alfabeto Base64 da RFC 2045 sem o preenchimento =. Um caractere fora do Set B terminava o deslocamento. Se fosse , era absorvido; +- representava um mais literal. Um mais seguido por algo que não fosse Set B nem hífen era malformado.

Antes do Base64, quantidades Unicode de 16 bits eram serializadas com o octeto mais significativo primeiro. As metades de um par substituto UTF-16 eram tratadas separadamente. Quantidade ímpar de octetos era inválida; bits finais incompletos só podiam ser descartados se fossem zero.

Essas regras tornam a sintaxe verificável, não a origem. Hi Mom +Jjo-! recupera o sorriso se a entrada estiver íntegra. Não prova a escolha do codificador inicial, o comportamento de cada relay ou a imagem vista pelo autor.

A linha encerrava o corredor

Uma sequência deslocada sempre terminava no fim da linha e não podia atravessá-lo. As linhas precisavam ser cortadas antes da codificação ou junto dela; se continuassem longas, cabia outra content-transfer encoding MIME, não uma dobra no meio do bloco.

A RFC também recomendava linhas curtas com CRLF SMTP e a conversão de separadores Unicode de linha e parágrafo para melhorar a leitura em sistemas antigos. Isso podia ser correto para interoperabilidade e ainda alterar a sequência fonte. Normalização operacional não é custódia byte a byte.

O mesmo texto podia vir de histórias diferentes

A Rule 2 aceitava qualquer sequência Unicode no modo deslocado, enquanto as Rules 1 e 3 deixavam certos caracteres diretos. Fluxos UTF-7 diferentes podiam, portanto, chegar à mesma sequência Unicode. O decodificador cumpria seu trabalho ao entregar caracteres, mesmo sem guardar a rota.

A aceitação deve separar: bytes e finais de linha brutos; validade estrita do UTF-7; unidades Unicode; e renderização no cliente. Para assinatura, perícia ou incidente, o objeto original e hashes por fronteira são indispensáveis.

A IANA mantém UTF-7, MIBenum 1012 e csUTF7. O registro prova o nome, não adoção ou segurança. UTF-7-IMAP é outro esquema, limitado a nomes de mailbox IMAP e desaconselhado fora desse contexto.

A RFC 2152 não discutiu segurança. Orientação Unicode posterior descreveu riscos de comparação e transformação divergentes, mas hoje informa que UTR 36 está estabilizado e parcialmente sucedido. Nem o silêncio antigo é garantia, nem o alerta posterior é medição de produtos.

Há dois errata verificados: o valor 96 é o acento grave e faltava uma palavra na frase sobre fim de linha. Uma terceira proposta foi rejeitada. O estado, não a contagem, é a evidência.

Pelo princípio de especificação mínima de Heng Lu, o UTF-7 deve ser lido como gramática determinística para uma coordenação estreita. A primazia do código exige observar o gateway real; as camadas de realidade impedem promover rótulo ou legibilidade a resultado de preservação.

Fontes