如何解决字符编码问题？
如果我们只看到丑陋的无字符框，那么我们使用什么工具或者策略找出出了什么问题？
(我要面对的特定场景是<select>中的无字符框，当它应该显示日语字符时。)
解决方案
回答
首先，"丑陋的无字符框"可能不是编码问题，它们可能只是我们没有安装可在页面上显示字形的字体的标志。
当字符串从一个系统传递到另一个系统时，大多数字符编码问题都会发生。对于webapp，这通常在浏览器和应用程序之间，应用程序和文件系统之间以及应用程序和数据库之间。
因此，我们需要检查错误编码的数据来自何处，在源处使用哪种字符编码以及如何接收该编码。最好的方法是发送已知系统存在问题的字符，并在应用程序的每个级别进行检查。他们在应用程序内部是什么样的？在数据库中？当我们从数据库取回它们时？当它们显示在浏览器中时？
抱歉，这么笼统，但是这个问题并不能解决更多问题。
回答
将数据重定向到磁盘，然后使用十六进制编辑器。大多数文本编辑器/查看器都是在后台进行自己的转换，因此很难确保我们看到的是真实格式的数据。
回答
如果我们发送到浏览器的数据变得混乱(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标签文件<HEAD>
<meta http-equiv =" content-type" content =" text / html; charset = utf-8">
通常也可以将英文HTML文档类型属性与上述字符混合使用。因此，在具有以下内容的HTML文档中添加上面的META标记似乎可行：
<html xmlns =" http://www.w3.org/1999/xhtml" xml：lang =" zh-CN" lang =" zh-CN">
电子邮件
这是完全不同的蠕虫病毒。 UTF8的工作原理很多，但是许多日本的老客户使用ISO2022X。这在这里不值得介绍。
调试UTF8问题
一旦有了像Maruo这样的可靠UTF8编辑器，就可以创建静态页面并解决问题。
希望能有所帮助
