在发布Web服务 的时候,WSDL 作为服务的描述,里面有一个标签可以写入中文 ,是用来作为注解来写入描述性信息的,这个标签就是<wsdl:documentation> 。OECP平台中使用开源ESB总线mule 来做webService 发布使用.发布时就遇到了中文 描述乱码 问题,经过一天多的时间来翻阅mule和cxf的源代码,问题最终被解决。这里记录一下解决的过程和方法。
mule 内使用的spring-cxf来将一个java方法转换为webService 。cxf有一个annotation是生成wsdl 中的<wsdl:documentation> 标签用的,这个annotation就是@WSDLDocumentation 。但是这个标签使用后,生成的WSDL 文件,中文 却显示成了乱码 。
经过测试发现,单纯使用Spring-cxf时,@WSDLDocumentation 不会产生乱码 。这就说明问题出在mule 上。只能翻一下mule 的 源代码来查找原因了。由于找不到与当前使用的jar包版本相同的源代码,只能使用升级版的源码,调试的时候发现升级的改动比较大,删掉的以前的一些方法和 代码修改也蛮多,错行缺行导致调试可读性极差,让我一直看了一天多。比较安慰的是最终还是找到了问题原因并解决了。下面就具体说一下原理。运费
我们知道发布WebService 以后,使用url+?wsdl的方式访问,将会获取到服务描述文件wsdl 文件.mule 中发布服务后,
ByteArrayOutputStream使用buffer中所有的byte创建并返回了一个String对象。这里注意,创建String的时候并没 有指定编码格式。那么它用的是什么编码格式?我们去String中看看,String使用了StringCoding来转化byte为char数组,而其 中选用的编码格式是从Charset.defaultCharset()得来的。从JDK的API中我们能找到了这个方法,上面是这么说的:
在我们的服务器运行环境中得到的默认编码 格式为GBK。于是乱码形成的原因找到了:由于Spring-cxf生成服务的wsdl 时用的是UTF-8编码,而被mule 错误的使用了服务器运行环境默认编码GBK,所以UTF-8下的正常显示中文 最终被显示为乱码 了。
mule 中的类CxfInboundMessageProcessor第201行:
msg = out.toString();
这就是乱码 产生的根源,在将字节流转为字符串的时候,没有指定编码格式,而默认使用了GBK,就是wsdl 文件乱码 的原因。
解决这个问题又两种方案:
1. 改变jvm的默认字符编码。
2. 修改CxfInboundMessageProcessor类的源代码。
第一种方案通过修改服务器的启动参数,追加一段“-Dfile.encoding=UTF-8”,就可以改变服务器的java运行环境。此时启动服务器时我们会发现,虽然我们的WSDL中文不再出现乱码了,但是服务器控制台显示的中文 却全都成了乱码 。我猜是服务器的日志输出依赖于操作系统的默认字符集吧。暂且不说这个日志乱码 问题,即使不存在这个问题我认为这种方案也是不太合适的。wsdl 是否出现乱码依赖于运行服务器的默认字符集,对于OECP平台来说是不可控的。OECP平台使用什么样的字符编码应该依赖于应用自己的配置。
于是决定修改mule 的源代码,比较幸运的是CxfInboundMessageProcessor这个类,在升级的过程中没有改动,不然就要反编译来获取源码了。
将201行的msg = out.toString();修改为如下代码:
从mule 的配置中得到配置的编码格式,并在将Stream转换为String的时候指定使用此编码格式.至此问题解决了.
我们可以在使用mule发布服务时,使用WSDLDocumentation 标签来为服务添加描述了.wsdl 作为WebService 的描述,如果没有注释性的文字,wsdl 描述可读性实在不是很好. WSDLDocumentation 标签就是作为这种描述存在的,如果你想在WSDL 中加入中文 的描述这个标签应该是唯一的选择.如果你使用的也是mule ,也遇到了中文 的乱码 问题,希望可上面的内容可以帮助你。