Resumo

  • A RFC 1922 exigiu que cada linha ISO-2022-CN com chinês repetisse sua designação e voltasse ao ASCII com SI antes do CRLF. Uma janela aberta no meio da mensagem podia reconstruir o estado localmente.
  • As formas ISO-2022-CN eram de sete bits; CN-GB e CN-Big5 exigiam proteção Base64/Quoted-Printable ou negociação 8BITMIME para transporte direto. Receber octetos não provava renderização correta.
  • Parâmetros de edição e extensão descreviam diferenças de tabelas e repertórios privados. Eles melhoravam a evidência, mas não instalavam mapas, autenticavam o remetente nem demonstravam adoção.

Entrega não devolvia o bit perdido

Os sistemas de correio para os quais a RFC 1922 foi escrita ainda carregavam uma fronteira de sete bits. Uma forma chinesa de oito bits podia parecer normal no computador do remetente. Se passasse crua por um agente antigo, o bit superior de cada octeto corria o risco de desaparecer. O servidor seguinte podia registrar sucesso e entregar uma sequência impossível de ler.

CN-GB e CN-Big5 precisavam, portanto, de Base64 ou Quoted-Printable em caminhos de sete bits. A transmissão direta dependia da extensão SMTP 8BITMIME ter sido realmente negociada. A capacidade declarada por um trecho não certificava todos os demais trechos nem o decodificador final.

As formas ISO-2022-CN e ISO-2022-CN-EXT escolheram outra superfície: mantiveram todos os octetos em sete bits. Isso dispensava uma codificação de transferência apenas para preservar o bit alto, mas não dispensava rótulo MIME, sequência de estados válida ou suporte ao repertório.

Cada linha quitava a dívida de estado

Publicada em março de 1996 como Informational, a RFC 1922 começava ISO-2022-CN em ASCII. Uma sequência de escape designava um conjunto; SO mudava para o conjunto chinês de dois bytes e SI voltava ao ASCII. Uma designação posterior no mesmo registro substituía a anterior.

O problema era a memória invisível. Leitores rolavam diretamente para o meio, respostas citavam fragmentos e danos podiam remover o começo. Se a linha atual dependesse de uma designação distante, seus bytes estariam presentes sem a regra para interpretá-los.

Por isso, toda linha com caracteres chineses precisava trazer sua própria designação. Antes do CRLF, o emissor retornava ao ASCII com SI. A linha seguinte começava limpa. A repetição confinava uma falha e permitia que uma janela reconstruísse o presente sem conhecer todo o passado.

Um empréstimo de exatamente dois bytes

SS2 e SS3 invocavam conjuntos adicionais apenas para os próximos dois bytes, equivalentes a um caractere chinês. Depois, o estado SI/SO anterior era retomado. Não eram mudanças permanentes. Confundi-las com SO alteraria o significado de todos os octetos seguintes.

ISO-2022-CN-EXT ampliou os conjuntos e planos disponíveis. A gramática previa finais ainda não atribuídos para futuros registros ISO, mas proibia usá-los antes da atribuição. Reservar um encaixe não autorizava um fornecedor a impor ali sua tabela privada.

Uma implementação precisava preservar designação, duração do deslocamento e retorno. O simples registro “modo chinês” apagaria o detalhe que permite refazer a decisão.

A etiqueta de uma tabela não desenhava o caractere

Os padrões chineses tinham edições. charset-edition informava o ano esperado. Um receptor que entendesse o parâmetro podia escolher a tabela correspondente; outro o ignoraria e talvez usasse uma edição anterior, causando um conjunto limitado de enganos. O ano tornava a diferença investigável, não certificava a tela.

charset-extension identificava repertórios de fornecedores ou extensões locais por nomes registrados ou privados x-. O aviso podia explicar por que um caractere não existia no destino. Não fornecia o mapa ausente. A própria RFC reconhecia que extensões desse tipo podiam prejudicar a interoperabilidade.

A conversão entre Big5 e CNS 11643 continuava dependente de tabelas e decisões de implementação. Um fluxo sintaticamente válido podia resultar em outro glifo. Uma tradição gráfica associada à codificação tampouco revelava identidade, nacionalidade ou autorização do remetente.

Duas colunas por caractere, espaço para a resposta

Sequências de escape ocupavam bytes sem ocupar colunas. Um caractere chinês costumava ocupar dois bytes e duas colunas de tela. A RFC recomendava não dividir o par entre linhas e manter cerca de 75 colunas visíveis. O espaço restante acomodava o > acrescentado por respostas de correio.

Era uma regra pequena sobre uso real. O arquivo precisava sobreviver a citações e recortes, não só a uma transmissão ideal. O retorno de estado em cada linha e a margem para citação protegiam a mensagem contra transformações previsíveis do próprio meio.

O conjunto documental prova o mecanismo, não o alcance

A fonte principal é a RFC 1922. A RFC 1468 e a RFC 1557 fornecem contextos próximos para correio japonês e coreano de sete bits. A RFC 1521 descreve o MIME contemporâneo; a RFC 1652, a negociação 8BITMIME; e a RFC 2046, a organização posterior dos tipos MIME. A RFC 3629 registra depois a padronização de UTF-8.

Essa sequência não mede implantação. A RFC 1922 recomendou, no mínimo, enviar e receber ISO-2022-CN e receber tantos formatos descritos quanto fosse viável. Não comprovou conformidade de produto nem migração automática e sem perda para UTF-8. Sua seção de segurança declarou que o tema não era discutido.

A primazia do código em execução oferece uma disciplina posterior: o documento e os nomes registrados coordenam, mas analisadores, relés, tabelas e fontes produzem a realidade operacional. A especificação inicial mínima, decisão futura localizada e adoção voluntária ajuda a separar o núcleo determinístico—designar, deslocar, limitar octetos e retornar—das escolhas locais de repertório e atualização. Essas ideias posteriores não demonstram a intenção dos autores.

O mérito histórico da RFC 1922 foi recusar duas falsas equivalências: entregar bytes não era entregar texto, e ver uma linha não devia exigir fé em um estado invisível acima dela.