因为没有使用java平台，也就没有使用建议的axis对提供的wsdl文件做处理，所有关于数据包的解析只能自己写程序做解析处理。
华为提供的vac请求样例包request.xml

实际在网络上收到的数据包

通过对数据包的分析，可以看到在实际包里面，采用了multiRef方式，对userIdType和updateType数据的值使用了href引 用，这样在分析数据包时，就同时要根据节点的href属性值来判断处理所引用的值节点，然后再遍历multiRef的节点找匹配id属性值的，从而找出正 确的值所在。

——-
虽然现在解析正确了，但是没有使用标准的xml开发包工具开发，缺少开发包所做的类型验证，数据包还原等处理，如果以后接口数据格式有发生变化还是要再次 进行解析代码的修改处理，不过不想只为了一个xml解析目的就为服务器添加上java的一堆环境和东西，只好先忍受着自己手工分析xml数据吧。

三次握手Three-way Handshake

一个虚拟连接的建立是通过三次握手来实现的

1. (B) --> [SYN] --> (A)

假如服务器A和客户机B通讯. 当A要和B通信时，B首先向A发一个SYN (Synchronize) 标记的包，告诉A请求建立连接.

注意: 一个 SYN包就是仅SYN标记设为1的TCP包(参见TCP包头Resources). 认识到这点很重要，只有当A受到B发来的SYN包，才可建立连接，除此之外别无他法。因此，如果你的防火墙丢弃所有的发往外网接口的SYN包，那么你将不能让外部任何主机主动建立连接。

2. (B) <-- [SYN/ACK] <--(A)

接着，A收到后会发一个对SYN包的确认包(SYN/ACK)回去，表示对第一个SYN包的确认，并继续握手操作.

注意: SYN/ACK包是仅SYN 和 ACK 标记为1的包.

3. (B) --> [ACK] --> (A)

B收到SYN/ACK 包,B发一个确认包(ACK)，通知A连接已建立。至此，三次握手完成，一个TCP连接完成

Note: ACK包就是仅ACK 标记设为1的TCP包. 需要注意的是当三此握手完成、连接建立以后，TCP连接的每个包都会设置ACK位

这就是为何连接跟踪很重要的原因了. 没有连接跟踪,防火墙将无法判断收到的ACK包是否属于一个已经建立的连接.一般的包过滤(Ipchains)收到ACK包时,会让它通过(这绝对不是个好主意). 而当状态型防火墙收到此种包时，它会先在连接表中查找是否属于哪个已建连接，否则丢弃该包

四次握手Four-way Handshake

四次握手用来关闭已建立的TCP连接

1. (B) --> ACK/FIN --> (A)

2. (B) <-- ACK <-- (A)

3. (B) <-- ACK/FIN <-- (A)

4. (B) --> ACK --> (A)

注意: 由于TCP连接是双向连接, 因此关闭连接需要在两个方向上做。ACK/FIN 包(ACK 和FIN 标记设为1)通常被认为是FIN(终结)包.然而, 由于连接还没有关闭, FIN包总是打上ACK标记. 没有ACK标记而仅有FIN标记的包不是合法的包，并且通常被认为是恶意的

连接复位Resetting a connection

四次握手不是关闭TCP连接的唯一方法. 有时,如果主机需要尽快关闭连接(或连接超时,端口或主机不可达),RST (Reset)包将被发送. 注意在，由于RST包不是TCP连接中的必须部分, 可以只发送RST包(即不带ACK标记). 但在正常的TCP连接中RST包可以带ACK确认标记

请注意RST包是可以不要收到方确认的?

无效的TCP标记Invalid TCP Flags

到目前为止，你已经看到了 SYN, ACK, FIN, 和RST 标记. 另外，还有PSH (Push) 和URG (Urgent)标记.

最常见的非法组合是SYN/FIN 包. 注意:由于 SYN包是用来初始化连接的, 它不可能和 FIN和RST标记一起出现. 这也是一个恶意攻击.

由于现在大多数防火墙已知 SYN/FIN 包, 别的一些组合,例如SYN/FIN/PSH, SYN/FIN/RST, SYN/FIN/RST/PSH。很明显，当网络中出现这种包时，很你的网络肯定受到攻击了。

