Contador de bytes

Como funciona

1. Insira ou cole o texto: Digite ou cole qualquer texto no campo de entrada.
2. Veja a contagem de bytes: A ferramenta mostra instantaneamente a contagem de bytes em UTF-8, UTF-16, ASCII e outras codificações lado a lado.
3. Verifique os limites: Compare a contagem de bytes com os limites comuns (SMS: 160 caracteres, cabeçalhos HTTP: 8 KB, campos de banco de dados, etc.) para ver se seu conteúdo cabe.

Por que usar o contador de bytes?

A contagem de caracteres e a contagem de bytes não são a mesma coisa. Um único emoji pode ter 4 bytes em UTF-8. Caracteres chineses e árabes ocupam 2-3 bytes cada. Muitos sistemas impõem limites de bytes, não limites de caracteres - incluindo campos VARCHAR do MySQL, valores do Redis, cabeçalhos HTTP, mensagens SMS e nomes de objetos de armazenamento em nuvem. O contador de bytes revela o tamanho real em bytes do seu texto em cada codificação para que você possa ficar dentro das restrições do sistema.

Recursos

• Múltiplos tamanhos de codificação: Mostra a contagem de bytes para UTF-8, UTF-16 LE/BE, UTF-32 e Latin-1.
• Detalhamento de caracteres: Conta separadamente o total de caracteres, pontos de código Unicode e caracteres multibyte.
• Predefinições de limites comuns: Compare com SMS (160), tweet (280), meta description (160), limites de VARCHAR do MySQL e muito mais.
• Atualizações ao vivo: A contagem de bytes é atualizada em tempo real enquanto você digita.
• Comparação de codificações: Veja qual codificação é mais compacta para seu texto específico.

Perguntas frequentes

Por que minha contagem de bytes é maior que a contagem de caracteres?

Muitos caracteres ocupam mais de 1 byte em UTF-8. Caracteres ASCII (A-Z, 0-9, pontuação) têm 1 byte cada. Caracteres latinos estendidos (letras acentuadas) têm 2 bytes. Caracteres chineses, japoneses, coreanos e árabes geralmente têm 3 bytes. Emojis normalmente têm 4 bytes.

Qual codificação a maioria dos sistemas web usa?

UTF-8 é a codificação dominante para conteúdo web, APIs, JSON e bancos de dados. MySQL e PostgreSQL usam UTF-8 por padrão. Ao verificar os limites de bytes, use a coluna UTF-8, a menos que seu sistema especifique o contrário.

Por que as mensagens SMS têm limite de 160 caracteres?

O SMS tradicional usa codificação GSM de 7 bits, que permite 160 caracteres por segmento. Quando você inclui qualquer caractere não GSM (como aspas tipográficas, emoji ou letra não latina), a mensagem muda para a codificação UCS-2, que reduz o limite para 70 caracteres por segmento.

O que é um byte, realmente?

Um byte são 8 bits, que podem armazenar 256 valores distintos. Em texto, esses 256 valores mapeiam para caracteres através de uma codificação, um livro de regras que diz «esta sequência de bytes equivale a este caractere». A mesma cadeia de bytes pode significar texto completamente diferente sob codificações distintas: o byte 0xE9 é «é» em Latin-1, o início de uma sequência de 3 bytes em UTF-8, ou parte de uma unidade de código UTF-16. A codificação é toda a história.

Quando você salva texto no disco, envia pela rede ou armazena em um banco de dados, o que realmente persiste são bytes, não caracteres. A contagem de caracteres que você vê em um editor de texto é calculada na hora da exibição, após decodificar os bytes. Erre a codificação em qualquer um dos lados e você obtém mojibake: texto decodificado com a codificação errada aparece como gibberish (o clássico é em vez de é quando bytes Windows-1252 são lidos como UTF-8).

Contagem de bytes é o que limites de colunas de banco de dados, buffers de cabeçalhos HTTP, payloads SMS e chaves de objetos de armazenamento em nuvem todos medem, independentemente de como o texto «parece». Este contador relata o tamanho em bytes nas quatro codificações que você provavelmente vai se importar: UTF-8 (o padrão moderno), UTF-16 (o formato interno do Windows / Java / JavaScript), ASCII (válido apenas para texto latino inglês) e Latin-1 (um fallback legado de um byte). A contagem de caracteres ao lado é dada como referência.

UTF-8: a história

UTF-8 foi esboçado por Ken Thompson e Rob Pike no Bell Labs na noite de 2 de setembro de 1992, supostamente em um jogo americano em um diner de Nova Jersey, depois que a equipe do Plan 9 precisou de uma codificação de comprimento variável compatível com ASCII para Unicode. O design carrega três propriedades que quase nada mais tem ao mesmo tempo: texto ASCII também é UTF-8 válido (1 byte por caractere, bytes idênticos), a codificação é auto-sincronizante (os bits altos de qualquer byte te dizem se ele inicia um novo caractere ou continua um existente), e não há ambiguidade de ordem de bytes. Essas três propriedades juntas explicam por que UTF-8 deslocou todas as codificações concorrentes na web.

