两千条产品描述变成问号，老板以为被投毒了
那天下午我接到电话，客户在那头声音发抖，说网站产品页全变成一串问号和方块字。我远程连上去一看，典型的编码错位。老库是latin1存的中文，新库建成了utf8mb4，导入的时候没指定字符集，一路转下来全废。这种事故在广州做建站的技术圈里几乎是入门必踩的坑，谁没被问号折磨过谁不算入行。
编码乱是果，不是因，真正的病根在三个环节
老数据库本身的字符集设置是一个。很多五年前建的站用的是utf8或者latin1，那会儿utf8mb4还不普及。导出工具的默认参数是第二个环节，命令行工具不显式指定字符集，就按它自己的默认来，跟你的库对不上。新库的建库语句是最后一环，建的时候字符集和排序规则得写明白。
三个环节里任何一个错位，中文就成天书。我的习惯是动手前先把老库的实际字符集查清楚，注意是"实际存的"而不是"声明的"，这俩经常不一致。库声明utf8，字段里塞的却是gbk字节流，这种情况在国产老建站系统里特别常见。
救回来的办法：先还原再转换，别跳步
已经乱了的库，硬改字段字符集救不回来。正确的路子是把数据按原来那套错误的编码原样导出成二进制安全的文件，再用正确的字符集声明重新导入，等于把中间那次错误的转换撤销掉。这个过程听着绕，实操就是导出导入各改一个参数的事。
要是原始数据已经被覆盖了，那就只能靠备份。这也是为什么我一直啰嗦迁移前必须做还原验证——真出这种事，有一份能用的备份就是几万块和几小时的区别。
emoji和特殊符号，是隐藏的定时炸弹
utf8mb4和utf8的区别就在能不能存四字节字符。产品描述里客户复制粘贴带了个表情符号，或者某些生僻汉字、外文特殊字母，utf8存不下，导入直接截断，那条记录后半段全没了。做外贸独立站尤其要注意，欧洲语言的重音符号、俄语西里尔字母、阿拉伯语，全是坑。
新站一律用utf8mb4，排序规则选unicode_ci，这是2026年还在做站的人不该再讨论的默认选项。多花的那点存储空间，跟数据出错的代价比不值一提。
迁移完的验收，抽检要抓极端样本
别只看首页正常就以为万事大吉。挑那些最容易出问题的记录抽检：最长的产品描述、含表格的富文本、带外文的型号、含引号和反斜杠的字段、日期时间字段。这些地方过了，剩下的基本没问题。
我一般还会写个小查询，统计各表里包含问号连续三个以上的记录数，跑一遍全库。有异常立刻浮出来，比人眼一条条翻靠谱一万倍。做广州网站建设这些年，能被脚本干的活儿我从不用人肉硬扛。
时区和数字格式，另外两个隐形杀手
编码修好了，别以为数据就干净了。老服务器在广州，时区设的是东八区，新服务器放在美西，时区默认是太平洋时间。数据库里存的时间字段搬过去之后，所有文章的发布时间集体往前跳了十五个小时，几年前发的文章显示成了明天发布的。搜索引擎看到未来时间的内容会很困惑，前台的排序也全乱了。
处理办法是数据库统一用世界协调时存储，显示的时候在应用层按需要转换。迁移之前把老库的时区设置查清楚，导入之后拿最早和最晚的几条记录核对时间对不对。
数字格式也有坑，做外贸的尤其要留神。小数点和千位分隔符在不同地区的写法是反的，价格字段如果在迁移中被当成本地格式解析，一千二百三十四点五会变成一百二十三万四千五。这种错误一旦流到前台，客户看见的报价就是笑话。
老库里通常躺着大量垃圾：测试订单、重复的产品记录、废弃的草稿、几年前的日志表、卸载插件留下的孤儿数据表。这些东西搬过去只会让新库臃肿，查询变慢，往后每次备份都要多背几个G。
动手前先清一遍。日志类的表直接清空，草稿和回收站里的内容确认无用就删，孤儿表核对清楚来源后移除。我处理过一个用了六年的站，老库四点二个G，清理之后只剩八百多兆，导入速度快了五倍，新站的后台响应也明显轻快了。
清理必须在备份之后做，而且要一类一类来，删完一类跑一遍站看有没有异常。一口气全清完再发现问题，你都不知道是哪一刀砍错了。
编码这东西平时看不见，出事就是全站毁容。宁可动手前多查十分钟，别等客户打电话来质问。
广州网站建设
如没特殊注明，文章均为高端网站定制专家万智网络原创，转载请注明来自https://www.wanzhiweb.com/xwzx/jyfx/18119.html