标签:string ase 乱码问题 ace sci 使用 modifier 0.12 键盘
本文介绍 GLS 相关知识,说明如何正确设置 Informix GLS 语言环境相关变量(DB_LOCALE,CLIENT_LOCALE),保证 Informix 数据库服务器、客户端能正确的支持中文字符和支持使用中文的对象名。说明在 CSDK 2.7 以上版本(当前最新版本为 CSDK 3.5)中对语言环境设置的要求。以及举例说明语言环境设置常见错误及解决办法。
IBM Informix 产品可以支持许多语言、文化和代码集。所有特定于文化的信息汇集于单个环境中,称为 Global Language Support (GLS)语言环境。除了 ASCII 美国英语之外,GLS 允许您在其他语言环境中工作并在 SQL 数据和标识中使用非 ASCII 字符。可以使用 GLS 功能来与特定语言环境定制保持一致。语言环境文件包括特定于文化的信息,如货币和日期格式以及整理顺序。
本文介绍 GLS 相关知识,说明如何正确设置 Informix GLS 语言环境相关变量(DB_LOCALE, CLIENT_LOCALE),保证 Informix 数据库服务器、客户端能正确的支持中文字符和支持使用中文的对象名。以及说明在 CSDK 2.7 以上版本(当前最新版本为 CSDK 3.5)中对语言环境设置的要求。
字符(Character)是各种文字和符号的总称,包括各国家文字、标点符号、图形符号、数字等。字符集(Character set)是多个字符的集合,字符集种类较多,每个字符集包含的字符个数不同,常见字符集名称:ASCII字符集、GB2312字符集(简体中文)、BIG5字符集(繁体中文)、 GB18030字符集(亚洲字符集合)、Unicode( 常用 UTF-8) 字符集等。
Informix GLS 语言环境对常用的字符集进行了命名及内部编码(采用 16 进制编码)管理。通过服务器端的文件:$InformixDIR/gls/cm3/registry 查看 GLS 字符名称、编码对照表。示例如下:
字符集名称 编码 十六进制编码 8859-1 819 # 0x0333 gb 57357 # 0xe00d GB2312-80 57357 # 0xe00d utf8 57372 # 0xe01c big5 57352 # 0xe008 GB18030-2000 5488 # 0x1570
GLS 环境中不同字符集名称可能对应同一个字符集编码,但一个字符集只能有一个编码,也就是说字符集编码才是唯一的。
GLS 环境中按照语言和地区把所支持的字符集分成不同的目录。$InformixDIR/gls/lc11/ 语言 _ 地区 /,如中文大陆地区的目录为:$InformixDIR/gls/lc11/zh_cn/,该目录下有如下两个文件:1570.lco e00d.lco ,说明我们在设置字符集时,我们可以使用 zh_cn.GB18030-2000 zh_cn.gb zh_cn.GB2312-80 三个不同的名称。这里(zh_cn.gb 与 zh_cn.GB2312-80 对应相同的字符集)。
GLS 环境中不同的字符集可以正确的进行转换,查看那些字符集可以正确转换的方法,查看目录 $InformixDIR/gls/cv9 目录下的是否存在指定字符集互相转换的文件。如该目录下有文件 e01ce00d.cvo 和 e00de01c.cvo 两个文件,表示 GLS 通过这两个转换文件支持 UTF-8 与 GB 之间的字符转换。
Informix 通过 DB_LOCALE 和 CLIENT_LOCALE 来设置数据库的语言本地化支持设置。DB_LOCALE 和 CLIENT_LOCALE 的值由四部分组成 ( 第 4 部分为可选 ),字符集不区分大小写。
1 2 3 4 < 语言 >_< 国家和地区 >.< 字符集名 / 字符集编码 >[@modifier]
举例说明 :
CLIENT_LOCALE=en_us.8859-1 CLIENT_LOCALE=en_us.819 # 以上两个为同一字符集:819 为 8859-1 的编码 DB_LOCALE=zh_cn.gb
Informix 数据库服务器端、客户端字符集的工作原理示意图见图 1。
客户机语言环境指定客户机应用程序用于执行读和写(I/O)操作的语言、地域和代码集。在客户机应用程序中,I/O 操作包括读取键盘输入或要发送至数据库的数据文件,以及将数据库服务器从数据库中检索的数据写入屏幕、文件或打印机。 通过 CLIENT_LOCALE 来设置客户机语言环境。
通过 DB_LOCALE 环境变量设置的数据库语言环境指定数据库服务器用于正确解释特定数据库中语言环境相关的数据类型(NCHAR 和 NVARCHAR)所需的语言、地域和代码集。DB_LOCALE 中指定的代码集确定哪些字符在任何字符列中都是有效的,并且确定数据库对象(如数据库、表、列和视图)的名称。数据库服务器使用 DB_LOCALE 环境变量指定的数据库代码集将数据传入和传出数据库。
数据库服务器使用 SERVER_LOCALE 环境变量指定的服务器代码集写文件(如调试和警告文件)。但是,数据库服务器不使用服务器语言环境来写入采用 Informix 专用格式的文件(数据库和表文件)。
数据库服务器使用数据库语言环境的代码集作为服务器处理语言环境的代码集 , 使用服务器处理语言环境来写入采用 Informix 专用格式的文件(数据库和表文件)。也就是说数据库服务器使用数据库语言环境(DB_LOCALE)来写入采用 Informix 专用格式的文件(数据库和表文件)。
在客户机应用程序请求与数据库的连接时,数据库服务器使用 GLS 语言环境执行以下步骤。
对比如下两个语言环境:
在客户机 / 服务器环境中,如果客户机或服务器计算机使用不同的代码集来表示相同的字符,那么需要将字符数据从一种代码集转换为另一种代码集。如果不进行代码集转换,那么一台计算机无法正确地处理或显示源自另一台计算机的字符数据(在这两台计算机使用不同的代码集时)。
何时执行代码集转换
只有在两个代码集(客户机和服务器处理语言环境,或服务器处理语言环境和服务器)不同时,应用程序才必须使用代码集转换。以下情况是代码集不同的可能原因:
在图 1 中,黑点表示在客户机 / 服务器环境中可能发生代码集转换的两个时刻。
客户机应用程序代码集转换
当以下两个条件都为真时,客户机应用程序自动在客户机和数据库代码集之间执行代码集转换:
客户机应用程序开始执行时,它会比较客户机和数据库语言环境的名称,以确定是否执行代码集转换。如果设置了 CLIENT_LOCALE 和 DB_LOCALE 环境变量,那么客户机应用程序使用这些语言环境名称来分别确定客户机和数据库的代码集。如果未设置 CLIENT_LOCALE(且未设置 DBNLS),那么客户机应用程序假定客户机语言环境为缺省语言环境。如果未设置 DB_LOCALE(且未设置 DBNLS),那么客户机应用程序假定数据库语言环境与客户机语言环境(CLIENT_LOCALE 设置的值)相同。
如果客户机和数据库代码集相同,那么无需进行代码集转换。但是,如果代码集不匹配,客户机应用程序必须确定这两个代码集是否可转换。如果客户机可以找到关联的代码集转换文件,那么两个代码集是可转换的。这些代码集转换文件必须存在于客户机计算机上。
举例说明:
客户机应用程序:CLIENT_LOCALE=en_us.1252 DB_LOCALE=en_us.8859-1 客户机应用程序确定它必须在 Windows 代码页 1252(客户机语言环境中)和 ISO8859-1 代码集(数据库语言环境中)之间执行代码集转换。 若链接具有 GB(zh_cn.gb) 语言环境的数据库,那么数据库将设置 SQLWARN 警告,原因是语言、地区和代码 集不同。客户机应用程序将不正确地执行代码集转换。 它将继续在 Windows 代码页 1252 和 ISO8859-1 之间,而不是在 Windows 代码页 1252 和 zh_cn.gb 之间进行 转换。这种情况可能会导致数据破坏。应用程序将不会继续此链接。
Informix 通过 DB_LOCALE 和 CLIENT_LOCALE 来设置数据库的语言本地化支持设置。
在创建数据库时(为了统一系统数据库与应用数据库的字符集,在创建数据库实例时),请按如下步骤设置数据库的 DB_LOCALE 值。
1. 设置环境变量 DB_LOCALE set DB_LOCALE=zh_cn.gb 2. 创建数据库 create database dbname 3. 验证当前数据库字符集 SELECT dbs_collate FROM sysmaster:sysdbslocale WHERE dbs_dbsname = ‘ dbname ’
当我们使用 ODBC,JDBC 连接数据库时,我们需要在连接信息中正确设置语言环境变量:DB_LOCALE 和 CLIENT_LOCALE。
设置语言环境变量 DB_LOCALE=zh_cn.gb CLIENT_LOCALE=zh_cn.gb
ODBC:
下图为 WINDOWS 环境下 ODBC 语言环境设置示意图。
UNIX 环境下需要在 odbc.ini 文件中定义:
在 odbc.ini 文件中定义如下两项数据库语言环境变量 DB_LOCALE=zh_cn.gb CLIENT_LOCALE=zh_cn.gb
JDBC:
在使用 JDBC 连接数据库时,我们需要在连接数据库的 URL 中设置数据库语言环境变量:DB_LOCALE 和 CLIENT_LOCALE。示例如下:
String url = "jdbc:Informix-sqli://10.127.1.11:8001/testdb:
InformixSERVER=servername;user=user;password=password;
DB_LOCALE=zh_CN.gb;CLIENT_LOCALE=zh_CN.gb";
在 Informix 数据库字符集设置与使用过程,我们常会遇到一些字符集相关错误,知道了错误产生的原因,就可以很容易解决问题。这里我们总结了几种常见的字符集设置相关问题。
当设置的 DB_LOCALE 和 CLIENT_LOCALE 的字符集对应的以下文件不存在时,出现该错误。
举例说明:
DB_LOCALE = en_us.utf8 #(对应的 16 进制编码为:e01c) CLIENT_LOCALE = zh_cn.gb18030-2000 #(对应的 16 进制编码为:1570) 以下 3 个文件必须存在,缺任意文件将报 Error -23101。 - $InformixDIR/gls/lc11/en_us/e01c.lco - $InformixDIR/gls/lc11/zh_cn/e01c.lco - $InformixDIR/gls/lc11/zh_cn/1570.lco
当设置的 DB_LOCALE 和 CLIENT_LOCALE 的字符集对应的以下转换文件不存在时,会出现该错误。当然只有当 DB_LOCALE 和 CLIENT_LOCALE 的字符集不一致时才会需要转换,如果一致则不会出现 -23104 错误。
- $InformixDIR/gls/cv9/ccccdddd.cvo
- $InformixDIR/gls/cv9/ddddcccc.cvo
其中:cccc 为 CLIENT_LOCALE 字符集编码对应的 16 进制值
dddd 为 DB_LOCALE 字符集编码对应的 16 进制值
举例说明:
DB_LOCALE = en_us.utf8 #(对应的 16 进制编码为:e01c) CLIENT_LOCALE = zh_cn.gb18030-2000 #(对应的 16 进制编码为:1570) 以下 2 个文件必须存在,缺任意文件将报 Error -23104。 - $INFOMRIXDIR/gls/cv9/e01c1570.cvo - $INFOMRIXDIR/gls/cv9/1570e01c.cvo
当出现如下情况时,出现 -23197 错误。
举例说明:
数据库的 LOCALE= en_us.8859-1 可以通过如下 SQL 读取当前数据库的 LOCALE 值 SELECT dbs_collate FROM sysmaster:sysdbslocale WHERE dbs_dbsname = ‘ dbname ’ 客户端 DB_LOCALE 设置如下(注意:如果没有设置 DB_LOCALE,将使用在服务器计算机上设置的 DB_LOCALE),则会出现 -23197 错误DB_LOCALE = zh_cn.gb
Error -201,-202 数据库提示语法错误,不支持中文对象名,如中文表名、字段别名、视图名。该类错误提示原因是当前数据库的 DB_LOCALE 设置问题。
如果数据库的 DB_LOCALE 设置为 zh_cn.GB18030-2000,则数据库就可以支持中文对象名。
举例说明:
DB_LOCALE = zh_cn.GB18030-2000 的数据库,可以支持如下中文对象名,否则将提示语法错误。
Select c1 第一列 from test_cn;
Create table 中文表名 (c1 integer, 中文列名 integer);
drop table 中文表名 ;
若类似 SQL 不能运行,请核查数据库的 DB_LOCALE 值。
SELECT dbs_collate FROM sysmaster:sysdbslocale WHERE dbs_dbsname = ‘dbname‘
Informix 字符出现乱码问题,或者不能正确显示中文字符。问题的原因是客户端 CLIENT_LOCALE 设置的值与 DB_LOCALE 值不一致,而且两者对应的字符集之间不能正确进行转换。需要重新设置 CLIENT_LOCALE 与 DB_LOCALE 的值,确保两者一致或者可以正确相互转换。
Informix 数据库的时间格式由数据库服务器端环境变量 GL_DATE GL_DATETIME 控制,默认的字符集下默认的时间格式为:
GL_DATE="%m/%d/%iy"
DATETIME="%iY-%m-%d %H:%M:%S"
但是,当我们设置了 DB_LOCALE 为 zh_cn.gb 的情形下,而没有设置 GL_DATE,DATETIME,则时间格式会采用 CLIENT_LOCALE 的值,在 zh_cn.gb 情况下,会出现:“2009 年 10 月 2 日”的日期格式,如果我们之前系统采用默认的时间格式的情况下,就会出现时间格式不匹配的错误。如果我们仍然需要采用默认的时间格式,我们需要在数据库服务端修改时间格式环境变量即可:
GL_DATE="%m/%d/%iy"
DATETIME="%iY-%m-%d %H:%M:%S"
CSDK2.8 及以上版本中(目前最新版本为 CSDK3.5),为了正确支持语言文字的处理,Informix GLS 语言环境下要求正确设置数据库服务器语言环境及客户端语言环境。在中文语言环境下,我们应该按如下要求设置服务器端和客户端语言环境。
数据库服务端:
在创建数据库时(为了统一系统数据库与应用数据库的字符集,在创建数据库实例时),请按如下步骤设置数据库的 DB_LOCALE 值。
1. 设置环境变量 DB_LOCALE set DB_LOCALE=zh_cn.GB18030-2000 2. 创建数据库 create database dbname 3. 验证当前数据库字符集 SELECT dbs_collate FROM sysmaster:sysdbslocale WHERE dbs_dbsname = ‘dbname‘
客户端:
当我们使用 ODBC,JDBC 连接数据库时,我们需要在连接信息中正确设置语言环境变量:DB_LOCALE 和 CLIENT_LOCALE。
设置语言环境变量 DB_LOCALE=zh_cn.GB18030-2000 CLIENT_LOCALE=zh_cn.GB18030-2000
再或者更改数据库的字符集(设置 DB_LOCALE=zh_cn.GB18030-2000,重新创建数据库),然后按本文中描述的方法进行 DB_LOCALE 与 CLIENT_LOCALE 的设置方法进行处理。若在实际环境下重建数据库成本太高,可以考虑如下步骤进行解决 ODBC 支持中文的问题。
数据库服务器端: 1. 设置环境变量: IFMX_UNDOC_B168163=1 2. 将 en_us.8859-1 字符集文件拷贝到 zh_cn 目录下 cd $INFORMIXDIR/gls/lc11 cp ./en_us/0333.lco ./zh_cn 3. 重新启动 IDS 客户端: 设置语言环境: l DB_LOCALE=zh_cn.GB18030-2000 l CLIENT_LOCALE=zh_cn.GB18030-2000
对于 JDBC 我们可以通过 NEWCODESET 来解决该问题:
newcodeset的格式如下:
newcodeset=jdk codeset, ifx codeset,ifx codenum
jdbc的URL链接信息如下:
URLString = "jdbc:Informix-sqli://9.125.66.130:6346/dbname:InformixSERVER=servername; NEWCODESET=GB18030-2000,8859-1,819; CLIENT_LOCALE=en_US.8859-1; DB_LOCALE=en_US.8859-1;"
在简体中文应用环境下,请使用 zh_cn.GB18030-2000 字符集,在需要 unicode 的应用环境下,可以采用 en_us.utf8 字符集。
举例说明:采用 zh_cn.GB18030-2000字符集
数据库服务器端: 在创建数据库实例前,设置环境变量 DB_LOCALE=zh_cn.GB18030-2000 CLIENT_LOCALE=zh_cn.GB18030-2000 创建数据库 数据库客户端端: 需要在 setnet32、ODBC、JDBC 连接中配置 DB_LOCALE=zh_cn.GB18030-2000 CLIENT_LOCALE=zh_cn.GB18030-2000
举例说明:采用 utf8字符集
数据库服务器端: 在创建数据库实例前,设置环境变量 DB_LOCALE=en_us.utf8 CLIENT_LOCALE= en_us.utf8 创建数据库 数据库客户端端: 需要在 setnet32、ODBC、JDBC 连接中配置 DB_LOCALE= en_us.utf8 CLIENT_LOCALE= en_us.utf8
特别注意,在安装数据库前请设置好环境变量 DB_LOCALE 为规划的字符集,因为数据库一旦创建就不能修改其字符集,除非重新创建。在默认情况下将采用 en_us.8859-1。
如何正确设置 Informix GLS 及 CSDK 语言环境
标签:string ase 乱码问题 ace sci 使用 modifier 0.12 键盘
原文地址:http://www.cnblogs.com/fsw-blog/p/6000880.html