Foi padronizado pela primeira vez como RFC 2044 em outubro de 1996, revisado como RFC 2279 em janeiro de 1998, e substituído pelo atual RFC 3629 (novembro de 2003), que limitou UTF-8 a 4 bytes por caractere para corresponder ao teto final de pontos de código Unicode em U+10FFFF. A W3Techs rastreia o uso de codificações na web pública continuamente desde 2010; UTF-8 passou de 56 % dos sites em 2011 para aproximadamente 98 % em 2026. A especificação HTML5 obriga UTF-8 para conteúdo novo; HTTP/2 e HTTP/3 enviam cabeçalhos em UTF-8 via HPACK / QPACK; RFC 8259 obriga UTF-8 para intercâmbio JSON entre sistemas. Se você tem que escolher uma codificação para tudo, a resposta dos últimos 15 anos tem sido UTF-8 e a resposta para os próximos 15 será a mesma.

UTF-8 é de comprimento variável, de 1 a 4 bytes por caractere:

Consequência prática: texto inglês em UTF-8 tem média ~1 byte por caractere; chinês ~3 bytes; uma mensagem rica em emoji pode atingir 4 bytes por caractere visível, e emoji combinados (sequências ZWJ de família) facilmente alcançam 20-30 bytes pelo que parece um único caractere.

UTF-16 e a armadilha dos pares substitutos

UTF-16 foi a codificação de escolha para Windows NT (1993), Java 1.0 (1996), JavaScript (1995), .NET e Mac OS X Cocoa NSString. Usa 2 bytes para cada caractere no Plano Multilíngue Básico (U+0000 – U+FFFF), e pares substitutos para qualquer coisa fora dele: um substituto alto (D800–DBFF) mais um substituto baixo (DC00–DFFF), 4 bytes no total. UTF-16 precisa de uma marca de ordem de bytes (BOM) no disco para distinguir big-endian (UTF-16BE, FE FF) de little-endian (UTF-16LE, FF FE); Windows usa little-endian por padrão.

A armadilha: em JavaScript, "😀".length === 2. O MDN afirma diretamente: a propriedade length «contém o comprimento da string em unidades de código UTF-16». É por isso que um único emoji como 😄 reporta um comprimento de 2 (vive no plano suplementar e precisa de um par substituto), e a sequência ZWJ de família 👨‍👩‍👧‍👦 reporta um comprimento de 11 (quatro emoji de 2 unidades de código mais três junções de largura zero). O mesmo emoji de família de um caractere conta como 11 em JavaScript, 5 em Python 3 e 1 em Swift, dependendo do modelo de string de cada linguagem. Para contagens corretas de caracteres visíveis em JavaScript, use Intl.Segmenter com granularidade grapheme (todos os navegadores evergreen desde 2021).

ASCII, Latin-1 e a bagunça pré-Unicode

ASCII (American Standard Code for Information Interchange) foi padronizado como ASA X3.4-1963, revisado como X3.4-1968 e novamente como ANSI X3.4-1986. Um código de 7 bits, 128 caracteres: 95 imprimíveis mais 33 de controle. Os 33 caracteres de controle incluem heranças de teletipo como BEL, BS, CR, LF, DEL, e alguns que sobrevivem em protocolos modernos (NUL, TAB, LF, CR, ESC). ASCII ainda funciona como um subconjunto estrito de UTF-8, é por isso que «texto ASCII puro» também é UTF-8 válido e por que a migração para UTF-8 foi indolor para sistemas só em inglês.

Latin-1 / ISO-8859-1 (1987) era uma extensão de um byte com 256 caracteres que adicionava letras acentuadas da Europa Ocidental, símbolos monetários e pontuação comum. Foi a codificação de fato do conteúdo web ocidental de 1995 até UTF-8 deslocá-la por volta de 2008. Windows-1252 é o superconjunto Microsoft do Latin-1, adicionando «aspas tipográficas», travessões e o símbolo do euro no intervalo de controle C1 (0x80-0x9F); quando arquivos CSV são enviados por email entre Mac e Windows, essa é a fonte do clássico mojibake é quando um lado lê bytes Windows-1252 como UTF-8.

A armadilha «utf8» do MySQL

