从技术的角度来说，有必要提一下我们的调试环境。我们使用的是Windows XP操作系统 ，安装有JAVA 2 SDK 1.4.1，Apache SOAP 2.3.1，JAF 1.0.2，JavaMail 1.3.1和Xerces 2.6.0。上面所提及的都能在Tcomcat 4.1.29 JSP /Servlet 容器中正常运行。所有的软件都是免费自由软件，因此你能够很容易的下载 它们并自己在任何你喜欢的平台如Windows或UNIX上安装它们。Java SDK，JAF和JAVAMAIL位于SUN的官方网站（ http://java.sun.com ），其他的软件在Jakarta项目组的官方网站（ http://jakarta.apache.org ）上有down的。可能你在看到我们需要这么多不同的包（package）时已经有点担心和不安了，但是实际上你不应该担心这些的。一旦你懂了基础，那么对你将相当容易。安装不是一件很难的事情，你只需要在设置环境变量的时候仔细些，比如CATALINA_HOME , CLASSPATH , JAVA_HOME 等等，所有这些步骤都是手工的。由于我仅仅是想将你的注意力再次集中到它们身上，所以你能很快的就完成以上配置过程。我只是添加下面的一些字符串到Tomcat的bin/setclasspath.bat 文件中：

...
set CATALINA_HOME=C:\Tomcat4.1.29
set CLASSPATH=%JAVA_HOME%\lib\tools.jar
set CLASSPATH=%JAVA_HOME%\soap-2.3.1\lib\soap.jar
set CLASSPATH=%CLASSPATH%;%JAVA_HOME%\javamail-1.3.1\mail.jar
set CLASSPATH=%CLASSPATH%;%JAVA_HOME%\jaf-1.0.2\activation.jar
set CLASSPATH=%CLASSPATH%;%JAVA_HOME%\xerces-2_6_0\xercesImpl.jar
set CLASSPATH=%CLASSPATH%;%JAVA_HOME%\xerces-2_6_0\xercesSamples.jar
set CLASSPATH=%CLASSPATH%;%JAVA_HOME%\xerces-2_6_0\xml-apis.jar
set CLASSPATH=%CLASSPATH%;%JAVA_HOME%\xerces-2_6_0\xmlParserAPIs.jar
set CLASSPATH=%CLASSPATH%;%CATALINA_HOME%\common\lib\servlet.jar
set CLASSPATH=%CLASSPATH%;%CATALINA_HOME%\common\lib\tools.jar
...

如果你的安装路径（installation paths）和上面使用的不同，你需要更正它们，然后关闭和重启Tomcat以使它们生效。这样，你就有为运行SOAP作好了准备。但是现在，我要忘记有关的技术部分，来学一点理论知识。

SOAP意思是简单对象访问协议（S imple O bject A ccess P rotocol）。的确如它的名字一样，SOAP是很简单的。它是一个基于XML的协议，允许程序组件和应用程序彼此使用一种标准的Internet协议 --HTTP来通讯。SOAP是一种独立的平台，它不依赖程序语言，它是简单的，弹性的，很容易扩展的。目前，应用程序能够彼此使用一种基于DCOM和 CORBA技术的远程过程调用（RPC）来进行相互通讯，但HTTP不被设计为这个目的。RPC在Internet上应用是非常困难的，它们会出现许多兼容性和安全性的问题，因为防火墙 和代理服务器 通常都会阻断（block）这些类型的流量。应用程序之间最好的通讯方式是通过HTTP协议，因为HTTP是支持所有Internet浏览器和服务器的。基于这个目的，SOAP协议被创建出来。

那么，它们是如何运作的呢？比如，一个应用程序（A）需要和另一个应用程序（B）在SOAP的帮助下进行彼此通讯。它们将使用下面的框架图来完成这个过程：

这个SOAP信封（SOAP envelope）是一个包含以下内容的XML文档：

正如你看到的，它是非常简单的。它看起来确实就象一个普通的信封或者你的 email。你想看看它们是如何动作的吗？下面跟我们一起来吧。其实我们有很多方法是不用SOAP来在创建和运行我们自己的“Hello World”应用程序的，但是因为我们要保持它的简单性，我会给你一个它运作方式的框架图（scheme）。

