字元集問題解決方法

『壹』 Mysql字元集的問題,更改資料庫的字元集問題

碼一片，記得我以前也曾經有過一次切換出現亂碼的經驗，原因肯定是Mysql版本之間的差異問題。

只好查資料，發現了一個解決方法，就是在mysql_connect後面加一句SET NAMES UTF8，即可使得UTF8的資料庫消除亂碼，對於GBK的資料庫則使用SET NAMES GBK，代碼如下：

$mysql_mylink = mysql_connect($mysql_host, $mysql_user, $mysql_pass);
mysql_query("SET NAMES 'GBK'");

『貳』 oracle字元集問題[復制粘貼勿擾]，如何解決

你的環境變數設置根本就是錯的，所以無效！
嘗試將NLS設置為set NLS_LANG=SIMPLIFIED CHINESE_CHINA.AL32UTF8，你確定你設置變數名是NLS_LANG？而正確的是LNS_LANG，所以你的系統環境根本就沒改變。
把變數名改正確，然後重啟試下就知道了。

『叄』 高分請教oracle字元集問題

基本上不可能正常使用，以下回答屬於轉載：

經常看到一些朋友問ORACLE字元集方面的問題，我想以迭代的方式來介紹一下。

第一次迭代：掌握字元集方面的基本概念。
有些朋友可能會認為這是多此一舉，但實際上正是由於對相關基本概念把握不清，才導致了諸多問題和疑問。
首先是字元集的概念。
我們知道，電子計算機最初是用來進行科學計算的（所以叫做「計算機」），但隨著技術的發展，還需要計算機進行其它方面的應用處理。這就要求計算機不僅能處理數值，還能處理諸如文字、特殊符號等其它信息，而計算機本身能直接處理的只有數值信息，所以就要求對這些文字、符號信息進行數值編碼，最初的字元集是我們都非常熟悉的ASCII，它是用7個二進制位來表示128個字元，而後來隨著不同國家、組織的需要，出現了許許多多的字元集，如表示西歐字元的ISO8859系列的字元集，表示漢字的GB2312-80、GBK等字元集。
字元集的實質就是對一組特定的符號，分別賦予不同的數值編碼，以便於計算機的處理。
字元集之間的轉換。字元集多了，就會帶來一個問題，比如一個字元，在某一字元集中被編碼為一個數值，而在另一個字元集中被編碼為另一個數值，比如我來創造兩個字元集demo_charset1與demo_charset2，在demo_charset1中，我規定了三個符號的編碼為：A（0001），B（0010），？（1111）；而在demo_charset2中，我也規定了三個符號的編碼為：A（1001），C（1011），？（1111），這時我接到一個任務，要編寫一個程序，負責在demo_charset1與demo_charset2之間進行轉換。由於知道兩個字元集的編碼規則，對於demo_charset1中的0001，在轉換為demo_charset2時，要將其編碼改為1001；對於demo_charset1中的1111，轉換為demo_charset2時，其數值不變；而對於demo_charset1中的0010，其對應的字元為B，但在demo_charset2沒有對應的字元，所以從理論上無法轉換，對於所有這類無法轉換的情況，我們可以將它們統一轉換為目標字元集中的一個特殊字元（稱為「替換字元」），比如在這里我們可以將？作為替換字元，所以B就轉換為了？，出現了信息的丟失；同樣道理，將demo_charset2的C字元轉換到demo_charset1時，也會出現信息丟失。
所以說，在字元集轉換過程中，如果源字元集中的某個字元在目標字元集中沒有定義，將會出現信息丟失。
資料庫字元集的選擇。
我們在創建資料庫時，需要考慮的一個問題就是選擇什麼字元集與國家字元集（通過create database中的CHARACTER SET與NATIONAL CHARACTER SET子句指定）。考慮這個問題，我們必須要清楚資料庫中都需要存儲什麼數據，如果只需要存儲英文信息，那麼選擇US7ASCII作為字元集就可以；但是如果要存儲中文，那麼我們就需要選擇能夠支持中文的字元集（如ZHS16GBK）；如果需要存儲多國語言文字，那就要選擇UTF8了。
資料庫字元集的確定，實際上說明這個資料庫所能處理的字元的集合及其編碼方式，由於字元集選定後再進行更改會有諸多的限制，所以在資料庫創建時一定要考慮清楚後再選擇。
而我們許多朋友在創建資料庫時，不考慮清楚，往往選擇一個默認的字元集，如WE8ISO8859P1或US7ASCII，而這兩個字元集都沒有漢字編碼，所以用這種字元集存儲漢字信息從原則上說就是錯誤的。雖然在有些時候選用這種字元集好象也能正常使用，但它會給資料庫的使用與維護帶來一系列的麻煩，在後面的迭代過程中我們將深入分析。
客戶端的字元集。
有過一些Oracle使用經驗的朋友，大多會知道通過NLS_LANG來設置客戶端的情況，NLS_LANG由以下部分組成：NLS_LANG=<Language>_<Territory>.<Clients Characterset>，其中第三部分<Clients Characterset>的本意就是用來指明客戶端操作系統預設使用的字元集。所以按正規的用法，NLS_LANG應該按照客戶端機器的實際情況進行配置，尤其對於字元集一項更是如此，這樣Oracle就能夠在最大程度上實現資料庫字元集與客戶端字元集的自動轉換（當然是如果需要轉換的話）。
總結一下第一次迭代的重點：
字元集：將特定的符號集編碼為計算機能夠處理的數值；
字元集間的轉換：對於在源字元集與目標字元集都存在的符號，理論上轉換將不會產生信息丟失；而對於在源字元集中存在而在目標字元集中不存在的符號，理論上轉換將會產生信息丟失；
資料庫字元集：選擇能夠包含所有將要存儲的信息符號的字元集；
客戶端字元集設置：指明客戶端操作系統預設使用的字元集。

