主题：【求助】服务器端编码和客户端解码的问题：php, javascript -- 铁手

外链出处

通常情况下，我们的网页要指定一个编码字符集，如 GB2312、UTF-8、ISO-8859-1 等，这样我们就可以在网页上显示我们指定编码的文字了。但是我们很可能会遇到这种情况，那就是我们可能希望在 ISO-8859-1 编码的网页上显示汉字，或者在 GB2312 编码的网页上显示韩文等。当然一种解决办法就是我们不用 ISO-8859-1 或者 GB2312 编码，而统统都采用 UTF-8 编码，这样我们只要在这种编码下，就可以混合显示各国文字了，这是现在很多网站采用的方法。

而我这里所说的并非上面这种方法，因为上面这种方法必须要指定字符集为 UTF-8 才可以，一旦用户手工指定为其他字符集，或者可能因为某些原因，那个字符集设置没起作用，而浏览器又没有正确自动识别的话，我们看到的网页还是乱码，尤其是在某些用框架作的网页中，某个框架中的页面如果字符集设置没起作用，在 firefox 中显示乱码而且还没法改变（我是说在不装RightEncode插件的情况下）。

而我这里介绍的方法即使是把网页指定为 ISO-8859-1 字符集，也能够正确显示汉字、日文等。原理很简单，就是把除了 ISO-8859-1 编码中前128个字符以外的所有其他的编码都用 NCR(Numeric character reference) 来表示。比如“汉字”这两个字，如果我们写成“汉字”这种形式，那么它在任意字符集下都可以正确显示。根据这个原理，我写了下面这个程序，它可以把现有的网页转化为在任意字符集下都能显示的网页。你只需要指定源网页的字符集和源网页，点提交按钮，就可以得到目标网页了。你也可以只转化某些文字，只需要把文字填写到文本框中，并指定这些文字原来的字符集，点提交按钮，就会在页面上面显示编码后的文字了。另外我还编写了 WordPress 的插件，现在我的 Blog 已经可以在任意字符集下都能正确显示了。

实现方法：

首先第一步是要把源字符集的字符串转化为UTF-16字符集，做这一步是因为UTF-16字符集中的每个字符都是两个字节，后面处理起来很容易，而如果在源字符集上直接做处理则很复杂。源字符集可以从原网页中的meta标签中获得，也可以单独指定，我的程序是让用户在表单中指定源字符集，因为我不能保证用户提交的文件就一定是HTML文件（其他文件也是可以的，比如这个WordPress的汉化包源文件是个po文件，它里面的内容也可以这样处理），而且即使是HTML文件，里面也不一定就有用于指定字符集的meta标签，所以通过表单单独指定字符集比较保险。你可能会觉得将一种字符集转化为另一种字符集很复杂，确实如此，如果自己来实现的话，确实非常麻烦，但是用PHP来做却很容易，因为它里面已经包含这样的函数了，你可以通过iconv函数很容易的来实现各种字符集之间的转化，如果你的机器上没有安装iconv扩展，你也可以使用mb_convert_encoding函数，如果Multibyte String扩展也没有安装，那就没办法了，因为你要自己实现那么多种编码的转化基本上是不可能的，除非你是顶级大牛！推荐使用iconv，因为这个效率高，支持的字符集也更多。

做完上面那一步之后，接下来是以每两个字节为单位对字符串进行处理。这两个字节直接转化为数字就是 &#xxxxx;中的xxxxx，如果这个数字小于128就直接使用这个字符（注意这里就变成单字节了），否则就使用&#xxxxx;的形式。这里有一点要注意，就是当这个数字是65279（16进制的0xFEFF）时，请把它忽略掉，因为这个是Unicode编码中的传输控制字符，而我们现在的字符串已经只有iso-8859-1编码中的前128个字符了，所以我们不需要它了。

好了，基本思路就是这样，下面是实现的程序：

PHP程序版本函数：

<?php

function nochaoscode($encode, $str) {

$str = iconv($encode, "UTF-16BE", $str);

for ($i = 0; $i < strlen($str); $i++,$i++) {

$code = ord($str{$i}) * 256 + ord($str{$i + 1});

if ($code < 128) {

$output .= chr($code);

} else if ($code != 65279) {

$output .= "&#".$code.";";

}

}

return $output;

}

