Ⅰ java string 17 亂碼 顯示成問號 怎麼去除
你從資料庫獲得的信息是以UTF-8進行編碼的，當傳遞到Myeclipse下，獲得的數據是以GB2312 編碼的，即Myeclipse會用GB2312對資料庫中以UTF-8 編碼的字元再次編碼，得到的肯定是亂碼。
解決方法，推薦的是使用String a = new String("資料庫數據".getBytes("ISO8859-1"),"GB2312");將字元轉換為GB2312，這樣應該就顯示正常了
Ⅱ 我從資料庫調出來的數據中文顯示問號，資料庫也是問號
先查看資料庫表的編碼。如果使用phpmyadmin，點擊「結構」，看錶格的「整理一列」。如gbk_chinese_ci、utf8_general_ci等
確認你程序的編碼，使用你所用的編輯器查看
如果兩者不一致，就會出現問號亂碼。兩種方法解決
修改資料庫編碼
讀、寫資料庫時將字元串轉碼
另外，注意你有沒有執行 set names 'utf8'
Ⅲ 如何去掉Oracle資料庫中欄位中出現的問號
update 表名 set 列名=replace(列名 , '?' ,'')把問號替換成空就可以了
Ⅳ mysql 資料庫後台 亂碼問題 全市問號 怎麼辦
最後用到的一句代碼是：
<%= new String(rst.getString(2).getBytes("ISO-8859-1"),"gb2312")%>
大家在JSP的開發過程中，經常出現中文亂碼的問題，可能一至困擾著您，我現在把我在JSP開發中遇到的中文亂碼的問題及解決辦法寫出來供大家參考。
一、JSP頁面顯示亂碼
下面的顯示頁面(display.jsp)就出現亂碼：
對不同的WEB伺服器和不同的JDK版本，處理結果就不一樣。原因：伺服器使用的編碼方式不同和瀏覽器對不同的字元顯示結果不同而導致的。解決辦法：在JSP頁面中指定編碼方式(gb2312),即在頁面的第一行加上：，就可以消除亂碼了。完整頁面如下：
二、表單提交中文時出現亂碼
下面是一個提交頁面(submit.jsp)，代碼如下：
下面是處理頁面(process.jsp)代碼：
如果submit.jsp提交英文字元能正確顯示，如果提交中文時就會出現亂碼。原因：瀏覽器默認使用UTF-8編碼方式來發送請求，而UTF-8和GB2312編碼方式表示字元時不一樣，這樣就出現了不能識別字元。解決辦法:通過request.seCharacterEncoding("gb2312")對請求進行統一編碼，就實現了中文的正常顯示。修改後的process.jsp代碼如下：
三、資料庫連接出現亂碼
只要涉及中文的地方全部是亂碼，解決辦法：在資料庫的資料庫URL中加上useUnicode=true&characterEncoding=GBK就OK了。
四、資料庫的顯示亂碼
在mysql4.1.0中,varchar類型，text類型就會出現中文亂碼，對於varchar類型把它設為binary屬性就可以解決中文問題，對於text類型就要用一個編碼轉換類來處理，實現如下：
public class Convert {
/** 把ISO-8859-1碼轉換成GB2312
*/
public static String ISOtoGB(String iso){
String gb;
try{
if(iso.equals("") || iso == null){
return "";
}
else{
iso = iso.trim();
gb = new String(iso.getBytes("ISO-8859-1"),"GB2312");
return gb;
}
}
catch(Exception e){
System.err.print("編碼轉換錯誤："+e.getMessage());
return "";
}
}
}
把它編譯成class，就可以調用Convert類的靜態方法ISOtoGB()來轉換編碼。
和Java一樣，JSP是目前比較熱門的一個話題。它是一種在伺服器端編譯執行的Web設計語言，因為腳本語言採用了Java，所以JSP繼承了Java的所有優點。可是在使用JSP程序的過程中，常遇到中文亂碼問題，很多人為此頭疼不已，筆者就深受其害，而且使用平台不同，中文亂碼問題的解決方法也不同，無形中增加了學習JSP的難度。其實，在徹底了解相關原因後，問題還是比較容易解決的。筆者結合自己的工作實踐，對中文顯示問題進行了一定的研究，並在不同的環境下進行了相關測試，以下是筆者總結的解決方法，相信對讀者會有一定的借鑒意義。
字元內碼
每個國家（或區域）都規定了計算機信息交換用的字元編碼集，如美國的擴展ASCII碼、中國的GB2312-80、日本的 JIS 等，作為該國家(區域)信息處理的基礎，有著統一編碼的重要作用。由於各本地字元集代碼范圍重疊，相互間信息交換困難，軟體本地化版本獨立維護成本較高。因此有必要將本地化工作中的共性抽取出來，做一致性處理，將特殊的本地化處理內容降低到最少，這就是所謂的國際化（I18N）。各種語言信息被規范為本地信息，而底層字元集採用包含了所有字元的Unicode。
字元內碼(character code)指的是用來代表字元的內碼。我們在輸入和存儲文檔時都要使用內碼，內碼分為單位元組內碼和雙位元組內碼。單位元組內碼的英文全稱是Single-Byte Character Sets (SBCS)，可以支持256個字元編碼；雙位元組內碼的英文全稱是Double-Byte Character Sets(DBCS)，可以支持65000個字元編碼，主要用來對大字元集的東方文字進行編碼。
CodePage指的是一個經過挑選的以特定順序排列的字元內碼列表，對於早期的單位元組內碼的語種，CodePage中的內碼順序使得系統可以按照此列表來根據鍵盤的輸入值給出一個對應的內碼。對於雙位元組內碼，給出的是MultiByte到Unicode的對應表，這樣就可以把以Unicode形式存放的字元轉化為相應的字元內碼。引入對CodePage的支持主要是為了訪問多語種文件名，目前在NTFS和FAT32/VFAT下的文件系統上都使用Unicode，這需要系統在讀取這些文件名時動態地將其轉換為相應的語言編碼。
相信了解JSP代碼的讀者對ISO8859-1一定不陌生，ISO8859-1是我們平時使用比較多的一個CodePage，它屬於西歐語系。GB2312-80 是在國內計算機漢字信息技術發展初始階段制訂的，其中包含了大部分常用的一、二級漢字和9區的符號。該字元集是幾乎所有的中文系統和國際化的軟體都支持的中文字元集，這也是最基本的中文字元集。
GBK 是 GB2312-80 的擴展，是向上兼容的。它包含了20902個漢字，其編碼范圍是 0x8140～0xFEFE，剔除高位 0x80 的字位，其所有字元都可以一對一映射到 Unicode 2.0，也就是說 Java 實際上提供了對 GBK 字元集的支持。
>GB18030-2000(GBK2K) 在 GBK 的基礎上進一步擴展了漢字，增加了藏、蒙等少數民族的文字。GBK2K 從根本上解決了字位不夠、字形不足的問題。
不同開發平台的區別
1．Tomcat 4開發平台
Windows 98／2000下的Tomcat 4以上版本都會出現中文問題（而在Linux下和Tomcat 3.x中則沒有問題），主要表現是頁面顯示亂碼。在IE中調整字元集為GB2312，就可以正常顯示了。
為解決這個問題，可在每個JSP的頁面開始處加上。不過，這還不夠，雖然這時顯示了中文，但是發現從資料庫讀出的欄位變成了亂碼。經過分析發現: 在資料庫中保存的中文字元是正常的，資料庫用ISO8859-1字元集存取數據，而Java程序在處理字元時默認採用統一的ISO8859-1字元集(這也體現了Java國際化思想)，所以在數據添加的時候Java和資料庫都是以ISO8859-1方式處理，這樣不會出錯。但是在讀取數據的時候就出現問題了，因為數據讀出也採用ISO8859-1字元集，而 JSP的文件頭中有語句，這說明頁面採用GB2312的字元集顯示，這樣就和讀出的數據不一樣。這時頁面顯示從資料庫中讀出的字元是亂碼，解決的方法是對這些字元轉碼，從ISO8859-1轉成GB2312，就可以正常顯示了。這個解決辦法對很多平台具有通用性，讀者可以靈活運用。
2．Tomcat 3.x、Resin及Linux平台
在Tomcat 3.x、Resin中或是在Linux下，沒有加入語句，而頁面中的語句起了作用，此時可以正常顯示。相反，如果加上系統會報錯，說明Tomcat 4以上版本的引擎在處理JSP時還是有差別的。
另外，對於不同的資料庫如SQL Server，Oracle，Mysql，Sybase等，字元集的選擇很重要。如果考慮多語言版本，資料庫的字元集就應該統一採用ISO8859-1，需要輸出的時候在不同的字元集之間做轉換就可以了。
以下是針對不同平台的總結：
(1) JSWDK只適合於普通開發，穩定性和其他問題可能不如商業軟體。 由於JDK 1.3版性能要好於JDK 1.2.2很多，並且對中文的支持也較好，所以應該盡量採用。
(2) 作為免費的商業軟體，Resin不僅速度快、穩定、自動編譯，還可以指出出錯行，並可在伺服器端支持使用JavaScript等，而且對中文的支持也很好。
(3) Tomcat僅僅是一個對JSP 1.1、Servlet 2.2標準的實現, 我們不應該要求這個免費軟體在細節和性能上都面面俱到, 它主要考慮英文用戶, 這也是為什麼不做特殊轉換，漢字用URL方法傳遞就有問題的原因。大部分IE瀏覽器預設始終以UTF-8發送, 這似乎是Tomcat的一個不足, 另外Tomcat不管當前的操作系統是什麼語言, 都按ISO8859去編譯JSP, 似乎也欠妥。
JSP代碼的中文處理
在JSP代碼中以下幾處經常需要涉及到中文處理:
1. 在URL中附帶中文參數。這里中文參數通常可以直接讀取，例如:
2. 在JSWDK中讀取HTML表單提交的中文值這時需要加以編碼，較為簡潔的寫法是：
String name1=new String(request.getParameter(「user_id」).getBytes(「ISO8859_1」))。
另外，在JDK 1.3的支持下，不需加入 ，而在JDK 1.2.2 以下，即使以上兩種方法同時運用也很不穩定。但在Resin平台，情況較好，只要在頁面第一行加入：即可正確處理中文，如果再加代碼則反而不對。
3．在JSWDK中Session包含的中文，如果從表單中讀出的值經過編碼可正確顯示，但直接賦予中文值則不行，而Resin平台則很好。
4. 在編譯Servlet和JSP時加入代碼選項。在編譯Servlet時使用Java-Encoding ISO8859-1 myservlet.java；在JSP的ZONE配置文件中，修改編譯參數為：Compiler=builtin - javac- encoding ISO8859-1。使用這種方法後，不需要做其他的改動就可以正常顯示中文了。
另外，流行的關系資料庫系統都支持資料庫Encoding，也就是說在創建資料庫時可以指定它自己的字元集設置，資料庫的數據以指定的編碼形式存儲。當應用程序訪問數據時，在入口和出口處都會有 Encoding 轉換。對於中文數據，資料庫字元編碼的設置應當保證數據的完整性。 GB2312、GBK、UTF-8 等都是可選的資料庫 Encoding，也可以選擇 ISO8859-1 (8-bit)， 但會增加了編程的復雜度，ISO8859-1不是推薦的資料庫 Encoding。在JSP/Servlet編程時，可以先用資料庫管理系統提供的管理功能檢查其中的中文數據是否正確。
處理方法實例
下面是兩個具體的中文亂碼解決實例，讀者仔細研究後可能會有所收獲。
1．常見的字元轉換方法
將Form 中 的 值 傳 送 到 數 據 庫 中 再 取 出 來 後 全 變 成 了「？」。Form用POST提交數據，代碼中使用了語句：String st=new(request.getParameter(「name」).getBytes(「ISO8859_1」))， 而且也聲明了charset=gb2312。
要處理Form中傳遞的中文參數，應該在JSP中加入下面的代碼，另外定義一個專門解決這個問題的getStr類，然後對接收到的參數進行轉換：
String keyword1=request.getParameter(「keyword1」);
keyword1=getStr(keyword1);
這樣就可以解決問題了，代碼如下：
2. JDBC Driver的字元轉換
目前大多數JDBC Driver採用本地編碼格式來傳輸中文字元，例如中文字元「0x4175」會被轉成「0x41」和「0x75」進行傳輸。因此需要對JDBC Driver返回的字元以及要發給JDBC Driver的字元進行轉換。當用JDBC Driver向資料庫中插入數據時，需要先將Unicode轉成Native code; 當 JDBC Driver從資料庫中查詢數據時，則需要將Native code轉換成Unicode。下面給出了這兩種轉換的實現:
String native2Unicode(String s) {
if (s == null || s.length() == 0) {
return null;
}
byte[] buffer = new byte[s.length()];
for (int i = 0; i s.length(); i++) { if (s.charAt(i)>= 0x100) {
c = s.charAt(i);
byte []buf = (「」+c).getBytes();
buffer[j++] = (char)buf[0];
buffer[j++] = (char)buf[1];
}
else {buffer[j++] = s.charAt(i);}
}
return new String(buffer, 0, j);
}
要注意的是，有些JDBC Driver如果通過JDBC Driver Manager設置了正確的字元集屬性，以上方法就不需要了。具體情況可參考相關JDBC的資料。