1、中文问题的来源

    计算机最初的操作系统支持的编码是单字节的字符编码，于是，在计算机中一切处理程序最初都是以单字节编码的英文为准进行处理。随着计算机的发展，为了适应世界其它民族的语言（当然包括我们的汉字），人们提出了UNICODE编码，它采用双字节编码，兼容英文字符和其它民族的双字节字符编码，所以，目前，大多数国际***的软件内部均采用UNICODE编码，在软件运行时，它获得本地支持系统（多数时间是操作系统）默认支持的编码格式，然后再将软件内部的 UNICODE转化为本地系统默认支持的格式显示出来。Java的JDK和JVM即是如此，我这里说的JDK是指国际版的JDK，我们大多数程序员使用的是国际化的JDK版本，以下所有的JDK均指国际化的JDK版本。我们的汉字是双字节编码语言，为了能让计算机处理中文，我们自己制定的gb2312、 GBK、GBK2K等标准以适应计算机处理的需求。所以，大部分的操作系统为了适应我们处理中文的需求，均定制有中文操作系统，它们采用的是GBK, GB2312编码格式以正确显示我们的汉字。如：中文Win2K默认采用的是GBK编码显示，在中文WIN2k中保存文件时默认采用的保存文件的编码格式也是GBK的，即，所有在中文WIN2K中保存的文件它的内部编码默认均采用GBK编码，注意：GBK是在GB2312基础上扩充来的。

    由于Java语言内部采用UNICODE编码，所以在JAVA程序运行时，就存在着一个从UNICODE编码和对应的操作系统及浏览器支持的编码格式转换输入、输出的问题，这个转换过程有着一系列的步骤，如果其中任何一步出错，则显示出来的汉字就会出是乱码，这就是我们常见的JAVA中文问题。

    同时，Java是一个跨平台的编程语言，也即我们编写的程序不仅能在中文windows上运行，也能在中文Linux等系统上运行，同时也要求能在英文等系统上运行（我们经常看到有人把在中文win2k上编写的JAVA程序，移植到英文Linux上运行）。这种移植操作也会带来中文问题。

    还有，有人使用英文的操作系统和英文的IE等浏览器，来运行带中文字符的程序和浏览中文网页，它们本身就不支持中文，也会带来中文问题。

    几乎所有的浏览器默认在传递参数时都是以UTF-8编码格式来传递，而不是按中文编码传递，所以，传递中文参数时也会有问题，从而带来乱码现象。

    总之，以上几个方面是JAVA中的中文问题的主要来源，我们把以上原因造成的程序不能正确运行而产生的问题称作：JAVA中文问题。

　　2、JAVA编码转换的详细过程

    我们常见的JAVA程序包括以下类别：
     *直接在console上运行的类(包括可视化界面的类)
     *JSP代码类（注：JSP是Servlets类的变型）
     *Servelets类
     *EJB类
     *其它不可以直接运行的支持类

    这些类文件中，都有可能含有中文字符串，并且我们常用前三类JAVA程序和用户直接交互，用于输出和输入字符，如：我们在JSP和Servlet中得到客户端送来的字符，这些字符也包括中文字符。无论这些JAVA类的作用如何，这些JAVA程序的生命周期都是这样的：

    *编程人员在一定的操作系统上选择一个合适的编辑软件来实现源程序代码并以.java扩展名保存在操作系统中，例如我们在中文win2k中用记事本编辑一个java源程序；
     *编程人员用JDK中的javac.exe来编译这些源代码，形成.class类(JSP文件是由容器调用JDK来编译的)；
     *直接运行这些类或将这些类布署到WEB容器中去运行，并输出结果。
    那么，在这些过程中，JDK和JVM是如何将这些文件如何编码和解码并运行的呢？

这里，我们以中文win2k操作系统为例说明JAVA类是如何来编码和被解码的。

    第一步，我们在中文win2k中用编辑软件如记事本编写一个Java源程序文件(包括以上五类JAVA 程序)，程序文件在保存时默认采用了操作系统默认支持GBK编码格式(操作系统默认支持的格式为file.encoding格式)形成了一个.java文件，也即，java程序在被编译前，我们的JAVA源程序文件是采用操作系统默认支持的file.encoding编码格式保存的，java源程序中含有中文信息字符和英文程序代码；要查看系统的file.encoding参数，可以用以下代码：