O MySQL carrega uma verruga notória de conjunto de caracteres desde a versão 4.1: o alias de conjunto de caracteres utf8 não é realmente UTF-8. É um subconjunto com máximo de 3 bytes que não pode representar caracteres acima de U+FFFF, o que significa que não pode armazenar emoji ou caracteres do plano suplementar. Inserir «🎉» em uma coluna utf8 produz «?» ou um erro dependendo do sql_mode. A correção é utf8mb4, adicionado no MySQL 5.5.3 (março de 2010); o MySQL 8.0 (abril de 2018) tornou-o o novo padrão. Mas esquemas criados antes do 8.0 frequentemente ainda usam a versão de 3 bytes por padrão. Se você vir emoji sumindo silenciosamente da entrada do usuário, essa é quase sempre a causa. O PostgreSQL não tem uma armadilha equivalente, ele aceita UTF-8 verdadeiro nativamente.

SMS, GSM-7 e a carga útil de 160 bytes

O limite de 160 caracteres do SMS remonta a um cálculo de Friedhelm Hillebrand em 1985, um engenheiro do Grupo de Trabalho GSM que supostamente sentou em sua máquina de escrever, digitou frases aleatórias e contou que «a maioria das mensagens pode ser expressa em 160 caracteres ou menos». Os 160 foram então deduzidos para caber em uma carga útil de 140 bytes usando um alfabeto de 7 bits (140 × 8 ÷ 7 = 160). Os detalhes da codificação estão formalizados no 3GPP TS 23.038 (originalmente GSM 03.38), e ainda governam o faturamento de SMS hoje.

Em bytes: um único SMS são 140 bytes na linha. Com GSM-7 isso são 160 caracteres; com UCS-2 (uma codificação de largura fixa de 2 bytes usada para qualquer coisa fora do alfabeto GSM-7) são 70. Mensagens multi-segmento perdem 7 caracteres GSM-7 ou 3 caracteres UCS-2 por segmento para um cabeçalho de dados de usuário (User Data Header) usado para remontagem, então mensagens longas limitam-se a 153 caracteres GSM-7 por segmento ou 67 caracteres UCS-2 por segmento. Uma única aspa tipográfica, travessão ou emoji rebaixa toda a mensagem para UCS-2 e divide ao meio o limite por segmento. O «Smart Encoding» da Twilio substitui automaticamente aspas curvas por aspas retas para manter campanhas de marketing na codificação mais barata.

Onde os limites em bytes realmente mordem

Três categorias onde os limites em bytes (e não em caracteres) te pegam:

Cabeçalhos de requisição HTTP. Sem máximo na especificação formal, cada servidor impõe um. O LimitRequestFieldSize do Apache é 8 KB por cabeçalho por padrão; os large_client_header_buffers do Nginx são 4 × 8 KB por padrão; IIS é 16 KB; o AWS Application Load Balancer aceita 16 KB por cabeçalho e 60 KB no total; o Cloudflare permite 32 KB. JWTs com conjuntos de claims inchados rotineiramente excedem o padrão de 8 KB do Apache, que é o modo de falha em produção mais comum para autenticação baseada em tokens.

Chaves de objetos de armazenamento em nuvem. S3 e GCS ambos limitam chaves de objeto a 1024 bytes de UTF-8. O Azure Blob Storage limita nomes de blob a 1024 caracteres (UTF-16 interno). Para o S3, um nome de arquivo rico em CJK (3 bytes por caractere) tope a ~341 caracteres; um rico em emoji (4 bytes por caractere) a ~256, muito antes do que o desenvolvedor espera.

Limites de linhas e índices de bancos de dados. O MySQL InnoDB tem um tamanho de linha de 65.535 bytes e um limite de prefixo de chave de índice de 3072 bytes no formato de linha DYNAMIC (767 no mais antigo COMPACT). Uma coluna VARCHAR(255) utf8mb4 precisa de 1020 bytes (255 × 4) de espaço de índice, bem em DYNAMIC, quebrado em COMPACT. Documentos BSON do MongoDB topam em 16 MB. Itens DynamoDB topam em 400 KB (incluindo nomes de atributos). Valores Redis topam em 512 MB.

Casos de uso comuns

• Validação de campos de banco de dados, confirmar que um nome enviado pelo usuário caberá antes do INSERT, especialmente quando a coluna é VARCHAR(255) utf8mb4 e a entrada é CJK.
• Texto de marketing SMS, confirmar que a mensagem permanece em GSM-7 (~1 byte por caractere visível na carga útil) em vez de cair acidentalmente em UCS-2 por causa de uma aspa tipográfica.
• Orçamento de carga útil de API, confirmar que um corpo JSON cabe sob um limite conhecido (DynamoDB 400 KB, carga útil do AWS Lambda 6 MB síncrona, 256 KB assíncrona).
• Chaves de objetos em nuvem, confirmar que uma chave S3 / GCS fica sob 1024 bytes após transcodificação não-ASCII.
• Divulgação de emoji, ver exatamente quanto «peso» um emoji ou sequência ZWJ de família adiciona a uma string.
• Seleção de codificação, comparar tamanhos em bytes UTF-8 vs UTF-16; para conteúdo predominantemente CJK, UTF-16 pode ser mais compacto (2 bytes por caractere CJK vs 3 em UTF-8).

