专题实验 字符集(全球化支持）
1. 安装数据库时, 设置的字符集
CHARACTER SET AL32UTF8
NATIONAL CHARACTER SET AL16UTF16
这里推荐使用 unicode 字符集, 这也是大趋势, unicode协会的口号是, 给每个字符提供了一个唯一的数字, 无论是什么平台, 无论是什么程序, 无论是什么语言.
2. 关于字符集
字符集, 是指我们输入的字符所对应的一个编码, 字符集不同, 所对应的编码就不同, 可以使用dump('你') 查看当前的编码, 编码不同, 意味着有可能出现乱码, 另外, 字符集 等字符的显示也有很重要的影响, 比如日期的显示样式 等.
注: 创建数据库以后想改变字符集是一件很困难的事情, 所以, 最好在创建数据库以前就准备好.
client 端字符集, server 端字符集, 某些字符集之间可以发生转换.( 子集-超集的关系才可以)
3. NLS_LANG 参数
NLS_LANG=language_territory.charset :
language: 服务器消息语言
territory: 地区, 指定了服务器的日期和数字等的格式
charset: 字符集
从NLS_LANG 的组成我们可以看出, 真正影响数据库字符集的其实是第三部分, 所以两个数据库之间的字符集只要第三部分一样就可以相互导入导出数据, 前面影响的只是提示信息.
导入导出(IMP/EXP)是一个常用的数据迁移及转化工具, 因其导出文件具有平台无关性, 所以在跨平台迁移中, 最为常用, 在使用EXP工具进行导出操作时, 非常重要的时客户端的字符集设置, 也就是客户端的NLS_LANG设置
自己以前在客户端执行一个脚本时, 脚本的时间格式是英文格式, 但是客户端的字符集是中文, 所以导致脚本执行出错. 修改了客户端的字符集, 运行脚本成功的经历.
传统的导入导出工具(IMP/EXP)是客户端软件, 同sqlplus一样, 因此, 使用EXP/IMP工具将同样按照NLS_LANG定义的方式调用字符集文件, 并且在服务器和客户端之间根据设置进行字符集转换:
通常在执行导出操作时, 最好把客户端字符集设置的和数据库相同, 这样同样避免在导出时发生不必要的数据转换, 导出文件将和数据库具有相同的字符集.
4. 查询字符集
1） select * from nls_database_parameters;
2) server 端: select userenv('language') from dual;
3) client端: 主要是查看 NSL_LANG 这个参数.
5. 乱码问题
3个字符集的设置
- 客户端应用字符集(sqlplus 等等) (客户端操作系统可控)
- 客户端NLS_LANG参数设置
- 服务器端, 数据库字符集(character set 设置) ( 可见跟服务器端的 NLS_LANG没啥关系)
由于一个字符在客户端应用(sqlplus 等)中以怎样的字符显示取决于客户操作系统, 客户端能够显示怎样的字符, 我们就可以在应用中录入这些字符, 至于这些字符能否在数据库中正常存储, 就和另外两个字符集设置紧密相关了(通常我们可以忽略应用程序的字符集, 这个字符集在应用程序安装时, 已经被内在的决定, 并且会依据操作系统的相关设置进行选择)
在传输过程中, 客户端NLS_LANG主要用于转换判断, 如果客户端NLS_LANG等于数据库字符集, 则不进行任何转换直接把字符插入数据库, 如果不同则进行转换, 转换有以下两种:
- 如果存在对应关系, 子集-超集, 则把相应二进制代码经过映射后传递给数据库.
- 如果不存在对应关系, 则传递一个替换字符(最常见的替换字符是"?")
综上:
1. 客户端应用字符集, 一般只要满足输入就可以了, 也就是说我们输入的字符是我们本身的意愿, 在windows平台如何查看这个字符集, cmd 命令, 这个工具的字符集决定查询结果在终端上输出显示, 当前这个cmd的字符代码页是936, 对应的时GBK字符集:
2. 客户端NLS_LANG: 要么选择跟数据库一样 AL32UTF8, 要么选择 AL32UTF8的子集, 具体的集合关系(查看本blog环境设置里图)
3. 数据库字符集: 个人推荐 AL32UTF8