Informações Unicode

O que é Unicode?

Unicode é o padrão que dá um número único a cada caractere existente, seja de qualquer idioma, símbolo, emoji ou ideograma. Esse número é o code point (por exemplo, U+1F600 corresponde a 😀).

Na codificação UTF-8, cada code point ocupa de 1 a 4 bytes. O ASCII, que vai de U+0000 a U+007F, usa apenas 1 byte; já um emoji costuma consumir 4 bytes.

Roda inteiramente no navegador.

Entendendo o Unicode: do code point aos bytes em disco

Unicode é o padrão universal de codificação de caracteres mantido pelo Unicode Consortium, criado para suportar o intercâmbio, o processamento e a exibição de toda língua escrita moderna, além de uma grande quantidade de scripts históricos, notações matemáticas, símbolos técnicos e emojis. A versão 1.0 foi publicada em 1991 como resposta ao caos das dezenas de páginas de código de 8 bits incompatíveis entre si (Windows-1252, ISO-8859-1, Shift_JIS, Big5, KOI8-R etc.), em que o mesmo byte 0xE9 podia significar "é" no Latin-1, um caractere katakana no Shift_JIS ou um byte de controle em outro lugar. A promessa do Unicode era simples: um número, chamado code point, para cada caractere existente no planeta.

Um code point Unicode é escrito como U+ seguido de quatro a seis dígitos hexadecimais. O espaço total vai de U+0000 até U+10FFFF, totalizando 1.114.112 code points teóricos. Desses, 2.048 são surrogates (usados apenas pelo UTF-16), 66 são não-caracteres e 137.468 são Private Use Area, sobrando cerca de 974.530 para atribuição pública. Até o Unicode 16.0 (setembro de 2024) e o 17.0 em preparação, mais de 154.000 caracteres de 168 sistemas de escrita foram atribuídos, incluindo emojis, cuneiforme antigo, hieróglifos egípcios e ideogramas modernos do chinês, japonês e coreano.

Planos e blocos: como 1,1 milhão de posições são organizadas

O espaço Unicode é dividido em 17 planos de 65.536 code points cada, numerados de 0 a 16. Cada plano é subdividido em blocos nomeados de tamanho variável (de 16 até 65.536 code points).

• Plano 0 — BMP (Basic Multilingual Plane), U+0000–U+FFFF: caracteres de praticamente toda língua moderna — latim, cirílico, grego, árabe, hebraico, devanágari, tailandês e os ideogramas CJK mais comuns (URO) — além de pontuação, símbolos monetários e setas.
• Plano 1 — SMP (Supplementary Multilingual Plane), U+10000–U+1FFFF: scripts históricos (Linear B, itálico antigo, fenício, gótico), notação musical, alfanuméricos matemáticos e — crucial para apps modernos — quase todos os emojis. O rosto sorridente 😀 é U+1F600.
• Plano 2 — SIP (Supplementary Ideographic Plane), U+20000–U+2FFFF: ideogramas CJK raros, ausentes em padrões nacionais anteriores.
• Plano 3 — TIP (Tertiary Ideographic Plane): escrita em ossos oraculares e ideogramas CJK adicionais.
• Planos 4–13: ainda não atribuídos, reservados para scripts futuros.
• Plano 14 — SSP (Supplementary Special-purpose Plane): caracteres "tag" e seletores de variação.
• Planos 15–16 — Private Use Areas (PUA): nunca atribuídos pelo Unicode; reservados para símbolos específicos da aplicação (fontes de ícones, sistemas internos).

Codificações: UTF-8, UTF-16, UTF-32

Um code point é um inteiro abstrato; a codificação é a regra que o transforma em bytes reais. O aviso clássico de Joel Spolsky continua valendo: "não existe isso de texto puro" — você não pode interpretar uma string sem saber a codificação.

• UTF-8 (definido pela RFC 3629): largura variável, 1 a 4 bytes por code point. ASCII (U+0000–U+007F) ocupa 1 byte, então texto em inglês é byte-a-byte idêntico ao ASCII legado. É dominante na web (~98% das páginas) e padrão em Linux, macOS, JSON, XML e HTML5.
• UTF-16: 2 ou 4 bytes. Caracteres do BMP cabem em uma única unidade de 16 bits; caracteres suplementares exigem um par de surrogates (high surrogate em D800–DBFF + low surrogate em DC00–DFFF). É a representação interna de strings em Java, JavaScript, .NET e nas APIs do Windows.
• UTF-32: 4 bytes fixos por code point. Indexação trivial, mas desperdício de memória; raramente usado para armazenamento, às vezes internamente.