　　public class ShowSystemDefaultEncoding {
　　public static void main(String[] args) {
　　String encoding = System.getProperty("file.encoding");
　　System.out.println(encoding);
　　}}

    第二步，我们用JDK的javac.exe文件编译我们的Java源程序，由于JDK是国际版的，在编译的时候，如果我们没有用-encoding参数指定我们的 JAVA源程序的编码格式，则javac.exe首先获得我们操作系统默认采用的编码格式，也即在编译java程序时，若我们不指定源程序文件的编码格式，JDK首先获得操作系统的file.encoding参数(它保存的就是操作系统默认的编码格式，如WIN2k，它的值为GBK)，然后JDK就把我们的java源程序从file.encoding编码格式转化为JAVA内部默认的 UNICODE格式放入内存中。然后，javac把转换后的unicode格式的文件进行编译成.class类文件，此时.class文件是 UNICODE编码的，它暂放在内存中，紧接着，JDK将此以UNICODE编码的编译后的class文件保存到我们的操作系统中形成我们见到的. class文件。对我们来说，我们最终获得的.class文件是内容以UNICODE编码格式保存的类文件，它内部包含我们源程序中的中文字符串，只不过此时它己经由file.encoding格式转化为UNICODE格式了。

    这一步中，对于JSP源程序文件是不同的，对于JSP，这个过程是这样的：即WEB容器调用JSP编译器，JSP编译器先查看JSP文件中是否设置有文件编码格式，如果JSP文件中没有设置JSP文件的编码格式，则JSP编译器调用JDK先把JSP文件用JVM默认的字符编码格式(也即WEB容器所在的操作系统的默认的file.encoding)转化为临时的Servlet类，然后再把它编译成UNICODE格式的class类，并保存在临时文件夹中。如：在中文win2k上，WEB容器就把JSP文件从GBK编码格式转化为UNICODE格式，然后编译成临时保存的Servlet类，以响应用户的请求。

    第三步，运行第二步编译出来的类，分为三种情况：

    A、 直接在console上运行的类
    B、 EJB类和不可以直接运行的支持类(如JavaBean类)
    C、 JSP代码和Servlet类
    D、 JAVA程序和数据库之间
    下面我们分这四种情况来看。
    A、直接在console上运行的类

    这种情况，运行该类首先需要JVM支持，即操作系统中必须安装有JRE。运行过程是这样的：首先java启动JVM，此时JVM读出操作系统中保存的 class文件并把内容读入内存中，此时内存中为UNICODE格式的class类，然后JVM运行它，如果此时此类需要接收用户输入，则类会默认用 file.encoding编码格式对用户输入的串进行编码并转化为unicode保存入内存（用户可以设置输入流的编码格式）。程序运行后，产生的字符串（UNICODE编码的）再回交给JVM，最后JRE把此字符串再转化为file.encoding格式(用户可以设置输出流的编码格式)传递给操作系统显示接口并输出到界面上。

    对于这种直接在console上运行的类，它的转化过程可用图1更加明确的表示出来：

图1

以上每一步的转化都需要正确的编码格式转化，才能最终不出现乱码现象。

    B、EJB类和不可以直接运行的支持类(如JavaBean类)

    由于EJB类和不可以直接运行的支持类，它们一般不与用户直接交互输入和输出，它们常常与其它的类进行交互输入和输出，所以它们在第二步被编译后，就形成了内容是UNICODE编码的类保存在操作系统中了，以后只要它与其它的类之间的交互在参数传递过程中没有丢失，则它就会正确的运行。
这种EJB类和不可以直接运行的支持类, 它的转化过程可用图2更加明确的表示出来：

图2

    C、JSP代码和Servlet类

    经过第二步后，JSP文件也被转化为Servlets类文件，只不过它不像标准的Servlets一校存在于classes目录中，它存在于WEB容器的临时目录中，故这一步中我们也把它做为Servlets来看。

    对于Servlets，客户端请求它时，WEB容器调用它的JVM来运行Servlet，首先，JVM把Servlet的class类从系统中读出并装入内存中，内存中是以UNICODE编码的Servlet类的代码，然后JVM在内存中运行该Servlet类，如果Servlet在运行的过程中，需要接受从客户端传来的字符如：表单输入的值和URL中传入的值，此时如果程序中没有设定接受参数时采用的编码格式，则WEB容器会默认采用ISO-8859- 1编码格式来接受传入的值并在JVM中转化为UNICODE格式的保存在WEB容器的内存中。Servlet运行后生成输出，输出的字符串是 UNICODE格式的，紧接着，容器将Servlet运行产生的UNICODE格式的串（如html语法，用户输出的串等）直接发送到客户端浏览器上并输出给用户，如果此时指定了发送时输出的编码格式，则按指定的编码格式输出到浏览器上，如果没有指定，则默认按ISO-8859-1编码发送到客户的浏览器上。这种JSP代码和Servlet类，它的转化过程可用图3更加明确地表示出来：

