我们对项目的要求是:
多个站点(生产、测试、本地开发)通过多种方法(PHPMyAdmin、Navicat、BackupBuddy)迁移我们面临的问题是while original production site seems to work fine, rest of the installations are constantly plagued by text encoding issues.
原始站点配置为latin
MySQL表,但配置了WP并将页面用作UTF-8
, (在我们的聊天中)有人告诉我,这已经有问题了。其余站点(其数据库主要反映原始生产站点)显示以下问题:
断字符(可通过调整WP编码设置进行更正)
断字符(无法通过调整WP编码设置进行更正)站点运行良好,但将残缺的字符提供给外部库由于我已经尝试解决这一问题有一段时间了,而且没有太多关于WP中编码问题诊断的信息,我的问题如下:
如何可靠地诊断站点是否存在编码配置问题,即使在正常情况下可能不会显示这些问题?
应该制定哪些规则,将其纳入文档并加以实施,以防止迁移中的编码问题?
最合适的回答,由SO网友:Rarst 整理而成
所以大约一年后(断断续续!)我已经设法解决了编码问题。
我的经验总结为,像这样的编码问题主要是由miscommunication when moving data around.
在最好的情况下,当正确的数据被错误地解释时,这是读取不匹配;在最坏的情况下,当数据被错误地保存时,这是写入不匹配,导致问题层出不穷,并导致各种程度的损坏。在WP中,最早可以搞砸数据库编码的是在创建数据库时。所以,甚至在您下载WP归档文件进行安装之前。
不要依赖默认值,并确保组件以相同的编码进行通信(如UTF8)internally, as well as to each other and visitors. 这远远超出了WP的范围,涉及到MySQL配置,可能还需要对Apache和PHP进行一些改进。
看见WordPress Database Charset and Collation Configuration
修复当事情彻底破裂时,你将面临巨大的痛苦,找出问题所在以及如何恢复正常。
我发现mb_detect_encoding()
非常有用。这不是一根魔杖,但(在严格的模式下)它的错误返回是一个很好的信号not 典型的
在WP特定前部$wpdb
具有编码相关属性。
当您有错误的原因/猜测/想法时,请将数据拖到安全的地方,并尝试将数据转换为有意义的规范化数据,请参阅: