理解CCSID,LANGID对系统内码的影响

     A          R CUSTOMER                  TEXT('CUST INFO')                    
     A            CUSTID        12A         TEXT('CUSTOMER ID')                  
     A            CUSTNAME      10O         TEXT('CUSTOMER NAME')                
     A            ADDRESS       10O         TEXT('CUSTOMER ADDRESS')             

或者在利用STRSQL运行如下的建表语句的时候，

CREATE TABLE CRMINFO/CUSTOMER
(
  CUSTID   CHAR (12 ) FOR SBCS  DATA NOT NULL, 
CUSTNAME CHAR (10 ) FOR MIXED DATA NOT NULL, 
ADDRESS  CHAR (10 ) FOR MIXED DATA NOT NULL  
);                                                            

都会生成一个以937作为CCSID的对象。其中，单字节字段CUSTID的CCSID为37，双字节字段CUSTNAME和ADDRESS的CCSID皆为937。在一个以37为缺省CCSID的作业环境中，系统为什么会以937作为这些物理文件或数据库表当中的双字节字段的CCSID呢？原因很简单，对于物理文件或数据库表中的那些双字节字段，以37作为缺省CCSID的作业无法确定它们应该属于日文、韩文、简体中文、抑或繁体中文，也就无法为这些字段标上正确的CCSID。在这种情况下，系统会给这些双字节字段都标上937，权当作为它们的CCSID，进而937也成为了这些物理文件或数据库表的CCSID。糟糕的是，937是繁体中文的主机代码页。这样一来，一旦这些物理文件被用来存放简体中文字符，那么，含有简体中文字符的字段在文件传输当中往往就会出现乱码。

正确的方法应是在系统安装完毕后，将相关的系统值设置成针对简体中文的取值，特别是将系统值QLANGID设置成CHS，将系统值QCCSID设置成935或1388。这样就可使作业的CCSID和作业的缺省CCSID都变为935或1388。由于935和1388都是针对简体中文的混合字节CCSID，在一个以935或1388作为缺省CCSID的作业环境中，当我们编译那些含有双字节字段的物理文件的时候，或是当我们创建那些含有双字节字段的数据库表的时候，系统就会生成一个以935或1388作为CCSID的对象，并给那些双字节字段都标上正确的CCSID。在上面的例子中，单字节字段CUSTID的CCSID应为836或13124，双字节字段CUSTNAME和ADDRESS的CCSID应为935或1388。

论坛热门帖子:	[lch203] 写得蛮好的linux学习笔记(10-21) [黑马制造] 学习java的30个目标(10-19) [笑傲股林] 做测试半年了，有点迷茫，应该再学些什么提高自己的测试水平和测试能力呢？(10-19) [udp8589] 大家用google的来吱一声? 用百度的~~也来报道下?(10-18) [沂偌掳兆] 本人总结的一些认为C++比较经典的书籍，希望对大家有用(10-18)
TAG标签:	影响 系统 理解 CCSID 字节 文件 作业 中文 用户 作为