别的已知的非法包有FIN (无ACK标记)和"NULL"包。如同早先讨论的，由于ACK/FIN包的出现是为了关闭一个TCP连接，那么正常的FIN包总是带有 ACK 标记。"NULL"包就是没有任何TCP标记的包(URG,ACK,PSH,RST,SYN,FIN都为0)。

到目前为止，正常的网络活动下，TCP协议栈不可能产生带有上面提到的任何一种标记组合的TCP包。当你发现这些不正常的包时，肯定有人对你的网络不怀好意。

UDP (用户数据包协议User Datagram Protocol)
TCP是面向连接的，而UDP是非连接的协议。UDP没有对接受进行确认的标记和确认机制。对丢包的处理是在应用层来完成的。(or accidental arrival).

此处需要重点注意的事情是：在正常情况下，当UDP包到达一个关闭的端口时，会返回一个UDP复位包。由于UDP是非面向连接的, 因此没有任何确认信息来确认包是否正确到达目的地。因此如果你的防火墙丢弃UDP包，它会开放所有的UDP端口(?)。

由于Internet上正常情况下一些包将被丢弃，甚至某些发往已关闭端口(非防火墙的)的UDP包将不会到达目的，它们将返回一个复位UDP包。

因为这个原因，UDP端口扫描总是不精确、不可靠的。

