Como exportar um banco MySQL em UTF-8 sem perder acentuação?

Em resumo:

• Diagnosticar o sintoma visível antes de alterar qualquer configuração ajuda a distinguir dupla codificação (recuperável) de perda real de caracteres (não recuperável).
• Verificar charset e collation do servidor, do banco e da conexão antes de exportar evita que o arquivo de exportação saia em um padrão diferente do esperado pelo destino.
• Alinhar o charset do dump com o charset do banco de destino resolve a maioria dos casos de “João” e “informação”.
• Quando os caracteres já foram substituídos por “?” ou símbolos de erro, ajustar o charset não recupera o texto — apenas a restauração de um backup anterior ao problema resolve.

Depois de exportar e reimportar um banco MySQL, é comum abrir uma tabela e encontrar “João” no lugar de “João”, ou “informação” no lugar de “informação”.

• Quer ser um especialista em tecnologia? Conheça a Allevo Tech!

O problema normalmente não está nas letras em si, e sim na forma como elas foram lidas durante a migração.

Um banco de dados não guarda “letras”: ele guarda bytes e uma instrução sobre como esses bytes devem ser interpretados — o charset. Quando o arquivo de exportação é lido com uma instrução diferente da que foi usada para gravá-lo, o resultado visual muda, mesmo que os bytes originais continuem intactos.

Diagnosticar o problema pelo sintoma visível

O primeiro passo prático é observar exatamente o que aparece na tela, porque cada padrão de erro aponta para uma causa diferente e para uma ação diferente.

Sintoma na tela	Causa provável	O que fazer
“João”, “informação”	Texto gravado em UTF-8 foi lido como latin1 (ou o inverso) em algum ponto da exportação ou importação	Verificar e alinhar charset e collation entre origem, dump e destino antes de reimportar
“Jo?o”, “informa??o”	Os caracteres já foram convertidos com perda; o byte original não existe mais no dado atual	Restaurar um backup anterior ao problema; ajuste de charset não recupera o texto
Caractere de substituição (losango com ponto de interrogação)	Byte inválido para o charset declarado na leitura do arquivo	Confirmar o charset real do arquivo ou do dump antes de importar
“???” no lugar de emojis ou símbolos especiais	O charset utf8 (de até 3 bytes) não acomoda o caractere	Avaliar a conversão do banco, da tabela e da conexão para utf8mb4

Quando o padrão observado é o segundo da tabela — letras substituídas por “?” —, é importante não tratar o caso como um problema de configuração a ser corrigido na origem.

Essa marca normalmente indica que a informação original já foi perdida durante uma conversão anterior, e o caminho correto é buscar uma cópia de segurança anterior ao problema, não reconfigurar charset no banco atual.

Verificar charset e collation antes de exportar e importar

Antes de gerar qualquer arquivo de exportação, vale consultar as variáveis de charset e collation do servidor, da conexão e do banco com comandos como SHOW VARIABLES LIKE ‘character_set%’ e SHOW VARIABLES LIKE ‘collation%’.

Esses comandos mostram, separadamente, o charset do cliente, da conexão, do servidor e do banco de dados.

Quando esses valores não coincidem entre si, cada camada pode estar interpretando o mesmo byte de um jeito diferente.

Por isso, o ideal é repetir essa verificação em dois momentos: antes de gerar o dump na origem, para saber em que charset o arquivo será escrito, e antes de importar no destino, para confirmar que o banco de destino espera o mesmo charset do arquivo que será carregado.

Preparar a exportação em UTF-8 sem corromper caracteres

A causa mais comum de acentuação quebrada depois de uma migração é o utilitário de exportação (como o mysqldump) ou uma ferramenta como o phpMyAdmin gravando o arquivo em um charset diferente do que o banco de destino está configurado para esperar na importação.

Esse cenário costuma ser chamado de dupla codificação, e vale entender por que ele não é, na maioria dos casos, uma perda definitiva: os bytes originais continuam presentes no arquivo ou no banco, o que se perde é apenas a instrução correta de como lê-los. Isso é diferente do caso em que o caractere já foi substituído por “?”, tratado na seção anterior.

Na prática, isso significa que o ponto crítico da exportação não é um comando isolado, e sim a coerência entre três elementos: o charset em que os dados estão gravados na origem, o charset em que o arquivo de exportação é escrito, e o charset que o banco de destino vai usar para interpretar esse arquivo na importação.

Definir charset e collation no banco de destino

Charset e collation não são a mesma coisa. O charset define o conjunto de caracteres que podem ser armazenados e quantos bytes cada um ocupa; a collation define as regras de comparação e ordenação dentro daquele charset, e cada charset tem seu próprio conjunto de collations disponíveis, cada uma com particularidades de comportamento.