第二次迭代：通過實例加深對基本概念的理解
下面我將引用網友tellin在ITPUB上發表的「CHARACTER SET研究及疑問」帖子，該朋友在帖子中列舉了他做的相關實驗，並對實驗結果提出了一些疑問，我將對他的實驗結果進行分析，並回答他的疑問。
實驗結果分析一

quote:
--------------------------------------------------------------------------------
最初由 tellin 發布
設置客戶端字元集為US7ASCII
D:\>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII
查看伺服器字元集為US7ASCII
SQL> SELECT * FROM NLS_DATABASE_PARAMETERS;
PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_CHARACTERSET US7ASCII

建立測試表
SQL> CREATE TABLE TEST (R1 VARCHAR2(10));

Table created.

插入數據
SQL> INSERT INTO TEST VALUES('東北');

1 row created.

SQL> SELECT * FROM TEST;

R1
----------
東北

SQL> EXIT

--------------------------------------------------------------------------------

這一部分的實驗數據的存取與顯示都正確，好象沒什麼問題，但實際上卻隱藏著很大的隱患。
首先，要將漢字存入資料庫，而將資料庫字元集設置為US7ASCII是不合適的。US7ASCII字元集只定義了128個符號，並不支持漢字。另外，由於在SQL*PLUS中能夠輸入中文，操作系統預設應該是支持中文的，但在NLS_LANG中的字元集設置為US7ASCII，顯然也是不正確的，它沒有反映客戶端的實際情況。
但實際顯示卻是正確的，這主要是因為Oracle檢查資料庫與客戶端的字元集設置是同樣的，那麼數據在客戶與資料庫之間的存取過程中將不發生任何轉換。具體地說，在客戶端輸入「東北」，「東」的漢字的編碼為182（10110110）、171（10101011），「北」漢字的編碼為177（10110001）、177（10110001），它們將不做任何變化的存入資料庫中，但是這實際上導致了資料庫標識的字元集與實際存入的內容是不相符的，從某種意義上講，這也是一種不一致性，也是一種錯誤。而在SELECT的過程中，Oracle同樣檢查發現資料庫與客戶端的字元集設置是相同的，所以它也將存入的內容原封不動地傳送到客戶端，而客戶端操作系統識別出這是漢字編碼所以能夠正確顯示。
在這個例子中，資料庫與客戶端的設置都有問題，但卻好象起到了「負負得正」的效果，從應用的角度看倒好象沒問題。但這裡面卻存在著極大的隱患，比如在應用length或substr等字元串函數時，就可能得到意外的結果。另外，如果遇到導入/導出（import /export）將會遇到更大的麻煩。有些朋友在這方面做了大量的測試，如eygle研究了「源資料庫字元集為US7ASCII，導出文件字元集為US7ASCII或ZHS16GBK，目標資料庫字元集為ZHS16GBK」的情況，他得出的結論是 「如果的是在Oracle92中，我們發現對於這種情況，不論怎樣處理，這個導出文件都無法正確導入到Oracle9i資料庫中」、「對於這種情況，我們可以通過使用Oracle8i的導出工具，設置導出字元集為US7ASCII，導出後修改第二、三字元，修改 0001 為0354,這樣就可以將US7ASCII字元集的數據正確導入到ZHS16GBK的資料庫中」。我想對於這些結論，這樣理解可能更合適一些：由於ZHS16GBK字元集是US7ASCII的超級，所以如果按正常操作，這種轉換應該沒有問題；但出現問題的本質是我們讓本應只存儲英文字元的US7ASCII資料庫，非常規地存儲了中文信息，那麼在轉化過程中出現錯誤或麻煩就沒什麼奇怪的了，不出麻煩倒是有些奇怪了。
所以說要避免這種情況，就是要在建立資料庫時選擇合適的字元集，不讓標簽（資料庫的字元集設置）與實際（資料庫中實際存儲的信息）不符的情況發生。