我们的“Hello World”范例会包含一个SOAP Service。我们的SOAP Client将发送它们的名字到该SOAP Service，并试图得到一些答复或响应。这个SOAP Service需要部署到一个SOAP Admin的工具，以至重定位所有请求的SOAP（Proxy） RPC Router能够知道它们应该使用哪种服务来运作。总而言之，这个是以下面的方式来运作的：

现在，我们来一步步的看看到底发生了什么。在Step 1里，HelloWorldClient将连接一个SOAP RPC Router，请求我们的SOAP Service并将包含我们名字的一个字符串传递给它。该SOAP RPC Router会检查是否它已经部署了这个SOAP Service。如果它被发现是被部署的，那么它将传递数据到这个SOAP Service并调用特定的方法，这个是Step 2。然后SOAP Service方法会被执行，将返回某个字符串值（该值就是SOAP Client的答复或者响应）（Step 3）。在Step4中，SOAP RPC Router将仅仅只是重定向这个数据到SOAP Client。所有在Step1和Step4里传输的数据是通过SOAP Envelope来完成的。正如你所看到的，算法是相当简单的，因此我们只准备关心实际的代码。

首先，我们要创建一个SOAP Service。下面是它的代码，请不要忘记将它放入HelloWorld/ 目录中（必须被包含在你的CLASSPATH中）：

1: // SOAPService.java
2: package HelloWorld;
3: public class SOAPService {
4:   public String sayHi(String x) {
5:     return("Hello my friend, " + x + "! Glad to see you!");
6:   }
7: }

添加任何注释也是很容易的。要编译它，只需要用下列命令：

javac SOAPService.java

第二步，一旦我们准备好了SOAP Service，我们需要用SOAP Service Manager来部署它。这个可以通过很多方式来实现，但是为了能让初学SOAP的读者更容易理解SOAP，我提供了一个最容易的方式。我们假设你的Web Server（Tomcat或其他）已经正常运行，并且你已经正确安装了SOAP。那么当浏览器访问 http://localhost:8080/soap/ ，你会看见Apache SOAP的欢迎页面。点击Run the admin client ，然后 Deploy 。你会得到一个屏幕显示，在那里你需要填入ID，Scope，Method，Provider Type和JAVA Provider的信息到表单域中。你能忽略其他所有的表单域，除非你真的需要它们的信息。我们的“HelloWorld”例子不需要它们，所以，我们填的下面的值：

一些注释：ID是我们要从SOAP Client标识我们的SOAP Service的唯一名字。Method包含SOAP Service提供的一系列方法。JAVA Provider-Provider Class是SOAP Service Java类的名字。

现在，点击Deploy 按钮，那么你的服务会被部署。再次强调，请注意正确设置CLASSPATH环境变量。然后，你的HelloWorld.SOAPService类能够被找到，并且所有必需的jar包也能被找到。这是个几乎每个人都会犯的普通错误。现在，你能够点击 List ，将会看见你的服务已经被部署进来。恭喜！

最后，让我们来创建一个SOAP Client。代码看起来有点复杂，但是在现实中不会只有这么点长。

 1: // HelloWorldClient.java
2: import java.io.*;
3: import java.net