看起来大UDP包的碎片是常见的DOS (Denial of Service)攻击的常见形式 (这里有个DOS攻击的例子，http://grc.com/dos/grcdos.htm ).

ICMP (网间控制消息协议Internet Control Message Protocol)
如同名字一样， ICMP用来在主机/路由器之间传递控制信息的协议。 ICMP包可以包含诊断信息(ping, traceroute - 注意目前unix系统中的traceroute用UDP包而不是ICMP)，错误信息(网络/主机/端口 不可达 network/host/port unreachable), 信息(时间戳timestamp, 地址掩码address mask request, etc.)，或控制信息 (source quench, redirect, etc.) 。

你可以在http://www.iana.org/assignments/icmp-parameters中找到ICMP包的类型。

尽管ICMP通常是无害的，还是有些类型的ICMP信息需要丢弃。

Redirect (5), Alternate Host Address (6), Router Advertisement (9) 能用来转发通讯。

Echo (8), Timestamp (13) and Address Mask Request (17) 能用来分别判断主机是否起来，本地时间和地址掩码。注意它们是和返回的信息类别有关的。它们自己本身是不能被利用的，但它们泄露出的信息对攻击者是有用的。

ICMP消息有时也被用来作为DOS攻击的一部分(例如：洪水ping flood ping,死 ping ?呵呵，有趣 ping of death)?/p>

包碎片注意A Note About Packet Fragmentation

如果一个包的大小超过了TCP的最大段长度MSS (Maximum Segment Size) 或MTU (Maximum Transmission Unit)，能够把此包发往目的的唯一方法是把此包分片。由于包分片是正常的，它可以被利用来做恶意的攻击。

因为分片的包的第一个分片包含一个包头，若没有包分片的重组功能，包过滤器不可能检测附加的包分片。典型的攻击Typical attacks involve in overlapping the packet data in which packet header is 典型的攻击Typical attacks involve in overlapping the packet data in which packet header isnormal until is it overwritten with different destination IP (or port) thereby bypassing firewall rules。包分片能作为 DOS 攻击的一部分，它可以crash older IP stacks 或涨死CPU连接能力。

Netfilter/Iptables中的连接跟踪代码能自动做分片重组。它仍有弱点，可能受到饱和连接攻击，可以把CPU资源耗光。

握手阶段：
序号 方向 seq ack
1　　A->B 10000 0
2 B->A 20000 10000+1=10001
3 A->B 10001 20000+1=20001
解释：
1：A向B发起连接请求，以一个随机数初始化A的seq,这里假设为10000，此时ACK＝0

2：B收到A的连接请求后，也以一个随机数初始化B的seq，这里假设为20000，意思是：你的请求我已收到，我这方的数据流就从这个数开始。B的ACK是A的seq加1，即10000＋1＝10001

3：A收到B的回复后，它的seq是它的上个请求的seq加1，即10000＋1＝10001，意思也是：你的回复我收到了，我这方的数据流就从这个数开始。A此时的ACK是B的seq加1，即20000+1=20001


数据传输阶段：
序号　　方向　　　　　　seq ack size
23 A->B 40000 70000 1514
24 B->A 70000 40000+1514-54=41460 54
25 A->B 41460 70000+54-54=70000 1514
26 B->A 70000 41460+1514-54=42920 54
解释：
23:B接收到A发来的seq=40000,ack=70000,size=1514的数据包
24:于是B向A也发一个数据包，告诉B，你的上个包我收到了。B的seq就以它收到的数据包的ACK填充，ACK是它收到的数据包的SEQ加上数据包的大小(不包括以太网协议头，IP头，TCP头)，以证实B发过来的数据全收到了。
25:A在收到B发过来的ack为41460的数据包时，一看到41460，正好是它的上个数据包的seq加上包的大小，就明白，上次发送的数据包已安全到达。于是它再发一个数据包给B。这个正在发送的数据包的seq也以它收到的数据包的ACK填充，ACK就以它收到的数据包的seq(70000)加上包的size(54)填充,即ack=70000+54-54(全是头长，没数据项)。

其实在握手和结束时确认号应该是对方序列号加1,传输数据时则是对方序列号加上对方携带应用层数据的长度.如果从以太网包返回来计算所加的长度,就嫌走弯路了.
另外,如果对方没有数据过来,则自己的确认号不变,序列号为上次的序列号加上本次应用层数据发送长度.

一．引言

    ORACLE数据库字符集，即Oracle全球化支持(Globalization Support)，或即国家语言支持（NLS）其作用是用本国语言和格式来存储、处理和检索数据。利用全球化支持，ORACLE为用户提供自己熟悉的数据库母语环境，诸如日期格式、数字格式和存储序列等。Oracle可以支持多种语言及字符集，其中oracle8i支持48种语言、76个国家地域、229种字符集，而oracle9i则支持57种语言、88个国家地域、235种字符集。由于oracle字符集种类多，且在存储、检索、迁移oracle数据时多个环节与字符集的设置密切相关，因此在实际的应用中，数据库开发和管理人员经常会遇到有关oracle字符集方面的问题。本文通过以下几个方面阐述，对oracle字符集做简要分析

二．字符集基本知识

2.1字符集
    实质就是按照一定的字符编码方案，对一组特定的符号，分别赋予不同数值编码的集合。Oracle数据库最早支持的编码方案是US7ASCII。
    Oracle的字符集命名遵循以下命名规则:
    <Language><bit size><encoding>
    即:  <语言><比特位数><编码>
    比如: ZHS16GBK表示采用GBK编码格式、16位（两个字节）简体中文字符集

2.2字符编码方案
<st1:chsdate year="1899" month="12" day="30" islunardate="False" isrocdate="False" w:st="on">2.2.1</st1:chsdate> 单字节编码
    （1）单字节7位字符集，可以定义128个字符，最常用的字符集为US7ASCII
    （2）单字节8位字符集，可以定义256个字符，适合于欧洲大部分国家
    例如：WE8ISO8859P1(西欧、8位、ISO标准8859P1编码)
2.2.2 多字节编码
    （1）变长多字节编码
    某些字符用一个字节表示，其它字符用两个或多个字符表示，变长多字节编码常用于对亚洲语言的支持，   例如日语、汉语、印地语等
    例如：AL32UTF8（其中AL代表ALL,指适用于所有语言）、zhs16cgb231280
    （2）定长多字节编码
    每一个字符都使用固定长度字节的编码方案，目前oracle唯一支持的定长多字节编码是AF16UTF16，也是仅用于国家字符集
2.2.3 unicode编码
    Unicode是一个涵盖了目前全世界使用的所有已知字符的单一编码方案，也就是说Unicode为每一个字符提供唯一的编码。UTF-16是unicode的16位编码方式，是一种定长多字节编码，用2个字节表示一个unicode字符，AF16UTF16是UTF-16编码字符集。
    UTF-8是unicode的8位编码方式，是一种变长多字节编码，这种编码可以用1、2、3个字节表示一个unicode字符，AL32UTF8，UTF8、UTFE是UTF-8编码字符集

2.3 字符集超级
    当一种字符集（字符集A）的编码数值包含所有另一种字符集（字符集B）的编码数值，并且两种字符集相同编码数值代表相同的字符时，则字符集A是字符集B的超级，或称字符集B是字符集A的子集。
    Oracle8i和oracle9i官方文档资料中备有子集-超级对照表（subset-superset pairs），例如：WE8ISO8859P1是WE8MSWIN1252的子集。由于US7ASCII是最早的Oracle数据库编码格式，因此有许多字符集是US7ASCII的超集，例如WE8ISO8859P1、ZHS16CGB231280、ZHS16GBK都是US7ASCII的超集。

2.4 数据库字符集（oracle服务器端字符集）
    数据库字符集在创建数据库时指定，在创建后通常不能更改。在创建数据库时，可以指定字符集(CHARACTER SET)和国家字符集(NATIONAL CHARACTER SET)。
<st1:chsdate year="1899" month="12" day="30" islunardate="False" isrocdate="False" w:st="on">2.4.1</st1:chsdate>字符集
    (1)用来存储CHAR, VARCHAR2, CLOB, LONG等类型数据
    (2)用来标示诸如表名、列名以及PL/SQL变量等
    (3)用来存储SQL和PL/SQL程序单元等
2.4.2国家字符集：
    (1)用以存储NCHAR, NVARCHAR2, NCLOB等类型数据
    (2)国家字符集实质上是为oracle选择的附加字符集，主要作用是为了增强oracle的字符处理能力，因为NCHAR数据类型可以提供对亚洲使用定长多字节编码的支持，而数据库字符集则不能。国家字符集在oracle9i中进行了重新定义，只能在unicode编码中的AF16UTF16和UTF8中选择，默认值是AF16UTF16
2.4.3查询字符集参数
    可以查询以下数据字典或视图查看字符集设置情况
    nls_database_parameters、props$、v$nls_parameters
    查询结果中NLS_CHARACTERSET表示字符集，NLS_NCHAR_CHARACTERSET表示国家字符集
2.4.4修改数据库字符集
    按照上文所说，数据库字符集在创建后原则上不能更改。如果需要修改字符集，通常需要导出数据库数据，重建数据库，再导入数据库数据的方式来转换，或通过ALTER DATABASE CHARACTER SET语句修改字符集，但创建数据库后修改字符集是有限制的，只有新的字符集是当前字符集的超集时才能修改数据库字符集，例如UTF8是US7ASCII的超集，修改数据库字符集可使用ALTER DATABASE CHARACTER SET UTF8。

2.5 客户端字符集（NLS_LANG参数）
<st1:chsdate year="1899" month="12" day="30" islunardate="False" isrocdate="False" w:st="on">2.5.1</st1:chsdate>客户端字符集含义
    客户端字符集定义了客户端字符数据的编码方式，任何发自或发往客户端的字符数据均使用客户端定义的字符集编码,客户端可以看作是能与数据库直接连接的各种应用，例如sqlplus,exp/imp等。客户端字符集是通过设置NLS_LANG参数来设定的。
2.5.2 NLS_LANG参数格式
    NLS_LANG=<language>_<territory>.<client character set>
    Language:显示oracle消息,校验，日期命名
    Territory：指定默认日期、数字、货币等格式
    Client character set：指定客户端将使用的字符集
    例如：NLS_LANG=AMERICAN_AMERICA.US7ASCII 
    AMERICAN是语言，AMERICA是地区，US7ASCII是客户端字符集
2.5.3客户端字符集设置方法
     1)UNIX环境
         $NLS_LANG=“simplified chinese”_china.zhs16gbk
         $export NLS_LANG
         编辑oracle用户的profile文件
    2)Windows环境
         编辑注册表
         Regedit.exe---HKEY_LOCAL_MACHINE---SOFTWARE---ORACLE—HOME0
