MSSQL网站制作之字符集成绩的开端切磋(四)

你看出了作者的深度？深处半米！当初是冲那么多的大牛给他写序才买的，后来才发现无啥内容，作者也只是才用几年的新手，百花了几十两银子，再次感叹当今社会的虚伪与浮躁成绩
link:

http://www.eygle.com/special/NLS_CHARACTER_SET_04.htm

4．导进导出及转换



导进导出是我们经常使用的一个数据迁徙及转化工具，因其导出文件具有平台有关性，以是在跨平台迁徙中，最为经常使用。
在导出操纵时，十分主要的是客户真个字符集设置，也就是客户真个NLS_LANG设置。
NLS_LANG参数由以下部分构成:







NLS_LANG=<Language>_<Territory>.<ClientsCharacterset>





NLS_LANG各部分寄义以下:LANGUAGE指定:-Oracle动静利用的言语-日期中月份和日显现TERRITORY指定-泉币和数字格局-区域和盘算礼拜及日期的习气CHARACTERSET:-把持客户端使用程序利用的字符集一般设置大概即是客户端(如Windows)代码页大概关于unicode使用设置为UTF8在Windows上检察以后体系的代码页可使用chcp命令:

E:>chcp
举动的代码页:936


代码页936也就是中笔墨符集GBK,在Microsoft的官方站点上，我们能够遭到关于936代码页的详细编码划定规矩,请参考以下链接:


http://www.microsoft.com/globaldev/reference/dbcs/936.htm

我们看一个复杂的测试，来懂得一下这几个参数的感化:




E:>setNLS_LANG=SIMPLIFIEDCHINESE_CHINA.ZHS16GBKE:>sqlplus"/assysdba"SQL*Plus:Release9.2.0.4.0-Productionon礼拜六11月122:51:592003Copyright(c)1982,2002,OracleCorporation.Allrightsreserved.毗连到:Oracle9iEnterpriseEditionRelease9.2.0.4.0-ProductionWiththePartitioning,OracleLabelSecurity,OLAPandOracleDataMiningoptionsJServerRelease9.2.0.4.0-ProductionSQL>selectsysdatefromdual;SYSDATE----------01-11月-03已选择1行。SQL>exit从Oracle9iEnterpriseEditionRelease9.2.0.4.0-ProductionWiththePartitioning,OracleLabelSecurity,OLAPandOracleDataMiningoptionsJServerRelease9.2.0.4.0-Production中止开E:>setNLS_LANG=AMERICAN_AMERICA.ZHS16GBKE:>sqlplus"/assysdba"SQL*Plus:Release9.2.0.4.0-ProductiononSatNov122:52:242003Copyright(c)1982,2002,OracleCorporation.Allrightsreserved.Connectedto:Oracle9iEnterpriseEditionRelease9.2.0.4.0-ProductionWiththePartitioning,OracleLabelSecurity,OLAPandOracleDataMiningoptionsJServerRelease9.2.0.4.0-ProductionSQL>selectsysdatefromdual;SYSDATE---------01-NOV-031rowselected.SQL>


检察客户端NLS_LANG设置可使用以下办法:

Windows利用:echo%NLS_LANG%如:E:>echo%NLS_LANG%AMERICAN_AMERICA.ZHS16GBKUnix利用:env|grepNLS_LANG如:/opt/oracle>env|grepNLS_LANGNLS_LANG=AMERICAN_CHINA.ZHS16GBKWindows客户端设置,能够在注册表中变动NLS_LANG,详细键值位于:HKEY_LOCAL_MACHINEOFTWAREORACLEHOMExxxx指存在多个ORACLE_HOME时体系编号。

导进和导出是客户端产物，同SQL*PLUS和OralceForms一样，因而，利用EXP/IMP工具将依照NLS_LANG界说的体例转换字符集。

导出利用的字符集将会纪录在导出文件中，当文件导进时，将会反省导出时利用的字符集设置，假如这个字符集分歧于导进客户真个NLS_LANG
设置，字符集将依据导进客户端NLS_LANG设置举行转换，假如需要，在数据拔出数据库之前会举行进一步转换。

一般在导出时最好把客户端字符集设置得和数据库端不异，如许能够制止在导出时产生不用要的数据转换，导出文件将和数据库具有不异的字符集。
即便未来会把导出文件导进到分歧字符集的数据库中，如许做也能够把转换延缓至导进时候。

当举行数据导进时，次要存在以下两种情形:
1.源数据库和方针数据库具有不异字符集设置
这时候，只必要设置NLS_LANG即是数据库字符集便可导进(条件是，导出利用的是和源数据库不异字符集，即三者不异)

2.源数据库和方针数据库字符集分歧
假如我们导出时分利用的NLS_LANG是和源数据库不异的字符集，那末导进时就能够设置客户端NLS_LANG即是导出时利用的字符集，这
样转换只产生在数据库端，并且只产生一次。

比方:
假如举行从WE8MSWIN1252到UTF8的转换
1)利用NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252导出数据库。
这时候创立的导出文件包括WE8MSWIN1252的数据
2)导进时利用NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252
这时候转换仅产生在insert数据到UTF8的数据库中。

以上假定的转换只在方针数据库字符集是源数据库字符集的超集时才干转换。假如分歧，一样平常就必要举行一些特别的处置。

我们复杂看一下导进的转换历程(以Oracle8i为例)：