實驗結果分析二

quote:
--------------------------------------------------------------------------------
[ 更改客戶端字元集為ZHS16GBK
D:\>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

D:\>SQLPLUS "/ AS SYSDBA"

無法正常顯示數據

SQL> SELECT * FROM TEST;

R1
--------------------
6+11

疑問1：ZHS16GBK為US7ASCII的超集，為什麼在ZHS16GBK環境下無法正常顯示

--------------------------------------------------------------------------------

這主要是因為Oracle檢查發現資料庫設置的字元集與客戶端配置字元集不同，它將對數據進行字元集的轉換。資料庫中實際存放的數據為182（10110110）、171（10101011）、177（10110001）、177（10110001），由於資料庫字元集設置為US7ASCII，它是一個7bit的字元集，存儲在8bit的位元組中，則Oracle忽略各位元組的最高bit，則182（10110110）就變成了54（0110110），在ZHS16GBK中代表數字元號「6」（當然在其它字元集中也是「6」），同樣過程也發生在其它3個位元組，這樣「東北」就變成了「6+11」。

實驗結果分析三

quote:
--------------------------------------------------------------------------------
最初由 tellin 發布
用ZHS16GBK插入數據
SQL> INSERT INTO TEST VALUES('東北');

1 row created.

SQL> SELECT * FROM TEST;

R1
--------------------
6+11
??

SQL> EXIT

--------------------------------------------------------------------------------

當客戶端字元集設置為ZHS16GBK後向資料庫插入「東北」，Oracle檢查發現資料庫設置的字元集為US7ASCII與客戶端不一致，需要進行轉換，但字元集ZHS16GBK中的「東北」兩字在US7ASCII中沒有對應的字元，所以Oracle用統一的「替換字元」插入資料庫，在這里為「？」，編碼為63（00111111），這時，輸入的信息實際上已經丟失，不管字元集設置如何改變（如下面引用的實驗結果），第二行SELECT出來的結果也都是兩個「？」號（注意是2個，而不是4個）。

quote:
--------------------------------------------------------------------------------

更改客戶端字元集為US7ASCII
D:\>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII

D:\>SQLPLUS "/ AS SYSDBA"

無法顯示用ZHS16GBK插入的字元集，但可以顯示用US7ASCII插入的字元集
SQL> SELECT * FROM TEST;

R1
----------
東北
??

更改伺服器字元集為ZHS16GBK
SQL> update props$ set value$='ZHS16GBK' WHERE NAME='NLS_CHARACTERSET';

1 row updated.

SQL> COMMIT;

更改客戶端字元集為ZHS16GBK
D:\>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

D:\>SQLPLUS "/ AS SYSDBA"

可以顯示以前US7ASCII的字元集，但無法顯示用ZHS16GBK插入的數據，說明用ZHS16GBK插入的數據為亂碼。

SQL> SELECT * FROM TEST;

R1
--------------------
東北
??

--------------------------------------------------------------------------------

需要指出的是，通過「update props$ set value$='ZHS16GBK' WHERE NAME='NLS_CHARACTERSET';」來修改資料庫字元集是非常規作法，很可能引起問題，在這里只是原文引用網友的實驗結果。

實驗結果分析四

quote:
--------------------------------------------------------------------------------

SQL> INSERT INTO TEST VALUES('東北');

1 row created.

SQL> SELECT * FROM TEST;

R1
--------------------
東北
??
東北

SQL> EXIT

--------------------------------------------------------------------------------

由於此時資料庫與客戶端的字元集設置均為ZHS16GBK，所以不會發生字元集的轉換，第一行與第三行數據顯示正確，而第二行由於存儲的數據就是63（00111111），所以顯示的是「？」號。

quote:
--------------------------------------------------------------------------------

更改客戶端字元集為US7ASCII

D:\>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII

D:\>SQLPLUS "/ AS SYSDBA"

無法顯示數據

SQL> SELECT * FROM TEST;

R1
----------
??
??
??

疑問2：第一行數據是用US7ASCII環境插入的，為何無法正常顯示？

--------------------------------------------------------------------------------

將客戶端字元集設置改為US7ASCII後進行SELECT，Oracle檢查發現資料庫設置的字元集為ZHS16GBK，數據需要進行字元集轉換，而第一行與第三行的漢字「東」與「北」在客戶端字元集US7ASCII中沒有對應字元，所以轉換為「替換字元」（「？」），而第二行數據在資料庫中存的本來就是兩個「？」號，所以雖然在客戶端顯示的三行都是兩個「？」號，但在資料庫中存儲的內容卻是不同的。

實驗結果分析五

quote:
--------------------------------------------------------------------------------

SQL> INSERT INTO TEST VALUES('東北');

1 row created.

SQL> EXIT
更改客戶端字元集為ZHS16GBK
D:\>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

D:\>SQLPLUS "/ AS SYSDBA"

無法顯示用US7ASCII插入的字元集，但可以顯示用ZHS16GBK插入的字元集
SQL> SELECT * FROM TEST;

R1
--------------------
東北
??
東北
6+11

SQL>
疑問3：US7ASCII為ZHS16GBK的子集，為何在US7ASCII環境下插入的數據無法顯示？ [/B]
--------------------------------------------------------------------------------

在客戶端字元集設置為US7ASCII時，向字元集為ZHS16GBK的資料庫中插入「東北」，需要進行字元轉換，「東北」的ZHS16GBK編碼為182（10110110）、171（10101011）與177（10110001）、177（10110001），由於US7ASCII為7bit編碼，Oracle將這兩個漢字當作四個字元，並忽略各位元組的最高位，從而存入資料庫的編碼就變成了54（00110110）、43（00101011）與49（00110001）、49（00110001），也就是「6+11」，原始信息被改變了。這時，將客戶端字元集設置為ZHS16GBK再進行SELECT，資料庫中的信息不需要改變傳到客戶端，第一、三行由於存入的信息沒有改變能顯示「東北」，而第二、四行由於插入數據時信息改變，所以不能顯示原有信息了。

分析了這么多的內容，但實際上總結起來也很簡單
分析了這么多的內容，但實際上總結起來也很簡單，要想在字元集方面少些錯誤與麻煩，需要堅持兩條基本原則：
在資料庫端：選擇需要的字元集（通過create database中的CHARACTER SET與NATIONAL CHARACTER SET子句指定）；
在客戶端：設置操作系統實際使用的字元集（通過環境變數NLS_LANG設置）。

『肆』 請教mysql 字元集的問題。

跟mysql字元集有關的有：
1. 資料庫的的字元集
2. 文本欄位( varchar , text ,char ) 的字元集
你指的是哪個呢？
以下例子以utf8為字元集（注意是utf8 不是 utf-8 )
建庫時指定字元集： create database XXXX charset utf8
一旦在建庫時指定了字元集，在建表時就可以不用指定字元集了，它會默認繼承資料庫的字元集。
如果建表時還想指定字元集：create table XXXX ( xxxxxxx ) type=MyISAM default charset utf8
或
create table XXXX ( aa varchar(8) charset utf8, bb char(4) charset utf8) type=MyISAM default charset utf8;
一旦設置了utf8為字元集，在讀取時，特別是用作網頁作為輸出 和 從網頁接受數據時，要注意：
1. 請將網頁的編碼設置為 utf-8 (請注意是 utf-8 不是 utf8 )
2. 在進行 資料庫操作 之前請先執行一下SQL： set names utf8 ， 然後再執行其它SQL語句