2.5.4 NLS参数查询
    Oracle提供若干NLS参数定制数据库和用户机以适应本地格式，例如有NLS_LANGUAGE,NLS_DATE_FORMAT,NLS_CALENDER等，可以通过查询以下数据字典或v$视图查看。
    NLS_DATABASE_PARAMETERS--显示数据库当前NLS参数取值，包括数据库字符集取值
    NLS_SESSION_PARAMETERS--显示由NLS_LANG 设置的参数，或经过alter session 改变后的参数值（不包括由NLS_LANG 设置的客户端字符集）
    NLS_INSTANCE_PARAMETE--显示由参数文件init<SID>.ora 定义的参数V$NLS_PARAMETERS--显示数据库当前NLS参数取值
2.5.5修改NLS参数
    使用下列方法可以修改NLS参数
    （1）修改实例启动时使用的初始化参数文件
    （2）修改环境变量NLS_LANG
    （3）使用ALTER SESSION语句，在oracle会话中修改
    （4）使用某些SQL函数
    NLS作用优先级别：Sql function>alter session>环境变量或注册表>参数文件>数据库默认参数

三．导入/导出与字符集转换

3.1 EXP/IMP
    Export 和 Import 是一对读写Oracle数据的工具。Export 将 Oracle 数据库中的数据输出到操作系统文件中, Import 把这些文件中的数据读到Oracle 数据库中，由于使用exp/imp进行数据迁移时，数据从源数据库到目标数据库的过程中有四个环节涉及到字符集，如果这四个环节的字符集不一致，将会发生字符集转换。

