Normalizador Unicode

O que é a normalização Unicode

O Unicode dá muitas vezes mais do que uma maneira de escrever a mesma coisa. A letra é pode ser um único ponto de código, ou pode ser a letra e seguida de um acento agudo de combinação. As duas aparecem iguais e as duas estão correctas, mas são sequências de bytes diferentes: uma comparação ingénua diz que são cadeias diferentes, procurar uma não encontra a outra, e uma base de dados com uma restrição de unicidade aceita ambas sem se queixar.

A normalização é a solução. Reescreve o texto numa de quatro formas definidas para que tudo o que significa o mesmo acabe escrito da mesma maneira. As formas chamam-se NFC, NFD, NFKC e NFKD, e escolher entre elas é a parte que realmente conta.

Os nomes codificam duas decisões independentes. O C é de composta e o D de decomposta: se o é acaba como um ponto de código ou dois. O K, que baralha, é de compatibilidade, e esse é um eixo completamente diferente: controla se caracteres que apenas se parecem são fundidos uns nos outros. Errar no primeiro não custa nada que um leitor consiga ver. Errar no segundo destrói informação.

Como usar

1. Cole qualquer texto na caixa. As quatro formas são calculadas à medida que escreve. Cada uma vem etiquetada como canónica ou de compatibilidade, e assinalada quando difere do que escreveu.
2. Compare as três contagens por baixo de cada forma. As unidades UTF-16 são o que o comprimento de uma cadeia comunica, os pontos de código são o que o Unicode conta, e os caracteres são o que um leitor conta. A mesma palavra pode dar três respostas diferentes, e NFC e NFD discordam nas duas primeiras apesar de significarem o mesmo texto.
3. Veja o que lhe faz o truque de tirar acentos. O painel de baixo corre a receita habitual e mostra, carácter a carácter, que letras foram dobradas para ASCII, quais ficaram intactas e quais desapareceram por completo.

O canónico é seguro, o de compatibilidade não

NFC e NFD são formas canónicas. Reordenam sem mudar o significado: o é como um ponto de código e o é como dois são genuinamente o mesmo carácter, e passar de um para o outro é reversível no sentido que interessa, porque o NFC aplicado à forma decomposta devolve exactamente a composta. Aplicar qualquer uma delas a texto arbitrário é seguro, e o NFC é o que quer quase sempre, porque é o que a web, os nomes de ficheiro e a maioria das bases de dados esperam.

NFKC e NFKD são formas de compatibilidade, e são um tipo de operação diferente com um nome parecido. Fundem caracteres em outros de que apenas se aproximam. O dois em expoente de m² passa a um 2 vulgar, portanto um metro quadrado passa a m2. A ligadura fi passa a duas letras. O numeral romano Ⅳ passa às letras I e V. O símbolo de marca registada passa a TM. A fracção ½ passa a 1⁄2. Os números dentro de círculos passam a algarismos normais, e as letras latinas de largura completa a letras correntes.

Nada disso é um defeito: é precisamente o objectivo. A dobragem de compatibilidade existe para que procurar m2 encontre m², e para que não se possam falsificar identificadores com caracteres parecidos. Mas é de sentido único. Depois de dobrar um expoente num algarismo já não consegue saber se o original era m² ou m2, e se essa distinção transportava significado, perdeu-se. Use as formas de compatibilidade para chaves de comparação e índices de procura; não guarde o que elas produzem como se fosse o texto do utilizador.

A medição por trás disto merece ser dita tal como é. Sobre os 288 767 pontos de código atribuídos, o NFC muda 1120, o NFD muda 13 233, o NFKC muda 4928 e o NFKD muda 17 029. Cada par de formas discorda de qualquer outro algures: o NFC contra o NFKD em 15 930 pontos de código só por si. Um único carácter também pode crescer de forma espectacular: o U+FDFA, uma ligadura árabe, expande-se para dezoito caracteres sob NFKD.

O truque de tirar acentos apaga letras a sério

Procure como tirar acentos de uma cadeia e vai encontrar a mesma receita de três passos em todo o lado: normalizar para NFD, tirar as marcas de combinação e ficar só com ASCII. Funciona lindamente com o exemplo que toda a gente testa. café passa a cafe, naïve passa a naive, e o truque é copiado para outro projecto.

Vale a pena ser preciso sobre onde a coisa se estraga, porque a versão habitual conta ao contrário. O passo de normalizar não apaga rigorosamente nada: medido sobre todas as letras latinas, tirar as marcas de combinação depois do NFD elimina exactamente zero. O estrago é feito pelo filtro ASCII a seguir. Uma letra como ß, ø, ł, đ, ħ, þ ou æ não tem acento nenhum para tirar à partida; sobrevive à normalização completamente intacta, e é depois deitada fora pelo crime de não estar entre o a e o z.

Varrido por todas as 907 letras latinas do Unicode, o NFD seguido desse filtro dobra 540 para ASCII e apaga 367 por completo. Mudar para NFKD melhora pouco: 578 dobradas, 329 apagadas, resgatando 38 letras que o NFD perde por terem decomposição de compatibilidade onde não têm canónica.

Em palavras normais o resultado não é subtil. Straße passa a Strae, que não é Strasse, a transliteração alemã correcta, mas uma palavra a que falta simplesmente uma letra. Łódź passa a odz. Đà Nẵng passa a aNang. E Ærø, uma ilha dinamarquesa, passa à única letra r, porque duas das suas três letras são apagadas e a sobrevivente é um r ASCII que nunca foi tocado. Se precisa de dobrar texto para ASCII, o que precisa é de uma tabela de transliteração e não de uma forma de normalização.

Limites honestos

As quatro formas são calculadas pela implementação da norma do seu próprio navegador, que é a mesma que o seu código vai usar. Esta página não implementa a normalização; mostra-lhe o que a plataforma faz e conta as consequências.

A demonstração do truque dos acentos reproduz o excerto popular de propósito, incluindo os seus intervalos de marcas de combinação. Está ali para mostrar o que aquela receita concreta faz, não para ser o melhor dobrador para ASCII possível: uma ferramenta que usasse em silêncio um algoritmo melhor estaria a discutir com algo que ninguém escreveu.

A normalização não é dobragem de maiúsculas e minúsculas, e por si só não é uma fronteira de segurança. O NFKC é usado como parte da comparação de identificadores em várias normas, mas dobrar por si só não faz com que dois identificadores possam ser tratados como iguais sem risco; os caracteres confundíveis entre alfabetos são outro problema com os seus próprios dados de Unicode, e esta página não o aborda.

Por fim, os números citados acima estão presos a uma versão do Unicode. Foram medidos contra a versão que a biblioteca padrão do Python traz, cruzados com a implementação do seu navegador, e o script que os produziu está guardado ao lado do sítio para que os números possam ser regenerados em vez de acreditados.

Porque é grátis

Porque não custa nada manter. Cada forma é calculada no seu navegador à medida que escreve; nada é enviado, nada é registado e nenhum servidor vê o seu texto.

Nem conta, nem registo, nem nada guardado atrás de um. O comportamento vem do anexo do Unicode que o seu navegador já implementa, e as medições desta página são confrontadas com uma implementação diferente em Python, portanto os números são uma comparação e não uma afirmação.