我正在将大量的mysql数据库从一些共享的Web主机迁移到一个共享的Web主机。
其中大多数都是葡萄牙语，因此有很多特殊字符。我正在迁移的一些数据库是latin1，有些是cp1251，有些是utf8。
当然，简单地转储数据库，然后将转储恢复到新主机上会完全破坏编码和“？”字符和其他废话显示在与数据库关联的实际网站中。
在小规模上，可以接受html charset标签，知道要转储/恢复的内容，但问题是我们正在处理数千个数据库和网站，并且迁移都是通过几个脚本自动完成。
我正在寻找关于转储/恢复这些数据库的最佳方法的建议，假设执行工作的脚本不知道HTML标记中指定的编码。
到目前为止，我已经尝试使用实际的mysqldump工具，以及使用php脚本模仿它，并从内存转储到内存而不是从文本文件转储，这些都不能完全复制数据。一对一没有编码问题。
我是否应该使用UTF8对转储进行编码，然后无论html代码页如何都恢复原样？ 无论HTML代码页如何，都在UTF8中转储和恢复？ 在每个create table语句中找到的默认字符集中转储和恢复？
我对这些不同场景的含义和影响的理解是有限的，但我需要知道的是，如果有一种方法可以完全复制数据而不需要在2个数据库服务器之间编码问题而不知道所使用的代码页，那么我需要知道的是正在访问数据的脚本的HTML。
答案 0 :(得分：0)
编码是一个非常难以解决的问题，尤其是在移动数据库时。首先尝试进行结构导入，然后将新结构与旧结构进行精确比较，特别注意数据库字符集，表默认字符集和列字符集。您可以从information_schema数据库中轻松获取这些信息。
一旦这些被绝对镜像，您就可以开始导入了。但是，请注意您可以在差异编码列中保存差异编码类型中的字符（在latin1列中使用utf8有效字符是很常见的，拉丁1是1字节字符集，而utf8可以包含字符到3个字节）。
您可以在此之后尝试各种方法来转换转储，但据我所知，到目前为止，没有一种100％有效的方法可以在同一列中转换此类混合编码类型的情况。最终，您可能需要进行一些手动清理。但希望第一种方法就足够了，一切都会好的。