Erros comuns

1. Confiar em .length do JavaScript para tamanho em bytes. .length retorna unidades de código UTF-16, não bytes nem caracteres. Para bytes UTF-8, use new TextEncoder().encode(text).length; para caracteres visíveis, use Intl.Segmenter.
2. Assumir que MySQL utf8 é realmente UTF-8. É um subconjunto de 3 bytes que descarta silenciosamente emoji. Use sempre utf8mb4 (e utf8mb4_unicode_ci para a colação) em qualquer coluna que toque texto enviado pelo usuário.
3. Assumir que um emoji equivale a um byte. Um único emoji são 4 bytes em UTF-8, 4 bytes em UTF-16 (par substituto). Uma sequência ZWJ de família pode exceder 30 bytes pelo que parece um único caractere.
4. Contar um BOM UTF-8 como conteúdo. O BOM UTF-8 de três bytes EF BB BF no início de um arquivo é metadado, não texto. A maioria das ferramentas CLI (awk, head, sed) o trata como parte do primeiro campo, que é a fonte de muitos bugs de «por que meu primeiro nome de coluna tem um caractere estranho».
5. Reportar uma contagem de «bytes ASCII» para texto não-ASCII. ASCII não pode representar caracteres acima de U+007F. Este contador avisa quando a entrada contém não-ASCII para que você saiba que a coluna ASCII não é significativa.

Mais perguntas frequentes

Por que um emoji são 4 bytes quando caracteres de texto são apenas 1?

UTF-8 usa 1 byte para ASCII (U+0000 a U+007F), 2 bytes para latino estendido / grego / cirílico / árabe / hebraico (U+0080 a U+07FF), 3 bytes para a maioria das escritas CJK e índicas (U+0800 a U+FFFF), e 4 bytes para emoji e caracteres do plano suplementar (U+10000 a U+10FFFF). Um emoji típico como 😀 (U+1F600) está no plano suplementar e custa 4 bytes. Emoji combinados (por exemplo, família 👨‍👩‍👧‍👦) são construídos de vários emoji base colados juntos por junções de largura zero; cada emoji base são 4 bytes, cada junção são 3 bytes, então uma família de 4 leva 4×4 + 3×3 = 25 bytes pelo que parece um caractere.

O que MySQL utf8 realmente significa?

No MySQL, o alias de conjunto de caracteres utf8 é um subconjunto com máximo de 3 bytes do UTF-8 real. Pode codificar todos os caracteres do Plano Multilíngue Básico de Unicode, mas não pode armazenar emoji nem qualquer caractere acima de U+FFFF. UTF-8 real de 4 bytes no MySQL é utf8mb4, disponível desde MySQL 5.5.3 (março de 2010), padrão desde MySQL 8.0 (abril de 2018). Se você pode alterar o esquema, use sempre utf8mb4 com a colação utf8mb4_0900_ai_ci (ou utf8mb4_unicode_ci em servidores mais antigos).

Este contador inclui uma marca de ordem de bytes UTF-8?

Não. A marca de ordem de bytes UTF-8 são os três bytes EF BB BF que o Excel no Windows exige no início de um arquivo para detectar UTF-8. O contador mede os bytes do texto que você cola; se seu texto começa com um BOM, esses três bytes são contados como conteúdo. Se você quer saber se os bytes do seu arquivo alcançarão um limite, cole apenas o corpo do arquivo, não o BOM.

Por que meu texto chinês mostra 3 bytes por caractere em UTF-8?

Quase todos os ideogramas CJK estão no intervalo Unicode U+4E00 a U+9FFF (o bloco CJK Unified Ideographs), que UTF-8 codifica como 3 bytes cada. Uma frase chinesa de 100 caracteres é, portanto, 300 bytes UTF-8. Em UTF-16, o mesmo texto são 200 bytes (2 bytes por caractere), então UTF-16 é mais compacto para conteúdo predominantemente CJK. UTF-8 vence para conteúdo misto latino-e-CJK porque caracteres latinos custam 1 byte cada em vez de 2.

Meu texto é enviado para algum lugar?

Não. O contador de bytes funciona inteiramente no seu navegador. As contagens de bytes UTF-8 vêm da API padrão TextEncoder (todos os navegadores modernos a suportam), as contagens UTF-16 e Latin-1 vêm de loops simples. Não há requisição de rede, não há chamada ao servidor, não há registro. Uma vez que a página é carregada, a ferramenta funciona offline. Seguro para inspecionar tokens de API, dados internos ou qualquer coisa que você não colaria em um contador de texto de terceiros.