strlen vs mb_strlen no PHP: por que contar caracteres com acento dá errado

strlen('ação') devolve 6, não 4. A função não está errada — ela só não conta o que você imagina: strlen conta bytes, mb_strlen conta caracteres. Em UTF-8, letras acentuadas ocupam mais de um byte cada, então qualquer texto em português faz as duas contagens divergirem. E o problema vai além do número: cortar com substr pode partir uma letra ao meio e produzir o famoso �. Este artigo mostra o mecanismo, quais funções têm par mb_*, como diagnosticar, e — importante — quando strlen continua sendo a escolha certa, porque trocar tudo cegamente também é erro.

O mecanismo: UTF-8 tem letras de tamanhos diferentes

Em UTF-8, o número de bytes por caractere é variável. Letras do ASCII (a–z, 0–9) ocupam 1 byte; letras acentuadas do português ocupam 2; símbolos e emojis podem ocupar 3 ou 4. Dá para ver isso com bin2hex, que mostra os bytes crus da string:

$s = 'ação';
echo strlen($s);      // 6  ← bytes
echo mb_strlen($s);   // 4  ← caracteres
echo bin2hex($s);     // 61 c3a7 c3a3 6f
//                       a    ç    ã   o
//                       1B   2B   2B  1B  = 6 bytes, 4 letras

strlen foi criada quando 1 byte = 1 caractere era verdade (era o mundo ASCII). Ela continua fazendo exatamente aquilo: medir o tamanho da string em bytes. Não é uma função "quebrada" — é uma função que responde outra pergunta. A família mb_* (de multibyte string) sabe interpretar UTF-8 e responde a pergunta que você geralmente quer: quantas letras.

O corte: onde nasce o �

Contar errado é chato; cortar errado é visível para o usuário. O substr também trabalha em bytes, então ele corta na posição N de bytes — e essa posição pode cair no meio de uma letra. Sobra um pedaço de byte que não forma caractere válido, e o navegador desenha �:

substr('ação', 0, 1);   // "a"     bytes: 61
mb_substr('ação', 0, 1);// "a"

substr('ação', 0, 2);   // "a�"    bytes: 61 c3   ← quebrou
mb_substr('ação', 0, 2);// "aç"

substr('ação', 0, 3);   // "aç"    bytes: 61 c3a7
mb_substr('ação', 0, 3);// "açã"

substr('ação', 0, 4);   // "aç�"   bytes: 61 c3a7 c3
mb_substr('ação', 0, 4);// "ação"

mb_substr($texto, 0, 100);   // sempre 100 letras, sempre íntegro

Num caso real — gerar o resumo de um texto — a diferença fica óbvia:

$frase = 'Descrição do produto';

echo strlen($frase);            // 22 (bytes) — mas são 20 letras
echo substr($frase, 0, 12);     // "Descrição "  ← só 10 letras
// os acentos "comeram" 2 posições do corte

$frase = 'Descrição do produto';

echo mb_strlen($frase);         // 20 — letras de verdade
echo mb_substr($frase, 0, 12);  // "Descrição do" ← 12 letras

Não é só contar e cortar: a família inteira

O mesmo raciocínio vale para todas as funções de string "clássicas" — elas operam byte a byte. Três exemplos que costumam passar despercebidos:

$s = 'ação';

echo strtoupper($s);      // "AçãO"  ← o ç e o ã ficam de fora
echo mb_strtoupper($s);   // "AÇÃO"

echo str_pad($s, 6, '.'); // "ação"  ← acha que já tem 6 (bytes!) e não completa
echo mb_str_pad($s, 6, '.'); // "ação.." (PHP 8.3+)

echo strrev($s);          // "o?ç?a" ← inverte BYTES e destrói os acentos

O strtoupper é especialmente enganoso porque o resultado parece funcionar: metade das letras sobe, os acentos não. E o str_pad mostra que o problema não é só "contar" — a contagem errada contamina qualquer função que dependa de tamanho.

Diagnóstico: descobrir se o problema é esse

Duas checagens rápidas resolvem a dúvida "será que é isso que está acontecendo comigo?":

// 1. Se os dois números divergem, a string tem caracteres multibyte
var_dump(strlen($texto), mb_strlen($texto));

// 2. Ver os bytes crus e onde estão os multibyte
echo wordwrap(bin2hex($texto), 2, ' ', true);

Se strlen > mb_strlen, qualquer lógica sua baseada em strlen/substr está operando com números diferentes do que o usuário vê. Vale checar especialmente validações de formulário: um limite de "máximo 20 caracteres" implementado com strlen rejeita nomes acentuados antes da conta fechar.

Quando strlen continua certo

Aqui está a parte que quase nenhum tutorial diz: não saia trocando todo strlen por mb_strlen. Os dois respondem perguntas diferentes, e às vezes a pergunta certa é mesmo sobre bytes:

• Limite de armazenamento. Uma coluna VARCHAR do MySQL em utf8mb4 reserva espaço por caractere, mas limites de bytes (como o tamanho máximo de uma chave de índice) são medidos em bytes — aí strlen é a medida correta.
• Dados binários. Conteúdo de arquivo, imagem, hash: não são texto, e contar "caracteres" não faz sentido. Use strlen.
• Protocolos e cabeçalhos. Content-Length é em bytes, sempre.
• Performance em ASCII garantido. Se a string é comprovadamente ASCII (um UUID, um hash hexadecimal, um código gerado por você), strlen é mais rápida e igualmente correta.

A regra prática que resume tudo: texto que veio de gente (ou vai para gente) → mb_*; bytes que vão para disco, rede ou memória → strlen.

A camada seguinte: caractere ≠ o que você vê

Já que você chegou até aqui, vale saber que mb_strlen também tem um limite — ela conta code points, que nem sempre correspondem ao que aparece na tela. Duas situações reais:

$pre  = "é";            // 1 code point (U+00E9)      → mb_strlen = 1
$comp = "e\u{0301}";    // "e" + acento combinante     → mb_strlen = 2
var_dump($pre === $comp);  // false — e os dois aparecem como "é" na tela!

As duas formas são visualmente idênticas, mas são strings diferentes — é a explicação para o clássico "o usuário jura que digitou o mesmo nome, mas a busca não acha". Quando o texto vem de fontes variadas (macOS, colagem de PDF, APIs), normalize antes de comparar ou salvar, com a extensão intl:

$normalizado = Normalizer::normalize($texto, Normalizer::FORM_C);

O mesmo vale para emojis compostos: uma família 👨‍👩‍👧 é um símbolo na tela, mas mb_strlen conta 5 (são vários code points unidos por junções invisíveis). Quando o que importa é o que o olho enxerga, a medida correta é o grapheme: grapheme_strlen(), também da intl.

Resumo de decisão