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>_.，其中第三部分的本意就是用來指明客戶端作業系統預設使用的字符集。所以按正規的用法，nls_lang應該按照客戶端機器的實際情況進行配置，尤其對於字符集一項更是如此，這樣oracle就能夠在最大程度上實現資料庫字符集與客戶端字符集的自動轉換（當然是如果需要轉換的話）。總結一下第一次迭代的重點：字符集：將特定的符號集編碼為計算機能夠處理的數值；字符集間的轉換：對於在源字符集與目標字符集都存在的符號，理論上轉換將不會產生資訊丟失；而對於在源字符集中存在而在目標字符集中不存在的符號，理論上轉換將會產生資訊丟失；資料庫字符集：選擇能夠包含所有將要儲存的資訊符號的字符集；客戶端字符集設定：指明客戶端作業系統預設使用的字符集 2、資料庫的字符集字符集在建立資料庫時指定，在建立後通常不能更改，所以在建立資料庫時能否選擇乙個正確的字符集就顯得尤為重要。在建立資料庫時，我們可以指定字符集(character set)和國家字符集(national character set)。字符集用來儲存：char、varchar2、clob、long等型別資料；用來標示諸如表名、列名以及pl/sql變數等；sql和pl/sql程式單元等。國家字符集用以儲存：nchar, nvarchar2, nclob等型別資料。這些設定在資料庫建立時指定，我們可以看一下資料庫的建立指令碼： connect sys/change_on_install as sysdba set echo on spool e:\oracle\ora92\assistants\dbca\logs\createdb.log startup nomount pfile="e:\oracle\admin\eygle\scripts\init.ora"; create database eygle maxinstances 1 maxloghistory 1 maxlogfiles 5 maxlogmembers 3 maxdatafiles 100 datafile 'e:\oracle\oradata\eygle\system01.dbf' size 250m reuse autoextend on next 10240k maxsize unlimited extent management local default temporary tablespace temp tempfile 'e:\oracle\oradata\eygle\temp01.dbf' size 40m reuse autoextend on next 640k maxsize unlimited undo tablespace "undotbs1" datafile 'e:\oracle\oradata\eygle\undotbs01.dbf' size 50m reuse autoextend on next 5120k maxsize unlimited character set zhs16gbk national character set al16utf16 logfile group 1 ('e:\oracle\oradata\eygle\redo01.log') size 10m, group 2 ('e:\oracle\oradata\eygle\redo02.log') size 10m, group 3 ('e:\oracle\oradata\eygle\redo03.log') size 10m; spool off exit; 以上用粗體顯示的就是對我們至關重要的字符集設定。在建立資料庫的過程中選擇你的字符集，對於簡體中文平台，預設的字符集是:zhs16gbk zhs16cgb231280 cgb2312-80 16-bit simplified chinese mb, ascii zhs16gbk gbk 16-bit simplified chinese mb, ascii, udc 其中gb2312碼是中華人民共和國國家漢字資訊交換用編碼，全稱《資訊交換用漢字編碼字符集--基本集》，由國家標準總局發布，2023年5月1日實施，通行於大陸。新加坡等地也使用此編碼。gbk編碼是2023年12月頒布的指導性規範。gbk與國家標準 gb 2312-80 資訊處理交換碼所對應的、事實上的內碼標準相容；同時，在字彙一級支援 iso/iec 10646-1 和gb 13000-1 的全部中日韓 (cjk) 漢字(20902字)。包含了更多的編碼。但是我們說，zhs16gbk 並非是zhs16cgb231280的嚴格超集（雖然後者的漢字在前者中都存在，但是同樣的編碼在不同兩個字符集中可能表達不同的漢字），所以在做資料庫字元轉換時仍然需要特別注意。 oracle的字符集命名遵循以下命名規則：即: 《語言》《位元位數》《編碼》比如: zhs · 16 ·gbk

需要說明的是，有些字符集命名違背了這個規範，oracle8/oralce8i中的utf-8是第乙個打破這個命名規範的字符集。我們可以看到一類字符集以al開頭，如:al16utf16。其中al代表all，指適用於所有語言(all languages)，按照這個標準當年utf-8本應被命名為al24utf8。

itpub jeffli73

Oracle資料庫字符集問題解析

Oracle資料庫字符集問題解決

oracle 資料庫字符集

oracle資料庫字符集

Oracle資料庫字符集問題解析

Oracle資料庫字符集問題解決

oracle 資料庫字符集

oracle資料庫字符集

相關推薦