上面的思想是：請盡量保持所有的操作都用同一種編碼。

『伍』 mysql字元集問題 請教怎麼解決

一、轉碼失敗
在數據寫入到表的過程中轉碼失敗，資料庫端也沒有進行恰當的處理，導致存放在表裡的數據亂碼。
針對這種情況，前幾篇文章介紹過客戶端發送請求到服務端。
其中任意一個編碼不一致，都會導致表裡的數據存入不正確的編碼而產生亂碼。
比如下面簡單一條語句：
set @a = "文本字元串";
insert into t1 values(@a);

• 變數 @a 的字元編碼是由參數 CHARACTER_SET_CLIENT 決定的，假設此時編碼為 A，也就是變數 @a 的編碼。

2. 寫入語句在發送到 MySQL 服務端之前的編碼由 CHARACTER_SET_CONNECTION 決定，假設此時編碼為 B。

3. 經過 MySQL 一系列詞法，語法解析等處理後，寫入到表 t1，表 t1 的編碼為 C。
那這里編碼 A、編碼 B、編碼 C 如果不兼容，寫入的數據就直接亂碼。


二、客戶端亂碼
表數據正常，但是客戶端展示後出現亂碼。
這一類場景，指的是從 MySQL 表裡拿數據出來返回到客戶端，MySQL 里的數據本身沒有問題。客戶端發送請求到 MySQL，表的編碼為 D，從 MySQL 拿到記錄結果傳輸到客戶端，此時記錄編碼為 E（CHARACTER_SET_RESULTS）。
那以上編碼 E 和 D 如果不兼容，檢索出來的數據就看起來亂碼了。但是由於數據本身沒有被破壞，所以換個兼容的編碼就可以獲取正確的結果。
這一類又分為以下三個不同的小類：