EXP
     ____________   _________________  _____________
     |imp导入文件|<-|环境变量NLS_LANG|<-|数据库字符集|
     ------------   -----------------  -------------

IMP
     ____________   _________________  _____________
     |imp导入文件|->|环境变量NLS_LANG|->|数据库字符集|
     ------------   -----------------  -------------

   四个字符集是
   （1）源数据库字符集
   （2）Export过程中用户会话字符集（通过NLS_LANG设定）
   （3）Import过程中用户会话字符集（通过NLS_LANG设定）
   （4）目标数据库字符集

3.2导出的转换过程
    在Export过程中，如果源数据库字符集与Export用户会话字符集不一致，会发生字符集转换，并在导出文件的头部几个字节中存储Export用户会话字符集的ID号。在这个转换过程中可能发生数据的丢失。
例:如果源数据库使用ZHS16GBK，而Export用户会话字符集使用US7ASCII，由于ZHS16GBK是16位字符集,而US7ASCII是7位字符集，这个转换过程中，中文字符在US7ASCII中不能够找到对等的字符，所以所有中文字符都会丢失而变成“?? ”形式，这样转换后生成的Dmp文件已经发生了数据丢失。
因此如果想正确导出源数据库数据，则Export过程中用户会话字符集应等于源数据库字符集或是源数据库字符集的超集

3.3导入的转换过程
    （1）确定导出数据库字符集环境
    通过读取导出文件头，可以获得导出文件的字符集设置
    （2）确定导入session的字符集，即导入Session使用的NLS_LANG环境变量
    （3）IMP读取导出文件
    读取导出文件字符集ID，和导入进程的NLS_LANG进行比较
    （4）如果导出文件字符集和导入Session字符集相同，那么在这一步骤内就不需要转换，如果不同，就需要把数据转换为导入Session使用的字符集。可以看出，导入数据到数据库过程中发生两次字符集转换
    第一次:导入文件字符集与导入Session使用的字符集之间的转换，如果这个转换过程不能正确完成，Import向目标数据库的导入过程也就不能完成。
    第二次:导入Session字符集与数据库字符集之间的转换。
    然而,oracle8i的这种转换只能在单字节字符集之间进行,oracle8i导入Session不支持多字节字符集之间的转换，因此为了避免第一次转换，导入Session使用的NLS_LANG与导出文件字符集相同，第二次转换（通过SQL*Net）支持任何两种字符集。以上情况在Oracle9i中略有不同

四．乱码问题

    oracle在数据存储、迁移过程中经常发生字符乱码问题，归根到底是由于字符集使用不当引起。下面以使用客户端sqlplus向数据库插入数据和导入/导出（EXP/IMP）过程为例，说明乱码产生的原因。

4.1使用客户端sqlplus向数据库存储数据
    这个过程存在3个字符集设置
    （1）客户端应用字符集
    （2）客户端NLS_LANG参数设置
    （3）服务器端数据库字符集(Character Set)设置
    客户端应用sqlplus中能够显示什么样的字符取决于客户端操作系统语言环境(客户端应用字符集)，但在应用中录入这些字符后，这些字符能否在数据库中正常存储，还与另外两个字符集设置紧密相关，其中客户端NLS_LANG参数主要用于字符数据传输过程中的转换判断。常见的乱码大致有两种情形：
    （1）汉字变成问号“？”；
当从字符集A 转换成字符集B时，如果转换字符之间不存在对应关系，NLS_LANG使用替代字符“？”替代无法映射的字符
    （2）汉字变成未知字符（虽然有些是汉字，但与原字符含义不同）
