Resumo

  • O RFC 3536 distinguiu octetos codificados, caracteres abstratos, sistemas de escrita, idiomas e glifos escolhidos pelo renderizador; o êxito de uma camada não certificava a seguinte.
  • O glossário de 2003 era Informativo, não normativo e incompleto, e foi substituído pelo RFC 6365 em 2011. Sua lição continua útil: uma forma legível comprova renderização, não idioma nem significado.

Um cadastro brasileiro recebe o nome de um fornecedor estrangeiro. Na interface, cada sinal parece nítido e a equipe encerra o chamado como “sem problema de Unicode”. Mas aquela mesma imagem poderia vir de uma etiqueta de charset incorreta, de uma normalização silenciosa ou de uma fonte substituta. O monitor prova apenas que um mecanismo encontrou contornos para desenhar. Não revela a história do texto.

Publicado em maio de 2003, o RFC 3536 chamava-se Terminology Used in Internationalization in the IETF. Não era uma codificação nem um perfil de conformidade. Era um glossário Informativo, criado porque discussões técnicas estavam misturando conceitos vizinhos. O documento avisa que as definições não são normativas, a lista não é completa e nem todos concordavam, sobretudo quanto a “idioma”. A captura atual da página de erratas não lista nenhuma; isso não transforma uma terminologia assumidamente provisória em ontologia final.

Na rede, o ponto inicial são bits e octetos. Um charset explica como os octetos se tornam caracteres abstratos: reúne um conjunto codificado e um esquema de codificação sob um nome registrado na IANA. O UTF-8 do RFC 3629 resolve essa transformação. O rótulo não informa se a frase é português, árabe ou japonês, não confirma a gramática e não atesta o que alguém entendeu.

O caractere também não é seu desenho. Ele é um elemento abstrato reconhecido por nome e propriedades; o glifo é uma forma renderizada. Fonte, contexto e regras de composição influenciam a seleção. Um caractere pode assumir várias formas, e sequências distintas podem parecer iguais. A observação “está bonito” pertence à saída e não permite reconstruir, sem outras provas, os octetos de entrada.

Escrita e idioma mantêm relações de muitos para muitos. Uma escrita atende várias línguas; uma língua pode usar mais de uma escrita. Detectar script ajuda na composição, mas não identifica o idioma. O RFC 3066 e, depois, o RFC 5646 definiram etiquetas de língua como metadado separado. Mesmo uma etiqueta sintaticamente válida pode ter sido inferida ou aplicada de modo errado; não garante fluência nem compreensão.

O RFC 2277 já localizava o objetivo nas pessoas: protocolos não possuem língua natural, mas carregam cadeias destinadas a usuários. Aceitar octetos além de ASCII é só o início. Entrada, armazenamento, comparação, busca, ordenação, apresentação visual, fala, tato e uso humano são transições independentes.

A normalização mostra por que a aparência engana. Unicode admite sequências diferentes que são canonicamente equivalentes. O Unicode Standard Annex #15 define formas de normalização, e o RFC 5198 acrescentou um formato para intercâmbio em rede. A obrigação destacada pelo RFC 3536 é dizer onde a normalização ocorre. Se cada componente decidir sozinho, textos visualmente iguais podem virar chaves diferentes, ou registros distintos podem ser unidos sem trilha de auditoria.

Esse recorte não repete o artigo sobre o RFC 5137. Aquele texto trata de escapes Unicode, identificadores normalizados e ambiguidade entre contas. Este acompanha a cadeia mais ampla: octetos viram caracteres, recebem contexto de escrita e idioma e chegam a um glifo. Política de identificador é apenas uma aplicação possível.

Ordenação também tem camada própria. Colação depende de idioma e convenção e, em geral, não coincide com a ordem numérica dos pontos de código. Comunidades que usam a mesma escrita podem esperar índices diferentes. Um banco pode terminar sua consulta de modo determinístico e ainda oferecer uma lista inadequada. “Sort executado” não comprova “ordem certa para o leitor”.

Em texto bidirecional, ordem em memória e ordem visível divergem. Uma captura de tela não recompõe necessariamente a sequência; movimento do cursor, cópia ou leitura por voz podem expor outra estrutura. E renderização, no RFC 3536, inclui saídas visuais, audíveis e táteis. Uma tela correta pode coexistir com pronúncia errada e braile inútil.

A posição histórica precisa ser preservada. O RFC 3536 nunca foi Internet Standard. Em setembro de 2011, o RFC 6365 saiu como BCP 166 após consenso e revisão pública do IETF e o tornou obsoleto. O RFC 7997 alterou depois a política de caracteres não ASCII nos próprios RFCs. São avanços posteriores, não validação retroativa de toda definição de 2003.

A seção de segurança do RFC 3536 diz que segurança não é discutida. Não cabe atribuir-lhe um modelo de ameaças atual. É possível estudar hoje riscos de codificação, direção e formas confundíveis, mas a conclusão histórica segura é outra: apagar limites entre dado codificado, texto abstrato, idioma e apresentação destrói a auditabilidade.

Uma cadeia completa guarda octetos e charset; registra decodificação e validação; nomeia forma e ponto de normalização; conserva etiqueta de idioma e procedência; separa scripts e direções; anota motor, fonte solicitada e fallback; testa visual, voz e tato; declara a colação; e consulta o público que deve entender. O glifo fecha apenas uma dessas passagens.

Fontes