?>

函数的参数中，$encode是源字符集，$str是需要进行转化的字符串。返回结果是转化以后字符串。

外链出处

若想明白jsp开发过程中为什么会产生中文乱码，我们先来看看unicode编码。

Unicode （统一码）顾名思义是一个将世界上各种文字统一在一起的东东。由美国各大电脑厂商组成的Unicode策进会来推动。目的，推广一个世界通用的编码体制，惊世界上所有常用的文字都涵盖进去，从而减少个电脑商开发国外市场遇到的问题。

为了将成千上万的文字统统收集到一个共同的编码机制下，在兼顾经济的原则下，不管是东方还是西方文字，每个字在Unicode中一律以两个Bytes来表示，这样至少有2的16次方65536种不同的组合，足以应付目前绝大多数场合的需要。

基本上，计算机只是处理数字。它们指定一个数字，来储存字母或其他字符。在创造Unicode之前，有数百种指定这些数字的编码系统。没有一个编码可以包含足够的字符：例如，单单欧州共同体就需要好几种不同的编码来包括所有的语言。即使是单一种语言，例如英语，也没有哪一个编码可以适用于所有的字母，标点符号，和常用的技术符号。

这些编码系统也会互相冲突。也就是说，两种编码可能使用相同的数字代表两个不同的字符，或使用不同的数字代表相同的字符。任何一台特定的计算机(特别是服务器)都需要支持许多不同的编码，但是，不论什么时候数据通过不同的编码或平台之间，那些数据总会有损坏的危险。

Unicode 给每个字符提供了一个唯一的数字，不论是什么平台，不论是什么程序，不论什么语言。Unicode标准已经被这些工业界的领导们所采用，例如： Apple, HP, IBM, JustSystem, Microsoft, Oracle, SAP, Sun, Sybase, Unisys和其它许多公司。最新的标准都需要Unicode，例如XML, Java, ECMAScript (JavaScript), LDAP, CORBA 3.0, WML等等，并且，Unicode是实现ISO/IEC 10646的正规方式。许多操作系统，所有最新的浏览器和许多其他产品都支持它。Unicode标准的出现和支持它工具的存在，是近来全球软件技术最重要的发展趋势。

将Unicode与客户服务器或多层应用程序和网站结合，比使用传统字符集节省费用。Unicode使单一软件产品或单一网站能够贯穿多个平台，语言和国家，而不需要重建。它可将数据传输到许多不同的系统，而无损坏。

在与Unicode相关的各技术文件中，经常会看到ISO 10646和UCS这两个名词。

ISO是位于瑞士的国际标准局的缩写。

UCS为ISO颁布的第10646号标准 Universal Character Set,就是世界通用字符集。

UCS 通用字符集采用4个Bytes来编码,将世界上所有的官用和商用编码大小通吃，一网打尽。Unicode自1991年便和ISO的UCS小组密切配合，让 Unicode和ISO 10646保持一致。因此Unicode 自2.0版开始，便和 ISO 10646-1使用相同的编码。

康熙字典中的汉字有4万7千，如果再加上里面没有的简体字，和不同写法的日文字，那么 Unicode6万多的分配空间，光用来分配汉字就显得捉禁见昼，更别说什么泰文，阿拉伯等其他文字了。针对这个问题Unicode和UCS采用了[中日韩文整合]（CJK Unification）的解决方案，把中日韩笔画详尽的汉字用同一个单码表示。

经过[中日韩文整合]的Unicode称为统汉字Unihan。

完整的Unicode4.0版可由http://www.unicode.org/Public/UNIDATA/Unihan.txt 下载。

UTF (Unicode/UCS Transformation Format),Unicode推荐使用UTF-8和UTF-16两种格式其中8和16指的是Bits数而不是Bytes数。

UTF-16基本就是Unicode双字节的实现，加上一个应付未来需要的扩充编码机制（很少用）

UTF-8 是一种不等幅的编码方式，英数字（Ascii字码）保持原状，完全不受影响（因此不需要做转换），而其他汉字资料须透过程序来转换，会[变胖]，因为每个字需要额外一个或两个Bytes来编码。

UCS字符集中，有UCS-2和UCS-4等编码方式其中的2和4指的是bytes数，对应UTF-8和UTF-16.

UCS-2基本和Unicode双byte 编码差不多