.*;
4: import java.util.*;
5: import org.apache.soap.*;
6: import org.apache.soap.rpc.*;
7: public class HelloWorldClient {
8:   public static void main(String[] arg) throws Exception {
9:     Call c = null;
10:     URL url = null;
11:     Vector params = null;
12:     Response rep = null;
13:     String ourName = "Superman";
14:     String ourUrn = "urn:HelloWorld_SOAPService";
15:     String ourMethod = "sayHi";
16:     url = new URL("http://localhost:8080/soap/Servlet

/
rpcrouter");
17:     System.out.println("Passing to our deployed "+ourUrn+"
our name ("+ourName+"): ");
18:     c = new Call();
19:     c.setTargetObjectURI(ourUrn);
20:     c.setMethodName(ourMethod);
21:     c.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);
22:     params = new Vector();
23:     params.addElement(new Parameter("ourName", String.class,
ourName, null));
24:     c.setParams(params);
25:     System.out.print("and its answer is: ");
26:     rep = c.invoke(url, "");
27:     if (rep.generatedFault()) {
28:       Fault fault = rep.getFault();
29:       System.out.println("\nCall failed!");
30:       System.out.println("Code = " + fault.getFaultCode());
31:       System.out.println("String = " + fault.getFaultString());
32:     } else {
33:       Parameter result = rep.getReturnValue();
34:       System.out.print(result.getValue());
35:       System.out.println();
36:     }
37:   }
38:}

下面我要做一些解释。在第13行，我们设置了我们的名字，这个名字将会传递给 SOAP Service。在第14行，我们设置了我们将要调用的服务的ID（service ID），和第15行里设置的服务方法（service method）。有了这个ID，服务能够被部署到SOAP服务管理器（SOAP Service Manager）中。我们没有设置任何其他值，仅仅只用刚才那些基础值就可以正常运作了。你能从SOAP的官方文档上得到相关信息，该文档来自SOAP包中，它们的解释超出了本文的范围。

用以下方式编译这个SOAP Client：

javac HelloWorldClient.java

为了圆满完成它，让我们检查一下针对我们的测试，是否所有事情都准备就绪。Tomcat正在运行，所有的环境变量都正确，SOAP Service被编译和部署，SOAP Client被成功编译。OK，让我们运行它，你将看到这个屏幕：

正如你所看到的，我们的SOAP Client使用SOAP协议成功发送它的名字和接收了一个答复。正如前面所说的，SOAP Service发送和接收的是SOAP envelope。这个是SOAP envelope的源代码。

被发送 到SOAP Service的SOAP Envelope

<?XML

version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/
soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/
XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHi xmlns:ns1="urn:HelloWorld_SOAPService"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/
soap/encoding/">
<ourName xsi:type="xsd:string">Superman</ourName>
</ns1:sayHi>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>:

从SOAP Service接收 的SOAP Envelope

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/
soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/
XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHiResponse xmlns:ns1="urn:HelloWorld_SOAPService"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.
org/soap/encoding/">
<return xsi:type="xsd:string">Hello my friend, Superman!
Glad to see you!</return>
</ns1:sayHiResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

要理解SOAP Envelope中的所有标签的含义，我建议你花一点时间阅读 http://www.w3.org/2001/06/soap-envelope 命名空间规范。

我希望本文能够在你理解SOAP技术上有一定帮助。这个技术是简单的，有趣的，强大的，弹性的。它被用在许多Web应用中，这些应用的数量也在不断增加。学习SOAP是值得的，至少你要知道它是什么和它是怎么运作的

华为彩信模拟器的参数设置

最近开发了一个SP的彩信接入系统，代码编写完成后，觉得有必要进行接发测试。从网上下载来华为彩信模拟器，测试过程中发现始终无法成功。不得已使用DJ Java Decompiler反汇编了一下代码，经过简单分析终于才了解到接发的URL地址和端口如何填写，真是不知道为什么华为不把文档写详细一点，搞得大家开发那么累。
1、mm7Config.xml中的ListenIP、ListenPort分别是接收彩信时的监听地址和端口，这里我使用了127.0.0.1和9080，对应华为彩信模拟器的Send to应该填写http://127.0.0.1:9080/Receiver。
2、mm7Config.xml中的mmscURL、mmscIP分别是彩信中心接收彩信时的URL和IP地址，这里我使用了/vas和127.0.0.1，对应华为彩信模拟器的Listener Port填写80即可。
这样对mm7Config.xml和华为彩信模拟器进行了适当的修改，启动自己开发的彩信接入系统。点击“Send”按钮，命令窗口还是报错，具体如下：
错误：“没有说明名称空间前缀“soap-env”。”
2009-6-24 17:20:05 com.sun.xml.internal.messaging.saaj.soap.MessageImpl writeTo
严重: SAAJ0540: Error during saving a multipart message
这个问题稍微麻烦一点，需要在系统属性中设置javax.xml.soap.MessageFactory和javax.xml.soap.SOAPConnectionFactory。实际上华为的彩信模拟器MMSCSimulation.exe是一个可执行的jar包，用WinRar将该文件展开到你的工作目录下，然后执行java -Xmx1024m -Xms1024m -Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.MessageFactoryImpl -Djavax.xml.soap.SOAPConnectionFactory=com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnectionFactory com.huawei.mms.simulation.MM7Simulation启动模拟器，就可以进行测试啦。

并非同类型协议

CMPP和SMPP都是短信协议中的一种，但它们不是同一类型的协议。SMPP和ESME和SMC（短信中心）之间的协议，而CMPP是SP和中国移动ISMG之间的通讯协议。

以下是CMPP 3.0文档中的图示。

<!--[if !vml]-->
<!--[endif]-->

与CMPP对应的协议有，联通的SGIP协议，中国电信的SMGP协议，网通的CNGP协议。

作为SP，只需要了解CMPP，不需要了解SMPP。

最新版本和兼容

SMPP协议是一个国际标准，有SMS论坛制定，官方网址为smsforum.net，截至2006年7月2日，最新版本是5.0。曾经流行的版本是3.3、3.4。SMPP协议向后兼容的。

CMPP最新版本似乎是3.0。现在（2006年7月），大多数还是使用CMPP 2.0。CMPP协议没有做到向后兼容，3.0的文档本身也没有讲到兼容的问题，甚至认为，协议制定者压根没想过要兼容。CMPP 3.0没做到向后兼容导致了一个问题，就是SP无法平滑升级。

PDU格式

PDU是协议数据单元的缩写，SMPP和CMPP都使用最先一个4位的长度标志整个PDU的长度。

SMPP Packet

消息头

必填参数

可选参数

CMPP Packet

消息头

消息体

<!--[if !vml]-->
<!--[endif]-->

SMPP是一个国际标准，不同的SMC的是实现可能要增加特定参数，为了具备更好的扩展性，SMPP 3.4以上版本，增加了可选参数，在5.0中，可选参数叫做TLVTable。

CMPP是中国移动定义的其内部ISMG之间、ISMG与SP之间的通讯标准，涉及一些具体的计费信息，但没有可选参数。

在SMPP中，消息头包括4部分：PDU长度、Command_Id、Command_Status、Sequence_Id。其中Command_Status字段，只在回应消息中使用，存在冗余。

CMPP中，消息头部包括3部分：PDU长度、Command_Id、Sequence_Id。个人认为，CMPP中的消息头，不包括Command_Status，似乎更好一些。

消息传输模式

SMPP和CMPP都支持异步传输，CMPP中，建议异步传输的窗口大小为16。

CMPP使用一个连接发送短信息和接收短信息。

SMPP支持多种的连接，其中TX类型的连接，只能发送短信息，RX类型的连接只能接收短信息，TRX类型的连接支持接收和发送短信息。

SMPP 3.4中，消息传输模式分三中：Store And Forward、Datagram、Forward。分别用在大吞吐量、可靠性保证等不同的应用场合。

CMPP没有规定其消息传输的模式，根据实际使用的情况看来，华为的网关的消息传输模式类似SMPP协议中规定的Datagram模式。

一个web中完全可以没有web.xml文件，也就是说，web.xml文件并不是web工程必须的。

那什么时候需要，什么时候可以不需要呢？

要想回答上面的问题，得先了解web.xml文件使用来干什么的。web.xml文件是用来配置：欢迎页、servlet、filter等的。当你的web工程没用到这些时，你可以不用web.xml文件来配置你的web工程。

那么web.xml能做的所有事情都有那些？

其实，web.xml的模式(Schema)文件中定义了多少种标签元素，web.xml中就可以出现它的模式文件所定义的标签元素，它就能拥有定义出来的那些功能。web.xml的模式文件是由Sun公司定义的，每个web.xml文件的根元素<web-app>中，都必须标明这个web.xml使用的是哪个模式文件。如：
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
</web-app>

而且web.xml的模式文件中定义的标签并不是定死的，模式文件也是可以改变的，一般来说，随着web.mxl模式文件的版本升级，里面定义的功能会越来越复杂，也即标签元素的种类会越来越多，但有些是不常用的，我们只需记住一些常用的就可以了。

下面列出web.xml常用的标签元素及这些标签元素的功能：

1、指定欢迎页面，例如：
<welcome-file-list>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
<welcome-file>index1.jsp</welcome-file>
</welcome-file-list>
上面的例子指定了2个欢迎页面，显示时按顺序从第一个找起，如果第一个存在，就显示第一个，后面的不起作用。如果第一个不存在，就找第二个，以此类推。

关于欢迎页面：

访问一个网站时，默认看到的第一个页面就叫欢迎页，一般情况下是由首页来充当欢迎页的。一般情况下，我们会在web.xml中指定欢迎页。但web.xml并不是一个Web的必要文件，没有web.xml，网站仍然是可以正常工作的。只不过网站的功能复杂起来后，web.xml的确有非常大用处，所以，默认创建的动态web工程在WEB-INF文件夹下面都有一个web.xml文件。
对于tomcat来说，当你只指定一个web的根名，没有指定具体页面，去访问时一个web时， 如果web.xml文件中配置了欢迎页，那么就返回指定的那个页面作为欢迎页，而在文中没有web.xml文件，或虽然有web.xml，但web.xml也没指定欢迎页的情况下，它默认先查找index.html文件，如果找到了，就把index.html作为欢迎页还回给浏览器。如果没找到index.html，tomcat就去找index.jsp。找到index.jsp就把它作为欢迎页面返回。而如果index.html和index.jsp都没找到，又没有用web.xml文件指定欢迎页面，那此时tomcat就不知道该返回哪个文件了，它就显示The requested resource (/XXX) is not available的页面。其中XXX表示web的根名。但如果你指定了具体页面，是可以正常访问的。

2、命名与定制URL。我们可以为Servlet和JSP文件命名并定制URL,其中定制URL是依赖一命名的，命名必须在定制URL前。下面拿serlet来举例：
(1)、为Servlet命名：
<servlet>
<servlet-name>servlet1</servlet-name>
<servlet-class>net.test.TestServlet</servlet-class>
</servlet>

(2)、为Servlet定制URL、
<servlet-mapping>
<servlet-name>servlet1</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>

3、定制初始化参数：可以定制servlet、JSP、Context的初始化参数，然后可以再servlet、JSP、Context中获取这些参数值。下面哪servlet来举例：
<servlet>
<servlet-name>servlet1</servlet-name>
<servlet-class>net.test.TestServlet</servlet-class>
<init-param>
<param-name>userName</param-name>
<param-value>Tommy</param-value>
</init-param>
<init-param>
<param-name>E-mail</param-name>
<param-value>Tommy@163.com</param-value>
</init-param>
</servlet>
经过上面的配置，在servlet中能够调用getServletConfig().getInitParameter("param1")获得参数名对应的值。

4、指定错误处理页面，可以通过“异常类型”或“错误码”来指定错误处理页面。
<error-page>
<error-code>404</error-code>
<location>/error404.jsp</location>
</error-page>
-----------------------------
<error-page>
<exception-type>java.lang.Exception<exception-type>
<location>/exception.jsp<location>
</error-page>

5、设置过滤器：比如设置一个编码过滤器，过滤所有资源
<filter>
<filter-name>XXXCharaSetFilter</filter-name>
<filter-class>net.test.CharSetFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>XXXCharaSetFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

6、设置监听器：
<listener>
<listener-class>net.test.XXXLisenet</listener-class>
</listener>

7、设置会话(Session)过期时间，其中时间以分钟为单位，假如设置60分钟超时：
<session-config>
<session-timeout>60</session-timeout>
</session-config>

除了这些标签元素之外，还可以往web.xml中添加那些标签元素呢，那些标签元素都能起什么作用呢？我们只要去查看web.xml的模式文件就能知道。直接看模式文件看不懂，可以找一些中文教程来看看。

a.Hashtable是继承自陈旧的Dictionary类的，HashMap继承自AbstractMap类同时是Java 1.2引进的Map接口的一个实现。
　　b.也许最重要的不同是Hashtable的方法是同步的，而HashMap的方法不是。这就意味着，然你可以不用采取任何特殊的行为就可以在一个 多线程的应用程序中用一个Hashtable，但你必须同样地为一个HashMap提供外同步。一个方便的方法就是利用Collections类的静态的synchronizedMap()方法，它创建一个线程安全的Map对象，并把它作为一个封装的对象来返回。这个对象的方法可以让你同步访问潜在的HashMap。这么做的结果就是当你不需要同步时，你不能切断Hashtable中的同步（比如在一个单线程的应用程序中），而且同步增加了很多处理费用。
　　c.第三点不同是，只有HashMap可以让你将空值作为一个表的条目的key或value。HashMap中只有一条记录可以是一个空的key，但任意数量的条目可以是空的value。这就是说，如果在表中没有发现搜索键，或者如果发现了搜索键，但它是一个空的值，那么get()将返回null。如果有必要，用containKey()方法来区别这两种情况。
　　d.HashMap去掉了Hashtable的contains方法，保留了containsValue和containsKey方法
　　e.Hashtable中hash数组默认大小是11，增加的方式是 old*2+1。HashMap中hash数组的默认大小是16，而且一定是2的指数

ArrayList和LinkedList区别
对于处理一列数据项,Java提供了两个类ArrayList和LinkedList,ArrayList的内部实现是基于内部数组Object[],所以从概念上讲,它更象数组，但LinkedList的内部实现是基于一组连接的记录,所以,它更象一个链表结构，所以,它们在性能上有很大的差别。
从上面的分析可知,在ArrayList的前面或中间插入数据时,你必须将其后的所有数据相应的后移,这样必然要花费较多时间，所以,当你的操作是在一列数据的后面添加数据而不是在前面或中间,并且需要随机地访问其中的元素时,使用ArrayList会提供比较好的性能
而访问链表中的某个元素时,就必须从链表的一端开始沿着连接方向一个一个元素地去查找,直到找到所需的元素为止，所以,当你的操作是在一列数据的前面或中间添加或删除数据,并且按照顺序访问其中的元素时,就应该使用LinkedList了。
如果在编程中,1，2两种情形交替出现,这时,你可以考虑使用List这样的通用接口,而不用关心具体的实现，在具体的情形下,它的性能由具体的实现来保证。
配置集合类的初始大小
在Java集合框架中的大部分类的大小是可以随着元素个数的增加而相应的增加的，我们似乎不用关心它的初始大小,但如果我们考虑类的性能问题时,就一定要考虑尽可能地设置好集合对象的初始大小,这将大大提高代码的性能。
比如,Hashtable缺省的初始大小为101,载入因子为0.75,即如果其中的元素个数超过75个,它就必须增加大小并重新组织元素，所以,如果你知道在创建一个新的Hashtable对象时就知道元素的确切数目如为110,那么,就应将其初始大小设为110/0.75=148,这样,就可以避免重新组织内存并增加大小

2、对于单个字符：ISO-8859-1单字节编码，GBK双字节编码，UTF-8三字节编码；因此中文平台(中文平台默认字符集编码GBK)下一个中文字符占2个字节，而英文平台(英文平台默认字符集编码Cp1252(类似于ISO-8859-1))。

3、getBytes()、getBytes(encoding)函数的作用是使用系统默认或者指定的字符集编码方式，将字符串编码成字节数组。

编码方式决定字节长度；在中文平台下，默认的字符集编码是GBK，此时如果使用getBytes()或getBytes("GBK")，则按照GBK的编码规则将每个中文字符用2个byte表示。所以我们看到"中文"最终GBK编码结果就是： -42 -48 -50 -60 。-42和-48代表了"中"字，而"-50"和"-60"则代表了"文"字。

在中文平台下，如果指定的字符集编码是UTF-8，那么按照UTF-8对中文的编码规则：每个中文用3个字节表示，那么"中文"这两个字符最终被编码成：-28 -72 -83、-26 -106 -121两组。每3个字节代表一个中文字符。

在中文平台下，如果指定的字符集编码是ISO-8859-1，由于此字符集是单字节编码，所以使用getBytes("ISO-8859-1")时，每个字符只取一个字节，每个汉字只取到了一半的字符。另外一半的字节丢失了。由于这一半的字符在字符集中找不到对应的字符，所以默认使用编码63代替，也就是?。

在英文平台下，默认的字符集编码是Cp1252(类似于ISO-8859-1)，如果使用GBK、UTF-8进行编码，得到的字节数组依然是正确的(GBK4个字节，UTF-8是6个字节)。因为在JVM内部是以Unicode存储字符串的，使用getBytes(encoding)会让JVM进行一次Unicode到指定编码之间的转换。对于GBK，JVM依然会转换成4个字节，对于UTF-8，JVM依然会转换成6个字节。但是对于ISO-8859-1，则由于无法转换(2个字节--->1个字节，截取了一半的字节)，所以转换后的结果是错误的。

在中文平台下，默认的字符集编码是GBK，于是content.getBytes()得到的是什么呢？就是下面这4个字节：

byte[0] = -42 hex string = ffffffd6

byte[1] = -48 hex string = ffffffd0

byte[2] = -50 hex string = ffffffce

byte[3] = -60 hex string = ffffffc4

如果新的encoding是GBK，那么经过解码后，由于一个字符用2个字节表示。于是最终的结果就是：

char[0]='中' --- byte[0] + byte[1]

char[1]='文' --- byte[2] + byte[3]

如果新的encoding是ISO-8859-1，那么经过解码后，由于一个字符用1个字节表示，于是原来本应该2个字节一起解析的变成单个字节解析，每个字节都代表了一个汉字字符的一半。这一半的字节在ISO-8859-1中找不到对应的字符，就变成了"?"了，最终的结果：

char[0]='?' ---- byte[0]

char[1]='?' ---- byte[1]

char[2]='?' ---- byte[2]

char[3]='?' ---- byte[3]

如果新的encoding是UTF-8，那么经过解码后，由于一个字符用3个字节表示，于是原来4个字节的数据无法正常的解析成UTF-8的数据，最终的结果也是每一个都变成"?"。

char[0]='?' ---- byte[0]

char[1]='?' ---- byte[1]

char[2]='?' ---- byte[2]

char[3]='?' ---- byte[3]

如果是在英文平台下，由于默认的编码方式是Cp1252，于是content.getBytes()得到的字节都是被截去一半的残留字符，所以我们看到在英文平台下，不论指定的encoding是GBK、UTF-8，其结果和ISO-8859-1都是一样的。

记住：这个方法再次证明了String的getBytes()方法的危险性，如果我们使用new String(str.getBytes(), encoding)对字符串进行重新编码解码时，我们一定要清楚str.getBytes()方法返回的字节数组的长度、内容到底是什么，因为在接下来使用新的encoding进行编码解码时，Java并不会自动地对字节数组进行扩展以适应新的encoding。而是按照新的编码方法直接对该字节数组进行解析。于是结果就像上面的例子一样，同样是4个原始字节，有些每2个一组进行解析，有些每个一组进行解析，有些每3个一组进行解析。其结果就只能看那种编码方式合适了。

结论：相同的平台下，同一个中文字符，在不同的编码方式下，得到的是完全不同的字节数组。这些字节数组有可能是正确的(只要该字符集支持中文)，也可能是完全错误的(该字符集不支持中文)。

记住：不要轻易地使用或滥用String类的getBytes(encoding)方法，更要尽量避免使用getBytes()方法。因为这个方法是平台依赖的，在平台不可预知的情况下完全可能得到不同的结果。如果一定要进行字节编码，则用户要确保encoding的方法就是当初字符串输入时的encoding。

———————————————————————————————————————————————————

和getBytes(encoding)不同，toCharArray()返回的是"自然字符"。但是这个"自然字符"的数目和内容却是由原始的编码方式决定的。

FileWriter是字符流输出流，而OutputStreamWriter是字节流输出流在中文平台下，如果使用FileWriter，不论你如何设置字符集都不会起作用。因为它采用的是默认的系统字符集。即便你设置了System.setProperty("file.encoding", "ISO-8859-1")，或者在运行时给予参数-Dfile.encoding=UTF-8都不会起作用。你会发现它最终还是都已"GB2312"或者"GBK"的方式保存。

在中文平台下，如果使用OutputStreamWriter，则在后台写入时会把字符流转换成字节流，此时指定的编码字符集就起作用了。可以看到在指定GBK、UTF-8的情况下中文可以正常的保存和读取，同时文件按照我们给定的方式保存了。而对于ISO-8859-1则变成了?，这再次证明了采用ISO-8859-1是不能保存中文的，而且会因为中文编码在ISO-8859-1的编码中找不到对应的字符而默认转换成?。

在英文平台下，如果使用FileWriter，不论你如何设置字符集同样都不会起作用。所有的文件都将按照ISO-8859-1的编码方式保存，毫无疑问地变成了?。在英文平台下，如果使用OutputStreamWriter，则只有当我们把字符和文件的编码方式正确设置为GBK、UTF-8的情况下，中文才能正确的保存并显示。

通过上述的实验证明，为了确保在不同的平台下，客户端输入的中文可以被正确地解析、保存、读取。最好的办法就是使用OutputStreamWriter配合UTF-8编码。如果不想使用UTF-8编码，那么可以考虑使用GB2312，不建议使用GBK、GB18030。因为对于某些老式的文本编辑器，甚至不支持GBK、GB18030的编码，但是对于GB2312则是一定支持的。因为前两者都不是国标但后者是。

关于String的getBytes()，getBytes(encoding)和new String(bytes, encoding)这三个方法，非常值得注意：A.getBytes()：使用平台默认的编码方式(通过file.encoding属性获取)方式来将字符串转换成byte[]。得到的是字符串最原始的字节编码值。

B.getBytes(NAME_OF_CHARSET)：使用指定的编码方式将字符串转换成byte[]，如果想要得到正确的字节数组，程序员必须给出正确的NAME_OF_CHARSET。否则得到的就不会得到正确的结果。

C.new String(bytes, encoding)：如果我们在客户端使用UTF-8编码的JSP页面发出请求，浏览器编码后的UTF-8字节会以ISO-8859-1的形式传递到服务器端。所以要得到经HTTP协议传输的原始字节，我们需要先调用getBytes("ISO-8859-1")得到原始的字节，但由于我们客户端的原始编码是UTF-8，如果继续按照ISO-8859-1解码，那么得到的将不是一个中文字符，而是3个乱码的字符。所以我们需要再次调用new String(bytes,"UTF-8")，将字节数组按照UTF-8的格式，每3个一组进行解码，才能还原为客户端的原始字符。

D.String的getBytes()、getBytes(NAME_OF_CHARSET)方法都是比较微妙的方法，原则上：传输时采用的是什么编码，我们就需要按照这种编码得到字节。new String(bytes, NAME_OF_CHARSET)则更加需要小心，原则上：客户端采用的是什么编码，那么这里的NAME_OF_CHARSET就必须和客户端保持一致。例如JSP页面是GBK，那么我们接收页面传递而来的参数时就必须使用new String(parameter.getBytes("ISO-8859-1"), "GBK");如果使用了错误的解码方式，如使用了UTF-8，那么得到的很有可能就是乱码了。也就是说：GBK--->ISO-8859-1--->GBK、UTF-8--->ISO-8859-1--->UTF-8的转换过程是没有问题的。但是GBK--->ISO-8859-1--->UTF-8、UTF-8--->ISO-8859-1--->GBK的字节直接转码则可能导致乱码，需要另外的转换过程。

记住：谨慎地使用getBytes(NAME_OF_CHARSET)和new String(bytes, NAME_OF_CHARSET)，除非你很清楚的知道原始的字符编码和传输协议使用的编码。推荐使用基于服务器的配置、过滤器设置request/response的characterEncoding、content type属性。还有就是JSP页面的pageEncoding属性、HTML meta元素的content type属性。尽量避免频繁的在代码中进行字符串转码，即降低了效率又增加了风险。

问题：我们在web应用开发过程中经常遇到输出某种编码的字符，如iso8859-1等，如何输出一个某种编码的字符串？

GBK
10
-50
utf-8
15
-26
???????ú??
我是中国人