如果你看到的只是丑陋的无字框，你用什么工具或策略来弄清楚出了什么问题？
（我面临的具体情况是＆lt; select＆gt;中应该显示日语字符时的无字框。）
答案 0 :(得分：3)
首先，“丑陋的无字框”可能不是编码问题，它们可能只是一个标志，表示您没有安装可以在页面中显示字形的字体。
当字符串从一个系统传递到另一个系统时，会发生大多数字符编码问题。对于webapps，这通常在浏览器和应用程序之间，应用程序和文件系统之间以及应用程序和数据库之间。
因此，您需要检查错误编码数据的来源，源代码处的字符编码以及接收的编码。最好的方法是通过您知道系统遇到问题的字符发送，并在应用程序的每个级别检查它们。它们在应用程序中的外观如何？在数据库中？当你从数据库中取回它们？当它们在浏览器中显示时？
很抱歉这么一般，但问题并没有给予更多的帮助。
答案 1 :(得分：2)
如果您发送到浏览器的数据变得严重（moji-bake），您将获得垃圾字符。此外，如果您在META标题中指定了错误的字符集，则浏览器将错误地渲染页面，导致再次出现moji-bake，有时会在页面上的随机位置。
处理CJK字符集时，必须确保在程序的整个生命周期内使用UTF8字符编码（数据存储，检索，代码中的数据操作，在浏览器等中显示......）
什么是UTF8？ UTF8处理二进制数据流，而不是字符串。这意味着位组合可以具有可变长度。 ASCII字符的固定长度为8位，代表1个字节，但UTF8字符可以由6位，8位，12位等组成......因此，UTF8很容易被日语称为“mojibake”。
作为一个编码器，从数据库到代码库再到浏览器，你应该尝试完全使用UTF8。对于电子邮件，您可以使用UTF8，但您可能会发现大多数邮件服务器和客户端仍旧，并使用不同字符集的混搭（例如ISO9022X）。
数据库设置 如果您是mysql用户，请确保必须确保与数据库的所有连接都使用UTF8，并且所有表/字段都使用UTF8。默认情况下，mysql使用拉丁（瑞典语）字符集。那些怪异的瑞典人喜欢他们的幽默感!!
检查代码库 根据我的经验，编辑器如Notepad ++，Notepad2，UltraEdit，e等...都有UTF8支持问题。他们大多数都在工作，但由于他们的开发人员自己不使用CJK语言，所以他们并没有完善。像关闭BOM（字节顺序标记），错位标签，不良字符集转换等问题......都存在问题。
我强烈建议使用Maruo等经过验证的UTF8编辑器。这是由一家日本公司制作的，但在http://www.hidemaru.interlink.or.jp/software/有一个英文版（和试用版）
最后，您可能需要将源文件转换为UTF8。特别是如果代码库本身包含CJK语言字符串。
操纵字符串 任何字符串函数都需要多字节安全。注意我没说双字节。 UTF8不是双字节而是多字节，具体取决于用于表示字符的总位数。在PHP中，您需要专门调用MB字符串函数。 Ruby和其他语言有更透明的支持，但您需要检查文档以了解应用程序服务器的风格！
META标记 查看google.co.jp或yahoo.co.jp的META标题。这些网站知道如何正确使用它。基本上包括以下META标签doucment＆lt; HEAD＆gt;
＆lt; meta http-equiv =“content-type”content =“text / html; charset = utf-8”＆gt;
将英文HTML文档类型属性与上述字符混合通常也是安全的。因此，添加上面的META标记似乎适用于具有以下内容的HTML文档：
＆lt; html xmlns =“http://www.w3.org/1999/xhtml”xml：lang =“en”lang =“en”＆gt;
电子邮件 这是一种完全不同的蠕虫病毒。 UTF8工作很多，但许多日本老客户更多地使用ISO2022X。这不值得。
调试UTF8问题 一旦拥有像Maruo这样可靠的UTF8编辑器，您就可以创建静态页面并解决问题。
希望有所帮助
答案 2 :(得分：1)
将数据重定向到磁盘并使用Hex Editor。大多数文本编辑/观看者在幕后进行自己的转换，因此很难确定您是否以真实的形式看到数据。