Guide
O curso de codificação de caracteres é um tutorial interativo de 14 níveis que responde a perguntas que aparecem o tempo todo no desenvolvimento e quase nunca são explicadas com clareza: quantos bytes ocupa um caractere chinês? Por que "😀".length é 2? Para que serve o = no fim do Base64? Quando o texto sai embaralhado, o arquivo quebrou ou dá para salvar? Cada nível traz um texto de teste (que você pode alterar à vontade) e várias visualizações — os bits, os bytes e o ponto de código Unicode de cada caractere, a decomposição do UTF-8 byte a byte, os grupos de 6 bits do Base64, a codificação percentual de URL e "o que aparece se isso for lido como outra codificação" — e o objetivo é ler um número, escrever uma sequência hexadecimal ou digitar um caractere que satisfaça uma condição, com o verificador marcando na hora.
Atualizado em 2026-09-095 sources15 min read
O curso de codificação de caracteres é um tutorial interativo de 14 níveis que responde a perguntas que aparecem o tempo todo no desenvolvimento e quase nunca são explicadas com clareza: quantos bytes ocupa um caractere chinês? Por que "😀".length é 2? Para que serve o = no fim do Base64? Quando o texto sai embaralhado, o arquivo quebrou ou dá para salvar? Cada nível traz um texto de teste (que você pode alterar à vontade) e várias visualizações — os bits, os bytes e o ponto de código Unicode de cada caractere, a decomposição do UTF-8 byte a byte, os grupos de 6 bits do Base64, a codificação percentual de URL e "o que aparece se isso for lido como outra codificação" — e o objetivo é ler um número, escrever uma sequência hexadecimal ou digitar um caractere que satisfaça uma condição, com o verificador marcando na hora.
A ordem do curso é a ordem da história da codificação: bits e bytes → as 128 convenções do ASCII → o Unicode numerando cada caractere → como o UTF-8 transforma o número em 1 a 4 bytes → UTF-16 e o comprimento das strings em JavaScript → o Base64 levando bytes para dentro de texto simples → codificação de URL → e as duas últimas lições só sobre mojibake: como ele surge e como sair do texto embaralhado de volta ao original.
São cerca de 40 minutos. É para desenvolvedores de front-end e back-end, para quem lida com dados e para qualquer pessoa que já tenha travado com mojibake, Base64 ou o comprimento de um emoji; basta saber contar em binário.
%XX; e a de "lido como outra codificação" mostra os mesmos bytes tratados como GBK, Latin-1 ou UTF-16.?lesson=n leva direto a um nível.O curso em si está acima desta página: altere o texto de teste, leia as visualizações e preencha a resposta.
O nível 6, "UTF-8 de dois bytes", usa café como amostra e pede os dois bytes de é:
O nível 14, "reverter o mojibake", mostra 浣犲ソ como o texto aparece quando lido como GBK e pede que você ache o original na caixa de teste:
Caractere Ponto de código Ponto em binário Modelo UTF-8 Bytes
c U+0063 1100011 0xxxxxxx 63
a U+0061 1100001 0xxxxxxx 61
f U+0066 1100110 0xxxxxxx 66
é U+00E9 000 1110 1001 110xxxxx 10xxxxxx C3 A9
→ 11 bits de carga 00011 101001 no modelo → 11000011 10101001
Resposta C3 A9 ✓Texto de teste 中文 bytes UTF-8 E4 B8 AD E6 96 87 lido como GBK → 涓枃
Texto de teste 你好 bytes UTF-8 E4 BD A0 E5 A5 BD lido como GBK → 浣犲ソ ← igual ao enunciado
Resposta 你好 ✓O computador só tem 0 e 1. Um bit é um interruptor; 8 bits formam um byte, capaz de representar valores diferentes. Somar valores posicionais converte binário em decimal: 01000001 = 64 + 1 = 65. Todo texto acaba sendo uma sequência de bytes, e "codificação de caracteres" é uma tabela que diz qual número representa qual caractere — tabelas diferentes são codificações diferentes.
O ASCII, definido em 1963, usava 7 bits para 128 caracteres: 0–31 são caracteres de controle como quebra de linha, tabulação e campainha; 48–57 são os dígitos 0–9; 65–90 são as maiúsculas e 97–122 as minúsculas. A tabela não é arbitrária: maiúsculas e minúsculas diferem em 32 (o 6º bit), então c | 0x20 transforma maiúscula em minúscula, e subtrair 48 de um dígito dá o valor numérico. O hexadecimal é a forma habitual de ler bytes, dois dígitos por byte: 0x48 0x69 = Hi. O ASCII usava só 7 bits e deixava o 8º livre — cada país depois preencheu esse bit do seu jeito (Latin-1, GBK, Shift_JIS…), de forma incompatível entre si, e é aí que está a raiz histórica do mojibake.
O Unicode numera os caracteres do mundo inteiro em um único esquema, chamado ponto de código (code point) e escrito como U+ mais hexadecimal: A é U+0041, 中 é U+4E2D e 😀 é U+1F600. O espaço vai de U+0000 a U+10FFFF, dividido em 17 "planos", com os caracteres de uso corrente quase todos no plano básico (U+0000–U+FFFF) e os emoji e ideogramas raros nos planos suplementares. O ponto essencial: ponto de código é só numeração, e a forma de transformá-lo em bytes é decidida por "formas de codificação" como UTF-8, UTF-16 e UTF-32. "Unicode" não é uma codificação; utf-8 é.
O UTF-8 (RFC 3629) usa de 1 a 4 bytes por ponto de código, e todas as regras estão escritas no prefixo do primeiro byte:
| Faixa de pontos de código | Bytes | Modelo | Bits de carga |
|---|---|---|---|
| U+0000–U+007F | 1 | 0xxxxxxx |
7 |
| U+0080–U+07FF | 2 | 110xxxxx 10xxxxxx |
11 |
| U+0800–U+FFFF | 3 | 1110xxxx 10xxxxxx 10xxxxxx |
16 |
| U+10000–U+10FFFF | 4 | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
21 |
Basta completar o binário do ponto de código com zeros à esquerda até a quantidade de bits de carga e preencher os x em ordem para obter os bytes. é = U+00E9 = 11101001; completado até 11 bits fica 00011 101001, e preenchendo o modelo de dois bytes chega-se a 11000011 10101001 = C3 A9.
Esse desenho traz três vantagens: texto em ASCII codificado em UTF-8 fica byte a byte idêntico (compatibilidade total para trás); todo byte de continuação começa com 10, então dá para achar o início do próximo caractere em qualquer posição do fluxo (autossincronia, e perder um byte não desalinha o resto); e codificações de comprimentos diferentes nunca se sobrepõem, de modo que um byte zero como 00 só representa U+0000 (seguro para strings em C). O preço é que um caractere chinês ocupa 3 bytes, 50% mais que os 2 do GBK — mas inglês, pontuação e código não são afetados, e por isso o UTF-8 é a codificação de mais de 98% das páginas da web.
Os níveis 7 e 8 pedem que você digite um caractere de 3 bytes e depois um de 4 bytes. Este último revela uma armadilha ainda comum: o conjunto de caracteres utf8 do MySQL, na verdade, só vai até 3 bytes, então gravar um emoji dá erro ou trunca, e é obrigatório usar utf8mb4.
.lengthJavaScript, Java, C# e a API do Windows usam UTF-16 internamente: cada unidade de código (code unit) tem 16 bits. Um caractere do plano básico ocupa uma unidade; um ponto de código de plano suplementar é dividido em duas unidades, chamadas par substituto (surrogate pair), nas faixas D800–DBFF e DC00–DFFF. Por isso "😀".length === 2, por isso "😀".split("") corta o emoji em duas metades sem sentido e por isso str[0] devolve o substituto alto. Para contar caracteres de verdade, use [...str].length (iterando por ponto de código); para contar o que a pessoa percebe como "um caractere" (incluindo emoji combinados e acentos), use Intl.Segmenter.
O Base64 (RFC 4648) não é criptografia: é uma forma de transportar bytes quaisquer como 64 caracteres ASCII imprimíveis (A–Z a–z 0–9 + /), para levar binário a lugares que só aceitam texto — anexos de e-mail, campos JSON, URLs data:, JWT. O método é pegar 3 bytes = 24 bits, cortar em 4 grupos de 6 bits () e consultar cada um: Man = 4D 61 6E = 01001101 01100001 01101110 → 010011 010110 000101 101110 → T W F u. O tamanho, portanto, cresce para 4/3 do original.
Quando a quantidade de bytes não é múltipla de 3, o último grupo fica incompleto: falta 1 byte, entra um =; faltam 2, entram dois =, assim o comprimento da saída é sempre múltiplo de 4. O byte único A tem 8 bits, é completado com zeros até 12 e cortado em 010000 01(0000) → QQ, seguido de ==. A variante URL-safe troca + / por - _ (para nada precisar de escape em uma URL) e costuma omitir o =, que o decodificador repõe pelo comprimento.
Em uma URL só uma pequena parte dos caracteres ASCII pode aparecer como está (RFC 3986 §2). Espaço e os caracteres reservados com sentido sintático, como &, =, ? e /, além de todos os caracteres não ASCII, precisam ser escritos como % mais o hexadecimal de cada byte. Então a codificação de URL é UTF-8 primeiro, % byte a byte depois: 中 → E4 B8 AD → %E4%B8%AD, transformando um caractere chinês em nove caracteres. Em JavaScript, encodeURIComponent codifica de forma mais completa (inclusive / ? & =) e serve para um valor de parâmetro; encodeURI preserva os caracteres estruturais e serve para o endereço inteiro. Um formulário enviado como application/x-www-form-urlencoded ainda escreve o espaço como + — convenção histórica dos formulários HTML, e não algo da RFC 3986.
Mojibake não é dado corrompido: é escrever com a codificação A e ler com a codificação B. O 中 em UTF-8 é E4 B8 AD:
ä¸ — uma sequência de letras com acentos é a marca de "UTF-8 lido como codificação ocidental".E4 B8 forma um caractere chinês e AD fica pela metade — "ideogramas estranhos e meio caractere" é a marca de "UTF-8 lido como GBK", e 浣犲ソ e 涓枃 são desse tipo.� (U+FFFD).Enquanto os bytes originais não se perderem, reler com a codificação correta restaura o texto por completo. Por isso a primeira regra para consertar mojibake é guardar o arquivo original e não converter várias vezes: cada conversão pode trocar um byte inválido por ? ou �, e aí sim há perda real de informação. O nível 14 pede uma operação inversa: ler o mojibake 浣犲ソ como GBK para voltar aos bytes E4 BD A0 E5 A5 BD e então ler como UTF-8 para obter 你好. A solução moderna é declarar UTF-8 de forma consistente no cabeçalho HTTP, no <meta charset> do HTML, na conexão do banco e na caixa de salvar arquivo, para que a incompatibilidade não tenha chance de acontecer.
O UTF-16 tem duas ordens de bytes, big-endian e little-endian, e o arquivo costuma começar com uma marca de ordem de bytes (BOM), FE FF ou FF FE. O UTF-8 não tem esse problema, mas o Bloco de Notas do Windows costumava gravar o BOM do UTF-8, EF BB BF, por padrão, o que quebra a primeira linha de um script de shell e coloca um caractere invisível na frente do nome da primeira coluna de um CSV. Se a visualização de decomposição do UTF-8 mostra esses três bytes no começo, você já sabe a origem.
TextDecoder do navegador, e a estrutura interna de GB18030, Big5 e Shift_JIS não é tratada.length é a quantidade de caracteres": em JavaScript é o número de unidades UTF-16, e um emoji ou um ideograma raro conta como 2; já o n de um VARCHAR(n) de banco de dados pode ser bytes ou caracteres, dependendo do banco.encodeURIComponent, senão &, # e espaços quebram a estrutura.Reconhecer %E4%B8%AD%E6%96%87 na hora como dois caracteres chineses em UTF-8; saber desfazer as três partes separadas por ponto de um JWT para chegar ao JSON; e entender por que + e %20 em um parâmetro são tratados como coisas diferentes pelo back-end.
Use o método dos níveis 13–14 para decidir se é "UTF-8 lido como GBK" ou o contrário e, no editor, prefira "reabrir com a codificação" em vez de "converter codificação" — preservar os bytes originais é a primeira regra.
Grave emoji com utf8mb4; ao estimar o armazenamento em UTF-8, conte 3 bytes por caractere chinês; e confirme se o comprimento do VARCHAR é medido em bytes ou em caracteres.
Ao truncar o apelido de um usuário, use [...str].slice(0, n) e não str.slice(0, n), para não cortar um emoji ao meio; e decida se a contagem deve ser em unidades, pontos de código ou agrupamentos de grafemas.
Emoji com modificador de tom de pele ou combinados com caractere de largura zero (ZWJ), como 👍🏽 e 👨👩👧, são formados por vários pontos de código, e a visualização de pontos de código lista todos eles. O nível 8 pede exatamente um caractere de 4 bytes, então use um emoji simples, como 😀.
Nada disso é exigido. c3a9, C3 A9 e c3 a9 são aceitos.
O curso usa o TextDecoder('gbk') embutido no navegador (na prática, um superconjunto do GB18030), que devolve � em sequências inválidas; algumas ferramentas mostram ? ou simplesmente pulam. O glifo muda, o significado não — é sempre "aqui não dá para decodificar".
Se os bytes originais estiverem íntegros e só a leitura estiver errada, sim: reabra o arquivo no editor com a codificação correta. Se o arquivo já passou por "conversões" e mostra muitos ?, essa parte da informação se perdeu e o curso também não a recupera.
No localStorage do navegador atual, sem envio para servidor; o link de "compartilhar este nível" carrega apenas o número do nível, não o progresso.
O curso roda inteiro no navegador: codificação, decodificação, Base64 e codificação de URL do texto de teste são feitos pelo TextEncoder / TextDecoder da própria página e por funções puras, sem envio a servidor nenhum; o progresso fica no localStorage do seu aparelho.
TextDecoder do navegador aceita e os algoritmos de decodificação, a norma por trás dos decodificadores GBK e windows-1252 usados na demonstração de mojibake: https://encoding.spec.whatwg.org/(consultado em 2026-09-09)Atualizado em 2026-09-09
14 níveis para entender bits, bytes, ASCII, pontos de código Unicode, codificação UTF-8 de comprimento variável, grupos Base64, codificação URL e a origem dos caracteres estranhos
Esta ferramenta ainda não está totalmente traduzida; parte do conteúdo usa o idioma de origem ou um idioma de reserva.
ObjetivoO texto de amostra é a letra A, cujo único byte aparece como 01000001. Converta este número binário em decimal e insira-o.
| Caractere | Ponto de código | Bytes UTF-8 | Unidades de código UTF-16 | Número de bytes |
|---|---|---|---|---|
| A | U+0041 | 41 | 0041 | 1 |
Os computadores armazenam apenas 0 e 1. Um bit é uma chave; 8 bits formam um byte, que pode conter de 0 a 255.256 valores. Valores posicionais de somas binárias: 01000001 = 64 + 1 = 65. Todos os textos, imagens e sons são, em última análise, sequências de bytes, e uma "codificação" define qual número significa qual caractere.