全球化支持.pptx

字符集字符集指的是对字符进行编码的方案。对于我们看到的每个字符，例如“A”，其存放在数据库中时并不会将A保存在数据文件中，而是会将其转换为一组数字，然后将这些数字转换为二进制的数值以后，在保存到数据文件中。字符数字二进制数值Oracle数据库中，最早出现的字符集是US7ASCII，用来支持ASCII的编码方案。单字节7bit来描述一个字符。总共可以表示的字符为128个。可以满足美国本土使用。US7ASCII属于单字节字符集。研究一个字符集，主要研究的就是下面的几个方面1、表示哪些字符（中文、韩文、还是日文）2、使用几个字节、表示多少字符（单字节、多字节、还是双字节）WE8ISO8859P1字符集，使用单字节8bit来描述一个字符集，总共可以描述的字符为256个。WE8ISO8859P1属于单字节字符集。多字节字符集（对于中国、韩国、日本、东欧等国家，使用单字节来表示256个字符明显不够用）。多字节字符集包括以下两种类型：固定长度的多字节字符集：采用固定长度的字节数来表示一个字符，在oracle 10g中，支持固定长度的多字节字符集只有一个AF16UTF16。变化长度的多字节字符集：采用1-3个字节来表示一个字符。某些字符用一个字节来表示（比如英文字母），某些字符用2个或多个字节表示。变长多字节字符集经常用于对亚洲语言的支持，包括中文、日文、印地语等，这些字符集包括ZHS16GBK、AL32UTF8（AL表示ALL、指适用于所有语言）等。在1991年，多家公司以及研究机构共同发起组织成立了一个unicode协会，用来推广unicode的编码方案。在unicode的编码方案中，为全世界的每个字符都提供一个唯一的编码。UTF-16，他是unicode的16位编码方案，是一种固定长度的多字节编码方案，用两个字节表示一个unicode字符。AF16UTF16就是实现UTF-16编码方案的字符集。UTF-8，是一种变化长度的多字节编码方案、可以使用1-3个字节来表示一个unicode字符，AL32UTF8、UTF-8等就是实现UTF-8编码方案的字符集。数据库字符集数据库字符集包括两个字符集：数据库字符集、国家字符集，都是在创建数据库的时候指定的。我们主要使用的是数据库字符集，国家字符集则是对数据库字符集的一个补充。在数据库中，有关数据库本身自带的PL/SQL程序包以及SQL语句等，都必须以能够兼容单字节的编码方式来存取，如果数据库中需要使用固定长度的多字节字符集的话，则不能兼容单字节的编码方式，也就是不能存放数据库本身自带的PL/SQL程序包以及SQL语句。因此为了能够支持固定长度的多字节的字符集，我们可以将该字符集指定为国家字符集。国家字符集只能在unicode编码中的UTF-8和AF16UTF中进行选择。默认是AF16UTF8.使用数据库字符集的情况：数据类型定义为CHAR、VARCHAR2、CLOB、LONG等类型时，则其中存放的数据使用数据库字符集进行编码，表名、列名、SQL、PL/SQL程序单元、PL/SQL变量等也都以数据库字符集进行编码并存放。如果将表的列定义为NCHAR、NVARCHAR2、NCLOB等类型时，则其中存放的数据使用国家字符集。国家字符集是数据库字符集的一个补充。数据库字符集和国家字符集。创建数据库的时候，一旦选定字符集，就不应该在创建数据库以后再修改。尽管oracle提供了修改字符集的命令，但是该命令要求新的字符集必须是当前字符集的严格超集。严格超集的意义：当一种字符集（字符集A）的编码数值包含另一种字符集（字符集B）的所有编码数值，并且两种字符集中相同的编码数值代表相同的字符时，则字符集A就是字符集B的超集，或称字符集B是字符集A的子集。US7ASCII是最早的数据库编码格式，因此有许多字符集都是US7ASCII的严格超集，例如WE8ISO8859P1、ZHS16GBK等都是US7ASCII的超集。在数据库的mount状态SQLALTER DATABASE CHARACTER SET 该命令并不会对数据库内部的字符集进行转换，而只是修改数据库中有关字符集的配置信息，因为如果是严格的超集，那么新的字符集对已有字符的编码和当前字符集的编码是一样的，因此不需要改变。但是如果不是超集，则会报错，就只能以新的字符集重新创建数据库。Oracle提供了一个非公开的命令SQLALTER DATABASE CHARACTER SET INTERNAL_CONVERT 该命令会绕开超子集的校验，而直接对字符集配置信息进行修改。可能引起很大的隐患，因此需要在测试环境中充分测试以后，确认没有问题以后，才能在产品数据库上实施。对于中文来说，存在两种字符集：ZHS16CGB231280（1981年实施）和ZHS16GBK（1995年实施）。后者表示的字符要比前者多，但是后者并不是前者的严格超集，因此不能正常的转换。如果数据库将来还要容纳繁体字符集、不仅仅是简体字符集，那么就不能使用ZHS16GBK，而是要选择UTF-8，虽然占用的磁盘空间会大一些，但是成本可以忽略不计。在服务器端，有关语言、地区方面的信息则由初始化参数来配置。NLS_LANGUAGE：登录到数据库的session所使用的语言，用来显示oracle消息、显示年月的语言以及默认的排序机制等。该参数决定了下面的两个参数的默认值。显示年月的参数使用排序机制：binary和语义排序登录到数据库的session所在的地区。该参数决定下面所有参数的默认值。NLS_CURRENCYNLS_DATE_FORMATNLS_DUAL_CURRENCYNLS_ISO_CURRENCYNLS_NUMERIC_CHARACTERSNLS_TIMESTAMP_FORMATNLS_TIMESTAMP_TZ_FORMAT因此两种重要的参数要设置正确。NLS_LANGUAGE和NLS_TERRITORY客户端字符集在客户端，通过设置环境变量来定义客户端的字符集。该环境变量为如下定义NLS_LANG=_.：用来显示Oracle消息、年月的名称（例如12月是应该显示“Dec”还是“12月”）以及默认的排序机制。对应服务器的初始化参数为NLS_LANGUAGE。：用来显示默认的日期格式、数字格式、以及货币格式等，对应服务器的初始化参数为NLS_TERRITORY。：客户端使用的字符集在windows下面，我们可以如下设置语言是中文、所在地区是中国、使用的字符集是ZHS16GBK。如何知道哪些值可以使用呢？通过视图v$nls_valid_values。可以从上面的视图中找出我们要设置的值。在windows里面，在注册表里面设置了NLS_LANG的值。在linux或者unix里面，使用export NLS_LANG=.来设置。我们还可以设置NLS_DATE_FORMAT来改变NLS_LANG对这个参数的默认值影响。不需要加引号。也可以在注册表里面设置。在会话级修改参数。这个修改将会覆盖客户端的NLS_DATE_FORMAT的设置。注意：客户端字符集的作用如下：当使用客户端工具连接到服务器的时候，需要使用到客户端字符集。对于客户端字符集来说，character必须和服务器端一样。对于被的一些设置：语言、地区等，可以和服务器不一致。因为显示中没有中文，因此也没有错误。因为ZHS16GBK是US7ASCII的严格超集。另起一个界面输入中文，都可以正常的显示。客户端就不能正常的显示。这不是什么严重的问题，因为数据存储在数据库里面是没有错误的。另起一个客户端。出现严重的问题，客户端的字符集和服务器端不一样，我们在客户端输入了客户端不能识别的字符集。数据保存到了数据库中，但是数据是错误的，数据存储的时候就是错误的。1、客户端输入的字符一定要是数据库字符集能够识别的字符。2、客户端的字符集一定要和服务器端是一样。客户端字符集与服务器端字符集的转换客户端字符集的意义在于，当我们在客户端输入字符信息，并通过网络，将客户端的字符信息传入到数据库进行处理，也就是说，客户端的字符集用于通知数据库端，当前传递的数据库端的字符信息所采用的编码方式。如果客户端的编码方式与数据库端的编码方式不同，那么数据库端在处理该信息时（比如将用户在客户端输入的值插入到表里），就需要将客户端的字符编码方式转换为数据库端的编码方式。用户在客户端输入“我”这个字，则在数据库端，就要找到在数据库字符集中表示“我”这个字的编码方式。如果没有找到，则“我”字就会使用一个默认的编码数值来存放。那么当客户端将“我”字从数据库中检索出来的时候就会显示乱码。数据库ora10g客户端字符集操作系统的字符集数据库字符集1、客户端是windows中文版，操作系统的字符集相当于数据库的ZHS16GBK。数据库的字符集是1、客户端的字符集是ZHS16GBK，结构图如下。客户端字符集操作系统的字符集数据库字符集ZHS16GBKWE8ISO8859P1ZHS16GBK客户端字符集操作系统的字符集数据库字符集ZHS16GBKWE8ISO8859P1ZHS16GBK“我们”经过本地操作系统的字符集以后，以字符编码的方式传输到了数据库服务器端。客户端告诉数据库服务器端，我的字符集是ZHS16GBK，数据库服务器端发现客户端的字符集和自己不一样，数据库服务器端需要将“我们”这个字符编码从ZHS16GBK转换成WE8ISO8851P1。因为WE8ISO8851P1字符集中没有这两个字符，因此只能以默认的字符编码存入。这是一种比较可怕的情况，字符在插入到数据库的时候，就是错误的。因此数据就是错误的。客户端和数据库字符集不一样。客户端字符集是WE8ISO8859P1。客户端字符集操作系统的字符集数据库字符集WE8ISO8859P1WE8ISO8859P1ZHS16GBK客户端字符集操作系统的字符集数据库字符集WE8ISO8859P1WE8ISO8859P1ZHS16GBK“我们”经过操作系统字符集编码以后，将编码发送到数据库服务器端。客户端字符集告诉数据库服务器，给你发过去的字符是WE8ISO8829P1字符集编码。数据库服务器发现客户端和自己的字符集一样，于是就将字符编码直接存入到了数据库中。没有经过任何的转换。虽然传送过去的字符编码是ZHS16GBK的字符编码，数据库服务器并不认识，但是数据库只认识客户端的NLS_LANG，既然NLS_LANG显示客户端和自己的字符集一样，于是就不进行转换而是直接进行存储。Select的时候，仍然存在字符集的转换问题。客户端的字符集是WE8ISO8859P1，将表里的数据取出来并显示在客户端时，由于客户端字符集和数据库字符集是一致的。数据库存放的“我们”的字符编码会原封不动的被传递到客户端，客户端显示数据的时候，则通过操作系统将取回的数值编码转换为字符，并进行显示。字符编码从客户端到数据库的时候，字符编码并没有被转换。还是windows的字符编码。因此取回来的时候，使用windows编码进行显示一切正常。使用ZHS16GBK客户端字符集出入数据的时候，在数据库端，字符被转换后，以错误的编码插入到了数据库中。检索这两个字的时候，错误的字符编码取回来以后，windows显示为“靠”。因此结论：字符转换是一个非常不好的情况。客户端和数据库端的字符集不一样。在进行检索的时候，对于以ZHS16GBK客户端字符集插入的字符。在字符插入的时候，已经因为字符的转换，在数据库中存入了错误的字符编码。因此检索的时候，显示的是乱码。以WE8ISO8859P1作为客户端字符集插入的字符，字符编码本身是ZHS16GBK编码。在检索的时候，客户端如果是ZHS16GBK，那么数据库就认为需要进行字符集的转换，ORACLE当然认为自己存储的字符是WEISO8859P1编码的（实际上是ZHS16GB编码），而客户端是ZHS16GBK的字符，因此将字符误认为是WEISO8859P1，而转换成了ZHS16GBK，于是就出现了乱码。对于ORACLE的很多客户端工具来说，都存在字符集的转换问题。导入导出工具就是一个最典型的例子。导出时：如果客户端和服务器端的字符集不一样，那么需要进行字符集的转换。转换过程中就可能发生数据的丢失。例如数据库字符集是ZHS16GBK，执行导出的客户端的字符集是WE8ISO8859P1。数据库中的中文不能被字符集WE8ISO8859P1所识别。数据在转储到二进制文件的时候，就丢失了数据。因此在导出以前，一定要设置NLS_LANG，确保和数据库的字符集一样。或者客户端的字符集是数据库端字符集的超集。Exp工具会在生成的转储文件头部的第2个和第3个字节记录客户端字符集的ID号。这个ID号代表着客户端字符集。导入imp，情况更加复杂1、二进制导出文件头部所记录的字符集2、客户端字符集（通过SET NLS_LANG设置的字符集）3、数据库端字符集导入时，首先读取导出文件头部所记录的字符集，然后与客户端字符集的NLS_LANG所指定的字符集进行比较，如果两者不同，进行第一次字符集的转换。如果客户端字符集和导出文件所记录的字符集不同，或者不是导出文件字符集的超集，则第一次转换就将丢失数据。转换完毕以后，转换后的数据将从客户端插入到数据库服务器中。比较客户端和数据库服务器端的字符集，如果不同，再次发生转换，同样道理，可能发生数据的丢失。为了避免发生数据的丢失数据库字符集=客户端字符集=导出文件字符集对于数据泵来说，相对简单，因为是在服务器端完成的，不牵涉客户端的字符集问题。导出时，生成的转储文件的字符集就是数据库字符集，导入时，则可能需要将导出文件中记录的字符集转换为导入数据库的字符集，也可能出现数据丢失现象。语义排序进行排序时，默认采用的是二进制方式。也就是要排序的数据转换为数值编码以后，再将这些数值编码转换为对应的二进制的值，然后对二进制的值进行排序。Oracle实际上可以提供非常多的排序方式。例如：忽略大小写、按照发音来排序、按照偏旁部首来排序，统称为语义排序。有很多的排序方式。按照拼音排序按照偏旁部首排序按照笔画排序按照二进制进行排序。忽略大小写。忽略发音二进制排序。上面讲的是排序。对于比较来说，也存在相同的情况。取决于参数NLS_COMP。默认是binary，比较时将要比较的值转换为二进制的数据，然后对转换后的二进制数据进行比较。如果设置为ansi，那么在比较的时候，参照nls_sort参数所设置的语义排序方式。NLS_SORT设置为binary_ci，并将nls_comp设置为ansi，说明在此比较的时候参照nls_sort的值。忽略大小写，然后再按照binary进行比较。返回字符的字符编码。所有的字符编码就构成了字符集。