NLS_LANG数据库字符集中文乱码问题分析和解决
前言
已经有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