1)欄位編碼和表一致，客戶端是不同的編碼
比如下面例子， 表數據的編碼是 utf8mb4，而 SESSION 1 發起的連接編碼為 gbk。那由於編碼不兼容，檢索出來的數據肯定為亂碼。

2）表編碼和客戶端的編碼一致，但是記錄之間編碼存在不一致的情形
比如表編碼是 utf8mb4，應用端編碼也是 utf8mb4，但是表裡的數據可能一半編碼是 utf8mb4，另外一半是 gbk。那麼此時表的數據也是正常的，不過此時採用哪種編碼都讀不到所有完整的數據。這樣數據產生的原因很多，比如其中一種可能性就是表編碼多次變更而且每次變更不徹底導致（變更不徹底，我之前的篇章里有介紹）。舉個例子，表 t3 的編碼之前是 utf8mb4，現在是 gbk，而且兩次編碼期間都被寫入了正常的數據。

3）每個欄位的編碼不一致，導致亂碼和第二點一樣的場景。不同的是：非記錄間的編碼不統一，而是每個欄位編碼不統一。舉個例子，表 c1 欄位 a1,a2。a1 編碼 gbk，a2 編碼是 utf8mb4。那每個欄位單獨讀出來數據是完整的，但是所有欄位一起讀出來，數據總會有一部分亂碼。


三、LATIN1
還有一種情形就是以 LATIN1 的編碼存儲數據
估計大家都知道字元集 LATIN1，LATIN1 對所有字元都是單位元組流處理，遇到不能處理的位元組流，保持原樣，那麼在以上兩種存入和檢索的過程中都能保證數據一致，所以 MySQL 長期以來默認的編碼都是 LATIN1。這種情形，看起來也沒啥不對的點，數據也沒亂碼，那為什麼還有選用其他的編碼呢？原因就是對字元存儲的位元組數不一樣，比如 emoji 字元 "❤"，如果用 utf8mb4 存儲，佔用 3 個位元組，那 varchar(12) 就能存放 12 個字元，但是換成 LATIN1，只能存 4 個字元。

