Resumo

  • O RFC 2070 separou a codificação externa em bytes de um recurso HTML do conjunto abstrato e fixo de caracteres UCS do documento; o charset de HTTP ou MIME identificava o mapeamento de decodificação.
  • Referências numéricas eram resolvidas no conjunto fixo do documento, preservando a identidade do caractere apesar de mudanças na codificação que transportava a marcação.
  • Decodificar era apenas uma etapa. Análise SGML, idioma e bidirecionalidade, cobertura de fontes, saída de glifos e interpretação pelo leitor continuavam sob responsabilidades distintas.

Considere a letra cirílica maiúscula И. Um recurso pode transportá-la literalmente em uma codificação compatível. Outro pode escrever И. Um terceiro pode armazenar essa referência em uma representação UCS multibyte. Os octetos são diferentes; com o decodificador correto e marcação válida, os três caminhos chegam ao mesmo número de caractere no documento HTML.

Essa era a fronteira decisiva do RFC 2070. Os bytes pertenciam a uma instância concreta do recurso. O número pertencia ao documento abstrato. Se ambos fossem confundidos, alterar apenas a codificação de transporte poderia alterar o sentido de uma referência. O RFC fixou o destino e deixou a variação na porta do decodificador.

O SGML precisava de caracteres antes de reconhecer sintaxe

O HTML ainda era uma aplicação SGML. Seu conjunto de caracteres do documento não era uma lista de bytes permitidos em um arquivo. Era a combinação de um repertório com números usados pelo tipo e pelas instâncias do documento. DTD, marcação e dados eram interpretados no mesmo espaço numerado.

O HTML 2.0 do RFC 1866 incorporava Latin-1 e alinhava suas posições com ISO 10646, apontando para um repertório maior. O RFC 2070 completou esse movimento em seu perfil de internacionalização de HTML 2.x, escolhendo o Universal Character Set de ISO 10646:1993 com emendas. Na data da publicação, o texto o descrevia como idêntico, posição por posição, ao Unicode 1.1.

Ampliar o repertório não tornou todo inteiro válido. A declaração SGML deixava sem uso as posições 128 a 159; portanto, ’ continuava ilegal naquele modelo, ainda que programas posteriores lhe atribuíssem uma aparência tipográfica. “Página Unicode” podia ocultar duas alegações: quais caracteres abstratos o HTML nomeava e qual codificação serializava um recurso específico. O RFC fixou a primeira sem impor uma única codificação à segunda.

charset escolhia a entrada, não redesenhava o destino

A codificação externa vinha do contexto de transporte ou armazenamento. Em HTTP, o parâmetro charset de Content-Type informava a codificação; no correio eletrônico, o parâmetro MIME cumpria a mesma função com regras próprias de omissão. O RFC registrou que FTP e sistemas de arquivos distribuídos ainda não tinham sinal padronizado equivalente.

O nome MIME podia enganar. charset não era apenas um repertório, mas um método de mapear sequências de octetos em sequências de caracteres, inclusive com mais de uma sequência possível para o mesmo resultado. O RFC 2045 exigia que um charset MIME registrado definisse integralmente esse mapeamento, mas não que todos os caracteres abstratos fossem codificáveis no sentido inverso.

O modelo de referência colocava: recurso → decodificador → gerenciador de entidades → analisador SGML → aplicação → exibição. O decodificador passava da representação externa ao conjunto do documento; as etapas seguintes lidavam com caracteres, e a exibição ainda podia convertê-los em representação de dispositivo. Um navegador não precisava conter módulos com esses nomes. Precisava se comportar, para um observador, como se a separação existisse. Era um contrato observável, não um inventário de implementações de 1997.

A referência numérica era estável porque vinha depois

O RFC chamou a invariância das referências numéricas de consequência mais importante do modelo. Elas eram resolvidas no conjunto fixo do documento e, por isso, apontavam para os mesmos caracteres em qualquer codificação externa.

A ordem é indispensável. Primeiro o receptor precisa transformar bytes nos caracteres de marcação &, #, algarismos e ;. Só então o SGML identifica a referência e resolve o número. A referência não conserta uma sequência já decodificada de maneira errada; ela se estabiliza depois de atravessar corretamente a fronteira.

Tampouco há promessa de preservar bytes no caminho inverso. O RFC advertia que até um valor padrão de formulário não editado podia retornar em octetos válidos diferentes dos existentes no documento de origem. Sequências compostas e caracteres pré-compostos também podiam variar representando texto equivalente. Copiar, enviar e salvar abriam novos eventos de codificação, não reproduções forenses do arquivo.

O rótulo de codificação tinha uma hierarquia de evidência

O RFC 2070 reconhecia limitações de 1997: servidores omitiam charset adequado e alguns navegadores tratavam mal um Content-Type que o incluísse. Isso é observação histórica, não medição do mercado atual.

A preferência era pelo charset recebido da origem, depois por um META HTTP-EQUIV inicial e, por fim, pelo CHARSET consultivo de um link. META enfrentava um problema de arranque: só podia ser encontrado se os bytes anteriores fossem decodificados suficientemente bem. O RFC o chamou de método não infalível e restringiu sua utilidade a codificações cujo início preservasse adequadamente os valores ASCII.

A ordem distinguia autoridade de disponibilidade. Uma dica próxima podia aparecer primeiro sem ganhar a autoridade dos metadados de resposta. E um rótulo autoritativo continuava sendo uma afirmação: não provava que o corpo obedecia ao mapeamento nem que o decodificador o implementava corretamente.

Um caractere decodificado ainda podia desaparecer na tela

UCS ampliava o que o HTML podia identificar, mas não criava fontes. O RFC previa caracteres analisáveis que o sistema não conseguiria mostrar e não impunha uma única reação. Um símbolo de glifo ausente ou um número hexadecimal era política de apresentação, não uma nova identidade de caractere.

Idioma e direção acrescentavam outros estados. LANG podia afetar glifos, aspas, hifenização, ligaturas, espaçamento e fala. DIR, BDO e o algoritmo bidirecional Unicode podiam alterar a ordem visual necessária à leitura. Atuavam sobre caracteres já identificados; não redefiniam os bytes externos.

Assim, havia relatórios de falha diferentes: sinal de codificação incorreto, resultado errado do decodificador, árvore de análise errada ou rejeitada e ausência de fonte ou tratamento ruim de idioma e direção. Uma captura de tela não localiza a primeira falha. Um hash íntegro dos bytes não demonstra sucesso posterior.

A fronteira sobreviveu à mudança de autoridade editorial

Quando a especificação de HTML passou ao W3C, o RFC 2854 tornou obsoletos o RFC 2070 e documentos HTML anteriores do IETF. Isso descreve governança e sucessão documental, não o desaparecimento da fronteira. O registro posterior de text/html ainda definia charset como a codificação usada para representar um documento HTML em bytes; o HTML 4.01 igualmente dizia que o conjunto do documento não bastava para interpretar uma sequência trocada.

A distinção posterior de Lu Heng entre especificação inicial mínima, decisões futuras locais e adoção voluntária oferece uma lente retrospectiva. O espaço fixo de números era uma invariável compartilhada. Decodificadores, tratamento de erro, fontes e apresentação continuavam decisões locais de implementação. Publicar a regra não executava essas decisões.

A lição operacional permanece: receber os bytes não constitui o documento, e resolver o número não produz o glifo. Cada transição requer sua própria evidência; nenhuma etapa amplia sua autoridade pegando emprestado o recibo da anterior.

Fontes