前言

已经有 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 日 - 初稿

Locale

下面 2 个地址对 Locale 语言字符集的介绍已经很清晰了，我只强调 2 点

大多数 UNIX 操作系统建议默认显示语言为英语，但是一定要添加中文语言支持包

显示中文乱码多数原因是操作系统 LANG 环境变量或者类似 Xshell 编码不统一造成的

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