之前就遇到過幾次由於Oracle字符集引發文字化問題，稍微整理一下，作為備忘。若有不對的地方，請指出。

所謂的文字化問題，是指在根據文字編碼將文字轉換為相應二進制編碼過程中，發生的轉換失敗（轉換後的二經制在對應的字元編碼中並不存在）問題。

由於字符集歷史以及很多軟件內部處理的關係，很遺憾文字化導致的問題是時有發生的。

文字化問題發生時，由於在整個文字化轉換過程中有多個軟件參與的原因，要定位問題發生的位置並予以處理，往往是需要花一定時間的。

本文簡單說明一下對Oracle內部文字化的一些理解。

Oralce的文字編碼

究竟什麼是文字編碼？

計算機內部，所有的資料都是以0、1的二進

文字也是一樣，在計算機內部以某種形式的二進制序列被表示。那麼某個文字究竟以哪種二進制序列被表示，這個表示規則就稱作[文字編碼]。

由於實際工作過程中接觸的多是日文系統，所以下面以常見的日文編碼為例進行說明。

表1-不同文字編碼下對應的文字[あ]的二進制序列（16進製表示）

  日文存在的數種字元編碼，根據作業系統的不同，主要適用的字元編碼也有所不同。比如，

例如，把文字[あ]從SHIFT_JIS編碼轉換為EUC_JP編碼的時候，其實也就是把二進位制序列0x82A0轉換為0xA4A2的過程。這種變換，是依照事先規定好的變換表來進行的。變換表中記載了，變換前二進位制編碼和變換後二進位制編碼的對應關係。

※也有某些例外，不需要變換表，而是根據算數運算進行變化的。

但是，實際上也存在

例如，Windows環境下使用的SHIFT_JIS編碼中的[（1）]文字，在EUC_JP編碼中一般是不存在的。

Oracle作為一款軟體，搭載在各種不同的作業系統之上，根據系統文字編碼的不同也需要發生也需要發生文字編碼的轉換。這時候就可能發生文字化的問題。

對於Oracle來說，相關的字符集可以問題兩部分。

1. 將資料儲存到資料庫中時使用的文字編碼，用資料庫字符集來表示。

2. 客戶端環境使用的文字編碼，用[NLS_LANG]來表示，

資料庫字符集，是在建立資料庫的時候指定，決定資料最終以怎樣的形式儲存到資料庫中，也就是資料庫檔案中。

而客戶端環境往往是相對複雜的，可能被部署在各行中各樣的作業系統之上，為了能保證不同的作業系統之上的客戶端都能正常動作，所以提供了[NLS_LANG]。

圖1 資料庫字符集和NLS_LANG

資料庫字符集

建立資料庫時，需要指定一個數據庫字符集。通常日語環境下，資料庫字符集在資料建立之後是不能變更的。下面表2就是日語環境下常見的字符集。

表2日文環境下常見的資料庫字符集