本文目錄一覽:
為什麼java編程中寫的漢字變成亂碼了???
你的編碼格式選擇的不對,右鍵單擊項目,點擊Properties:
將格式換成GBK或者UTF-8就行了
JAVA 亂碼 根本原因是什麼
java出現亂碼的原因是
1.
.java
文件中的編碼格式和命令提示符的指令不一致導致的
比如.java
使用的是utf-8,windows環境下命令提示符編碼是gbk,在使用javac
命令進行對.java文件進行編譯的時候,.java文件中的中文字元就會出現
亂碼.
出現這樣的情況,處理方式是通過現在編譯編碼-encoding
處理
javac -encoding utf-8 Test.java
java中文亂碼問題
亂碼問題也是我一直覺得比較蛋疼的問題,下面是我在網上看到的,樓主可以參考一下
一、Java中文問題的由來
Java的內核和class文件是基於unicode的,這使Java程序具有良好的跨平台性,但也帶來了一些中文亂碼問題的麻煩。原因主要有兩方面,Java和JSP文件本身編譯時產生的亂碼問題和Java程序於其他媒介交互產生的亂碼問題。
首先Java(包括JSP)源文件中很可能包含有中文,而Java和JSP源文件的保存方式是基於位元組流的,如果Java和JSP編譯成class文件過程中,使用的編碼方式與源文件的編碼不一致,就會出現亂碼。基於這種亂碼,建議在Java文件中盡量不要寫中文(注釋部分不參與編譯,寫中文沒關係),如果必須寫的話,盡量手動帶參數-ecoding GBK或-ecoding gb2312編譯;對於JSP,在文件頭加上或基本上就能解決這類亂碼問題。
本文要重點討論的是第二類亂碼,即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
如果在以上轉換過程中使用的編碼方式與位元組原有的編碼不一致,很可能就會出現亂碼。
二、解決方法
前面已經提到了Java程序與其他媒介交互時字元和位元組的轉換過程,如果這些轉換過程中容易產生亂碼。解決這些亂碼問題的關鍵在於確保轉換時使用的編碼方式與位元組原有的編碼方式保持一致,下面分別論述(Java或JSP自身產生的亂碼請參看第一部分)。
1、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:
CharacterEncodingFilter
net.vschool.web.CharacterEncodingFilter
encodingGBK
CharacterEncodingFilter
/*
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);
}
}
2、Java與資料庫之間的亂碼
大部分資料庫都支持以unicode編碼方式,所以解決Java與資料庫之間的亂碼問題比較明智的方式是直接使用unicode編碼與資料庫交互。很多資料庫驅動自動支持unicode,如Microsoft的SQLServer驅動。其他大部分資料庫驅動,可以在驅動的url參數中指定,如如mm的mysql驅動:jdbc:mysql://localhost/WEBCLDB?useUnicode=truecharacterEncoding=GBK。
3、Java與文件/流之間的亂碼
Java讀寫文件最常用的類是FileInputStream/FileOutputStream和FileReader/FileWriter。其中FileInputStream和FileOutputStream是基於位元組流的,常用於讀寫二進位文件。讀寫字元文件建議使用基於字元的FileReader和FileWriter,省去了位元組與字元之間的轉換。但這兩個類的構造函數默認使用系統的編碼方式,如果文件內容與系統編碼方式不一致,可能會出現亂碼。在這種情況下,建議使用FileReader和FileWriter的父類:InputStreamReader/OutputStreamWriter,它們也是基於字元的,但在構造函數中可以指定編碼類型:InputStreamReader(InputStream in, Charset cs) 和OutputStreamWriter(OutputStream out, Charset cs)。
4、其他
上面提到的方法應該能解決大部分亂碼問題,如果在其他地方還出現亂碼,可能需要手動修改代碼。解決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 );
出處:
原創文章,作者:小藍,如若轉載,請註明出處:https://www.506064.com/zh-tw/n/271703.html