『陸』 怎樣修改mysql資料庫字元集

首先，MySQL的字元集問題主要是兩個概念，一個是Character Sets，一個是Collations，前者是字元內容
及編碼，後者是對前者進行比較操作的一些規則。這兩個參數集可以在資料庫實例、單個資料庫、表、列等四個級
別指定。
對於使用者來說，一般推薦使用utf8編碼來存儲數據。而要解決亂碼問題，不單單是MySQL數據的存儲問題，還
和用戶的程序文件的編碼方式、用戶程序和MySQL資料庫的連接方式都有關系。

首先，MySQL有默認的字元集，這個是安裝的時候確定的，在編譯MySQL的時候可以通過DEFAULT_CHARSET=
utf8和DEFAULT_COLLATION=utf8_general_ci這兩個參數（MySQL5.5版本，5.1版本用--with-charset=
utf8 --with-collation=utf8_general_ci）來指定默認的字元集為utf8，這也是最一勞永逸的辦法，這樣指定後，
客戶端連接到資料庫的編碼方式也默認是utf8了，應用程序不需要任何處理。

但是遺憾的是，很多人編譯安裝MySQL的時候沒有指定這兩個參數，大多數人更是通過二進製程序的方式安裝，那
么這時候MySQL的默認字元集是latin1。而這時候我們仍然可以指定MySQL的默認字元集，通過my.cnf文件增加
兩個參數：
1.在[mysqld]下添加
default-character-set=utf8（mysql 5.5 版本添加character-set-server=utf8）
2.在[client]下添加
default-character-set=utf8
這樣我們建資料庫建表的時候就不用特別指定utf8的字元集了。配置文件里的這種寫法解決了數據存儲和比較的問題
，但是對客戶端的連接是沒有作用的，客戶端這時候一般需要指定utf8方式連接才能避免亂碼。也就是傳說總的set
names命令。事實上，set names utf8命令對應的是伺服器端以下幾個命令：
SET character_set_client = utf8;
SET character_set_results = utf8;
SET character_set_connection = xutf8;
但這三個參數是不能寫在配置文件my.cnf里的。只能通過set命令來動態修改。我們需要的是在配置文件里寫好一勞
永逸的辦法。那麼這時候，是否有在服務端解決問題的辦法呢，可行的思路是在init_connect里設置。這個命令在每
個普通用戶連接上來的時候都會觸發執行，可以在[mysqld]部分增加以下一行設置連接字元集：
在[mysqld]下添加：
init_connect = 'SET NAMES utf8'
總結：
1、首選在編譯安裝MySQL的時候指定兩個參數使用utf8編碼。
2、次選在配置文件my.cnf或my.ini設定兩個參數，同時設置init_connect參數。
3、第三在配置文件my.cnf或my.ini設定兩個參數，同時客戶端的連接指定set names命令。
4、在配置文件my.cnf里的client和server處加入default-character-set參數方便管理。

『柒』 用VS2008輸出一個變數的值時如何解決字元集的問題

看你傳遞的字元串是WCHAR*、char* 還是string 了針對這些都有不同的字元串轉換，string的 可以用strTemp.c_str(); WCHAR* 直接CString（strTemp）就行，如果是char* 就比較麻煩了，需要使用函數WideCharToMultiByte() 進行轉化，具體轉化方法你查查這個函數的用法吧。你這些問題是字元串轉換的問題，在C++中使用Unicode的程序中很常見。

『捌』 oracle 11g字元集問題，回顯都是問號怎麼解決。

你是在伺服器端插入數據的吧，嘗試在XP的客戶端輸入數據試試。
這是因為字元集的問題造成的
你系統字元集是zh_CN.gb2312
環境變數字元集是ZHS16GBK
伺服器資料庫字元集是 ZHS16GBK
由於你環境變數字元集和你的伺服器資料庫一樣，所以欺騙了資料庫，你輸入中文沒有進行轉碼，所以資料庫保存的字元代碼是zh_CN.gb2312的代碼，而該代碼在ZHS16GBK里找不到對應的字元，它就會用？符號表示。
解決方法把你的環境變數字元集修改得和你操作系統字元集合一樣或者是超集就可以了
export NLS_LANG=American_America.ZHS16CGB231280