图3

D、Java程序和数据库之间

    对于几乎所有数据库的JDBC驱动程序，默认的在JAVA程序和数据库之间传递数据都是以ISO-8859-1为默认编码格式的，所以，我们的程序在向数据库内存储包含中文的数据时，JDBC首先是把程序内部的UNICODE编码格式的数据转化为ISO-8859-1的格式，然后传递到数据库中，在数据库保存数据时，它默认即以ISO-8859-1保存，所以，这是为什么我们常常在数据库中读出的中文数据是乱码。
    对于JAVA程序和数据库之间的数据传递，我们可以用图4清晰地表示出来

                                                                    图4

    3、分析常见的JAVA中文问题几个必须清楚的原则

    首先，经过上面的详细分析，我们可以清晰地看到，任何JAVA程序的生命期中，其编码转换的关键过程是在于：最初编译成class文件的转码和最终向用户输出的转码过程。
    其次，我们必须了解JAVA在编译时支持的、常用的编码格式有以下几种：
    *ISO-8859-1，8-bit, 同8859_1,ISO-8859-1,ISO_8859_1等编码
    *Cp1252，美国英语编码，同ANSI标准编码
    *UTF-8，同unicode编码
    *GB2312，同gb2312-80,gb2312-1980等编码
    *GBK , 同MS936，它是gb2312的扩充
    及其它的编码，如韩文、日文、繁体中文等。同时，我们要注意这些编码间的兼容关体系如下：
    unicode和UTF-8编码是一一对应的关系。GB2312可以认为是GBK的子集，即GBK编码是在gb2312上扩展来的。同时，GBK编码包含了20902个汉字，编码范围为：0x8140-0xfefe，所有的字符可以一一对应到UNICODE2.0中来。

    再次，对于放在操作系统中的.java源程序文件，在编译时，我们可以指定它内容的编码格式，具体来说用-encoding来指定。注意：如果源程序中含有中文字符，而你用-encoding指定为其它的编码字符，显然是要出错的。用-encoding指定源文件的编码方式为GBK或gb2312，无论我们在什么系统上编译含有中文字符的JAVA源程序都不会有问题，它都会正确地将中文转化为UNICODE存储在class文件中。
    
    然后，我们必须清楚，几乎所有的WEB容器在其内部默认的字符编码格式都是以ISO-8859-1为默认值的，同时，几乎所有的浏览器在传递参数时都是默认以UTF-8的方式来传递参数的。所以，虽然我们的Java源文件在出入口的地方指定了正确的编码方式，但其在容器内部运行时还是以ISO-8859- 1来处理的。

一  .  对于Spring的容器管理,首先得知道什么是容器管理.

          java是一门面向对象的语言,在代码里,粗略的讲一个对象的体现就是一个类(class)的实例.也可以说就是一个JavaBean.在一个实际工程中,像这样的对象或实例会存在很多,并且每个对象的状态,作用范围,以及它们之间的关系(在Spring中为依赖)是很复杂的,所以要管理它们也是很大的开销.而在spring中,对与它们的管理就是容器管理.你可以看作容器就是这些bean的集合. 管理的方面主要有bean的创建,周期(作用域)和初始属性(注入),以及bean之间相互依赖的关系等.用比较专业的话就是------管理对象对其进行实例化、配置以及组装.
                  
                                                                                                                                                      Spring IoC 容器

二 .  容器的运作.
                  在Spring包的有两个很重要的东西,org.springframework.beans及org.springframework.context包,这两个包是IOC的基础包,自然也是运行IOC容器的关键.而其中关键的关键就是分别在两个包里的BeanFactory和ApplicationContext,其中BeanFactory提供了配制框架及基本功能,  而 ApplicationContext则是它的扩展,这个扩展是针对企业级别的,当中加入很多了企业级的支持,功能得到了进一步增强，比如更易与Spring AOP集成、消息资源处理(国际化处理)、事件传递及各种不同应用层的context实现(如针对web应用的WebApplicartionContext).
    1 . 实例化容器:
       在项目工程中用于实例化容器的类一般都是ApplicationContext以及他的扩展WebApplicationContext,当然BeanFactory也能用.
       在代码中一般是:

				

						//1.
 Resource resource = new FileSystemResource("beans.xml");
