RFC 9839 e o Unicode problemático

• RFC 9839 define claramente os caracteres Unicode problemáticos que podem aparecer em campos de texto no desenvolvimento de software
• Este RFC trata dos problemas causados pela falta de consistência no tratamento desses caracteres em diferentes linguagens e bibliotecas
• A 9839 propõe três subconjuntos menos problemáticos, que podem ser usados opcionalmente
• Em comparação com o framework PRECIS existente, sua aplicação é mais fácil e simples
• Uma biblioteca em Go para RFC 9839 também foi publicada, ajudando no uso prático

---

Contexto e visão geral da RFC 9839

• O Unicode é usado como padrão em quase todo o processamento de dados textuais
• Porém, ao projetar estruturas de dados ou protocolos reais, permitir todos os caracteres Unicode pode causar problemas
• Paul Hoffman e o autor enviaram um rascunho individual ao IETF para apresentar critérios claros sobre problemas recorrentes com Unicode
• Após dois anos de discussão, ele foi adotado como padrão oficial e publicado como RFC 9839
• Este documento explica em detalhes os tipos de caracteres problemáticos, por que eles causam problemas (por razões técnicas e normativas) e três subconjuntos que os usuários podem escolher conforme a necessidade

Principais pontos da RFC 9839

• É um documento de referência essencial no projeto de campos de texto em ambientes de software e rede
• A RFC 9839 tem 10 páginas, sendo relativamente concisa para um padrão do IETF
• Foi escrita de forma acessível, voltada principalmente a desenvolvedores de software e engenheiros de redes

Exemplos de caracteres Unicode problemáticos

• Por exemplo, uma string como a seguinte pode aparecer no campo username de um JSON

  {  
      "username": "\u0000\u0089\uDEAD\uD9BF\uDFFF"  
  }  
  

• Problemas de cada ponto de código
  • U+0000 : caractere NULL sem significado, que atrapalha o funcionamento de algumas linguagens de programação
  • U+0089 : código de controle C1 (CHARACTER TABULATION WITH JUSTIFICATION), cujo comportamento é complexo e inconsistente
  • U+DEAD : caractere surrogate não pareado, um problema que decorre das limitações do UTF-16. Isso gera dados indesejáveis
  • \uD9BF\uDFFF (na prática U+7FFFF) : Noncharacter, cuja troca é proibida pelo padrão
• Pontos de código como esses impossibilitam um tratamento consistente em estruturas de dados e protocolos, além de causar erros inesperados
• A RFC 9839 define formalmente esses caracteres problemáticos e indica claramente quais tipos devem ser excluídos

O projeto do JSON e suas limitações

• Não é responsabilidade do criador do JSON, Doug Crockford
• O formato foi projetado numa época em que o Unicode ainda não estava suficientemente maduro, então não foi possível restringir rigorosamente o conjunto de caracteres
• Como o padrão já não pode ser alterado, é necessário excluir empiricamente os caracteres problemáticos

Diferenças em relação ao framework PRECIS do IETF

• Mesmo antes da RFC 9839 de 2025, o IETF já oferecia vários padrões, como o RFC 8264 (PRECIS Framework)
  • Esse framework trata em detalhes de como preparar, aplicar e comparar strings internacionalizadas
  • Com 43 páginas, ele é abrangente tanto na explicação do contexto quanto nas soluções
• O PRECIS depende fortemente da versão do Unicode, além de ser complexo e difícil de aplicar
• A RFC 9839 é concisa e focada na praticidade, facilitando adoção rápida na definição de novos protocolos

Subconjuntos da RFC 9839 e exemplos de uso

• A 9839 apresenta três subconjuntos práticos: scalars, XML e assignables
• Cada subconjunto varia ligeiramente na faixa de caracteres problemáticos que exclui
• A seguir, um resumo de como os principais formatos de dados e os subconjuntos da RFC 9839 tratam caracteres problemáticos
  • Alguns formatos como CBOR, TOML, XML e YAML excluem parcialmente surrogates ou caracteres de controle
  • I-JSON exclui surrogates e noncharacters
  • JSON comum e Protobufs não os excluem
  • XML e YAML, por suas características de charset, excluem apenas parcialmente noncharacters/códigos de controle
    • Observação: XML e YAML não excluem noncharacters fora do Basic Multilingual Pane

Biblioteca RFC 9839 para Go

• Foi publicada uma pequena biblioteca em Go que oferece validação de caracteres para os três subconjuntos da RFC 9839
• Ela já foi suficientemente testada, embora a otimização ainda esteja em andamento
• Testes e feedback em uso real são bem-vindos

A importância da RFC 9839 e o processo de trabalho

• A RFC 9839 foi publicada oficialmente após mais de 15 revisões de rascunho, com feedback repetido dos coautores
• Graças às discussões e contribuições de muitos especialistas da comunidade, ela evoluiu para um documento muito mais completo do que a versão inicial
• Os colaboradores são mencionados na seção “Acknowledgements”

A experiência de uma submissão individual de RFC

• A RFC 9839 foi conduzida como submissão individual (individual submission)
• Em comparação com o método tradicional via Working Group, isso envolve maior esforço e carga processual
• Comparando com a experiência de participar de um Working Group, o método tradicional é mais eficiente e recomendável