java漢字亂碼解決辦法

自從接觸Java和JSP以來，就不斷與Java的中文亂碼問題打交道，如今終於獲得了完全的解決，現將咱們的解決心得與你們共享。  1、Java中文問題的由來  Java的內核和class文件是基於unicode的，這使Java程序具備良好的跨平臺性，但也帶來了一些中文亂碼問題的麻煩。緣由主要有兩方面，Java和JSP文件自己編譯時產生的亂碼問題和Java程序於其餘媒介交互產生的亂碼問題。  首先Java（包括JSP）源文件中極可能包含有中文，而Java和JSP源文件的保存方式是基於字節流的，若是Java和JSP編譯成class文件過程當中，使用的編碼方式與源文件的編碼不一致，就會出現亂碼。基於這種亂碼，建議在Java文件中儘可能不要寫中文（註釋部分不參與編譯，寫中文不要緊），若是必須寫的話，儘可能手動帶參數－ecoding   GBK或－ecoding   gb2312編譯；對於JSP，在文件頭加上 <%@   page   contentType= "text/html;charset=GBK "%> 或 <%@   page   contentType= "text/html;charset=gb2312 "%> 基本上就能解決這類亂碼問題。  本文要重點討論的是第二類亂碼，即Java程序與其餘存儲媒介交互時產生的亂碼。不少存儲媒介，如數據庫，文件，流等的存儲方式都是基於字節流的，Java程序與這些媒介交互時就會發生字符(char)與字節(byte)之間的轉換，具體狀況以下：  從頁面form提交數據到java程序   byte－> char  從java程序到頁面顯示   char—> byte  從數據庫到java程序   byte—> char  從java程序到數據庫   char—> byte  從文件到java程序   byte－> char  從java程序到文件   char－> byte  從流到java程序   byte－> char  從java程序到流   char－> byte  若是在以上轉換過程當中使用的編碼方式與字節原有的編碼不一致，極可能就會出現亂碼。  2、解決方法  前面已經提到了Java程序與其餘媒介交互時字符和字節的轉換過程，若是這些轉換過程當中容易產生亂碼。解決這些亂碼問題的關鍵在於確保轉換時使用的編碼方式與字節原有的編碼方式保持一致，下面分別論述（Java或JSP自身產生的亂碼請參看第一部分）。  一、JSP與頁面參數之間的亂碼  JSP獲取頁面參數時通常採用系統默認的編碼方式，若是頁面參數的編碼類型和系統默認的編碼類型不一致，極可能就會出現亂碼。解決這類亂碼問題的基本方法是在頁面獲取參數以前，強制指定request獲取參數的編碼方式：request.setCharacterEncoding( "GBK ")或request.setCharacterEncoding( "gb2312 ")。  若是在JSP將變量輸出到頁面時出現了亂碼，能夠經過設置response.setContentType( "text/html;charset=GBK ")或response.setContentType( "text/html;charset=gb2312 ")解決。  若是不想在每一個文件裏都寫這樣兩句話，更簡潔的辦法是使用Servlet規範中的過慮器指定編碼，過濾器的在web.xml中的典型配置和主要代碼以下：  web.xml:  <filter>  <filter-name> CharacterEncodingFilter </filter-name>  <filter-class> net.vschool.web.CharacterEncodingFilter </filter-class>  <init-param>  <param-name> encoding </param-name>  <param-value> GBK </param-value>  </init-param>  </filter>  <filter-mapping>  <filter-name> CharacterEncodingFilter </filter-name>  <url-pattern> /* </url-pattern>  </filter-mapping>  CharacterEncodingFilter.java:  public   class   CharacterEncodingFilter   implements   Filter    {  protected   String   encoding   =   null;    public   void   init(FilterConfig   filterConfig)   throws   ServletException    {  this.encoding   =   filterConfig.getInitParameter( "encoding ");  }  public   void   doFilter(ServletRequest   request,   ServletResponse   response,   FilterChain   chain)   throws   IOException,   ServletException    {  request.setCharacterEncoding(encoding);  response.setContentType( "text/html;charset= "+encoding);  chain.doFilter(request,   response);  }  }  二、Java與數據庫之間的亂碼  大部分數據庫都支持以unicode編碼方式，因此解決Java與數據庫之間的亂碼問題比較明智的方式是直接使用unicode編碼與數據庫交互。不少數據庫驅動自動支持unicode，如Microsoft的SQLServer驅動。其餘大部分數據庫驅動，能夠在驅動的url參數中指定，如如mm的mysql驅動：jdbc:mysql://localhost/WEBCLDB?useUnicode=true&characterEncoding=GBK。  三、Java與文件/流之間的亂碼  Java讀寫文件最經常使用的類是FileInputStream/FileOutputStream和FileReader/FileWriter。其中FileInputStream和FileOutputStream是基於字節流的，經常使用於讀寫二進制文件。讀寫字符文件建議使用基於字符的FileReader和FileWriter，省去了字節與字符之間的轉換。但這兩個類的構造函數默認使用系統的編碼方式，若是文件內容與系統編碼方式不一致，可能會出現亂碼。在這種狀況下，建議使用FileReader和FileWriter的父類：InputStreamReader/OutputStreamWriter，它們也是基於字符的，但在構造函數中能夠指定編碼類型：InputStreamReader(InputStream   in,   Charset   cs)   和OutputStreamWriter(OutputStream   out,   Charset   cs)。    四、其餘  上面提到的方法應該能解決大部分亂碼問題，若是在其餘地方還出現亂碼，可能須要手動修改代碼。解決Java亂碼問題的關鍵在於在字節與字符的轉換過程當中，你必須知道原來字節或轉換後的字節的編碼方式，轉換時採用的編碼必須與這個編碼方式保持一致。咱們之前使用Resin服務器，使用smartUpload組件上傳文件，上傳文件同時傳遞的中文參數獲取沒有亂碼問題。當在Linux中把Resin設置成服務後，上傳文件同時的中文參數獲取出現了亂碼。這個問題困擾了咱們好久，後來咱們分析smartUpload組件的源文件，由於文件上傳採用的是字節流的方式，裏面包含的參數名稱和值也是字節流的方式傳遞的。smartUpload組件讀取字節流後再將參數名稱和值從字節流中解析出來，問題就出如今smartUpload將字節流轉換成字符串時採用了系統默認的編碼，而將Resin設置成服務後，系統默認的編碼可能發生了改變，所以出現了亂碼。後來，咱們更改了smartUpload的源文件，增長了一個屬性charset和setCharset(String)方法，將upload()方法中提取參數語句：  String   value   =   new   String(m_binArray,   m_startData,   (m_endData   -   m_startData)   +   1   );  改爲了  String   value   =   new   String(m_binArray,   m_startData,   (m_endData   -   m_startData)   +   1,   charset   );  終於解決了這個亂碼問題。

自從接觸Java和JSP以來，就不斷與Java的中文亂碼問題打交道，如今終於獲得了完全的解決，現將咱們的解決心得與你們共享。  1、Java中文問題的由來  Java的內核和class文件是基於unicode的，這使Java程序具備良好的跨平臺性，但也帶來了一些中文亂碼問題的麻煩。緣由主要有兩方面，Java和JSP文件自己編譯時產生的亂碼問題和Java程序於其餘媒介交互產生的亂碼問題。  首先Java（包括JSP）源文件中極可能包含有中文，而Java和JSP源文件的保存方式是基於字節流的，若是Java和JSP編譯成class文件過程當中，使用的編碼方式與源文件的編碼不一致，就會出現亂碼。基於這種亂碼，建議在Java文件中儘可能不要寫中文（註釋部分不參與編譯，寫中文不要緊），若是必須寫的話，儘可能手動帶參數－ecoding   GBK或－ecoding   gb2312編譯；對於JSP，在文件頭加上 <%@   page   contentType= "text/html;charset=GBK "%> 或 <%@   page   contentType= "text/html;charset=gb2312 "%> 基本上就能解決這類亂碼問題。  本文要重點討論的是第二類亂碼，即Java程序與其餘存儲媒介交互時產生的亂碼。不少存儲媒介，如數據庫，文件，流等的存儲方式都是基於字節流的，Java程序與這些媒介交互時就會發生字符(char)與字節(byte)之間的轉換，具體狀況以下：  從頁面form提交數據到java程序   byte－> char  從java程序到頁面顯示   char—> byte  從數據庫到java程序   byte—> char  從java程序到數據庫   char—> byte  從文件到java程序   byte－> char  從java程序到文件   char－> byte  從流到java程序   byte－> char  從java程序到流   char－> byte  若是在以上轉換過程當中使用的編碼方式與字節原有的編碼不一致，極可能就會出現亂碼。  2、解決方法  前面已經提到了Java程序與其餘媒介交互時字符和字節的轉換過程，若是這些轉換過程當中容易產生亂碼。解決這些亂碼問題的關鍵在於確保轉換時使用的編碼方式與字節原有的編碼方式保持一致，下面分別論述（Java或JSP自身產生的亂碼請參看第一部分）。  一、JSP與頁面參數之間的亂碼  JSP獲取頁面參數時通常採用系統默認的編碼方式，若是頁面參數的編碼類型和系統默認的編碼類型不一致，極可能就會出現亂碼。解決這類亂碼問題的基本方法是在頁面獲取參數以前，強制指定request獲取參數的編碼方式：request.setCharacterEncoding( "GBK ")或request.setCharacterEncoding( "gb2312 ")。  若是在JSP將變量輸出到頁面時出現了亂碼，能夠經過設置response.setContentType( "text/html;charset=GBK ")或response.setContentType( "text/html;charset=gb2312 ")解決。  若是不想在每一個文件裏都寫這樣兩句話，更簡潔的辦法是使用Servlet規範中的過慮器指定編碼，過濾器的在web.xml中的典型配置和主要代碼以下：  web.xml:  <filter>  <filter-name> CharacterEncodingFilter </filter-name>  <filter-class> net.vschool.web.CharacterEncodingFilter </filter-class>  <init-param>  <param-name> encoding </param-name>  <param-value> GBK </param-value>  </init-param>  </filter>  <filter-mapping>  <filter-name> CharacterEncodingFilter </filter-name>  <url-pattern> /* </url-pattern>  </filter-mapping>  CharacterEncodingFilter.java:  public   class   CharacterEncodingFilter   implements   Filter    {  protected   String   encoding   =   null;    public   void   init(FilterConfig   filterConfig)   throws   ServletException    {  this.encoding   =   filterConfig.getInitParameter( "encoding ");  }  public   void   doFilter(ServletRequest   request,   ServletResponse   response,   FilterChain   chain)   throws   IOException,   ServletException    {  request.setCharacterEncoding(encoding);  response.setContentType( "text/html;charset= "+encoding);  chain.doFilter(request,   response);  }  }  二、Java與數據庫之間的亂碼  大部分數據庫都支持以unicode編碼方式，因此解決Java與數據庫之間的亂碼問題比較明智的方式是直接使用unicode編碼與數據庫交互。不少數據庫驅動自動支持unicode，如Microsoft的SQLServer驅動。其餘大部分數據庫驅動，能夠在驅動的url參數中指定，如如mm的mysql驅動：jdbc:mysql://localhost/WEBCLDB?useUnicode=true&characterEncoding=GBK。  三、Java與文件/流之間的亂碼  Java讀寫文件最經常使用的類是FileInputStream/FileOutputStream和FileReader/FileWriter。其中FileInputStream和FileOutputStream是基於字節流的，經常使用於讀寫二進制文件。讀寫字符文件建議使用基於字符的FileReader和FileWriter，省去了字節與字符之間的轉換。但這兩個類的構造函數默認使用系統的編碼方式，若是文件內容與系統編碼方式不一致，可能會出現亂碼。在這種狀況下，建議使用FileReader和FileWriter的父類：InputStreamReader/OutputStreamWriter，它們也是基於字符的，但在構造函數中能夠指定編碼類型：InputStreamReader(InputStream   in,   Charset   cs)   和OutputStreamWriter(OutputStream   out,   Charset   cs)。    四、其餘  上面提到的方法應該能解決大部分亂碼問題，若是在其餘地方還出現亂碼，可能須要手動修改代碼。解決Java亂碼問題的關鍵在於在字節與字符的轉換過程當中，你必須知道原來字節或轉換後的字節的編碼方式，轉換時採用的編碼必須與這個編碼方式保持一致。咱們之前使用Resin服務器，使用smartUpload組件上傳文件，上傳文件同時傳遞的中文參數獲取沒有亂碼問題。當在Linux中把Resin設置成服務後，上傳文件同時的中文參數獲取出現了亂碼。這個問題困擾了咱們好久，後來咱們分析smartUpload組件的源文件，由於文件上傳採用的是字節流的方式，裏面包含的參數名稱和值也是字節流的方式傳遞的。smartUpload組件讀取字節流後再將參數名稱和值從字節流中解析出來，問題就出如今smartUpload將字節流轉換成字符串時採用了系統默認的編碼，而將Resin設置成服務後，系統默認的編碼可能發生了改變，所以出現了亂碼。後來，咱們更改了smartUpload的源文件，增長了一個屬性charset和setCharset(String)方法，將upload()方法中提取參數語句：  String   value   =   new   String(m_binArray,   m_startData,   (m_endData   -   m_startData)   +   1   );  改爲了  String   value   =   new   String(m_binArray,   m_startData,   (m_endData   -   m_startData)   +   1,   charset   );  終於解決了這個亂碼問題。      自從接觸Java和JSP以來，就不斷與Java的中文亂碼問題打交道，如今終於獲得了完全的解決，現將咱們的解決心得與你們共享。  1、Java中文問題的由來  Java的內核和class文件是基於unicode的，這使Java程序具備良好的跨平臺性，但也帶來了一些中文亂碼問題的麻煩。緣由主要有兩方面，Java和JSP文件自己編譯時產生的亂碼問題和Java程序於其餘媒介交互產生的亂碼問題。  首先Java（包括JSP）源文件中極可能包含有中文，而Java和JSP源文件的保存方式是基於字節流的，若是Java和JSP編譯成class文件過程當中，使用的編碼方式與源文件的編碼不一致，就會出現亂碼。基於這種亂碼，建議在Java文件中儘可能不要寫中文（註釋部分不參與編譯，寫中文不要緊），若是必須寫的話，儘可能手動帶參數－ecoding   GBK或－ecoding   gb2312編譯；對於JSP，在文件頭加上 <%@   page   contentType= "text/html;charset=GBK "%> 或 <%@   page   contentType= "text/html;charset=gb2312 "%> 基本上就能解決這類亂碼問題。  本文要重點討論的是第二類亂碼，即Java程序與其餘存儲媒介交互時產生的亂碼。不少存儲媒介，如數據庫，文件，流等的存儲方式都是基於字節流的，Java程序與這些媒介交互時就會發生字符(char)與字節(byte)之間的轉換，具體狀況以下：  從頁面form提交數據到java程序   byte－> char  從java程序到頁面顯示   char—> byte  從數據庫到java程序   byte—> char  從java程序到數據庫   char—> byte  從文件到java程序   byte－> char  從java程序到文件   char－> byte  從流到java程序   byte－> char  從java程序到流   char－> byte  若是在以上轉換過程當中使用的編碼方式與字節原有的編碼不一致，極可能就會出現亂碼。  2、解決方法  前面已經提到了Java程序與其餘媒介交互時字符和字節的轉換過程，若是這些轉換過程當中容易產生亂碼。解決這些亂碼問題的關鍵在於確保轉換時使用的編碼方式與字節原有的編碼方式保持一致，下面分別論述（Java或JSP自身產生的亂碼請參看第一部分）。  一、JSP與頁面參數之間的亂碼  JSP獲取頁面參數時通常採用系統默認的編碼方式，若是頁面參數的編碼類型和系統默認的編碼類型不一致，極可能就會出現亂碼。解決這類亂碼問題的基本方法是在頁面獲取參數以前，強制指定request獲取參數的編碼方式：request.setCharacterEncoding( "GBK ")或request.setCharacterEncoding( "gb2312 ")。  若是在JSP將變量輸出到頁面時出現了亂碼，能夠經過設置response.setContentType( "text/html;charset=GBK ")或response.setContentType( "text/html;charset=gb2312 ")解決。  若是不想在每一個文件裏都寫這樣兩句話，更簡潔的辦法是使用Servlet規範中的過慮器指定編碼，過濾器的在web.xml中的典型配置和主要代碼以下：  web.xml:  <filter>  <filter-name> CharacterEncodingFilter </filter-name>  <filter-class> net.vschool.web.CharacterEncodingFilter </filter-class>  <init-param>  <param-name> encoding </param-name>  <param-value> GBK </param-value>  </init-param>  </filter>  <filter-mapping>  <filter-name> CharacterEncodingFilter </filter-name>  <url-pattern> /* </url-pattern>  </filter-mapping>  CharacterEncodingFilter.java:  public   class   CharacterEncodingFilter   implements   Filter    {  protected   String   encoding   =   null;    public   void   init(FilterConfig   filterConfig)   throws   ServletException    {  this.encoding   =   filterConfig.getInitParameter( "encoding ");  }  public   void   doFilter(ServletRequest   request,   ServletResponse   response,   FilterChain   chain)   throws   IOException,   ServletException    {  request.setCharacterEncoding(encoding);  response.setContentType( "text/html;charset= "+encoding);  chain.doFilter(request,   response);  }  }  二、Java與數據庫之間的亂碼  大部分數據庫都支持以unicode編碼方式，因此解決Java與數據庫之間的亂碼問題比較明智的方式是直接使用unicode編碼與數據庫交互。不少數據庫驅動自動支持unicode，如Microsoft的SQLServer驅動。其餘大部分數據庫驅動，能夠在驅動的url參數中指定，如如mm的mysql驅動：jdbc:mysql://localhost/WEBCLDB?useUnicode=true&characterEncoding=GBK。  三、Java與文件/流之間的亂碼  Java讀寫文件最經常使用的類是FileInputStream/FileOutputStream和FileReader/FileWriter。其中FileInputStream和FileOutputStream是基於字節流的，經常使用於讀寫二進制文件。讀寫字符文件建議使用基於字符的FileReader和FileWriter，省去了字節與字符之間的轉換。但這兩個類的構造函數默認使用系統的編碼方式，若是文件內容與系統編碼方式不一致，可能會出現亂碼。在這種狀況下，建議使用FileReader和FileWriter的父類：InputStreamReader/OutputStreamWriter，它們也是基於字符的，但在構造函數中能夠指定編碼類型：InputStreamReader(InputStream   in,   Charset   cs)   和OutputStreamWriter(OutputStream   out,   Charset   cs)。    四、其餘  上面提到的方法應該能解決大部分亂碼問題，若是在其餘地方還出現亂碼，可能須要手動修改代碼。解決Java亂碼問題的關鍵在於在字節與字符的轉換過程當中，你必須知道原來字節或轉換後的字節的編碼方式，轉換時採用的編碼必須與這個編碼方式保持一致。咱們之前使用Resin服務器，使用smartUpload組件上傳文件，上傳文件同時傳遞的中文參數獲取沒有亂碼問題。當在Linux中把Resin設置成服務後，上傳文件同時的中文參數獲取出現了亂碼。這個問題困擾了咱們好久，後來咱們分析smartUpload組件的源文件，由於文件上傳採用的是字節流的方式，裏面包含的參數名稱和值也是字節流的方式傳遞的。smartUpload組件讀取字節流後再將參數名稱和值從字節流中解析出來，問題就出如今smartUpload將字節流轉換成字符串時採用了系統默認的編碼，而將Resin設置成服務後，系統默認的編碼可能發生了改變，所以出現了亂碼。後來，咱們更改了smartUpload的源文件，增長了一個屬性charset和setCharset(String)方法，將upload()方法中提取參數語句：  String   value   =   new   String(m_binArray,   m_startData,   (m_endData   -   m_startData)   +   1   );  改爲了  String   value   =   new   String(m_binArray,   m_startData,   (m_endData   -   m_startData)   +   1,   charset   );  終於解決了這個亂碼問題。

 

自從接觸Java和JSP以來，就不斷與Java的中文亂碼問題打交道，如今終於獲得了完全的解決，現將咱們的解決心得與你們共享。  1、Java中文問題的由來  Java的內核和class文件是基於unicode的，這使Java程序具備良好的跨平臺性，但也帶來了一些中文亂碼問題的麻煩。緣由主要有兩方面，Java和JSP文件自己編譯時產生的亂碼問題和Java程序於其餘媒介交互產生的亂碼問題。  首先Java（包括JSP）源文件中極可能包含有中文，而Java和JSP源文件的保存方式是基於字節流的，若是Java和JSP編譯成class文件過程當中，使用的編碼方式與源文件的編碼不一致，就會出現亂碼。基於這種亂碼，建議在Java文件中儘可能不要寫中文（註釋部分不參與編譯，寫中文不要緊），若是必須寫的話，儘可能手動帶參數－ecoding   GBK或－ecoding   gb2312編譯；對於JSP，在文件頭加上 <%@   page   contentType= "text/html;charset=GBK "%> 或 <%@   page   contentType= "text/html;charset=gb2312 "%> 基本上就能解決這類亂碼問題。  本文要重點討論的是第二類亂碼，即Java程序與其餘存儲媒介交互時產生的亂碼。不少存儲媒介，如數據庫，文件，流等的存儲方式都是基於字節流的，Java程序與這些媒介交互時就會發生字符(char)與字節(byte)之間的轉換，具體狀況以下：  從頁面form提交數據到java程序   byte－> char  從java程序到頁面顯示   char—> byte  從數據庫到java程序   byte—> char  從java程序到數據庫   char—> byte  從文件到java程序   byte－> char  從java程序到文件   char－> byte  從流到java程序   byte－> char  從java程序到流   char－> byte  若是在以上轉換過程當中使用的編碼方式與字節原有的編碼不一致，極可能就會出現亂碼。  2、解決方法  前面已經提到了Java程序與其餘媒介交互時字符和字節的轉換過程，若是這些轉換過程當中容易產生亂碼。解決這些亂碼問題的關鍵在於確保轉換時使用的編碼方式與字節原有的編碼方式保持一致，下面分別論述（Java或JSP自身產生的亂碼請參看第一部分）。  一、JSP與頁面參數之間的亂碼  JSP獲取頁面參數時通常採用系統默認的編碼方式，若是頁面參數的編碼類型和系統默認的編碼類型不一致，極可能就會出現亂碼。解決這類亂碼問題的基本方法是在頁面獲取參數以前，強制指定request獲取參數的編碼方式：request.setCharacterEncoding( "GBK ")或request.setCharacterEncoding( "gb2312 ")。  若是在JSP將變量輸出到頁面時出現了亂碼，能夠經過設置response.setContentType( "text/html;charset=GBK ")或response.setContentType( "text/html;charset=gb2312 ")解決。  若是不想在每一個文件裏都寫這樣兩句話，更簡潔的辦法是使用Servlet規範中的過慮器指定編碼，過濾器的在web.xml中的典型配置和主要代碼以下：  web.xml:  <filter>  <filter-name> CharacterEncodingFilter </filter-name>  <filter-class> net.vschool.web.CharacterEncodingFilter </filter-class>  <init-param>  <param-name> encoding </param-name>  <param-value> GBK </param-value>  </init-param>  </filter>  <filter-mapping>  <filter-name> CharacterEncodingFilter </filter-name>  <url-pattern> /* </url-pattern>  </filter-mapping>  CharacterEncodingFilter.java:  public   class   CharacterEncodingFilter   implements   Filter    {  protected   String   encoding   =   null;    public   void   init(FilterConfig   filterConfig)   throws   ServletException    {  this.encoding   =   filterConfig.getInitParameter( "encoding ");  }  public   void   doFilter(ServletRequest   request,   ServletResponse   response,   FilterChain   chain)   throws   IOException,   ServletException    {  request.setCharacterEncoding(encoding);  response.setContentType( "text/html;charset= "+encoding);  chain.doFilter(request,   response);  }  }  二、Java與數據庫之間的亂碼  大部分數據庫都支持以unicode編碼方式，因此解決Java與數據庫之間的亂碼問題比較明智的方式是直接使用unicode編碼與數據庫交互。不少數據庫驅動自動支持unicode，如Microsoft的SQLServer驅動。其餘大部分數據庫驅動，能夠在驅動的url參數中指定，如如mm的mysql驅動：jdbc:mysql://localhost/WEBCLDB?useUnicode=true&characterEncoding=GBK。  三、Java與文件/流之間的亂碼  Java讀寫文件最經常使用的類是FileInputStream/FileOutputStream和FileReader/FileWriter。其中FileInputStream和FileOutputStream是基於字節流的，經常使用於讀寫二進制文件。讀寫字符文件建議使用基於字符的FileReader和FileWriter，省去了字節與字符之間的轉換。但這兩個類的構造函數默認使用系統的編碼方式，若是文件內容與系統編碼方式不一致，可能會出現亂碼。在這種狀況下，建議使用FileReader和FileWriter的父類：InputStreamReader/OutputStreamWriter，它們也是基於字符的，但在構造函數中能夠指定編碼類型：InputStreamReader(InputStream   in,   Charset   cs)   和OutputStreamWriter(OutputStream   out,   Charset   cs)。    四、其餘  上面提到的方法應該能解決大部分亂碼問題，若是在其餘地方還出現亂碼，可能須要手動修改代碼。解決Java亂碼問題的關鍵在於在字節與字符的轉換過程當中，你必須知道原來字節或轉換後的字節的編碼方式，轉換時採用的編碼必須與這個編碼方式保持一致。咱們之前使用Resin服務器，使用smartUpload組件上傳文件，上傳文件同時傳遞的中文參數獲取沒有亂碼問題。當在Linux中把Resin設置成服務後，上傳文件同時的中文參數獲取出現了亂碼。這個問題困擾了咱們好久，後來咱們分析smartUpload組件的源文件，由於文件上傳採用的是字節流的方式，裏面包含的參數名稱和值也是字節流的方式傳遞的。smartUpload組件讀取字節流後再將參數名稱和值從字節流中解析出來，問題就出如今smartUpload將字節流轉換成字符串時採用了系統默認的編碼，而將Resin設置成服務後，系統默認的編碼可能發生了改變，所以出現了亂碼。後來，咱們更改了smartUpload的源文件，增長了一個屬性charset和setCharset(String)方法，將upload()方法中提取參數語句：  String   value   =   new   String(m_binArray,   m_startData,   (m_endData   -   m_startData)   +   1   );  改爲了  String   value   =   new   String(m_binArray,   m_startData,   (m_endData   -   m_startData)   +   1,   charset   );  終於解決了這個亂碼問題。

 

自從接觸Java和JSP以來，就不斷與Java的中文亂碼問題打交道，如今終於獲得了完全的解決，現將咱們的解決心得與你們共享。 
1、Java中文問題的由來 
Java的內核和class文件是基於unicode的，這使Java程序具備良好的跨平臺性，但也帶來了一些中文亂碼問題的麻煩。緣由主要有兩方面，Java和JSP文件自己編譯時產生的亂碼問題和Java程序於其餘媒介交互產生的亂碼問題。 
首先Java（包括JSP）源文件中極可能包含有中文，而Java和JSP源文件的保存方式是基於字節流的，若是Java和JSP編譯成class文件過程當中，使用的編碼方式與源文件的編碼不一致，就會出現亂碼。基於這種亂碼，建議在Java文件中儘可能不要寫中文（註釋部分不參與編譯，寫中文不要緊），若是必須寫的話，儘可能手動帶參數－ecoding   GBK或－ecoding   gb2312編譯；對於JSP，在文件頭加上 <%@   page   contentType= "text/html;charset=GBK "%> 或 <%@   page   contentType= "text/html;charset=gb2312 "%> 基本上就能解決這類亂碼問題。 
本文要重點討論的是第二類亂碼，即Java程序與其餘存儲媒介交互時產生的亂碼。不少存儲媒介，如數據庫，文件，流等的存儲方式都是基於字節流的，Java程序與這些媒介交互時就會發生字符(char)與字節(byte)之間的轉換，具體狀況以下： 
從頁面form提交數據到java程序   byte－> char  從java程序到頁面顯示   char—> byte 
從數據庫到java程序   byte—> char  從java程序到數據庫   char—> byte 
從文件到java程序   byte－> char  從java程序到文件   char－> byte 
從流到java程序   byte－> char  從java程序到流   char－> byte 
若是在以上轉換過程當中使用的編碼方式與字節原有的編碼不一致，極可能就會出現亂碼。 
2、解決方法 
前面已經提到了Java程序與其餘媒介交互時字符和字節的轉換過程，若是這些轉換過程當中容易產生亂碼。解決這些亂碼問題的關鍵在於確保轉換時使用的編碼方式與字節原有的編碼方式保持一致，下面分別論述（Java或JSP自身產生的亂碼請參看第一部分）。 
一、JSP與頁面參數之間的亂碼  JSP獲取頁面參數時通常採用系統默認的編碼方式，若是頁面參數的編碼類型和系統默認的編碼類型不一致，極可能就會出現亂碼。解決這類亂碼問題的基本方法是在頁面獲取參數以前，強制指定request獲取參數的編碼方式：request.setCharacterEncoding( "GBK ")或request.setCharacterEncoding( "gb2312 ")。  若是在JSP將變量輸出到頁面時出現了亂碼，能夠經過設置response.setContentType( "text/html;charset=GBK ")或response.setContentType( "text/html;charset=gb2312 ")解決。  若是不想在每一個文件裏都寫這樣兩句話，更簡潔的辦法是使用Servlet規範中的過慮器指定編碼，過濾器的在web.xml中的典型配置和主要代碼以下：  web.xml: 
<filter>  <filter-name> CharacterEncodingFilter </filter-name>  <filter-class> net.vschool.web.CharacterEncodingFilter </filter-class>  <init-param>  <param-name> encoding </param-name>  <param-value> GBK </param-value>  </init-param>  </filter>  <filter-mapping>  <filter-name> CharacterEncodingFilter </filter-name>  <url-pattern> /* </url-pattern>  </filter-mapping> 
CharacterEncodingFilter.java: 
public   class   CharacterEncodingFilter   implements   Filter    { 
protected   String   encoding   =   null;   
public   void   init(FilterConfig   filterConfig)   throws   ServletException    {  this.encoding   =   filterConfig.getInitParameter( "encoding ");  } 
public   void   doFilter(ServletRequest   request,   ServletResponse   response,   FilterChain   chain)   throws   IOException,   ServletException    {  request.setCharacterEncoding(encoding);  response.setContentType( "text/html;charset= "+encoding);  chain.doFilter(request,   response);  } 
} 
二、Java與數據庫之間的亂碼  大部分數據庫都支持以unicode編碼方式，因此解決Java與數據庫之間的亂碼問題比較明智的方式是直接使用unicode編碼與數據庫交互。不少數據庫驅動自動支持unicode，如Microsoft的SQLServer驅動。其餘大部分數據庫驅動，能夠在驅動的url參數中指定，如如mm的mysql驅動：jdbc:mysql://localhost/WEBCLDB?useUnicode=true&characterEncoding=GBK。 
三、Java與文件/流之間的亂碼  Java讀寫文件最經常使用的類是FileInputStream/FileOutputStream和FileReader/FileWriter。其中FileInputStream和FileOutputStream是基於字節流的，經常使用於讀寫二進制文件。讀寫字符文件建議使用基於字符的FileReader和FileWriter，省去了字節與字符之間的轉換。但這兩個類的構造函數默認使用系統的編碼方式，若是文件內容與系統編碼方式不一致，可能會出現亂碼。在這種狀況下，建議使用FileReader和FileWriter的父類：InputStreamReader/OutputStreamWriter，它們也是基於字符的，但在構造函數中能夠指定編碼類型：InputStreamReader(InputStream   in,   Charset   cs)   和OutputStreamWriter(OutputStream   out,   Charset   cs)。   
四、其餘  上面提到的方法應該能解決大部分亂碼問題，若是在其餘地方還出現亂碼，可能須要手動修改代碼。解決Java亂碼問題的關鍵在於在字節與字符的轉換過程當中，你必須知道原來字節或轉換後的字節的編碼方式，轉換時採用的編碼必須與這個編碼方式保持一致。咱們之前使用Resin服務器，使用smartUpload組件上傳文件，上傳文件同時傳遞的中文參數獲取沒有亂碼問題。當在Linux中把Resin設置成服務後，上傳文件同時的中文參數獲取出現了亂碼。這個問題困擾了咱們好久，後來咱們分析smartUpload組件的源文件，由於文件上傳採用的是字節流的方式，裏面包含的參數名稱和值也是字節流的方式傳遞的。smartUpload組件讀取字節流後再將參數名稱和值從字節流中解析出來，問題就出如今smartUpload將字節流轉換成字符串時採用了系統默認的編碼，而將Resin設置成服務後，系統默認的編碼可能發生了改變，所以出現了亂碼。後來，咱們更改了smartUpload的源文件，增長了一個屬性charset和setCharset(String)方法，將upload()方法中提取參數語句：  String   value   =   new   String(m_binArray,   m_startData,   (m_endData   -   m_startData)   +   1   );  改爲了  String   value   =   new   String(m_binArray,   m_startData,   (m_endData   -   m_startData)   +   1,   charset   );  終於解決了這個亂碼問題。