BeanFactory factory = new XmlBeanFactory(resource);
//2.
ClassPathResource resource = new ClassPathResource("beans.xml");
BeanFactory factory = new XmlBeanFactory(resource);
//3.
ApplicationContext context = new ClassPathXmlApplicationContext(
        new String[]{"applicationContext.xml", "applicationContext-part2.xml"});
// of course, an ApplicationContext is just a BeanFactory
BeanFactory factory = (BeanFactory) context;  
//4.                   
ApplicationContext context = new FileSystemXmlApplicationContext("src\\beans.xml");
		

             实际的项目中,上述的实例化方法一般都是用于非Web工程(c/s)或者测试代码中而在web工程内一般用的是ApplicationContext,实例化它只是在web配置文件(web.xml)里写入配置信息: 
               

 <!--         必须                -->
<context-param>
  <param-name>contextConfigLocation</param-name>
  <param-value>/WEB-INF/daoContext.xml /WEB-INF/applicationContext.xml</param-value>
</context-param>

    <!--         下面的listener 和 servlet 是两个相同效果的配置 ,只能选其一,只是listener 不能在与Servlet 2.2兼容的web容器中使用,
                  但在都可用的情况下,官方推崇首选 listener    -->

<listener>
  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<!-- or use the ContextLoaderServlet instead of the above listener     -->

<servlet>
  <servlet-name>context</servlet-name>
  <servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>

         2. 容器的使用:
            一般这是在代码级创建了IOC容器后(就是上述的(1)),或者是获得了容器的"引用"后用(这里其实是beanFactory和ApplicationContext的实现类的引用 如:);

InputStream is  =   new  FileInputStream( " beans.xml " );
BeanFactory factory  =   new  XmlBeanFactory(is);

1. boolean containsBean(String) ：如果BeanFactory包含给定名称的bean定义(或bean实例)，则返回true
2. Object getBean(String) ：返回以给定名字注册的bean实例。根据bean的配置情况，如果为singleton模式将返回一个共享的实例，否则将返回一个新建的实例。如果没有找到指定的bean，该方法可能会抛出BeansException异常(实际上将抛出NoSuchBeanDefinitionException异常)，在对bean进行实例化和预处理时也可能抛出异常
3. Object getBean(String, Class) ：返回以给定名称注册的bean实例，并转换为给定class类型的实例，如果转换失败，相应的异常(BeanNotOfRequiredTypeException)将被抛出。上面的getBean(String)方法也适用该规则。
4. Class getType(String name) ：返回给定名称的bean的Class。如果没有找到指定的bean实例，则抛出NoSuchBeanDefinitionException异常。
5. boolean isSingleton(String) ：判断给定名称的bean定义(或bean实例)是否为singleton模式，如果bean没找到，则抛出NoSuchBeanDefinitionException异常。
6. String[] getAliases(String) ：返回给定bean名称的所有别名。

     上面六点,都是在BeanFactory中的基本和一些简单的用法,但在将其扩展后了的ApplicationContext中加入了企业级的功能,比如国际化,资源访问等,这些我将在学习Spring
      XML格式的元数据配置中学习.

    三  .  配置元数据
           我自己的理解: 配置元数据的作用就是Spring管理Bean对象关系和资源文件的"规章制度",它是告诉IOC容器如何去组织对象和对象之间的关系是怎样的.
           目前,Spring支持三种配置元数据格式：XML格式、Java属性文件格式或使用Spring公共API编程实现。很显然,XML是现在最方便和容易编写的配置元数据.
        在Spring的XMl配置元数据格式为:
          

<? xml version = " 1.0 "  encoding = " UTF-8 " ?>
< beans xmlns = " http://www.springframework.org/schema/beans "
       xmlns:xsi = " http://www.w3.org/2001/XMLSchema-instance "
       xsi:schemaLocation = " http: // www.springframework.org/schema/beans  http://www.springframework.org/schema/beans/spring-beans-2.0.xsd ">
   < bean id = "XXX "   class = "XXX " >
     <!--  collaborators and configuration  for   this  bean go here  -->
   </ bean >
   < bean id = "XXX "   class ="XXX " >
     <!--  collaborators and configuration  for   this  bean go here  -->
   </ bean >
   <!--  more bean definitions go here -->
</ beans >

              到此,理解了什么是Spring,以及它在工程中的基本框架,下面着重学习的就是它的依赖注入和AOP技术的运用,学习是如何在XML元数据中进行配置.