UCS-4四 byte编码表示一个字，在每个 UCS-2前面加上两个空白的Byte，便可得到对应的 UCS-4。

Unicode的空间分配：

以下Unicode区位码均以16进制表示

Unicode的前256个字符和ISO-8859-1(西欧字母)完全相同，其中前半段就是Ascii(u+0000到u+00FF)。每个ISO-8859-1码前面补上一个空byte(0x00)后才是相应的Unicode码。

和我们切身相关的Unihan主要分布在u+3400到u+F9FFF之间，GB2312和BIG5主要分布在u+4E00到U+9FFF之间。

UTF-8的编码原理和特性：

知道了西欧字符和汉字在Unicode中的位置后，来看看UTF-8

U+0000~U+007E 1 _ _ _ _ _ _ _ (7bits)

U+0080~U+07FF 1 1 0_ _ _ _ _ 1 0_ _ _ _ _ _ (11bits)

U+0800~U+FFFF 1 1 1 0 _ _ _ _ 1 0 _ _ _ _ _ _ 1 0 _ _ _ _ _ _ (16bits)

看一看Unicode三种格式提出自由的bits（下划线空位）是否足以用来代表区位中各Unicode码，刚好够用。

那么当程序处理UTF-8编码文件时，如何得知一个字符的疆界落在哪里？还有到底他是以三种形式那一中出现呢？

每个以UTF-8编码的字符，不管是以一、二、三个bytes出现，第一个byte前端都清楚地标示了该字符的byte总数。如110种有两个1，代表这种字符是以第二种方式出现，由两个bytes组成。而1110有三个1，表示这种字符一点种方式出现，由三个字节组成。

每个多重byte的UTF-8编码有一个共同的通性，即其中的第二个第三个byte, 一律以10两个bits开头。由于其中的最高位总设成1，可以很容易和那些在UTF-8中只用一个Byte的ASCII字元区分开来，方便侦错。

因为上述设计特点，UTF-8和Unicode之间，可以很容易做双向自由转换，而不会丢失任何资料。

解决办法：乱码问题在 NT操作系统我没怎么碰到过，但是在UNIX 或LINUX系统上出现的比较多

由于操作系统和使用环境不一样，产生乱码的方式也不一样，但是如果掌握了上面的Unicode 编码原理，自己仔细分析一下，很多问题便可迎刃而解。

下面看看几个常见的例子。

1． 如果一些网站服务器例如Tomcat 如果遇到中文乱码问题，可以修改conf目录下的server.xml

<Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" redirectPort="8443" acceptCount="100" debug="0"connectionTimeout="20000" disableUploadTimeout="true" URIEncoding="GBK"/>

URIENcoding 设成GBK或GB2312

2． 表单中或传递字符串：本来输入的汉字是正常的，但是提交后再显示出来是乱码，因为提交的一般是 ISO8859编码，所以显示的时候要转成GB2312编码：

String S=new String(rs.getString("news").getBytes("gb2312"),"ISO8859_1");

//rs为待转换的字符串

然后使用S字符串的值就可以了

3． 有的服务器端的语言环境如果设成简体中文的也可以解决此类问题

4． 插入数据库中的字符是乱码

看看数据库中支持的是何种编码方式，用类似2中的方式作一下转换即可。

5． 总之，用jsp开发，碰到乱码，你得分析是读的时候发生乱码，还是写的时候发生乱码，用2中的转换，基本就能解决问题，有些时候写的时候做一次转换，例如：

String S=new String(rs.getString("news").getBytes("gb2312"),"ISO8859_1");

//读的时候在转换回来

String S=new String(rs.getString("news").getBytes("ISO8859_1"),"GB2312");

或者把ISO8859-1和GB2312 的位置换一下，自己多试试，就能找到解决问题的办法。

你怎么解的别人愿意的话一目了然。至少也得是个编译过的java applet什么的吧。

也就是说，在服务器那里对内容加密，然后在客户端这里进行解密。

主要的问题是在于，服务器那里对中文的编码方式和浏览器的编码方式不一样。

在服务器端的改动（加密、编码）在浏览器那一端就不能正常解码。估计是除非服务器那端和客户这一段都是使用同样的编码方式才可以。

一时之间，服务器的编码暂时无法改动。

code＝？？？、