oracle資料庫亂碼
① Oracle數據出現中文亂碼怎麼解決
1. 伺服器指定字元集與客戶字元集不同，而與載入數據字元集一致。
解決方法：對於這種情況，只需要設置客戶端字元集與伺服器端字元集一致就可以了，具體操作如下：
* 查看當前字元集：
sql> select * from sys.props$
2 WHERE NAME=『NLS_CHARACTERSET』;
NAME value$
NLS_CHARACTERSET ZHS16GBK
可以看出，現在伺服器端Oracle資料庫的字元集為『ZHS16GBK』
* 根據伺服器的字元集在客戶端作相應的配置或者安裝Oracle的客戶端軟體時指定：
如果還沒安裝客戶端，那麼在安裝客戶端時，指定與伺服器相吻合的字元集即可；如果已經安裝好了客戶端，並且客戶端為 sql*net 2.0 以下版本，進入Windows的系統目錄，編輯oracle.ini文件，用US7ASCII替換原字元集，重新啟動計算機，設置生效；否則，如果，客戶端為 sql*net 2.0 以上版本，在Win98 下 運 行REGEDIT,第一步選HKEY_LOCAL_MACHINE,第二步選擇SOFTWARE， 第三步選擇 Oracle， 第四步選擇 NLS_LANG， 鍵 入 與服 務 器 端 相 同 的 字 符 集
（本例為：HKEY_LOCAL_MACHINE/
SOFTWARE/ORACLE/NLS_LANG ：AMERICAN _ AMERICA. ZHS16GBK）。
如果是UNIX客戶端，則：
SQL> conn / as sysdba
Connected.
SQL> SQL> UPDATE sys.PROPS$ SET value$=『SIMPLIFIED CHINESE』
2 WHERE NAME=『NLS_LANGUAGE』;
2. 伺服器指定字元集與客戶字元集相同,與載入數據字元集不一致。
解決方法：強制載入數據字元集與伺服器端字元集一致。要做到這一點，可以通過重新創建資料庫，並選擇與原卸出數據一致的字元集，然後IMP數據，這種情況僅僅適用於空庫和具有同一種字元集的數據。
解決這類問題，也可以先將數據載入到具有相同字元集的伺服器上，然後用轉換工具卸出為foxbase 格式或access格式資料庫，再用轉換工具轉入到不同字元集的Oracle資料庫中，這樣就避免了Oracle字元集的困擾。目前資料庫格式轉換的工具很多,像power builder5.0以上版本提供的pipeline及Microsoft Access資料庫提供的數據導入/導出功能等。
3. 伺服器指定字元集與客戶字元集不同,與輸入數據字元集不一致。
對於這種情況，目前為止都還沒有太好的解決方法。
通過上面的了解，我們知道，導致在後期使用資料庫時出現種種關於字元集的問題，多半是由於在資料庫設計、安裝之初沒有很好地考慮到以後的需要，所以，我們完全可以通過在伺服器上和客戶端使用相同的字元集來避免由此類問題引出的麻煩
怎樣修改查看Oracle字元集
a.資料庫伺服器字元集select * from nls_database_parameters，其來源於props$，是表示資料庫的字元集。
b.客戶端字元集環境select * from nls_instance_parameters,其來源於v$parameter，
表示客戶端的字元集的設置，可能是參數文件，環境變數或者是注冊表
c.會話字元集環境 select * from nls_session_parameters，其來源於v$nls_parameters，表示會話自己的設置，可能是會話的環境變數或者是alter session完成，如果會話沒有特殊的設置，將與nls_instance_parameters一致。
客戶端的字元集要求與伺服器一致，才能正確顯示資料庫的非Ascii字元。如果多個設置存在的時候，alter session>環境變數>注冊表>參數文件
實際情況
我用select * from nls_database_parameters
PARAMETER VALUE
------------------------------ ------------------------------
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET ZHS16GBK
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
PARAMETER VALUE
------------------------------ ------------------------------
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_RDBMS_VERSION 10.2.0.1.0
說明我在創建資料庫時指定的字元集是ZHS16GBK，我用
update sys.props$ set value$='AL32UTF8' where name='NLS_CHARACTERSET';
修改了字元集，但插入中文時仍然有問題，這或許就如上面資料所說的通過修改SYS.PROPS$來修改主要是對應客戶端的顯示，與存儲無關，
所以仍舊是亂碼。
然後我重新創建了個資料庫，指定字元集為AL32UTF8，插入中文就沒問題了。
可見我們如果要在資料庫中顯示中文，在創建資料庫時一定喲指定好所用的字元集。
② oracle亂碼問題
你可以進行下編碼轉換啊
ORACLE默認的好象是UTF-8，你轉換成GBK就可以了
在J2EE里可以使用過濾器，在PHP里我就不太清楚了
我想也應該有那一類的東東吧~
③ plsql連接oracle資料庫查詢漢子顯示亂碼
打開PLSQL
④ oracle資料庫表中某個欄位已存在漢字亂碼，怎樣查找出這些亂碼數據，
查詢資料庫表某欄位含「亂碼」的數據的一個方法
說明：
在某些情況下，由於字元集不兼容等問題，資料庫中的記錄可能存在「亂碼」，本文就是介紹一個SQL語句把亂碼的記錄找到。
什麼是「亂碼」
這是首先需要明確的，其實如果資料庫記錄了「半個漢字」實際他只會記錄一個「？」（Oracle），如果記錄的亂碼恰好變成另外一個「漢字」和殘余字元，那這個新的「漢字」是不能用下面的方法找出來的。
適用范圍
查找記錄中是否含有ascii碼（特別是「？」）的方式找到「亂碼」的記錄。
SQL模板
Select
*
from
Table_A
t
Where
instr(Name,chr(1))>0
or
instr(Name,chr(2))>0
or
instr(Name,chr(3))>0
or
instr(Name,chr(4))>0
or
instr(Name,chr(5))>0
or
instr(Name,chr(6))>0
or
instr(Name,chr(7))>0
or
instr(Name,chr(8))>0
or
instr(Name,chr(9))>0
or
instr(Name,chr(10))>0
or
instr(Name,chr(11))>0
or
instr(Name,chr(12))>0
or
instr(Name,chr(13))>0
or
instr(Name,chr(14))>0
or
instr(Name,chr(15))>0
or
instr(Name,chr(16))>0
or
instr(Name,chr(17))>0
or
instr(Name,chr(18))>0
or
instr(Name,chr(19))>0
or
instr(Name,chr(20))>0
or
instr(Name,chr(21))>0
or
instr(Name,chr(22))>0
or
instr(Name,chr(23))>0
or
instr(Name,chr(24))>0
or
instr(Name,chr(25))>0
or
instr(Name,chr(26))>0
or
instr(Name,chr(27))>0
or
instr(Name,chr(28))>0
or
instr(Name,chr(29))>0
or
instr(Name,chr(30))>0
or
instr(Name,chr(31))>0
or
instr(Name,chr(32))>0
or
instr(Name,chr(33))>0
or
instr(Name,chr(34))>0
or
instr(Name,chr(35))>0
or
instr(Name,chr(36))>0
or
instr(Name,chr(37))>0
or
instr(Name,chr(38))>0
or
instr(Name,chr(39))>0
or
instr(Name,chr(40))>0
or
instr(Name,chr(41))>0
or
instr(Name,chr(42))>0
or
instr(Name,chr(43))>0
or
instr(Name,chr(44))>0
or
instr(Name,chr(45))>0
or
instr(Name,chr(46))>0
or
instr(Name,chr(47))>0
or
instr(Name,chr(48))>0
or
instr(Name,chr(49))>0
or
instr(Name,chr(50))>0
or
instr(Name,chr(51))>0
or
instr(Name,chr(52))>0
or
instr(Name,chr(53))>0
or
instr(Name,chr(54))>0
or
instr(Name,chr(55))>0
or
instr(Name,chr(56))>0
or
instr(Name,chr(57))>0
or
instr(Name,chr(58))>0
or
instr(Name,chr(59))>0
or
instr(Name,chr(60))>0
or
instr(Name,chr(61))>0
or
instr(Name,chr(62))>0
or
instr(Name,chr(63))>0
or
instr(Name,chr(64))>0
or
instr(Name,chr(65))>0
or
instr(Name,chr(66))>0
or
instr(Name,chr(67))>0
or
instr(Name,chr(68))>0
or
instr(Name,chr(69))>0
or
instr(Name,chr(70))>0
or
instr(Name,chr(71))>0
or
instr(Name,chr(72))>0
or
instr(Name,chr(73))>0
or
instr(Name,chr(74))>0
or
instr(Name,chr(75))>0
or
instr(Name,chr(76))>0
or
instr(Name,chr(77))>0
or
instr(Name,chr(78))>0
or
instr(Name,chr(79))>0
or
instr(Name,chr(80))>0
or
instr(Name,chr(81))>0
or
instr(Name,chr(82))>0
or
instr(Name,chr(83))>0
or
instr(Name,chr(84))>0
or
instr(Name,chr(85))>0
or
instr(Name,chr(86))>0
or
instr(Name,chr(87))>0
or
instr(Name,chr(88))>0
or
instr(Name,chr(89))>0
or
instr(Name,chr(90))>0
or
instr(Name,chr(91))>0
or
instr(Name,chr(92))>0
or
instr(Name,chr(93))>0
or
instr(Name,chr(94))>0
or
instr(Name,chr(95))>0
or
instr(Name,chr(96))>0
or
instr(Name,chr(97))>0
or
instr(Name,chr(98))>0
or
instr(Name,chr(99))>0
or
instr(Name,chr(100))>0
or
instr(Name,chr(101))>0
or
instr(Name,chr(102))>0
or
instr(Name,chr(103))>0
or
instr(Name,chr(104))>0
or
instr(Name,chr(105))>0
or
instr(Name,chr(106))>0
or
instr(Name,chr(107))>0
or
instr(Name,chr(108))>0
or
instr(Name,chr(109))>0
or
instr(Name,chr(110))>0
or
instr(Name,chr(111))>0
or
instr(Name,chr(112))>0
or
instr(Name,chr(113))>0
or
instr(Name,chr(114))>0
or
instr(Name,chr(115))>0
or
instr(Name,chr(116))>0
or
instr(Name,chr(117))>0
or
instr(Name,chr(118))>0
or
instr(Name,chr(119))>0
or
instr(Name,chr(120))>0
or
instr(Name,chr(121))>0
or
instr(Name,chr(122))>0
or
instr(Name,chr(123))>0
or
instr(Name,chr(124))>0
or
instr(Name,chr(125))>0
or
instr(Name,chr(126))>0
or
instr(Name,chr(127))>0
⑤ 如何解決oracle資料庫因字元集出現的亂碼問題
oracle資料庫查詢時出現亂碼，很可能是該資料庫的字元集設定不支持中文，但是表中數據含有中文，所以變為亂碼。
如果是字元集原因，解決方法如下：
1、shutdown immediate； 關閉資料庫
2、startup mount； 開啟資料庫至掛載模式（只掛實例，不啟動資料庫）
3、alter system enable restricted session；開啟會話限制
4、alter system set aq_tm_processes=0；修改系統參數
5、alter system set job_queue_processes=0；修改系統參數
6、alter database open；啟動資料庫為open
7、alter database national character set internal_user (zhs16gbk)；修改字元集
8、alter system disable restricted session；關閉會話限制
括弧內可填寫字元集類型，zhs16gbk、AL32UTF8等字元集都支持中文。
⑥ idea中查詢Oracle資料庫數據中文亂碼，但是在plsql中查詢正常(Oracle字元集是US7ASCII)
oracle資料庫查詢時出現亂碼，很可能是該資料庫的字元集設定不支持中文，但是表中數據含有中文，所以變為亂碼。
如果是字元集原因，解決方法如下：
1、shutdown immediate； 關閉資料庫
2、startup mount； 開啟資料庫至掛載模式（只掛實例，不啟動資料庫）
3、alter system enable restricted session；開啟會話限制
4、alter system set aq_tm_processes=0；修改系統參數
5、alter system set job_queue_processes=0；修改系統參數
6、alter database open；啟動資料庫為open
7、alter database national character set internal_user (zhs16gbk)；修改字元集
8、alter system disable restricted session；關閉會話限制
括弧內可填寫字元集類型，zhs16gbk、AL32UTF8等字元集都支持中文。
⑦ oracle資料庫打開本地文件輸出亂碼怎麼解決
一般來說，你這情況是因為資料庫伺服器和客戶端字元集不匹配，執行sqlplus的機器就是客戶端，伺服器和客戶端也可能是一台機器，執行sqlplus之前要先設置客戶端的字元集，在linux上：export NLS_LANG=.......
在windows上set NLS_LANG
查詢資料庫字元集：select property_value from database_properties where property_name like 'NLS_CHAR%';
比如查詢結果是：ZHS16GBK
那你在sqlplus之前要設置：export NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
然後再登錄sqlplus用spool生成數據
⑧ oracle 亂碼 如何解決
1、對於Oracle Enterprise Manager中的所有工具，有一個配置文件名為dbappscfg.properties，修改該文件即可解決上述問題。這個文件的位置在$ORACLE_HOME\sysman\config目錄下，用任何的文本編輯器打開該文件，在這個文件裡面，找到這樣一項，
# SQLPLUS_NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
2、去掉注釋符#，同時將其修改為
SQLPLUS_NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
3、對於Windows操作系統，還需要修改一項，在文件中找到# SQLPLUS_SYSTEMROOT=c:\\WINNT40，去掉注釋符，將其修改為你所在機器的操作系統主目錄。如操作系統的主目錄在D盤的Winnt下，則將其修改為
SQLPLUS_SYSTEMROOT=d:\\WINNT。
對於後面一項的修改只對Windows操作系統進行，對UNIX操作系統則不需要。如果在Windows操作系統中不修改該項，在Oracle Enterprise Manager中，連接系統時，會提示如下的錯誤：
ORA-12560 TNS:protocol adapter error
或者
ORA-12545 Connect failed because target host or object does not exist
4、修改完成後，保存文件，退出編輯。重新連接SQL PLUS Worksheet，字元集亂碼問題得到解決,顯示正確的簡體中文字元集。
問題: 使用Oracle Instant Client 出現 ORA-12705: Cannot access NLS data files or invalid environment specified 錯誤。
如果是Windows平台，注冊表裡 \HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE 查找鍵 NLS_LANG,這個鍵由Oracle標准客戶端安裝創建, 值是 NA 。這個導致了 ORA-12705錯誤。解決方法就是改名 NLS_LANG。
Linux下 如果環境變數 NLS_LANG 值是NA 會引起 ORA-12705 錯誤，解決方法是刪除這個變數
unset NLS_LANG