转换存在对应关系，但字符集A 中的字符编码与字符集B 中的字符编码代表不同含义

4.2发生乱码原因
    乱码产生是由于几个字符集之间转换不匹配造成，分以下几种情况：
    （注：字符集之间如果不存在子集、超集对应关系时的情况不予考虑，因为这种情况下字符集之间转换必产生乱码）  
    1）服务器端数据库字符集与客户端应用字符集相同，与客户端NLS_LANG参数设置不同
    如果客户端NLS_LANG字符集是其它两种字符集的子集，转换过程将出现乱码。
    解决方法：将三种字符集设置成同一字符集，或NLS_LANG字符集是其它两种字符集的超集
    2）服务器端数据库字符集与客户端NLS_LANG参数设置相同，与客户端应用字符集不同
    如果客户端应用字符集是其它两种字符集的超集时，转换过程将出现乱码，但对于单字节编码存储中文问题，可参看本文第5章节的分析
    3）客户端应用字符集、客户端NLS_LANG参数设置、服务器端数据库字符集互不相同
    此种情况较为复杂，但三种字符集之间只要有不能转换的字符，则必产生乱码

4.3导入/导出过程出现乱码原因
    这个过程存在4个字符集设置，在3.1章节中已分析
   （1）源数据库字符集
   （2）EXP过程中NLS_LANG参数
   （3）IMP过程中NLS_LANG参数
   （4）目标数据库字符集
    出现乱码原因
    1）当源数据库字符集不等于EXP过程中NLS_LANG参数，且源数据库字符集是EXP过程中NLS_LANG的子集，才能保证导出文件正确，其他情况则导出文件字符乱码
    2）EXP过程中NLS_LANG字符集不等于IMP过程中NLS_LANG字符集，且EXP过程中NLS_LANG字符集是IMP过程中NLS_LANG字符集的子级, 才能保证第一次转换正常，否则第一次转换中出现乱码。
    3）如果第一次转换正常，IMP过程中NLS_LANG字符集是目标数据库字符集的子集或相同，才能保证第二次转换正常，否则则第二次转换中出现乱码

五．单字节编码存储中文问题

    由于历史的原因，早期的oracle没有中文字符集（如oracle6、oracle7、oracle7.1）,但有的用户从那时起就使用数据库了，并用US7ASCII字符集存储了中文，或是有的用户在创建数据库时，不考虑清楚，随意选择一个默认的字符集，如WE8ISO8859P1或US7ASCII，而这两个字符集都没有汉字编码，虽然有些时候选用这种字符集好象也能正常使用，但用这种字符集存储汉字信息从原则上说就是错误的，它会给数据库的使用与维护带来一系列的麻烦。
    正常情况下，要将汉字存入数据库，数据库字符集必须支持中文，而将数据库字符集设置为US7ASCII等单字节字符集是不合适的。US7ASCII字符集只定义了128个符号，并不支持汉字。另外，如果在SQL*PLUS中能够输入中文，操作系统缺省应该是支持中文的，但如果在NLS_LANG中的字符集设置为US7ASCII，显然也是不正确的，它没有反映客户端的实际情况。但在实际应用中汉字显示却是正确的，这主要是因为Oracle检查数据库与客户端的字符集设置是同样的，那么数据在客户与数据库之间的存取过程中将不发生任何转换，但是这实际上导致了数据库标识的字符集与实际存入的内容是不相符的。而在SELECT的过程中，Oracle同样检查发现数据库与客户端的字符集设置是相同的，所以它也将存入的内容原封不动地传送到客户端，而客户端操作系统识别出这是汉字编码所以能够正确显示。
    在这个例子中，数据库与客户端都没有设置成中文字符集，但却能正常显示中文，从应用的角度看好象没问题。然而这里面却存在着极大的隐患，比如在应用length或substr等字符串函数时，就可能得到意外的结果。
    对于早期使用US7ASCII字符集数据库的数据迁移到oracle8i/9i中（使用zhs16gbk），由于原始数据已经按照US7ASCII格式存储，对于这种情况，可以通过使用Oracle8i的导出工具，设置导出字符集为US7ASCII，导出后使用UltraEdit等工具打开dmp文件，修改第二、三字符，修改 0001 为0354,这样就可以将US7ASCII字符集的数据正确导入到ZHS16GBK的数据库中。