Antes de importar os dados, é possível definir explicitamente esse padrão no banco de destino com um comando como ALTER DATABASE nome_do_banco CHARACTER SET utf8 COLLATE utf8_general_ci, por exemplo, ou usando latin1 e latin1_swedish_ci quando esse for o padrão compatível com a origem.

A collation escolhida também afeta o comportamento das consultas. Uma collation como latin1_general_ci, por exemplo, é case-insensitive: uma busca pelo termo “teste” retorna também os registros gravados como “Teste” e “TESTE”.

Alinhar aplicação, dumps e arquivos importados ao mesmo charset

Nem todo problema de acentuação nasce dentro do banco. Parte considerável dos casos relatados vem da diferença de codificação entre Latin1 e UTF-8 em scripts externos que leem ou gravam no banco, e também de diferenças sutis entre ambientes.

Arquivos externos também merecem atenção própria. Um CSV exportado como UTF-8 com BOM (marca de início de arquivo) pode abrir corretamente no Excel e, ainda assim, apresentar acentuação errada depois de importado no banco, porque a ferramenta de importação pode não tratar esse BOM da mesma forma que o Excel.

Por isso, antes de importar um arquivo externo, vale confirmar a codificação real do arquivo, e não apenas confiar na aparência correta em um editor de planilhas.

Quando os dados já foram perdidos de verdade

Vale repetir esse ponto de forma isolada porque é onde promessas exageradas costumam aparecer: quando um dado já foi convertido com perda, aparecendo como “Jo?o” ou “informa??o”, não existe comando de charset, collation ou exportação capaz de reconstruir o caractere original a partir do que está no banco atual.

Nesses casos, a única saída real é localizar um backup gerado antes da conversão com perda e restaurar os dados a partir dele. Ajustar configuração de charset nesse cenário pode até parar de gerar novos erros a partir daquele ponto, mas não devolve a informação que já foi substituída.

Perguntas frequentes sobre acentuação no MySQL

Por que “João” aparece no lugar de “João”?

Porque o texto foi gravado em um charset (normalmente UTF-8) e, em algum ponto da exportação, importação ou leitura pela aplicação, foi interpretado como se estivesse em outro charset (normalmente latin1). Os bytes continuam os mesmos, só a leitura mudou.

Como exportar um banco MySQL para UTF-8 sem perder acentuação?

O ponto central é garantir coerência entre o charset de origem, o charset do arquivo de exportação e o charset que o destino vai usar na importação. Verificar esses três pontos antes de exportar evita que o arquivo seja gravado em um padrão diferente do que o banco de destino espera.

Como verificar o charset e o collation do banco?

Usando comandos como SHOW VARIABLES LIKE ‘character_set%’ e SHOW VARIABLES LIKE ‘collation%’ no servidor de origem e no de destino, antes de exportar e antes de importar, para confirmar se os valores coincidem em cada camada (cliente, conexão, servidor e banco).

Qual a diferença entre charset e collation?

Charset define o conjunto de caracteres aceitos e como eles são armazenados em bytes. Collation define como esses caracteres são comparados e ordenados. Cada charset tem seu próprio conjunto de collations, e escolher a combinação errada não corrompe o texto, mas pode alterar o resultado de buscas e ordenações.

É possível recuperar dados que viraram “Jo?o”?

Não a partir do dado atual. Quando o caractere já foi substituído por “?”, a informação original não está mais presente no banco, e a única forma de recuperá-la é restaurar um backup gerado antes dessa conversão com perda.

utf8 resolve emojis ou é preciso utf8mb4?

O charset utf8 tradicional do MySQL usa até 3 bytes por caractere, o que não é suficiente para emojis e alguns símbolos, geralmente exibidos como “???”. Para esses casos, é necessário usar utf8mb4, que suporta até 4 bytes por caractere, tanto no banco quanto na conexão.

Preciso mudar o charset da aplicação junto com o banco?

Sim, de forma coerente. Ajustar apenas o banco e deixar a aplicação (scripts, conexão, arquivos importados) em um charset diferente tende a reproduzir o mesmo tipo de erro em outra camada, mesmo que o banco em si esteja configurado corretamente.

Construa sua carreira em tecnologia com formações alinhadas ao mercado

Se você quer ingressar ou crescer no mercado da tecnologia, a Allevo Tech oferece formações práticas em áreas de alta demanda, como Engenharia de Software, Ciência de Dados e Inteligência Artificial.

As trilhas são estruturadas para desenvolver competências técnicas e preparar você para os desafios do mercado de trabalho.

Clique no botão abaixo e conheça as formações da Allevo Tech que podem impulsionar a sua trajetória profissional.