U+0041 "A"   UTF-8: 41           UTF-16: 0041        UTF-32: 00000041
U+00E9 "é"   UTF-8: C3 A9        UTF-16: 00E9        UTF-32: 000000E9
U+20AC "€"   UTF-8: E2 82 AC     UTF-16: 20AC        UTF-32: 000020AC
U+1F600 "😀"  UTF-8: F0 9F 98 80  UTF-16: D83D DE00   UTF-32: 0001F600

Categorias gerais e propriedades

Todo code point Unicode tem uma propriedade General Category — um código de duas letras cuja primeira letra é uma das sete classes principais:

• L — Letter (Lu maiúscula, Ll minúscula, Lt titlecase, Lm modificadora, Lo outra).
• M — Mark (Mn não-espaçada, Mc espaçada combinante, Me envolvente) — acentos, marcas vocálicas.
• N — Number (Nd dígito decimal, Nl letra, No outro).
• P — Punctuation (Pc, Pd, Ps, Pe, Pi, Pf, Po).
• S — Symbol (Sm matemático, Sc moeda, Sk modificador, So outro — os emojis vivem aqui).
• Z — Separator (Zs espaço, Zl linha, Zp parágrafo).
• C — Other (Cc controle, Cf formatação, Cs surrogate, Co private use, Cn não atribuído).

Normalização: NFC, NFD, NFKC, NFKD

Muitos caracteres podem ser escritos de mais de uma forma. A letra "é" pode ser um único code point pré-composto U+00E9 ou "e" + acento agudo combinante (U+0065 + U+0301). São visualmente idênticos, mas sequências de bytes diferentes — e isso quebra comparações ingênuas. O Unicode define quatro formas de normalização:

• NFC — composição canônica (pré-composta). Recomendada para armazenamento e para a web.
• NFD — decomposição canônica (base + marcas combinantes). Útil para buscas insensíveis a acentos.
• NFKC / NFKD — formas de compatibilidade, que também unificam variantes visualmente similares (fi → fi, ㈱ → (株)). Perdem informação, mas ajudam em comparações de segurança.

Emojis e sequências ZWJ

Emojis modernos nem sempre são um único code point. Muitos são sequências ZWJ: emojis-base unidos pelo Zero-Width Joiner U+200D, opcionalmente com modificadores de tom de pele (Fitzpatrick) ou seletores de variação. A família 👨‍👩‍👧 é a junção de quatro code points:

👨‍👩‍👧 = U+1F468 (homem) + U+200D (ZWJ) + U+1F469 (mulher) + U+200D (ZWJ) + U+1F467 (menina)
       = 5 code points, 17 bytes em UTF-8, 1 "caractere" visível

A unidade visível para o usuário chama-se extended grapheme cluster e é definida pelo Unicode Standard Annex #29. Movimentação do cursor, seleção e o "comprimento" visual de uma string devem operar sobre grapheme clusters — não sobre bytes, não sobre code units e geralmente nem mesmo sobre code points.

Armadilhas para devs

• Bytes ≠ code points ≠ caracteres. "😀".length em JavaScript é 2 (unidades UTF-16), não 1.
• Regex: . casa uma code unit por padrão. Use a flag u em JS e considere \p{L} para classes Unicode-aware.
• Ordenação: ordem de bytes não é ordem alfabética. Use colação sensível a locale (ICU, Intl.Collator).
• Fatiar strings por índice pode partir um par de surrogates ou um grapheme cluster, produzindo saída inválida e glitches visuais.
• VARCHAR(n) em banco: verifique se n conta bytes ou caracteres; o velho utf8 do MySQL é UTF-8 truncado em 3 bytes e não armazena emojis — use utf8mb4.
• Ataques homográficos: o "а" cirílico (U+0430) é idêntico ao "a" latino (U+0061). Normalize e compare domínios com regras IDNA.

FAQ

Quantos caracteres tem o Unicode? Cerca de 154.000 atribuídos até o Unicode 16.0, dos 1.114.112 code points teóricos.

Por que meu emoji vira "??" ou quadradinho? Ou o sistema de destino não tem fonte com aquele glifo, ou o texto passou por uma camada não-UTF-8 que cortou os bytes altos.

UTF-8 é sempre melhor que UTF-16? Para texto ocidental e para a web, sim. Para texto majoritariamente CJK em memória, UTF-16 pode ficar levemente menor — é por isso que Java e Windows o mantiveram.

O que é um BOM? Um Byte Order Mark (U+FEFF) sinaliza endianness de UTF-16/32. BOMs em UTF-8 são legais, porém desencorajados porque confundem ferramentas Unix.

Onde está a referência autoritativa? O Unicode Consortium publica o padrão completo, as code charts e o Unicode Character Database (UCD) em unicode.org.