六．结束语

    为了避免在数据库迁移过程中由于字符集不同导致的数据损失，oracle提供了字符集扫描工具（character set scanner），通过这个工具我们可以测试在数据迁移过程中由于字符集转换可能带来的问题，然后根据测试结果，确定数据迁移过程中最佳字符集解决方案。

及时监测连接被动关闭

       除非有特别要求，否则你应该总是对每个连接保持一个挂起的接收 pending io

（使用 WSARecv 投递）。如果用户主动关闭连接，你的 GetQueuedCompletionStatus 调用将返回成功，但接收到的数据长度为 0 ，你能根据这点检测连接是否已被对方关闭。如果连接被重置或者 io 被取消（如果你调用了 CancelIo 的话）， GetQueuedCompletionStatus 将返回失败，注意这时还应该判断 GetQueuedCompletionStatus 调用返回的 lpOverlapped 值，如果该值不为 NULL ，说明 iocp 已经检测到一个连接已经中断。

 

安全的关闭连接

       很多人写的服务器网络库有一个难以接受的缺陷（包括我曾就职公司的一些同事），当服务器程序主动关闭连接时，刚发往客户端的包有时出现丢失，这时他们推荐的方式往往是发送数据后等待几秒再关闭连接。豪无疑问，这是一种笨拙的实现方式，他们遇到的问题根源是什么呢？

       在非 IOCP 模式网络程序中，你只要简单的调用 closesocket 函数就可以确保数据在操作系统释放 socket 之前安全到达对方，但在 IOCP 模式下，如果调用 closesocket 时有未决的 pending IO 将导致 socket 被重置，所以有时会出现数据丢失。正统的解决方式是使用 shutdown 函数（指定 SD_SEND 标志），注意这时可能有未完成的发送 pengding IO ，所以你应该监测是否该连接的所有是否已完成（也许你要用一个计数器来跟踪这些 pending IO ），仅在所有 send pending IO 完成后调用 shutdown 。

当你调用 shutdown 时，也许数据仍然停留在操作系统的缓冲，操作系统将在数据发送完后发出一个 FIN 包来启动关闭进程，客户端接收完数据后，将接受到一个 0 长度的包，以此判断连接已关闭（你写的客户端肯定有检测连接关闭，不是吗？），然后调用 closesocket ，这时服务器的 GetQueuedCompletionStatus 将接收到一个数据长度为 0 的包，这时你就可以调用 closesocket ，并释放相关连接资源。

在绝大部分情况下上述的过程连接能完美的关闭。如果你特别注重服务器的安全性和健壮性，可能你还需要做一个“连接关闭队列”，对每个已调用 shutdown 的连接放到这个队列，然后定时的对这个队列扫描，如果一个连接 5 秒（你也可以自己调整）还不能关闭，那么就强制关闭它。

 

处理大并发短连接时如何避免 TIME_WAIT 状态

       关于如何避免 TIME_WAIT 这个问题，一直没看到有效的处理方式（至少我没有）， 我将在这里披露一种有效的方式。回到上一段，我们最后调用了 closesocket 关闭连接，这时仍然可能出现 TIME_WAIT 状态，但注意这时所有的数据都已经传输完毕，因此你可以强制关闭 socket 避免服务器连接进入 TIME_WAIT （这时只会发出连接重置 RESET 包）

// 立即关闭 ( 避免出现 TIME_WAIT 状态 )

              LINGER linger = {1,0};

              setsockopt(socket, SOL_SOCKET, SO_LINGER,

                     (char *)&linger, sizeof(linger));

 

 

socket唯一性问题

正常情况下 SOCKET 套结字值是唯一的，但是操作系统在分配 socket 值时有随机性，最近关闭的 socket 值可能重新分派给一个刚刚建立的新的 socket. ，尤其在大并发短连接的情况下。一个健壮的服务器 IOCP 网络库必须要考虑 socket 唯一性的问题，由于 IOCP 的排队机制，意味着当你调用 closesocket 关闭 socket 后， IOCP 队列中可能仍然堆积了该 socket 的一些 I/O completion packet ，而此时，刚关闭的 socket 值又分派给一个刚刚建立的 socket ，所以，你必须对 GetQueuedCompletionStatus 获取到的 I/O completion packet 小心翼翼处理，避免出现数据混乱，然而，最好的方式等到所有 I/O completion packet 返回后才调用 closesocket 关闭该 socket 。