JNI中文处理问题小结

由于工作关系，需要利用JNI在C++与Java程序之间进行方法调用和数据传递，但以前总是在英文环境下工作，对中文（其他语言编码同理）问题反倒没有太关注，最近抽了点时间研究了一下，将自己的体会整理如下，供大家讨论或参考。

在进一步讨论之前，有几点基础知识需要说明：

在Java内部，所有的字符串编码采用的是Unicode即UCS-2。Unicode是用两个字节表示每个字符的字符编码方案。Unicode有一个特性：它包括了世界上所有的字符字形。所以，各个地区的语言都可以建立与Unicode的映射关系，而Java正是利用了这一点以达到异种语言之间的转换；

UTF-8是另一种不同于UCS-2/UCS-4的编码方案，其中UTF代表UCS Transformation Format，它采用变长的方式进行编码，编码长度可以是1~3（据说理论上最长可以到6，不懂）。

由于UCS-2/UCS-4编码定长的原因，编码产生的字符串会包含一些特殊的字符，如\0（即0x0，所有0~256的字符Unicode编码的第一个字节），这在有些情况下（如传输或解析时）会给我们带来一些麻烦，而且对于一般的英文字母浪费了太多的空间，此外，据说UTF-8还有Unicode所没有的纠错能力（不懂！），因此，Unicode往往只是被用作一种中间码，用于逻辑表示。关于Unicode/UTF-8的更多信息，见参考1；

Java中文乱码问题在很多情况下都可能发生：不同应用间，不同平台间等等，但以上问题已有大量优秀的文章讨论过，这里不作深入探讨，详见参考2、3、4、5。下面简要总结一下：

当我们使用默认编码方式保存源文件时，文件内容实际上是按照我们的系统设定进行编码保存的，这个设定值即file.encoding可以通过下面的程序获得：

public class Encoding { 　　public static void main(String[] args) { 　　　　System.out.println(System.getProperty("file.encoding")); 　　} }javac在不指定encoding参数时，如果区域设定不正确，则可能造成编/解码错误，这个问题在编译一个从别的环境传过来的文件时可能发生；

2、虽然在Java内部（即运行期间，Runtime）字符串是以Unicode形式存在的，但在class文件中信息是以UTF-8形式存储的（Unicode仅被用作逻辑表示中间码） ；

对于Web应用，以Tomcat为例，JSP/Servlet引擎提供的JSP转换工具（jspc）搜索JSP文件中用<%@ page contentType ="text/html; charset=<Jsp-charset>"%>指定的charset。如果在JSP文件中未指定<Jsp-charset>，则取系统默认的file.encoding（这个值在中文平台上是GBK），可通过控制面板的Regional Options进行修改；jspc用相当于“javac –encoding <Jsp-charset>”的命令解释JSP文件中出现的所有字符，包括中文字符和ASCII字符，然后把这些字符转换成Unicode字符，再转化成UTF-8格式，存为JAVA文件。

我曾经偶然将jsp文件存成UTF-8，而在文件内部使用的charset却是GB2312，结果运行时总是无法正常显示中文，后来转存为默认编码方式才正常。只要文件存储格式与JSP开头的charset设置一致，就都可以正常显示（不过将文件保存成UTF-16的情况下我还没有试验成功）；

在XML文件中，encoding表示的是文件本身的编码方式，如果这个参数设定与文件本身实际的编码方式不一致的话，则可能解码失败，所以应该总是将encoding设置成与文件编码方式一致的值；而JSP/HTML的charset则表示按照何种字符集来解码从文件中读取出来的字符串（在理解中文问题时应该把字符串理解成一个二进制或16进制的串，按照不同的charset可能映射成不同的字符）。

我曾经在网上就encoding的具体含义跟别人讨论过：如果encoding指的是文件本身的编码方式，那么读取该文件的应用

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!