『壹』 java如何判斷一個文件是否存在亂碼
比如一些非法字元是亂碼的話，那你就讀全部文件，判斷裡面是否有些字元就好了吧
『貳』 java判斷一段字元串是否包含亂碼，不管什麼亂碼，只要不可讀就返回false，怎麼寫
packagetest;
publicclassLuanMaTest{
publicstaticvoidmain(String[]args){
System.out.println(newLuanMaTest().cclm("ab?c"));;
}
publicbooleancclm(Stringsource){
booleanflag=true;
charws[]=newchar[]{'"','?','',''','&'};
for(inti=0;i<source.length();i++){
charc=source.charAt(i);
for(intj=0;j<ws.length;j++){
charv=ws[j];
if(c==v){
flag=false;
}
}
if((int)c==0xfffd){
flag=false;
}
}
returnflag;
}
}
剛給你寫的,已經經過測試,如果對你有用,記得採納啊,一行一行打的代碼,挺辛苦的,哈哈
『叄』 java:如何判斷字元串是不是亂碼，請問自動將亂碼轉換成中文的jar包叫啥子名字啊
『肆』 java 怎麼判斷文本內容的編碼格式
UTF-8編碼的文本文檔，有的帶有BOM (Byte Order Mark, 位元組序標志)，即0xEF, 0xBB, 0xBF，有的沒有。Windows下的txt文本編輯器在保存UTF-8格式的文本文檔時會自動添加BOM到文件頭。在判斷這類文檔時，可以根據文檔的前3個位元組來進行判斷。然而BOM不是必需的，而且也不是推薦的。對不希望UTF-8文檔帶有BOM的程序會帶來兼容性問題，例如Java編譯器在編譯帶有BOM的UTF-8源文件時就會出錯。而且BOM去掉了UTF-8一個期望的特性，即是在文本全部是ASCII字元時UTF-8是和ASCII一致的，即UTF-8向下兼容ASCII。
在具體判斷時，如果文檔不帶有BOM，就無法根據BOM做出判斷，而且IsTextUnicode API也無法對UTF-8編碼的Unicode字元串做出判斷。那在編程判斷時就要根據UTF-8字元編碼的規律進行判斷了。
UTF-8是一種多位元組編碼的字元集，表示一個Unicode字元時，它可以是1個至多個位元組，在表示上有規律：
1位元組：0xxxxxxx
2位元組：110xxxxx 10xxxxxx
3位元組：1110xxxx 10xxxxxx 10xxxxxx
4位元組：11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
這樣就可以根據上面的特徵對字元串進行遍歷來判斷一個字元串是不是UTF-8編碼了。
舉例代碼：
java.io.File f=new java.io.File("待判定的文本文件名");
try{
java.io.InputStream ios=new java.io.FileInputStream(f);
byte[] b=new byte[3];
ios.read(b);
ios.close();
if(b[0]==-17&&b[1]==-69&&b[2]==-65)
System.out.println(f.getName()+"編碼為UTF-8");
else System.out.println(f.getName()+"可能是GBK");
}catch(Exception e){
e.printStackTrace();
}
『伍』 java讀取oracle資料庫裡面的數據生成xml文件,生成的xml文件出現亂碼怎麼解決
跟蹤問題所在：
1、查詢一下資料庫，判斷在資料庫中的時候，是否是已經存在了亂碼。
2、在讀取到Java的時候，你用SystemOut輸出一下，判斷這個時候，是否是亂碼。
3、寫入到xml文件的時候，XML中是否是亂碼。
如果是1種情況出現亂碼，則是寫入資料庫的時候出現亂碼，需要更改寫入程序的代碼。
如果是2種情況出現亂碼，則是讀取Oracle的字元集出現錯誤，設置讀取的字元集。
如果是3種情況出現亂碼，則是在Java類中寫入的時候，設置字元集，查看資料庫字元集，設置為UTF-8、或者是GBK字元集。
希望對你有幫助。
『陸』 Java判斷字元串是否是亂碼
java.nio.charset.Charset.forName("GBK").newEncoder().canEncode("測試") //判斷是不是GBK編碼 即是否亂碼
//使用request.getQueryString()獲取通過URL傳過來的值 有可能是亂碼 如：q=éæ¥
String s = request.getQueryString();
if(s!=null){
if(!(java.nio.charset.Charset.forName("GBK").newEncoder().canEncode(s))){
try {
s = new String(request.getQueryString().getBytes("ISO-8859-1"),"UTF-8");
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
}
}
『柒』 java:如何判斷字元串是不是亂碼
我覺得樓主說的是在WIN下常見的亂碼,但這在JAVA中是沒有的,因為JAVA用的是UNICODE集.可以參考這里:http://..com/question/31882416.html?si=3
所以設計的是哪種語言,輸出的也是哪種語言.就像現在可以直接查看日文網頁而不會是亂碼一樣.
而二樓說的正則表達式就是漢字在UNICODE集中的位置.
『捌』 java文件中文亂碼問題
選中你的文件--右擊--屬性（properties）--text file encoding 有個default和other 這里選other 然後選UTF-8(你默認的可能是ISO-8859-1的)
然後你把文件中的亂碼改回中文 保存~ 這次就不亂碼了~
『玖』 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=true&characterEncoding=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 );
出處：http://www.enet.com.cn/article/2008/0229/A20080229170410.shtml
『拾』 java如果判斷一個字元串中是否有亂碼
據我所知, 貌似沒有這樣的解決辦法...
從編譯器角度來說 , 因為java在得到一個字元串變數的時候, JVM就已經認定它是合法對象了
從業務邏輯上來說 , 什麼叫亂碼? 有可能是一堆中國人無法正常解讀的字元串, 如果是硬性要求的話, 需要參考一些中文的分詞器來做了, 例如庖丁解牛.
最後勸您一句, 如果沒有硬性要求, 不要繼續研究這個了, 沒有太大的實際意義.