『玖』 win7系統下oracle客戶端字元集設置問題

win7的字元集我沒弄過，我弄過win8的，你可以嘗試一下，就是去環境變數裡面新增一個字元集。截圖給你看一下：

你先去嘗試一下，我的就是這樣解決的，如果不行再想其他的辦法。希望能夠幫到你

『拾』 MYsql 字元集亂碼的問題，困擾了好久，幫我解決了再加100分

1、MySQL庫、表存儲設置UTF-8

2、驅動連接字元串String url=

」jdbc:mysql://127.0.0.1:3306/dbname?useUnicode=true&characterEncoding=UTF-8「

3、JSP頁面中<%@ page contentType="text/html; charset=utf-8"%>

這樣應該就可以傳遞正確編碼了、不過你的輸入輸出環節的轉換代碼具體是什麼樣的？

此前如果有遺漏可能還要檢查：

4、設置Tomcat6的server.xml中<Connector>標簽：<Connector port="8080"protocol="HTTP/1.1" connectionTimeout="20000"
URIEncoding="utf-8" useBodyEncodingForURI="true" redirectPort="8443" />

5、JSP頁面讀取後台中文變數<%=newstring(aStrVal.getstring(2).getbytes("iso8859-1"),"utf-8")%>

控制裝飾層從前端接收中文變數String aStrVal =new String(req.getParameter("strPara").getBytes("ISO8859_1"));

6、如果第4個措施因特殊情況不能修改，則可以自己寫過濾器：

packagefilters;

importjava.io.IOException;
importjavax.servlet.Filter;
importjavax.servlet.FilterChain;
importjavax.servlet.FilterConfig;
importjavax.servlet.ServletException;
importjavax.servlet.ServletRequest;
importjavax.servlet.ServletResponse;
importjavax.servlet.UnavailableException;

{
/**
*
*thisfilter.
*/
protectedStringencoding="UTF-8";

/**
*.Ifthisvalue
*isnull,.
*/
=null;
/**
*?
*/
protectedbooleanignore=true;

publicvoiddestroy(){
this.encoding=null;
this.filterConfig=null;
}

publicvoiddoFilter(ServletRequestrequest,ServletResponseresponse,
FilterChainchain)throwsIOException,ServletException{

//
if(ignore||(request.getCharacterEncoding()==null)){
Stringencoding=selectEncoding(request);
if(encoding!=null)
request.setCharacterEncoding(encoding);
}
chain.doFilter(request,response);
}

/**
*Placethisfilterintoservice.
*@
*/
publicvoidinit(FilterConfigfilterConfig)throwsServletException{

this.filterConfig=filterConfig;
this.encoding=filterConfig.getInitParameter("encoding");
Stringvalue=filterConfig.getInitParameter("ignore");
if(value==null)
this.ignore=true;
elseif(value.equalsIgnoreCase("true"))
this.ignore=true;
elseif(value.equalsIgnoreCase("yes"))
this.ignore=true;
else
this.ignore=false;
}

protectedStringselectEncoding(ServletRequestrequest){
return(this.encoding);
}
}

<filter>
<filter-name>encodingFilter</filter-name>
<filter-class>filters.SetCharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>GBK</param-value>
</init-param>
<init-param>
<param-name>ignore</param-name>
<param-value>false</param-value>
</init-param>
</filter>

<filter-mapping>
<filter-name>encodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

另外請確認如下都已經設置好：

MySQL 5.1在在my.ini內的 [mysql] 和[mysqld]兩處 default-character-set=utf8

MySQL 5.5在在my.ini內的 [mysql]default-character-set=utf8；[mysqld]character-set-server=utf8

Myeclipse偏好首選設置里：

General->Workspace Text file encoding；

General->Content Types，右側Content Types樹，點開Text，確認Java Source File下面的Default encoding框中是UTF-8，用到jsp、js、css同上；

--看你的截圖只是數據前後交換的問題，項目工作空間的都沒問題了。