前言
已經有3年多沒再關心或者遇到編碼格式的問題了，一是離Oracle數據庫操作遠了，二是現在的Terminal，IDE和操作系統語言環境配置都很標準，比如清一色的UTF-8編碼和UNIX(LF)，我自己的組合是以下形式，Xmanager + Visual Studio Code/Notepad2 + 增加中文語言包顯示的操作系統，Oracle zhs16gbk，MySQL utf8，Python 2/3 utf-8。本來應該是非常統一而和諧的開發環境因為sqlplus spool導出中文內容而又變更混沌，索性再徹底分析以下中文亂碼的源頭和解決方案。
保持操作系統，終端登錄，數據庫3者編碼格式一致性很重要
更新記錄
2017年09月06日 - 初稿
閱讀原文 - https://wsgzao.github.io/post/lang/
Locale
下面2個地址對Locale語言字符集的介紹已經很清晰了，我只強調2點
- 大多數UNIX操作系統建議默認顯示語言為英語，但是一定要添加中文語言支持包
- 顯示中文亂碼多數原因是操作系統LANG環境變量或者類似Xshell編碼不統一造成的
Locale - http://wiki.ubuntu.org.cn/Locale
Localization - https://wiki.gentoo.org/wiki/Localization/Guide
NLS_LANG
本次遇到的問題主要是由于使用sqlplus spool從Oracle數據庫導出中文數據引發連鎖問題，雖然和數據庫相關但是解決中文亂碼的思路基本上是一致的，方便各位以后可以借鑒和參考。
# 源主機：CentOS 6.8 已安裝中文語言包，保持LANG和NLS_LANG默認環境變量，Oracle Instant Client 12.2.0.1.0，已安裝sqlplus
echo $LANG
en_US.UTF-8
echo $NLS_LANG
空
# 數據庫服務器：Oracle Database 11.2.0.3.0，NLS_CHARACTERSET ZHS16GBK
sqlplus system/oracle@orabiz
SQL> select * from v$nls_parameters;
PARAMETER
----------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_LANGUAGE
AMERICAN
NLS_TERRITORY
AMERICA
NLS_CURRENCY
$
PARAMETER
----------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_ISO_CURRENCY
AMERICA
NLS_NUMERIC_CHARACTERS
.,
NLS_CALENDAR
GREGORIAN
PARAMETER
----------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_DATE_FORMAT
DD-MON-RR
NLS_DATE_LANGUAGE
AMERICAN
NLS_CHARACTERSET
ZHS16GBK
PARAMETER
----------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_SORT
BINARY
NLS_TIME_FORMAT
HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT
DD-MON-RR HH.MI.SSXFF AM
PARAMETER
----------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_TIME_TZ_FORMAT
HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT
DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY
$
PARAMETER
----------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_NCHAR_CHARACTERSET
AL16UTF16
NLS_COMP
BINARY
NLS_LENGTH_SEMANTICS
BYTE
PARAMETER
----------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_NCHAR_CONV_EXCP
FALSE
19 rows selected.
問題1：ORA-12705
ERROR:
ORA-12705: Cannot access NLS data files or invalid environment specified
12705, 00000, "Cannot access NLS data files or invalid environment specified"
// *Cause: Either an attempt was made to issue an ALTER SESSION command
// with an invalid NLS parameter or value; or the environment
// variable(s) NLS_LANG, ORA_NLSxx, or ORACLE_HOME was incorrectly
// specified, therefore the NLS data files cannot be located.
// *Action: Check the syntax of the ALTER SESSION command and the NLS
// parameter, correct the syntax and retry the statement, or
// specify the correct directory path/values in the environment
// variables.
根據以上Oracle官方提示，合理的解決思路大致是這樣
- 檢查數據庫服務器的NLS parameter
- 在客戶端中配置與服務端匹配的NLS_LANG
比如我的環境就需要配置
export NLS_LANG="american_america.zhs16gbk"
它的格式如下:NLS_LANG=language_territory.charset
它有三個組成部分(語言、地域和字符集)，每個成分控制了NLS子集的特性。
Language：指定服務器消息的語言， 影響提示信息是中文還是英文
Territory：指定服務器的日期和數字格式，
Charset：指定字符集。
如:AMERICAN_AMERICA.ZHS16GBK, SIMPLIFIED CHINESE_CHINA.ZHS16GBK
export NLS_LANG="SIMPLIFIED CHINESE_CHINA.ZHS16GBK"
從NLS_LANG的組成我們可以看出，真正影響數據庫字符集的其實是第三部分。
所以兩個數據庫之間的字符集只要第三部分一樣就可以相互導入導出數據，前面影響的只是提示信息是中文還是英文。
問題2：VI打開文件中文亂碼
其實這個問題就是由第一個問題引申出來的，主要和LANG環境變量有關
Locale 是軟件在運行時的語言環境, 它包括語言(Language), 地域 (Territory) 和字符集(Codeset)。
一個locale的書寫格式為: 語言[_地域[.字符集]].
zh_CN.GB2312＝中文_中華人民共和國＋國標2312字符集。
我說中文，身處中國大陸，使用國標2312字符集來表達字符。
zh_TW.BIG5=中文_臺灣.大五碼字符集
我說中文，身處臺灣地區，使用Big5字符集來表達字符。
根據以上信息合理的解決思路大致是這樣
- 檢查操作系統是否已添加中文語言包
- 檢查SecureCRT/Xshell等終端編碼是否為默認編碼或UTF-8
- 檢查LANG環境變量是否合適
比如我的環境就需要配置，為什么不加zh_CN.UTF-8，你猜呢
export LANG=zh_CN
