Conversor de Normalização Unicode | Vista paralela das quatro formas

Cole qualquer string e veja a normalização simultânea para NFC, NFD, NFKC e NFKD, com a contagem de caracteres, os bytes UTF-8 e a diferença de bytes em relação ao original para cada forma. A ferramenta é pensada para times de backend, donos de índices de busca e devs i18n que precisam ver exatamente o que cada normalização faz com uma string problemática antes de fechar a correção.

💡 Sobre esta ferramenta

Normalização Unicode existe porque o mesmo caractere "visível" pode ser escrito como sequências diferentes de bytes. O é pode ser um único code point U+00E9 (forma pré-composta) ou dois code points, e (U+0065) mais um acento agudo combinante (U+0301) (forma decomposta). As duas renderizam idênticas em qualquer fonte moderna, mas === no JavaScript, WHERE no SQL e equals() no Java os tratam como diferentes. Essa é a causa real da maioria dos bugs do tipo "o nome está no banco mas a query não acha".

A ferramenta pega o seu texto, passa por String.prototype.normalize() nas quatro formas oficiais do padrão Unicode, e mostra o resultado em paralelo: a string normalizada, o número de caracteres (contados como code points perceptíveis pelo usuário), o tamanho em bytes UTF-8 e a variação em relação à entrada. O indicador "forma de entrada" também detecta a qual forma o seu texto já pertence, o que evita conversão desnecessária quando a origem já está conforme.

NFKC e NFKD são as decomposições de compatibilidade: transformam latinas de largura completa em ASCII, expandem ligaduras tipográficas (fi → fi) e reescrevem números em círculo (① → 1). É exatamente o que você quer para uma chave de busca ou um hash de deduplicação, e exatamente o que você não quer para armazenar o nome próprio canônico de uma pessoa.

🧐 Perguntas frequentes

Q. Qual forma devo usar para armazenar texto? A. NFC, na quase totalidade dos casos. O W3C, no documento "Character Model for the World Wide Web" (Charmod-Norm), recomenda NFC para HTML, URLs, atributos do DOM e qualquer texto que atravesse uma fronteira de processo. NFD continua útil como representação intermediária (por exemplo, para tirar acentos antes de uma busca aproximada), mas a forma canônica de armazenamento deve ser NFC.

Q. É verdade que o macOS guarda os nomes de arquivo em NFD? A. Era verdade no HFS+, que usava uma variante específica chamada "NFD with reserved range". O APFS, o sistema de arquivos padrão desde o macOS High Sierra, não normaliza mais: grava exatamente os bytes que a aplicação fornece. Portanto "macOS = NFD" é uma meia verdade. Mas arquivos vindos de um Time Machine antigo, de um rsync histórico ou de um HD externo formatado em HFS+ ainda chegam em NFD e quebram comparações no Linux. Esta ferramenta serve justamente para confirmar em qual forma o texto realmente está, sem depender de suposições.

Q. Quando usar NFKC em vez de NFC? A. Para construir chaves de busca ou hashes de comparação onde a tipografia não importa. A Wikipédia normaliza títulos com NFKC + casefold(), mecanismos full-text como Elasticsearch normalizam na indexação, e sistemas de autenticação aplicam NFKC para evitar o ataque homográfico (Admin latino contra Аdmin cirílico). Regra prática: NFKC para a chave, NFC para o valor.

Q. Qual a diferença entre canônica (NFC/NFD) e compatibilidade (NFKC/NFKD)? A. As normalizações canônicas são reversíveis: NFC(NFD(s)) === s para qualquer string Unicode bem formada. Não perdem nem alteram informação. As de compatibilidade descartam distinções tipográficas que o padrão considera "secundárias": largura completa contra meia largura, sobrescritos contra base, ligaduras contra caracteres separados. Se for aplicar NFKC, faça na chave de busca, nunca no texto que o usuário verá.

Q. Por que alguns caracteres têm dois bytes em NFC e três em NFD? A. Porque a forma decomposta usa mais code points, e cada code point ocupa entre 1 e 4 bytes em UTF-8. Um á pré-composto é U+00E1 (2 bytes em UTF-8). O mesmo á decomposto é U+0061 (1 byte) mais U+0301 (2 bytes), total de 3 bytes. A coluna "delta" da tabela reflete diretamente essa diferença.

Q. O que acontece com os emojis? A. Emojis compostos (família, bandeiras, modificadores de tom de pele) são sequências ZWJ ou pares de indicadores regionais, não code points únicos, então nenhuma das quatro normalizações os modifica. O que muda com NFKC são caracteres matemáticos decorativos (𝒜, 𝓗) que viram latim comum — útil para deduplicação, péssimo se você os armazena como nome de marca.

Q. Funciona com textos grandes? A. Sim. normalize() é nativo do motor JavaScript (ICU por baixo) e processa megabytes em milissegundos. O gargalo costuma ser o textarea do navegador, não a normalização em si. Para depurar logs muito grandes, recorte uma amostra representativa para usar como entrada.

📚 Curiosidades

Uma decisão técnica surpreendentemente importante da história recente da web foi como o IDN (Internationalized Domain Names) tratou a normalização de compatibilidade. A primeira versão do padrão, IDNA2003, exigia a aplicação de NFKC e casefolding a todo nome de domínio (processo chamado "Nameprep"). Isso significava que ①.example resolvia literalmente para 1.example, e a maioria dos caracteres parecidos com ASCII colapsava entre si. Resultou em um desastre de segurança: ataques de homógrafo se tornaram triviais. A revisão IDNA2008 aboliu o Nameprep, exigindo que os nomes de host sejam armazenados em NFC e rejeitando qualquer rótulo que NFKC tivesse modificado. A barra de endereços do navegador é hoje uma das poucas superfícies de software que explicitamente proíbe a normalização de compatibilidade.

No português do Brasil, o caso clássico aparece com nomes de família portugueses ou africanos: Gonçalves, São, Nazaré, José. Muitos dumps antigos vindos de servidores Mac ou de exportações Latin-1 → UTF-8 mal feitas chegam em NFD, e a consulta WHERE nome ILIKE '%São%' retorna zero linhas mesmo com o valor visível na tabela. A solução padrão é passar a string de busca e os dados pela mesma forma (NFC, na prática) antes de comparar — e é exatamente isso que este conversor ajuda a confirmar em alguns segundos antes de você decidir reescrever a migração.