如果您看到的只是丑陋的无字符框，您使用什么工具或策略来找出问题所在？
（我面临的具体情况是 <select> 中的无字符框，它应该显示日文字符。）
Larsenal
问问题
2293 次
3 回答
3
首先，“丑陋的无字符框”可能不是编码问题，它们可能只是表明您没有安装可以在页面中显示字形的字体。
大多数字符编码问题发生在字符串从一个系统传递到另一个系统时。对于 webapps，这通常是在浏览器和应用程序之间、应用程序和文件系统之间以及应用程序和数据库之间。
因此，您需要检查错误编码数据的来源、源头的字符编码以及接收的编码。最好的方法是发送您知道系统存在问题的字符，并在应用程序的每个级别检查它们。它们在应用程序中是什么样子的？在数据库中？当你从数据库中取回它们？它们何时显示在浏览器中？
很抱歉这么笼统，但这个问题并没有提供更多的解决方法。
于 2008-08-27T04:26:58.737 回答
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 标头。这些网站知道如何正确使用它。基本上在文档 <HEAD> 中包含以下 META 标签
<meta http-equiv="content-type" content="text/html; charset=utf-8">
将英文 HTML 文档类型属性与上述字符混合通常也是安全的。因此，在上面添加 META 标记似乎适用于具有以下内容的 HTML 文档：
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
电子邮件 这是完全不同的蠕虫罐头。UTF8 很管用，但许多日本老客户更多地使用 ISO2022X。这不值得在这里讨论。
调试 UTF8 问题 一旦您拥有像 Maruo 这样可靠的 UTF8 编辑器，您就可以创建静态页面并解决您的问题。
希望有帮助
于 2008-09-13T03:40:17.770 回答
1
将数据重定向到磁盘并使用Hex Editor。大多数文本编辑器/查看器在幕后进行自己的转换，因此很难确定您看到的是真实形式的数据。
于 2008-08-27T06:53:48.803 回答