Unicode

Unicode é o padrão universal de codificação de caracteres mantido pelo Consórcio Unicode. Ele atribui um número único (um “ponto de código”) a cada caractere em cada sistema de escrita que foi formalmente proposto e aceito — atualmente cerca de 150.000 caracteres em 161 scripts, incluindo idiomas modernos, scripts históricos, símbolos matemáticos, notação técnica e emoji.

Os pontos de código são escritos como U+XXXX (4-6 dígitos hex). A letra A é U+0041; o i sem ponto turco é U+0131; o emoji de foguete é U+1F680.

O Unicode em si não especifica como os pontos de código são serializados em bytes — esse é o trabalho das codificações. As três principais codificações:

• UTF-8 — largura variável de 1-4 bytes por ponto de código. Compatível com ASCII. A codificação web dominante.
• UTF-16 — 2 ou 4 bytes por ponto de código. Usado internamente pelo Java, strings JavaScript e Windows.
• UTF-32 — exatamente 4 bytes por ponto de código. Simples, mas desperdiçador; raramente usado para armazenamento.

As ferramentas do Convertitive lidam com Unicode completo onde devem — o codificador Base64 lida com UTF-8 corretamente, o contador de palavras conta pontos de código e grafemas, o conversor de caso respeita a capitalização específica do turco (o problema do I com e sem ponto).

Ponto de código ≠ caractere ≠ grafema — a distinção que quebra toda biblioteca de strings: a letra “é” pode ser representada de duas formas em Unicode — como o único ponto de código U+00E9 (pré-composto) ou como U+0065 (e) seguido de U+0301 (acento agudo combinante). Ambos renderizam identicamente; ambos contam como “um caractere” para um humano; um é um ponto de código, o outro são dois. Emoji são piores: 👨‍👩‍👧 (família) é uma sequência ZWJ de sete pontos de código, mas um grafema. Contagens de comprimento em JavaScript (str.length) retornam unidades de código UTF-16, não grafemas — o emoji de família tem um comprimento de string de 11. Use Intl.Segmenter (navegadores modernos, Node 16+) para contagens precisas de grafemas.

Formas de normalização Unicode — quando o texto não corresponde a si mesmo: duas strings visualmente idênticas podem ter representações de bytes diferentes por causa da divisão pré-composto vs. decomposto acima. O Padrão Unicode define quatro formas de normalização (NFC, NFD, NFKC, NFKD) que canonicalizam isso. NFC (composto) é o padrão para HTML e a maioria dos sistemas de arquivos; NFD (decomposto) é o padrão do macOS HFS+ e a razão pela qual os caminhos de arquivo às vezes parecem idênticos mas comparam desiguais entre sistemas. Pesquisas de igualdade de strings em banco de dados e pesquisas em índice de busca devem normalizar para NFC na escrita para evitar o bug de “consulta idêntica não encontra correspondência”. Referência: O Padrão Unicode, Versão 15.

Exemplo prático

Pegue a string “café”. Duas representações Unicode igualmente válidas: NFC = U+0063 U+0061 U+0066 U+00E9 (4 pontos de código), NFD = U+0063 U+0061 U+0066 U+0065 U+0301 (5 pontos de código, “e” + acento agudo combinante). Ambos renderizam identicamente. Agora considere como cada um parece em diferentes contagens: em UTF-8, NFC tem 5 bytes (63 61 66 C3 A9); NFD tem 6 bytes (63 61 66 65 CC 81). Em JavaScript: "café".length = 4 para NFC, 5 para NFD. Compare a igualdade sem normalizar: nfc === nfd é false. Execute ambos através de String.prototype.normalize("NFC") primeiro: eles se tornam idênticos. Bug corrigido. Esta é a causa raiz exata do “pesquisei por José e o registro existe mas não aparece” em bancos de dados que armazenam nomes enviados por usuários de clientes Mac e Windows misturados.

Quando e por que isso importa

Todo aplicativo internacionalizado encontra casos extremos de Unicode em algum momento: nomes de usuário com marcas combinantes, caminhos de arquivo copiados entre macOS (NFD) e Linux (NFC), vietnamita com diacríticos empilhados, regras de capitalização turca (minúscula de “I” é “ı” e não “i” — o “problema do I turco” causou falhas reais no iOS em 2018), renderização da direita para a esquerda em árabe e hebraico, e emoji baseados em ZWJ cujos pontos de código componentes evoluem mais rápido do que a fonte do seu telefone. As regras defensivas: normalize para NFC na entrada, use Intl.Collator para classificação com reconhecimento de locale (não o sort de ponto de código do Array.sort), use Intl.Segmenter para truncamento com reconhecimento de grafemas, e deixe o CLDR (banco de dados de localidade do Unicode) orientar o comportamento específico de localidade em vez de regras codificadas. Referência: Relatório Técnico Unicode #15 — Formas de Normalização.