前言

三年多来不再感兴趣或出现编码格式问题,一是远离Oracle数据库操作,二是目前Terminal、IDE和操作系统语言环境配置都很标准。例如,清一色UTF-8编码和UNIX(LF),我自己的组合如下:添加Xmanager visual studio代码/notepad2中文语言包标记的操作系统、Oracle zhs16gbk、MySQL utf8和Python 2/3 UTF-8。

本来应该是非常统一而和谐的开发环境因为SQLplus spool导出中文内容而又变更混沌,索性再彻底分析以下中文乱码的源头和解决方案。

保持操作系统,终端登录,数据库3者编码格式一致性很重要

更新记录

Locale

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

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

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

Locale –

Localization –

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_

它有三个组成部分(语言、地域和字符集),每个成分控制了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的书写格式为: 语言[_地域[.字符集]].

z=中文_中华人民共和国+国标2312字符集。 我说中文,身处中国大陆,使用国标2312字符集来表达字符。

z中文_台湾.大五码字符集 我说中文,身处台湾地区,使用Big5字符集来表达字符。

根据以上信息合理的解决思路大致是这样

检查操作系统是否已添加中文语言包

检查SecureCRT/Xshell等终端编码是否为默认编码或UTF-8

检查LANG环境变量是否合适

比如我的环境就需要配置,为什么不加z,你猜呢

export LANG=zh_CN

相关推荐