PostgreSQL本地化
Posted 春困秋乏夏打盹
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了PostgreSQL本地化相关的知识,希望对你有一定的参考价值。
从管理员的角度描述可用的本地化特性。PostgreSQL支持两种本地化方法:
利用操作系统的区域(locale)特性,提供对区域相关的排序顺序、数字格式、 翻译过的信息和其它方面。
提供一些不同的字符集来支持存储所有种类语言的文本,并提供在客户端和服务器之间的字符集转换。
1. 区域支持
区域支持指的是应用遵守文化偏好的问题,包括字母表、排序、数字格式等。PostgreSQL使用服务器操作系统提供的标准 ISO C 和POSIX的区域机制。
1.1. 概述
区域支持是在使用initdb创建一个数据库集簇时自动被初始化的。默认情况下,initdb将会按照它的执行环境的区域设置初始化数据库集簇
如果你想使用其它的区域(或者你还不知道你的系统设置的区域是什么),那么你可以用--locale选项准确地告诉initdb你要用
哪一个区域。 比如:
initdb --locale=sv_SE//这个Unix系统上的例子把区域设置为瑞典(SE)瑞典语(sv)。
有一套区域子类用于控制本地化规则的某些方面:默认都是‘en_US.UTF-8‘
LC_COLLATE 字符串排序顺序
LC_CTYPE 字符分类(什么是一个字符?它的大写形式是否等效?)
LC_MESSAGES 消息使用的语言Language of messages
LC_MONETARY 货币数量使用的格式
LC_NUMERIC 数字的格式
LC_TIME 日期和时间的格式
一旦一个数据库被创建,你就不能在数据库上修改这些区域分类的值。LC_COLLATE和LC_CTYPE就是这样的分类。
它们影响索引的排序顺序,因此它们必需保持固定, 否则在文本列上的索引将会崩溃
1.2. 行为
区域设置特别影响下面的 SQL 特性:
在文本数据上使用ORDER BY或标准比较操作符的查询中的排序顺序
函数upper、lower和initcap
模式匹配操作符(LIKE、SIMILAR TO和POSIX风格的正则表达式);区域影响大小写不敏感匹配和通过字符类正则表达式的字符分类
to_char函数家族
为LIKE子句使用索引的能力
PostgreSQL中使用非C或非POSIX区域的缺点是性能影响。它降低了字符处理的速度并且阻止了在LIKE中对普通索引的使用。因此,只能在真正需要的时候才使用它。
1.3. 问题
如果根据上面解释区域支持仍然不能运转,检查一下操作系统的区域支持是否被正确配置。
要检查系统中安装了哪些区域,你可以使用命令locale -a(如果你的操作系统提供了该命令)。
请检查PostgreSQL确实正在使用你认为它该用的区域设置。LC_COLLATE和LC_CTYPE设置都
是在数据库创建时决定的,并且在除了创建数据库之外的操作中都不能被更改。
其它的区域设置包括LC_MESSAGES和LC_MONETARY都是由服务器启动的环境决定的, 但是可以在运行时
修改。你可以用SHOW命令检查活跃的区域设置。
2. 排序规则支持
排序规则特性允许指定每一列甚至每一个操作的数据的排序顺序和字符分类行为。这放松了
数据库的LC_COLLATE和LC_CTYPE设置自创建以后就不能更改这一限制。
2.1. 概念
在概念上,一种可排序数据类型的每一种表达式都有一个排序规则(内建的可排序数据类型是text、varchar和char。用户定义
的基础类型也可以被标记为可排序的,并且在一种可排序数据类型上的域也是可排序的)。
如果该表达式是一个列引用,该表达式的排序规则就是列所定义的排序规则。
如果该表达式是一个常量,排序规则就是该常量数据类型的默认排序规则。
当数据库系统必须要执行一次排序或者字符分类时,它使用输入表达式的排序规则。
这会在使用例如ORDER BY子句以及函数或操作符调用(如<)时发生。应用于ORDER BY子句的排序规则就是排序键的排序规则。
除比较操作符之外,在大小写字母之间转换的函数会考虑排序规则,例如lower、upper和initcap。
模式匹配操作符和to_char及相关函数也会考虑排序规则。
对于一个函数或操作符调用,其排序规则通过检查在执行指定操作时参数的排序规则来获得。
例如,考虑这个表定义:
CREATE TABLE test1 (
a text COLLATE "de_DE",
b text COLLATE "es_ES",
...
);
然后在
SELECT a < ’foo’ FROM test1;中,<比较被根据de_DE规则执行,因为表达式组合了一个隐式派生的排序规则和默认排序规则。但是在
SELECT a < (’foo’ COLLATE "fr_FR") FROM test1;中,比较被使用fr_FR规则执行,因为显式排序规则派生重载了隐式排序规则。更进一步,给定
SELECT a < b FROM test1;
解析器不能确定要应用哪个排序规则,因为a列和b列具有冲突的隐式排序规则。
由于<操作符不需要知道到底使用哪一个排序规则,这将会导致一个错误。该错误可以通过在一个输入表达式上附加一个显式排序规则说明符来解决,因此:
SELECT a < b COLLATE "de_DE" FROM test1;
或者等效的
SELECT a COLLATE "de_DE" < b FROM test1;
在另一方面,结构相似的情况
SELECT a || b FROM test1;
不会导致一个错误,因为||操作符不关心排序规则:不管排序规则怎样它的结果都相同
2.2. 管理排序规则
一个排序规则是一个SQL模式对象,它将一个SQL名字映射到一个操作系统区域。
在 所 有 的 平 台 上 , 名 为default、C和POSIX的 排 序 规 则 都 可 用 。
PostgreSQL在碰到具有相同属性的不同排序规则对象时会认为它们是不兼容的。
3. 字符集支持
PostgreSQL里面的字符集支持你能够以各种字符集存储文本,包括单字节字符集,以及多字节字符集
默认的字符集是在使用 initdb初始化你的PostgreSQL数据库集簇时选择的。
在你创建一个数据库时可以重载它,因此你可能会有多个数据库并且每一个使用不同的字符集。
但是,一个重要的限制是每个数据库的字符集必须和数据库的LC_CTYPE(字符分类)和LC_COLLATE (字符串排序顺序)设置兼容。
3.2. 设置字符集
initdb -E EUC_JP//把缺省字符集设置为EUC_JP
createdb -E EUC_KR -T template0 --lc-collate=ko_KR.euckr --lc-ctype=ko_KR.euckr korean
将创建一个使用EUC_KR字符集和ko_KR区域的名为korean的数据库。
使用 SQL 命令:
CREATE DATABASE korean WITH ENCODING ‘EUC_KR‘ LC_COLLATE=‘ko_KR.euckr‘ LC_CTYPE=‘ko_KR.euckr‘
-bash-4.2$ psql -l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
exampledb | dbuser | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =Tc/dbuser +
| | | | | dbuser=CTc/dbuser
hq | dbuser | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
3.3. 服务器和客户端之间的自动字符集转换
PostgreSQL支持一些编码在服务器和前端之间的自动编码转换。
服务器字符集 可用的客户端字符集
EUC_CN EUC_CN, MULE_INTERNAL, UTF8
UTF8 所有支持的编码
postgres=# SHOW client_encoding;
client_encoding
-----------------
UTF8
使用SET client_encoding TO。 可以使用这个SQL命令设置客户端编码:
SET CLIENT_ENCODING TO ’value’;
你还可以把标准SQL语法里的SET NAMES用于这个目的:
SET NAMES ’value’;
要返回到缺省编码:
RESET client_encoding;
以上是关于PostgreSQL本地化的主要内容,如果未能解决你的问题,请参考以下文章