形成原因

A 编码的文件（流）被 B 编码解析导致无法正常展示文字。

涉及到的原理

  1. 操作系统保存文件时，文件头内容中包含了文件编码。
  2. 文件被打开的时候会使用编辑器指定的编码方式。
  3. 文件保存时会将编码覆盖到文件头。
  4. 一些进程读取文件时原理类似文件被打开时使用指定编码方式打开（实际上也是一个进程指定编码方式进行读取文件）
  5. 字符数据被传输的过程中需要指定字符集。

项目常见编码问题集

IE/谷歌页面内容乱码

这个问题比较常见且普遍，以如下集中情况为例：

  1. 浏览器设置的编码与页面编码不一致
    》现在这类问题比较少，基本（除了IE）所有的常见浏览器都是按照 HTML 中的 meta 标签设置的编码作为解析，有些浏览器确实可以修改编码，但并不多，算作问题之一

  2. 当页面乱码数据为数据库中的数据，但数据库中的数据自己通过工具查询为正常文字。
    》这类问题一般在于应用服务器的 Java 进程（Dfile.encoding 参数）与数据库中的字符集不一致导致的，新版本的 JDBC (或其他链接工具)会提示这类问题，这类问题多出现于旧版本的 数据库 / JDBC。

  3. 页面数据本来正常，但保存后再展示出来就乱码了。
    》这类问题一般是数据库字符集和 Java 进程中的一致，但是页面解析编码与它俩不同（有可能是 页面字符集是 GB2312 但 Java进程中用的是 GB18030 ，这种情况一般会导致单个录入框的文字乱码）
    》也有可能是表单内容中多了个不可见的字符，在流传输的过程中导致字符集计算错误。
    》数据的编码被改动过，假设数据库的编码从 GB18030 改成了 GB2312 这可能导致内部编码异常。

冷知识：GB18030 是 GBK 的超集， GBK 是 GB2312 的超集

工具展示乱码（XSHELL finalshell MobaXterm IDEA eclipse PLSQL 等）

  1. 使用这类工具打开系统直接乱码
    》这种是链接工具需要指定控制台解析的字符集，只要指定与被连接的 linux 服务器相同的字符集即可。

  2. 使用这类工具打开系统不乱码，但是打开日志文件乱码
    》这种一般是文件编码与系统编码不一致导致的，或者ssh工具的解析字符集与文件字符集不一致（如果 Java 进程的项目，没有特殊字符集指定一般都是 Dfile.encoding 与 系统字符集不一致）

  3. 打开文件不乱码，但是通过 SVN 或其他版本管理工具保存后别人看乱码
    》这种有两种情况，一种是对方的编码方式有误（看看项目指定的字符集和该文件的字符集），另一种是上传该文件的人的字符集有问题，这两种情况都会导致这类问题，第一种对方一般会看到所有文件都有乱码，第二种只会出现上传的文件有乱码。

  4. 数据库连接工具乱码
    》这种情况与上面的都很类似，如果是 DbVisualizer DataGrip 这类 JDBC 工具，与Java进程的应用原理一模一样，URL指定编码即可（Mysql）如果是 PLSQL SQLDBX 这类工具，一般有专门的环境变量或参数指定即可。

统一解

最简单粗暴的方式就是将所有你能看到的设置字符集的地方设置成统一的字符集，包括但不限于：

  • HTML 的 meta 标签
  • Java 进程中的 Dfile.encoding
  • 数据库中的字符集
  • linux 中的字符集
  • PLSQL NLS_LANG 环境变量
  • 文件编辑器的保存编码
  • XSHELL 的小地球配置
  • 等等等等。。。。

注意 有些数据库比较特殊 被人都叫 GBK 它非得搞个 SIMPLIFIED CHINESE_CHINA.ZHS16GBK 一定注意，可以通过百度确定好字符集具体是什么。

相关资料