用VSTS代码验证工具捕获C/C 错误[1]

　　尽管关于Java中文问题的讨论已相当多了，但由于Java的相关技术标准繁多，面向Java的Web服务器、应用服务器连同JDBC数据库驱动等都没有官方的标准，所以Java应用在处理中文时所存在的问题不但没有消失而且随着所选用的服务器、驱动程式连同运行环境等因素的不同而变化。那么我们如何从众多现象中找出问题所在，并进行分析和解决呢？和大部分的讨论不同，本文将主要从如何预测、发现和检查问题的角度给出建议，帮助研发人员找出可能引起问题的各种源头，从而更好地解决Java的中文问题。

　　引言

　　尽管对于Java中文处理问题的讨论已不乏其数，但由于Java技术涉及内容广（J2EE包含了十几种相关技术），技术供给商繁多，面向Java的Web服务器、应用服务器连同JDBC数据库驱动等都没有官方的标准，所以Java应用在处理中文过程中出了存在固有的问题外也存在随着选用的服务器，驱动程式的不同而带来的Java中文问题的多变性，增加了问题的复杂度。那么，我们如何在这么纷繁的现象中找到问题的症结呢？

　　Java中文问题的一般解决办法

　　事实上，Java的中文问题都是由于Java应用所采用的缺省编码格式和目标或应用所要读入字符的编码格式不同而造成的（具体参见文献1）。对于如何解决Java的中文问题，通常有四种方法：

　　1）选择JDK的中文本地化版本。尽管Java2 　　JDK的中文本地化版本（http://java.sun.com/products/jdk/1.2/chinesejdk.html）并不是个官方的版本，Sun公司也没有承诺会对该本地化版本进行升级，但其仍不失为一个Java中文问题的解决方案。

　　2）选择合适的编译参数。对于Java的国际版本来讲，我们也能够在编译Java应用的时候通过指定确定的编码机制来实现其编译结果对中文的支持。例如，对于需要支持繁体中文和简体中文应用能够通过javac -encoding big5 sourcefile.java 和javac -encoding gb2312 sourcefile.java来编译源程式。

　　3）通过编程的方式实现字符编码的转换代码。通过编程的方式来解决Java的中文问题，已成为了一种较为普遍的做法。下面就是一种最常见的字符编码转换函数，其将字符的编码格式转换为中文Windows系统的GBK编码形式。

　　public static String toChinese(String 　　strvalue){try{if(strvalue==null)return null;else{strvalue = new 　　String(strvalue.getBytes("ISO8859_1"), "GBK");return 　　strvalue;}}catch(Exception e){return null;}}

　　4）定义字符输出集。对于JSP应用，我们能够通过或来定义JSP页面的字符输出集。当然，我们也能够通过HTML的标记来定义字符的输出集。

　　存在的问题

　　根据方法实现的方式，我们能够将以上四种方法分为两类，一类是通过利用某些标准或规则来实现的方法，上面的1)、2)、4）都属于此类；一类是通过针对性的编程来实现的方法，上面所提的方法3）就属于此类。

　　由于方法1)，2)，4）是具备规范性的一类方法，所以方法比较简单，解决方案也不具备较大的针对性，较为通用，例如我们能够采用方法2）的编译方式通过编译Java源文档来实现内码的预置，而无需考虑源码到底有哪些部分出现了Java的中文处理问题，诸如输出乱码等等。

　　但是，正由于这些方法不具备针对性，解决问题的方法过于统一，所以在某些情况下，他们并不能完全地解决Java的中文问题。举一个很常见的例子。在通常情况下，用户的Java应用往往需要和其他Java应用接口进行交互，例如通过某种版本的JDBC访问数据库。由于JDBC的驱动所支持的编码随着提供商乃至版本的不同而不同，所以假如在数据库的输入输出过程中出现中文不能正确处理问题时，我们需要在数据的输入和输出过程做两次正好相反的编码转换，这对于方法1），2），4）来说，往往是无法解决的。当然，对于方法2，我们也能够通过采用一些技巧使来满足上面的情况，一个最有效的办法就是尽量将Java应用的各个部分组件化。例如我们能够通过将数据库的读入和输出代码分解在不同的源文档上来实现分别编译，从而满足不同的字符编码需要。但是通常的程式设计都不太可能满足这种需要，因为这种程式的划分结果很可能是不合理的。例如，我们将数据库的读出和写入方法封装到一个类中是比较合适的一种设计，但假如将该类的这两个方法分别实现在两个文档里则变得很不合理。因此对于1），2），4）方法来说，虽然实现比较简单，但却具备一些无法克服的缺点。这也是那些实现起来相对复杂的编程方法得以流行的原因。

　　相对于方法1），2），4）来说，方法3）具备更好的针对性和灵活性。程式能够根据不同的情况做出灵活的处理，在任何需要的地方进行字符的编码转换，但是该方法的特点也对软件的研发人员提出了更高需要--必须能够准确的捕获到有可能发生中文处理问题的地方，并做出正确的判断和处理。

　　分析的原则

　　总的说来，任何解决Java中文处理的方法都不是很复杂。相反的是，由于Java技术特别是J2EE技术涉及的内容繁多，各种Web服务器、应用服务器连同JDBC数据库驱动等参差不齐，所以如何正确而及时的发现应用的中文处理问题则变得相对复杂的多。那么我们如何来发现这些问题呢？

　　对一个C 本机代码(Native Code)研发者来说，Visual Studio Team System对整个软件研发周期都提供了支持，VSTS源代码注释使研发者在静态代码分析或单元测试中，能够用方法参数前置或后置的有效条件来注释方法，且当注释违例时，会有相应的编译器警告，所以，能够这样说，VSTS提供了许多功能来帮助本机程式研发者。本文将着眼于VSTS验证程式，他是个分析工具，用于监控非托管代码的执行，并能够发现如不正确的内存分配、句柄使用等等错误。

　　和此相比，动态分析是检查那些传递给系统函数的关键变量值，以发现问题的，当方法被调用时，将会探测到某些非法参数，并上报给研发者;而使用非法参数时，某些问题不能被发现，只会在后续情况如内存崩溃、非正常程式退出等情况显现出来。

[1] [2] [3]