1.断定导出数据库字符集情况
经由过程读取导出文件头，能够取得导出文件的字符集设置
2.断定导进session的字符集，即导进Session利用的NLS_LANG情况变量
3.IMP读取导出文件
读取导出文件字符集ID，和导进历程的NLS_LANG举行对照
4.假如导出文件字符集和导进Session字符集不异，那末在这一步骤内就不必要转换
假如分歧，就必要把数据转换为导进Session利用的字符集。
但是这类转换只能在单byte字符集之间举行。
我们看一个测试：




E:
ls2>setNLS_LANG=AMERICAN_AMERICA.US7ASCII设置导进sessionNLS_LANG为US7ASCIIE:
ls2>e:oracleora8iinimpeygle/eyglefile=Sus7ascii-Cus7ascii-exp817.dmpfromuser=eygletouser=eygletables=test这个导出文件是从US7ASCII数据库导出，导出客户端NLS_LANG也是US7ASCIIImport:Release8.1.7.1.1-ProductiononFriNov700:59:222003(c)Copyright2000OracleCorporation.Allrightsreserved.Connectedto:Oracle8iEnterpriseEditionRelease8.1.7.1.1-ProductionWiththePartitioningoptionJServerRelease8.1.7.1.1-Production这时候导进，在DMP文件和NLS_LANG之间不必要举行字符集转换。ExportfilecreatedbyEXPORT:V08.01.07viaconventionalpathimportdoneinUS7ASCIIcharactersetandZHS16GBKNCHARcharactersetimportserverusesZHS16GBKcharacterset(possiblecharsetconversion)exportserverusesUTF8NCHARcharacterset(possiblencharsetconversion)..importingtable"TEST"2rowsimportedImportterminatedsuccessfullywithoutwarnings.

5.关于多Byte字符集的导进(如:UTF8)
必要设置导进Session字符集和导出字符集不异
不然就会碰到:IMP-16"Requiredcharactersetconversion(type%luto%lu)notsupported"毛病。
:

E:
ls2>setNLS_LANG=AMERICAN_AMERICA.ZHS16GBK导进Session字符集设置为ZHS16GBK导进US7ASCII的导出文件E:
ls2>e:oracleora8iinimpeygle/eyglefile=Sus7ascii-Cus7ascii-exp817.dmpfromuser=eygletouser=eygleImport:Release8.1.7.1.1-ProductiononFriNov700:38:552003(c)Copyright2000OracleCorporation.Allrightsreserved.Connectedto:Oracle8iEnterpriseEditionRelease8.1.7.1.1-ProductionWiththePartitioningoptionJServerRelease8.1.7.1.1-ProductionIMP-00016:requiredcharactersetconversion(type1to852)notsupportedIMP-00000:Importterminatedunsuccessfully在从导出文件US7ASCII到导进NLS_LANG设置为ZHS16GBK的过程当中，不撑持单Byte字符集向多Byte转换，报出以上毛病。

6.导进Session字符集应当是导出字符集的超等，不然，专有的字符将难以准确转换。
7.当数据转换为导进Session字符集设置今后，假如导进Session字符集分歧于导进数据库字符集，这时候还必要最初一步转换，这请求导进数据库字符
集是导进session字符集的超等，不然某些专有字符将不克不及一般转换。
我们持续看下面的两个历程，这里有如许两个准绳:
1．假如NLS_LANG的设置和数据库不异，那末数据（在传输过程当中固然是2进制码）不经由转换就间接拔出数据库中。
2．假如NLS_LANG的设置和数据库分歧，那末数据必要转换后才干拔出数据库中。
我们再转头来看下面的第一个例子:
:

ExportfilecreatedbyEXPORT:V08.01.07viaconventionalpathimportdoneinUS7ASCIIcharactersetandZHS16GBKNCHARcharactersetimportserverusesZHS16GBKcharacterset(possiblecharsetconversion)exportserverusesUTF8NCHARcharacterset(possiblencharsetconversion)..importingtable"TEST"2rowsimportedImportterminatedsuccessfullywithoutwarnings.这时候候经由第一步转换后的数据，US7ASCII到ZHS16GBK丧失首位，原样拔出数据库，我们看到这时候数据库中寄存的就是毛病的字符(在前面
部分我们做了具体的转换):E:
ls2>sqlpluseygle/eygleSQL*Plus:Release9.2.0.4.0-ProductiononFriNov700:35:392003Copyright(c)1982,2002,OracleCorporation.Allrightsreserved.Connectedto:Oracle8iEnterpriseEditionRelease8.1.7.1.1-ProductionWiththePartitioningoptionJServerRelease8.1.7.1.1-ProductionSQL>select*fromtest;NAME--------------------2bJTtest

在Oracle9i中，以下情况略有分歧。


修复过程包含最多4个阶段，在下面描述。在你开始前，你应该cd到数据库目录和检查表文件的权限，确保他们可被运行mysqld的Unix用户读取(和你，因为你需要存取你正在检查的文件)。如果它拒绝你修改文件，他们也必须是可被你写入的。

两个月啃那本sqlserver2005技术内部-存储引擎，花了几个月啃四本书

所以你总能得到相应的升级版本，来满足你的需求。

大家注意一点。如下面的例子：

不好!如果出了错;不好调试;不好处理!其实web开发将代码分为3层:web层;业务逻辑层和数据访问层;一般对数据库的操作都在数据访问层来做;这样便于调试和维护!而且将来如果是换了数据库的话;你只需要改数据层的代码;其他层的基本可以不变!要是你在jsp中直接调用sql数据库;那么如果换了数据库呢?岂不都要改?如果报了异常呢?怎么做异常处理?

对递归类的树遍历很有帮助。个人感觉这个真是太棒了！阅读清晰，非常有时代感。

你可以简单地认为适合的就是好，不适合就是不好。

原来公司用过MYSQL自己也只是建个表写个SQL