Encontrei algo que pode ser útil para outras pessoas
O negócio é exportar como latin1 e mudar o arquivo para "set NAMES utf8", já que todas as minhas tabelas são utf8.
Trabalhou.
Estou tentando migrar um banco de dados do servidor A para o servidor B.
O banco de dados é o mysql. Este banco de dados tem alguns registros com caráter como ç, ã é, ...
A codificação do banco de dados é UTF8
Então, no servidor A eu exporto assim
mysqldump -u root -p sis > sis3.sql
Depois abro o arquivo (com vi ) e os caracteres não estão OK.
Então eu tentei
mysqldump -u root -p sis --default-character-set=utf8 > sis3.sql
Ainda não está OK. Então
mysqldump -u root -p sis --default-character-set=latin1 > sis3.sql
E agora o arquivo parece OK.
A cópia para o servidor B é feita a partir do servidor B usando
scp -i p [email protected]:/home2/sis3.sql ~/
Mas sempre que o charset eu copio para o servidor B, o arquivo nunca é OK. os caracteres "especiais" estão sempre errados.
Eu tentei importar de três maneiras (latin1, utf8, sem padrão), tudo deu errado.
Eu importo assim:
mysql -u root -p"pwdpwdpwd" --default-character-set=utf8 sis < sis3.sql
Claro, alterando o conjunto de caracteres padrão.
Mas, como antes eu importo para o mysql, o arquivo já está "danificado", acho que isso provavelmente causou a transferência do ssh.
Existe uma maneira de transferir o banco de dados mysql sem esse problema?
Linux version 2.6.32-5-amd64 (Debian 2.6.32-48squeeze6) ([email protected]) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue May 13 16:34:35 UTC 2014
# locale
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=pt_BR.UTF-8
LC_TIME=pt_BR.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=pt_BR.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=pt_BR.UTF-8
LC_NAME=pt_BR.UTF-8
LC_ADDRESS=pt_BR.UTF-8
LC_TELEPHONE=pt_BR.UTF-8
LC_MEASUREMENT=pt_BR.UTF-8
LC_IDENTIFICATION=pt_BR.UTF-8
LC_ALL=
Linux version 4.4.0-0.bpo.1-amd64 ([email protected]) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.4.6-1~bpo8+1 (2016-03-20)
# locale
LANG=pt_BR.UTF-8
LANGUAGE=
LC_CTYPE="pt_BR.UTF-8"
LC_NUMERIC=pt_BR.UTF-8
LC_TIME=pt_BR.UTF-8
LC_COLLATE="pt_BR.UTF-8"
LC_MONETARY=pt_BR.UTF-8
LC_MESSAGES="pt_BR.UTF-8"
LC_PAPER=pt_BR.UTF-8
LC_NAME=pt_BR.UTF-8
LC_ADDRESS=pt_BR.UTF-8
LC_TELEPHONE=pt_BR.UTF-8
LC_MEASUREMENT=pt_BR.UTF-8
LC_IDENTIFICATION=pt_BR.UTF-8
LC_ALL=
Encontrei algo que pode ser útil para outras pessoas
O negócio é exportar como latin1 e mudar o arquivo para "set NAMES utf8", já que todas as minhas tabelas são utf8.
Trabalhou.
Verifique se o seu terminal ou emulador de terminal está usando a codificação UTF-8 .
locale despeja a configuração do seu shell, não do seu emulador de terminal.
Se você usar --default-character-set=utf8 , a saída será utf8 codificada. Então, se o seu terminal (no servidor A) não mostrar corretamente, a configuração do seu terminal está quebrada.
Por exemplo no menu do gnome-terminal, selecione Terminal , Set Character Encoding
Se a soma de verificação md5sum do arquivo, no servidor A e B, for idêntica, você pode "ter certeza" de que o arquivo foi transferido corretamente.
Não tem nada a ver com o seu emulador de terminal.
mysqldump -u root -p sis --default-character-set=latin1 > sis3.sql
mysql -u root -p"pwdpwdpwd" --default-character-set=utf8 sis < sis3.sql
Importe o arquivo usando o mesmo conjunto de caracteres com o qual você o exportou.
O que você vê no arquivo exportado depende das configurações da ferramenta usada para visualizá-lo. Não confunda o problema - veja como o mysql interpreta os dados. Se o backup for enorme, faça algumas experiências com um conjunto de dados menor.
Presumivelmente, isso é openssh? Contanto que você não esteja usando algum outro software no meio, o arquivo não será modificado em trânsito. Você pode verificar isso usando md5sum ou similar.