当前位置：文档之家› ipsec中文RFC

ipsec中文RFC

IPSec 中文RFC

Network Working Group D. Harkins Request for Comments: 2409 D. Carrel Category: Standards Track cisco Systems

November 1998

Internet密钥交换（IKE）

（The Internet Key Exchange）

本备忘录的现状

本文档指定了一个Internet 团体的Internet标准协议，并请求讨论和建议以作改进。请参考当前

版本的“Internet官方协议标准”（STD 1），查看本协议的标准化进程和现状。本文档的分发不受限

制。

版权通告

1.摘要 2

2.讨论 2

3.术语和定义 3

3.1必要的术语 3

3.2符号 3

3.3完全后继保密 4

3.4安全联盟 4

4.简介 5

5.交换 6

5.1 使用签名来验证的IKE第一阶段8

5.2 使用公共密钥加密的第一阶段验证8

5.3 使用修改过的公钥加密模式来进行第一阶段的验证10

5.4 使用共享密钥的第一阶段协商11

5.5 第二阶段——快速模式12

5.6 新组模式14

5.7 ISAKMP信息交换15

6 Oakley组15

6.1 第一个Oakley缺省组15

6.2 第二个Oakley组16

6.3 第三个Oakley组16

6.4 第四个Oakley组16

7. 完整IKE交换的负载爆炸17

7.1 使用主模式的第一阶段17

7.2 使用快速模式的第二阶段18

8. 完全后继保密举例20

10.安全考虑21

11.IANA考虑22

11.1 属性类22

11.2 加密算法类22

11.3 hash算法22

11.4 组描述和组类型23

11.5 存活期类型23

12. 鸣谢23

13.参考23

附录A25

属性分配号码25

属性种类26

种类值26

附录B 28

作者地址30

作者的注释30

1.摘要

ISAKMP ([MSST98])中对验证和密钥交换提出了结构框架，但没有具体定义。ISAKM被设计用来独立的进行密钥交换，即被设计用于支持多种不同的密钥交换。

Oakley ([Orm96])中描述了一系列被称为“模式”的密钥交换，并详述了每一种提供的服务（如密钥的完全后继保密（perfect forward secrecy），身份保护，以及验证）。

SKEME ([SKEME])中描述了一种提供匿名，否认，和快速密钥更新的通用密钥交换技术。本文档将描述使用部分Oakley，部分SKEME，并结合ISAKMP的一种协议，它使用ISAKMP 来得到已验证的用于生成密钥和其它安全联盟（如AH，ESP）中用于IETE IPsec DOI的材料。

2.讨论

本文档描述了一种混合协议。目的是用于以一种保护的方式来协商安全联盟并为它提供经验证过的密钥生成材料。

本文档中实现的过程可用于协商虚拟专用网（VPN），也可用于远程用户（其IP地址不需要事先知道）从远程访问安全主机或网络。支持客户协商。客户模式即为协商双方不是安全联盟发起的两个终点。当使用客户模式时，端点处双方的身份是隐藏的。

本协议并没有实现整个Oakley协议，只实现了满足目的所需要的部分子集。它并没有声称与整个Oakley协议相一致或兼容，也并不依靠Oakley协议。同样，本协议没有实现整个的SKEME协议，只使用了用于验证的公钥加密的方法和使用当前时间（nonce）交换来快速重建密钥的思路。本协议并不依靠SKEME协议。

3.术语和定义

3.1必要的术语

本文档中出现的关键字“MUST”，“MUST NOT”，“REQUIRED”，“SHOULD”，“SHOULD NOT”以及“MAY”的解释在[Bra97]中描述。

3.2符号

下列的符号在整个文档中都使用。

HDR是ISAKMP的报头，它的交换类型是模式。当写成HDR*时，意味着负载加密。SA是有一个或多个提议的SA协商负载。发起方可能提供多个协商的提议；应答方只能用一个提议来回答。

_b指明负载

数据部分（body）——不包括ISAKMP的通用vpayload负载。

SAi_b是SA负载的数据部分（除去ISAKMP通用报头）——也就是由发起者所提供的DOI、情况（situation）、所有的提议（proposal）、以及所有的变换（transform）。

CKY-I和CKY-R分别是ISAKMP报头中发起者和响应者的cookie。

g^xi和g^xr分别是Diffie-Hellman ([DH])中发起者和响应者的公共值。

g^xy是Diffie-Hellman的共享秘密。

KE是包含了用于Diffie-Hellman交换的公共信息的密钥交换负载。没有对KE负载的数据进行特殊的编码（如TLV）。

Nx是当前时间（nonce）负载；其中x可以是i和r，分别代表ISAKMP的发起者和响应者。

IDx是x的身份识别负载。x可以是“ii”或“ir”，分别表示第一阶段协商中的ISAKMP 发起者和响应者；也可以是“ui”或“ur”，分别表示第二阶段的用户发起者和响应者。用于互联网DOI的ID负载格式在[Pip97]中定义。

SIG是数字签名负载。签名的数据是特定于某种交换的。

CERT是证书负载。

HASH（以及衍生物，如HASH（2）或HASH_I）是hash负载。hash的内容是特定于验证方法的。

prf(key, msg)是key的伪随机函数——通常是key的hash函数——用于产生表现有伪随机性的确定的输出。prf用于导出密钥和验证（即作为有密钥的MAC）。（见[KBC96]）

SKEYID是从秘密材料中衍生出的字符串，只有某次交换中的活跃双方才知道。

SKEYID_e是ISAKMP SA用来保护消息的机密性的密钥材料。

SKEYID_a是ISAKMP SA用来验证消息所使用的密钥材料。

SKEYID_d是非ISAKMP安全联盟用来衍生出密钥所使用的密钥材料。

y表示“x”是由密钥“y”加密的。

-->表示“发起者到响应者”的通信（请求）。

<--表示“响应者到发起者”的通信（回答）。

| 表示信息的串联——如X | Y表示X和Y是串联的。

[x]表示x是可选的。

消息加密（ISAKMP报头后标注有“*”号）必须紧接在ISAKMP报头后。当通信是受保护的时候，所有ISAKMP报头后的负载必须要加密。从SKEYID_e产生加密密钥的方法由各个算法定义。

3.3完全后继保密

在本文档中使用的完全后继保密（PFS）术语是和一个概念相关的，即限制单密钥只能访问到受本单密钥保护的数据。要满足PFS，对于用来保护数据传输的已经存在的密钥来说，它就不能用于衍生出其它的密钥，如果用来保护数据传输的密钥是从其它密钥材料中衍生出来的，则这些材料就不能再用于衍生任何其它密钥。

在本协议中提供了密钥和身份的完全后继保密（5.5和8 节）

3.4安全联盟

安全联盟（SA）是一组用来保护信息的策略和密钥。在本协议中，ISAKMP SA 是协商双方为保护之间的通信而使用的共享的策略和密钥。

4.简介

Oakley和SKEME各自定义了建立经过验证的密钥交换的方法。其中包括负载的构建，信息负载的运送，它们被处理的顺序以及被使用的方法。

然而Oakley定义了“模式”，ISAKMP定义了“阶段”。两者之间的关系非常直接，IKE 描述了在两个阶段中进行的不同的、称为模式的交换。

第一阶段指两个ISAKMP实体建立一个安全、验证过的信道来进行通信。这被称为ISAKMP安全联盟（SA）。“主模式”和“积极模式”都能完成第一阶段的交换。“主模式”和“积极模式”只能在第一阶段中使用。

第二阶段指协商代表服务的安全联盟，这些服务可以是IPsec或任何其它需要密钥材料以及/或者协商参数的服务。

“新组模式”并不真正在第一阶段或第二阶段中。它紧接着第一阶段，用于建立可在以后协商中使用的新组。“新组模式”只能在第一阶段之后使用。

ISAKMP SA是双向的，即一旦建立，任何一方都可以发起快速模式交换，信息交换，以及新组模式交换。由ISAKMP基础文档可知，ISAKMP SA由发起者的cookie后跟响应者的cookie来标识——在第一阶段的交换中各方的角色决定了哪一个cookie是发起者的。由第一阶段的交换所建立的cookie顺序继续用于标识ISAKMP SA，而不管快速模式、信息、新组交换的方向。换句话来说，当ISAKMP SA的方向改变时，cookie不能交换位置。

由于使用ISAKMP阶段，实现中可以在需要时完成快速的密钥交换。单个第一阶段协商可以用于多个第二阶段的协商。而单个第二阶段协商可以请求多个安全联盟。由于这种优化，实现中每个SA可以少于一个传输往返，以及少于一次DH求幂运算。第一阶段中的“主模式”提供了身份保护。当身份保护不必要时，可以使用“积极模式”以进一步减少传输往返。下面的内容中包括了开发者对进行优化的提示。同时必须注意当使用公共密钥加密来验证时，积极模式仍然提供身份保护。

本协议本身并没有定义自己的DOI。在第一阶段中建立的ISAKMP SA可以使用非ISAKMP服务（如IETF IPSec DOI [Pip97]）的DOI和情形（situation）。在这种情况下，实现中可以限制使用ISAKMP SA来建立具有相同DOI的服务SA。另一种方法是使用DOI 和情形（situation）为零值（参看[MSST98]中对这些域的描述）来建立ISAKMP SA，在这种情况下，实现中可以自由使用ISAKMP SA来为任何已定义的DOI建立安全服务。如果使用DOI为零来建立第一阶段的SA，第一阶段中的标识负载的语法就在[MSST98]中定义，而不是从任何的DOI（如[Pip97]，它可能会进一步扩展标识的语法和语义）中定义。

IKE使用下面的属性，并且作为ISAKMP安全联盟的一部分来协商。（这些属性只属于ISAKMP安全联盟，而不属于ISAKMP为所代表的服务进行协商而建立的任何安全联盟）：

—加密算法

—hash算法

—验证方法

—进行Diffie-Hellman操作的组的有关信息。

所有这些属性是强制性的且必须被协商的。另外，可以可选的协商一个伪随机函数（“prf”）。（当前本文档中还没有定义可协商的伪随机函数。在双方都同意时可以私下使用属性值用于prf协商。）如果没有协商“prf”，协商的HMAC (参看[KBC96])的hash算法就作为伪随机函数。其它非强制性的属性在附录A中定义。选择的hash算法必须支持原始模式和HMAC模式。

Diffie-Hellman组必须使用一个已定义的组描述（第6节）来指定，或者定义一个组的全部属性（第5.6节）。组属性（如组类型或素数——参看附录A）不能和以前定义的组（不论是保留的组描述，还是由新组模式交换后确定并建立的私下使用的描述）相关联。

IKE的实现必须支持以下的属性值：

—使用弱、半弱密钥检查，且为CBC模式的DES[DES]。（弱、半弱密钥参考[Sch96]，并在附录A中列出）。密钥根据附录B进行衍生。

—MD5[MD5]和SHA[SHA]。

—通过共享密钥进行验证。

—对缺省的组1进行MODP（参看下面内容）。

另外，IKE的实现必须支持3DES加密；用Tiger ([TIGER])作为hash；数字签名标准，RSA[RSA]，使用RSA公共密钥加密的签名和验证；以及使用组2进行MODP。IKE 实现可以支持在附录A中定义的其它的加密算法，并且可以支持ECP和EC2N组。

当实现了IETF IPsec DOI[Pip97]时，IKE必须实现以上描述的模式。其它DOI也可使用这里描述的模式。

5.交换

有两中基本方法可以用来建立经过验证密钥交换：主模式和积极模式。它们都通过短暂的Diffie-Hellman交换来产生经过验证的密钥材料。主模式必须要实现；积极模式最好也实现。另外，作为产生新密钥材料和协商非ISAKMP安全服务机制的快速模式也必须要实现。另外，作为定义Diffie-Hellman交换私有组机制的新组模式应该要实现。实现中不能

在交换正在进行时改变交换类型。

交换遵从标准ISAKMP负载语法，属性编码，消息的超时和重传，以及信息消息——例如，当一个提议未被接时，或者签名验证或解密失败时，一个通知响应就被发送，等等。

在第一阶段交换中，SA负载必须先于任何其它的负载。除了另外的通知表明在任何消息的ISAKMP负载中没有需要特定顺序的需求。

不论在第一阶段还是第二阶段中，在KE负载中传递的Diffie-Hellman公共值必须在必要时用零填充，且长度必须为协商Diffie-Hellman组所需要的长度。

当前时间（nonce）负载的长度必须在8到256个字节之间。

主模式是ISAKMP身份保护交换的实现：头两个消息协商策略；下两个消息交换Diffie-Hellman的公共值和必要的辅助数据（例如：当前时间（nonce））；最后的两个消息验证Diffie-Hellman交换。作为初始ISAKMP交换的验证方法的协商影响负载的组成，而不是它们的目的。主模式的XCHG就是ISAKMP身份保护。类似的，积极模式是ISAKMP积极交换的实现。头两个消息协商策略，交换Diffie-Hellman公共值以及必要的辅助数据，还有身份。另外，第二个消息还要对响应者进行验证。第三个消息对发起者进行验证，并提供参与交换的证据。积极模式的XCHG就是ISAKMP的积极交换。在ISAKMP SA的保护下，如果需要，最后的消息可以不发送，这样允许每一方延迟求幂的运算，直到这次交换

完成以后再运算。积极模式的图示中显示最后的负载以明文发送，这不是必须的。

IKE的交换并不是open ended，而是有固定数目的消息。证书请求负载的回执不能扩展传输或期待的消息的数目。

积极模式在安全联盟协商中有一定的局限性。因为在消息构建请求中，Diffie-Hellman交换所需要的组不能被协商。另外，不同的验证方法可能进一步限制属性的协商。例如，利用公共密钥加密的验证就不能被协商，同时，当使用修改过的公共密钥加密方法来验证时，密码和hash又不能被协商。当要利用IKE能协商大量属性的能力时，就需要使用主模式了。

快速模式和新组模式在ISAKMP中没有与之对应的。它们的XCHG的值在附录A 中定义。

主模式，积极模式，以及快速模式进行安全联盟的协商。安全联盟的建议（offer）采取下列形式：转换（transform）负载封装在提议（proposal）负载中，而提议负载又封装在安全联盟（SA）负载中。第一阶段交换（主模式和积极模式）中如果多个建议提出，则必须采取下列形式：多个转换（transform）负载封装在一个提议（proposal）负载中，然后它们又封装在一个SA负载中。对第一阶段交换可以换种方式来表述：在单个SA负载中，不能有多个提议负载，同时，也不允许有多个SA负载。本文档并不禁止在第二阶段的交换中出现这些形式。

本来发起者发送给响应者的建议（offer）的数量是没有限制的，但出于性能考虑，实现中可以选择限制将进行检查的建议（offer）的数量。

在安全联盟的协商中，发起者向响应者提出可能的安全联盟的建议（offer）。响应者不能修改任何建议的属性，除了属性的编码（参看附录A）。如果交换的发起者注意到属性值被修改了，或者有属性在建议中被增加或删除了，则这个响应必须废弃。

主模式或积极模式中都允许四种不同的验证方法——数字签名，公共密钥加密的两种验证形式，或者共享密钥。对每种验证方法要分别计算SKEYID值。

对于数字签名：SKEYID = prf(Ni_b | Nr_b, g^xy)

对于公共密钥加密：SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R)

对于共享密钥：SKEYID = prf(pre-shared-key, Ni_b | Nr_b)

不论是主模式还是积极模式，结果都是产生三组经过验证的密钥材料：

SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)

SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)

SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

以及达成了用于保护通信的一致的策略。上面的值0，1，2由单个字节的值来代表。用于加密的密钥值根据具体的算法（参看附录B）从SKEYID_e中衍生出来。

对于使用数字签名的验证，HASH_I和HASH_R是经过签名并效验的；对于使用公共密钥加密验证或共享密钥的验证，HASH_I和HASH_R直接验证交换。整个ID负载（包括ID类型，端口，协议，但通用报头除外）被hash计算进HASH_I和HASH_R。

正如上面提到的，所协商的验证方法影响第一阶段模式的消息内容和使用，但不影响它们的目的。当使用公共密钥来验证时，第一阶段的交换可以使用签名或使用公钥加密（如果算法支持）来完成。下面是使用不同的验证选项的第一阶段交换。

5.1 使用签名来验证的IKE第一阶段

使用签名，在第二个传输往返中交换的辅助信息是当前时间（nonce）；通过对相互可以得到的hash值进行签名来对交换进行验证。使用签名验证的主模式描述如下：

发起者响应者

----------- -----------

HDR, SA-->

<-- HDR, SA

HDR, KE, Ni -->

<-- HDR, KE, Nr

HDR*, IDii, [ CERT, ] SIG_I -->

<-- HDR*, IDir, [ CERT, ] SIG_R

和ISAKMP相关联的带签名的积极模式描述如下：

发起者响应者

----------- -----------

HDR, SA, KE, Ni, IDii -->

<-- HDR, SA, KE, Nr, IDir,

[ CERT, ] SIG_R

HDR, [ CERT, ] SIG_I -->

两种模式中，签名的数据——SIG_I或SIG_R是协商的数字签名算法分别应用到HASH_I或HASH_R所产生的结果。

总的来说，就象上面说明的一样，签名使用协商的prf，或协商的HMAC hash函数（如果没有协商prf）来对HASH_I和HASH_R签名。但是，如果签名算法绑定于特定的hash算法（如DSS只定义使用SHA160位的输出），则签名的构建会有不同。在这种情况下，签名仍然将象上面一样覆盖HASH_I和HASH_R，但使用和签名方法向关联的HMAC hash算法。协商的prf和hash函数将被用作其它指定的伪随机函数。

既然使用的hash算法已知，就没有必要将它的OID也编码到签名之中。另外，在PKCS#1的RSA签名中使用的OID和本文档中使用的OID之间没有关联。所以，RSA签名在PKCS#1格式中必须被作为私有密钥加密来编码，而不是作为PKCS#1格式（它包括hash 算法的OID）中的签名。DSS签名必须作为r后跟s来编码。

一或多个证书负载在传递中是可选的。

5.2 使用公共密钥加密的第一阶段验证

使用公共密钥加密来验证交换，交换的辅助信息是加密的当前时间（nonce）。每一方重新构建hash（如果另一方能解密当前时间（nonce））的能力就验证了交换。

要执行公钥加密，发起者必须已经拥有响应者的公钥。当响应者有多个公钥时，发起者用来加密辅助信息的证书的hash值也作为第三个消息传递。通过这种方式，响应者可以确定使用哪一个对应的私钥来解密加密了的负载，同时也保持了身份保护功能。

除了当前时间（nonce）外，双方的身份（IDii和IDir）也使用对方的公钥进行加密。如果验证方法是公钥加密，则当前时间（nonce）和身份负载必须使用对方的公钥加密。只有负载的数据部分进行了加密，而负载的报头仍为明文形式。

当使用加密作为验证时，主模式定义如下：

发起者响应者

----------- -----------

HDR, SA-->

<-- HDR, SA

HDR, KE, [ HASH(1), ]

PubKey_r,

PubKey_r -->

HDR, KE, PubKey_i,

<-- PubKey_i

HDR*, HASH_I -->

<-- HDR*, HASH_R

积极模式使用加密作为验证的描述如下：

发起者响应者

----------- -----------

HDR, SA, [ HASH(1),] KE,

Pubkey_r,

Pubkey_r -->

HDR, SA, KE, PubKey_i,

<-- PubKey_i, HASH_R HDR, HASH_I -->

其中HASH（1）是发起者用于加密当前时间（nonce）和身份的证书的hash（使用协商的

hash

函数）。

RSA加密必须被编码进PKCS#1格式中。当只有ID和当前时间（nonce）负载的数据部分要加密时，加密的数据前必须有一个有效的ISAKMP通用报头。负载的长度是整个加密负载加上报头的长度。PKCS#1编码可以不用解密而确定明文负载的实际长度。

使用加密来验证提供了可信的可拒绝交换。没有证据（使用数字签名）表明通信曾经发生过，因为每一方都可以完全重新构建交换的两方。另外，秘密的产生也增加了安全，因为袭击者不仅不得不破解Diffie-Hellman交换，还要破解RSA加密。这种交换由[SKEME]提出。

注意，与其它的验证方法不一样，公钥加密验证允许积极模式有身份保护。

5.3 使用修改过的公钥加密模式来进行第一阶段的验证

使用公钥加密来进行验证比签名验证（参看5.2节）有更大的优点。不幸的是，这需要4个公钥操作为代价——两个公钥加密和两个私钥解密。而修改过的验证模式保持了使用公钥加密来验证的优点，但只需要一半的公钥操作。

在这种模式中，当前时间（nonce）仍然使用双方的公钥进行加密，但双方的身份（以及证书）使用协商的对称加密算法（从SA负载中获得）来加密，其密钥是从当前时间（nonce）中衍生而来。这种解决方案增加最少的复杂性和状态，而在每一方节省了两个公钥操作。另外，密钥交换（KE）负载也使用同一个衍生的密钥进行加密。这为对Diffie-Hellman 交换进行密码分析而提供了额外的保护。

使用公钥加密的验证方法（5.2节），如果响应者有多个证书包含可用的公钥（例如，如果证书不只是用于签名，也不受证书限制或算法限制），可以发送HASH负载来标识证书。如果HASH负载被发送，他必须是第二个消息交换的第一个负载，同时必须后跟加密的当前时间（nonce）。如果HASH负载没有发送，第二个消息交换的第一个负载必须是加密的当前时间（nonce）。另外，发起者可以可选的发送证书负载，以提供一个公钥给响应者进行响应时使用。

当使用修改过的加密模式来验证时，主模式定义如下：

发起者响应者

----------- -----------

HDR, SA-->

<-- HDR, SA

HDR, [ HASH(1), ]

Pubkey_r,

Ke_i,

[<Ke_i] -->

HDR, PubKey_i,

Ke_r,

<-- Ke_r,

HDR*, HASH_I -->

<-- HDR*, HASH_R

积极模式使用修改的加密方法来验证的描述如下：

发起者响应者

----------- -----------

HDR, SA, [ HASH(1),]

Pubkey_r,

Ke_i, Ke_i

[, Ke_i ] -->

HDR, SA, PubKey_i,

Ke_r, Ke_r,

<-- HASH_R

HDR, HASH_I -->

其中HASH（1）和5.2节相同。Ke_i和Ke_r是在SA负载交换中协商的对称加密算法的密钥。

只有负载的数据部分加密（公钥和对称密钥操作中都一样），通用的负载的报头保持明文形式。包含

报头的负载长度用于执行加密操作。

对称加密密钥是从解密的当前时间（nonce）中衍生出来的，如下所示。先计算值Ne_i和Ne_r：

Ne_i = prf(Ni_b, CKY-I)

Ne_r = prf(Nr_b, CKY-R)

接着，通过附录B中描述的方式分别从Ne_i 和Ne_r中得到密钥Ke_i和Ke_r，并用于为协商

的加密算法衍生出对称密钥。如果协商的prf产生的输出的长度大于或等于密码的密钥长度要求，则

Ke_i和Ke_r分别从Ne_i和Ne_r的最高位衍生。如果Ke_i和Ke_r需要的长度超过了prf 的输出的

长度，则还需要的比特位通过下列方式得到：不断的将prf输出的结果作为prf的输入，并连接产生

的结果，直到得到需要的长度。例如：如果协商的加密算法需要320比特的密钥，而prf的输出只有

128比特时，Ke_i就是K的最高320比特，其中：

K = K1 | K2 | K3 and

K1 = prf(Ne_i, 0)

K2 = prf(Ne_i, K1)

K3 = prf(Ne_i, K2)

为简洁起见，只显示了Ke_i的衍生过程；Ke_r是相同的。在计算K1时值0的长度是单个字节。

注意Ne_i，Ne_r，Ke_i，以及Ke_r都是暂时性的，必须在使用后废弃。

将请求存放在可选的HASH负载和强制的当前时间（nonce）负载的位置中，就没有其它的负载

请求了。跟在加密的当前时间（nonce）之后的所有的负载——无论任何顺序——都必须使用Ke_i

或Ke_r来加密，具体使用哪一个取决于方向。

如果CBC模式用于对称加密，则初始向量（IV）如下所设：当前时间（nonce）后的第一个负

载的IV设为0；后继的使用临时对称加密密钥——Ke_i来加密的负载的IV是先前的负载经加密过

后的密文块。加密过后的负载填充到最接近的块大小。所有的填充字节都是0x00，除了最后一个字

节。最后一个填充字节的内容为使用的填充字节数，包括它自己。注意，这就表示总是有填充的。

5.4 使用共享密钥的第一阶段协商

通过其它带外（out-of-band）机制而衍生出来的密钥也可用于验证交换。这种密钥实际的建立

过程已经超出了本文档的范围。

当进行共享密钥验证时，主模式定义如下：

发起者响应者

---------- -----------

HDR, SA-->

<-- HDR, SA

HDR, KE, Ni -->

<-- HDR, KE, Nr

HDR*, IDii, HASH_I -->

<-- HDR*, IDir, HASH_R

使用共享密钥的积极模式描述如下：

发起者响应者

----------- -----------

HDR, SA, KE, Ni, IDii -->

<-- HDR, SA, KE, Nr, IDir, HASH_R

HDR, HASH_I -->

当使用共享密钥的主模式时，密钥只能通过双方的IP地址来进行识别，因为HASH_I必须在发

起者处理IDir之前计算出来。积极模式允许使用大量的共享秘密的标识符。另外，积极模式还允许

双方维持多个不同的共享密钥，并能对一次特定的交换标识出正确的密钥。

5.5 第二阶段——快速模式

快速模式本身并不是一次完整的交换（因为它和第一阶段交换相关联），但又作为SA协商过程

（第二阶段）的一部分用来衍生密钥材料和协商非ISAKMP SA的共享策略。快速模式交换的信息

必须由ISAKMP SA来保护——即除了ISAKMP报头外，所有的负载都要加密。在快速模式中，

HASH负载必须立即跟随在ISAKMP报头后，SA负载必须紧跟在HASH负载之后。HASH 用于验

证消息，同时也提供了参与的证据。

在一个特定的ISAKMP SA中，在ISAKMP报头中的消息ID标识了快速模式正在进行中，而

ISAKMP SA本身由ISAKMP报头中的cookie来标识。因为每个快速模式的实例使用唯一的初始向

量（参看附录B），这就有可能在一个ISAKMP SA中的任一时间内同时有多个快速模式在进行中。

快速模式基本上是一次SA协商和提供重放（replay）保护的当前时间（nonce）交换。当前时间

（nonce）用于产生新的密钥材料并阻止通过重放攻击产生虚假的安全联盟。可选的密钥交换（KE）

负载可以经交换来实现通过快速模式产生附加的Diffie-Hellman交换以及求幂运算。但是必须支持使

用快速模式的密钥交换负载成为可选的。

基本的快速模式（没有KE负载）更新第一阶段的求幂运算所衍生出来的密钥材料。这并不提

供PFS。使用可选的KE负载，执行额外的求幂运算，从而为密钥材料提供了PFS。

在快速模式中SA协商中的身份隐含假定为ISAKMP双方的IP地址，且没有对协

议或端口号隐

含施加限制，除非在快速模式中客户标识符是指定的。如果ISAKMP代表另一方作为客户协商代表，

则双方的身份必须传递为IDci和IDcr。本地策略将决定是否接受身份指定的提议（proposal）。如果

客户身份没有被快速模式的响应者所接受（由于策略或其它原因），一个通知消息类型为INV ALID-ID-INFORMA TION (18)的通知负载将发出。

在双方之间有多个隧道存在的情况下，客户身份用于标识并指导流量进入对应的隧道，同时也

用于支持不同粒度的唯一和共享SA。

快速模式期间所发出的所有消息逻辑上是相关的并且必须一致。例如，如果KE负载被发出，

描述Diffie-Hellman组的属性（参看6.1节和[Pip97]）必须被包括在协商的SA中的每个提议

（proposal）中的每个转换（transform）之中。同样的，如果使用了客户身份，则它们必须应用到协

商的每个SA中。

快速模式定义如下：

发起者响应者----------- -----------

HDR*, HASH(1), SA, Ni

[, KE ] [, IDci, IDcr ] -->

<-- HDR*, HASH(2), SA, Nr

[, KE ] [, IDci, IDcr ]

HDR*, HASH(3) -->

其中：

HASH（1）是从ISAKMP报头中的消息id（M-ID）开始，连接跟在hash后的整个消息的prf

结果,其中包括所有的负载头，但不包括为加密而加入的填充。HASH（2）和HASH（1）一样，除

了发起者的不包含负载头的当前时间（nonce）——Ni被增加在M-ID后，完整的消息之前。HASH

（2）中添加当前时间是为了增加参与证据。用于参与的HASH（3）是用单个字节代表的值0，后

跟串联着的消息id和除去负载头的两个当前时间（nonce）——先是发起者的，后跟响应者的nonce

的prf结果。换句话说，以上的交换的hash是：

HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )

HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr )

HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)

除了HASH，SA，和可选的ID负载以外，快速模式没有对负载顺序的限制。当消息中的负载

顺序不同于示例时，或当有可选的负载，如通知负载被链入到了消息中时，HASH（1）和HASH（2）

可以和上面的示例不同。

如果不需要PFS，并且没有KE负载交换，则新的密钥材料定义为：KEYMA T = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b)。

如果需要PFS且有KE负载交换，则新密钥材料定义为：

KEYMA T = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)

其中快速模式中的g(qm)^xy是临时Diffie-Hellman交换的共享秘密。

在任一种情况下，“协议”和“SPI”是从包含协商的转换（transform）负载的ISAKMP 提议负

载中得到的。

单个SA协商导致两个安全联盟——一个入，一个出。每个SA（一个由发起者选择，另一个

有响应者选择）的不同的SPI保证了每个方向有不同的密钥。SA的目的地选择的SPI用于衍生SA

的KEYMA T。

当需要的密钥材料的长度大于prf所提供的长度时，KEYMA T就不断的通过将prf 的结果回填

给自己，并将结果串联起来，直到满足需要的长度。即：

KEYMA T = K1 | K2 | K3 | ...

其中

K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)

K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)

K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)

等等。

这个密钥材料（不论是否满足PFS，和是直接衍生出，还是串联而成）必须在协商的SA中使

用。而由服务来定义怎样从密钥材料中衍生密钥。

在快速模式中使用临时Diffie-Hellman交换的情况下，指数（g（qm）^xy）从当前状态中不可

恢复的删除掉，并且SKEYID_e和SKEYID_a（从第一阶段协商中衍生）继续用于保护和验证ISAKMP

SA，同时SKEYID_d继续用于衍生密钥。

使用快速模式，多个SA和密钥可以使用一个交换来协商，如下所示：

发起者响应者

----------- -----------

HDR*, HASH(1), SA0, SA1, Ni,

[, KE ] [, IDci, IDcr ] -->

<-- HDR*, HASH(2), SA0, SA1, Nr,

[, KE ] [, IDci, IDcr ]

HDR*, HASH(3) -->

密钥材料和在单个SA的情况中一样的衍生出来。在这种情况下（两个SA负载的协商），结果

将是四个安全联盟——每个方向两个。

5.6 新组模式

新组模式不能在ISAKMP SA建立之前使用。新组的描述只能跟在第一阶段协商之后。（虽然它r

也不是第二阶段的交换）。

发起者响应者

----------- -----------

HDR*, HASH(1), SA-->

<-- HDR*, HASH(2), SA

其中HASH（1）是prf的输出，它使用SKEYID_a作为密钥，从ISAKMP报头中的消息ID 开

始，串接整个SA的提议（包括头和数据部分）作为数据；HASH（2）也是prf的输出，它使用SKEYID_a

作为密钥，同时从ISAKMP报头中的消息ID开始，串接应答作为数据。换种方式表达，上面交换

的hash为：

HASH(1) = prf(SKEYID_a, M-ID | SA)

HASH(2) = prf(SKEYID_a, M-ID | SA)

提议将指定组的特性（参看附录A，“属性分配编号”）。私有组的组描述必须大于或等于2^15。

如果组不能被接受，响应者必须使用消息类型设为A TTRIBUTES-NOT-SUPPORTED (13)的通知负载

来应答。

ISAKMP的实现可以要求私有组在建立的它的SA中设置超时。

组可以在主模式的SA提议中直接协商。对于MODP组来说，要达到这目的，必须将下列值作

为SA的属性来传递（参看附录A）：类型、素数和产生器；对于EC2N组来说，需要类型、不可约

分多项式、组产生器1、组产生器2、组曲线A、组曲线B和组顺序。另一方面，使用新组

模式，组

的种类（nature）可以隐藏，同时在第一阶段的协商中只有组标识符以明文方式传递。

5.7 ISAKMP信息交换

本协议在可能时保护ISAKMP信息交换。当使用本协议时，一旦ISAKMP安全联盟已经建立（同

时SKEYID_e 和SKEYID_a也已产生），则ISAKMP信息交换就如下所示：

发起者响应者----------- -----------

HDR*, HASH(1), N/D -->

其中N/D要么是ISAKMP通知（notify）负载，要么是ISAKMP删除（delete）负载，同时HASH

（1）是prf的输出，它使用SKEYID_a作为密钥，而本交换唯一的M-ID和串接的整个信息负载（通

知负载或者删除负载）作为数据。换种方式表达，上面交换的hash为：

HASH(1) = prf(SKEYID_a, M-ID | N/D)

和提到过的一样，ISAKMP报头中的消息ID——也用在prf的计算中——是这个交换中唯一的，

不能和产生这次信息交换的第二阶段交换中的另一个消息ID相同。使用SKEYID_e来加密这个消息

时，初始向量的导出在附录B中描述。

如果ISAKMP安全联盟在信息交换时还没有建立，则交换就以明文发送，同时没有HASH负载。

6 Oakley组

使用IKE，进行Diffie-Hellman交换的组是协商而得的。下面定义了四个组，从1到4。这些组

起源于Oakley协议，因此被称为“Oakley组”。组的属性类在附录A中定义。所有大于等于2^15

的值都作为私有组的标识符。对于缺省Oakley组强度的讨论，请参考下面的安全考虑一节。

这些组都是由Richard Schroeppel在Arizona大学中创造出来的。它们的属性在[Orm96]中描述。

6.1 第一个Oakley缺省组

Oaklay的实现必须支持有下列素数和产生器的MODP组。这个组分配的id号为1。

素数为: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }

它的16进制值为：

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD

EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF

产生器为：2

6.2 第二个Oakley组

IKE的实现必须支持有下列素数和产生器的MODP组。这个组分配的id号为2。

素数为2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }。

它的16进制值为：

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD

EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245

E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED

EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381

FFFFFFFF FFFFFFFF

产生器为2（十进制）。

6.3 第三个Oakley组

IKE的实现应该支持有下列特征的EC2N组：组被分配的id号为3。曲线是基于伽罗瓦域

GF[2^155]，域大小为155。域的不可约多项式为：

u^155 + u^62 + 1

椭圆曲线的方程为：

y^2 + xy = x^3 + ax^2 + b

域大小：155

组素数/不可约多项式：0x0800000000000000000000004000000000000001

组产生器1：0x7b

组曲线A：0x0

组曲线B：0x07338f

当使用这个组时，KE负载中的数据就是解答（x，y）中的值x，曲线上点的选择是通过随机选

择秘密Ka并计算Ka*P而来，其中*代表组相加并加倍的不断重复的操作，P是x坐标等于产生器1

的值，y坐标为由所定义的方程计算出的值所确定的曲线上的一点。曲线的方程式由组类型和系数A

和B隐含确定。对于y坐标有两个可能的值；任何一个都可成功的使用（双方不需要对选择达成共

识）。

6.4 第四个Oakley组

IKE的实现应该支持有下列特征的EC2N组：组被分配的id号为4；曲线是基于伽罗瓦域

GF[2^185]，域大小为185。域的不可约多项式为：

u^185 + u^69 + 1

椭圆曲线的方程为：

y^2 + xy = x^3 + ax^2 + b

域大小：185

组素数/不可约多项式：0x020000000000000000000000000000200000000000000001

组产生器1：0x18

组曲线A：0x0

组曲线B：0x1ee9

当使用这个组时，KE负载中的数据和使用Oakley组3时一样。

使用新组模式也可定义其它组。这些组是由Richard Schroeppel在Arizona大学中创建出来的。

这些素数的特性在[Orm96]中定义。

7. 完整IKE交换的负载爆炸

这一节说明IKE协议的使用目的：

—在ISAKMP进程间（第一阶段）建立一个安全并经过验证的信道；同时

—为IPsec SA（第二阶段）产生密钥材料，并协商。

7.1 使用主模式的第一阶段

下列图表说明在双方的第一个传输往返的交换中的负载交换。发起者可以提出多个提议；响应

者只能用一个来回答。

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ ISAKMP Header with XCHG of Main Mode, ~

~ and Next Payload of ISA_SA~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! 0 ! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Domain of Interpretation !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Situation !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! 0 ! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! ISA_TRANS ! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Transform #1 ! KEY_OAKLEY| RESERVED2 !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ prefered SA attributes ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! 0 ! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Transform #2 ! KEY_OAKLEY| RESERVED2 !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ alternate SA attributes ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

响应者选择一个转换的（transform）提议（ISAKMP SA的属性）来应答。

第二个交换由下列负载组成：

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ ISAKMP Header with XCHG of Main Mode, ~

~ and Next Payload of ISA_KE ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! ISA_NONCE ! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ D-H Public V alue (g^xi from initiator g^xr from responder) ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! 0 ! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ Ni (from initiator) or Nr (from responder) ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

共享密钥SKEYID_e和SKEYID_a现用于保护和验证所有后继的通信。注意SKEYID_e和

SKEYID_a都未经过验证。

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ ISAKMP Header with XCHG of Main Mode, ~

~ and Next Payload of ISA_ID and the encryption bit set ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! ISA_SIG ! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ Identification Data of the ISAKMP negotiator ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! 0 ! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ signature verified by the public key of the ID above ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

如5.1节所描述的一样，密钥交换是用签名的hash来验证的。一旦签名使用作为ISAKMP SA

协商的一部分的验证算法来校验且通过了，则共享密钥、SKEYID_e和SKEYID_a可以被认为经过

验证了。（为简洁起见，证书负载没有被交换）。

7.2 使用快速模式的第二阶段

下列负载在进行ISAKMP SA协商的快速模式的第一个传输往返中交换。在这假设的交换中，

ISAKMP协商者作为其它需要验证的部分的代表。

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ ISAKMP Header with XCHG of Quick Mode, ~

~ Next Payload of ISA_HASH and the encryption bit set ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! ISA_SA! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ keyed hash of message ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! ISA_NONCE ! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Domain Of Interpretation !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Situation !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! 0 ! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ SPI (4 octets) ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! ISA_TRANS ! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Transform #1 ! AH_SHA| RESERVED2 !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! other SA attributes !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! 0 ! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Transform #2 ! AH_MD5 | RESERVED2 !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! other SA attributes !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! ISA_ID ! RESERVED ! Payload Length !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ nonce ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! ISA_ID ! RESERVED ! Payload Length !

中文文本挖掘预处理流程总结

中文文本挖掘预处理流程总结 2017-09-22 12:14 编程派 0 0 阅读 15 作者：刘建平来源：https://www.doczj.com/doc/8f5260812.html,/pinard/p/6744056.html 在对文本做数据分析时，我们一大半的时间都会花在文本预处理上，而中文和英文的预处理流程稍有不同，本文就对中文文本挖掘的预处理流程做一个总结。 1. 中文文本挖掘预处理特点首先我们看看中文文本挖掘预处理和英文文本挖掘预处理相比的一些特殊点。首先，中文文本是没有像英文的单词空格那样隔开的，因此不能直接像英文一样可以直接用最简单的空格和标点符号完成分词。所以一般我们需要用分词算法来完成分词，在文本挖掘的分词原理中，我们已经讲到了中文的分词原理，这里就不多说。第二，中文的编码不是utf8，而是unicode。这样会导致在分词的时候，和英文相比，我们要处理编码的问题。这两点构成了中文分词相比英文分词的一些不同点，后面我们也会重点讲述这部分的处理。当然，英文分词也有自己的烦恼，这个我们在以后再讲。了解了中文预处理的一些特点后，我们就言归正传，通过实践总结下中文文本挖掘预处理流程。 2. 中文文本挖掘预处理一：数据收集在文本挖掘之前，我们需要得到文本数据，文本数据的获取方法一般有两种：使用别人做好的语料库和自己用爬虫去在网上去爬自己的语料数据。对于第一种方法，常用的文本语料库在网上有很多，如果大家只是学习，则可以直接下载下来使用，但如果是某些特殊主题的语料库，比如"机器学习"相关的语料库，则这种方法行不通，需要我们自己用第

对于第二种使用爬虫的方法，开源工具有很多，通用的爬虫我一般使用beautifulsoup。但是我们我们需要某些特殊的语料数据，比如上面提到的"机器学习"相关的语料库，则需要用主题爬虫（也叫聚焦爬虫）来完成。这个我一般使用ache。 ache允许我们用关键字或者一个分类算法来过滤出我们需要的主题语料，比较强大。 3. 中文文本挖掘预处理二：除去数据中非文本部分这一步主要是针对我们用爬虫收集的语料数据，由于爬下来的内容中有很多html的一些标签，需要去掉。少量的非文本内容的可以直接用Python的正则表达式(re)删除, 复杂的则可以用beautifulsoup来去除。去除掉这些非文本的内容后，我们就可以进行真正的文本预处理了。 4. 中文文本挖掘预处理三：处理中文编码问题由于Python2不支持unicode的处理，因此我们使用Python2做中文文本预处理时需要遵循的原则是，存储数据都用utf8，读出来进行中文相关处理时，使用GBK之类的中文编码，在下面一节的分词时，我们再用例子说明这个问题。 5. 中文文本挖掘预处理四：中文分词常用的中文分词软件有很多，个人比较推荐结巴分词。安装也很简单，比如基于Python的，用"pip install jieba"就可以完成。下面我们就用例子来看看如何中文分词。首先我们准备了两段文本，这两段文本在两个文件中。两段文本的内容分别是nlp test0.txt和 nlp test2.txt： 1. 沙瑞金赞叹易学习的胸怀，是金山的百姓有福，可是这件事对李达康的触动很大。易学习又回忆起他们三人分开的前一晚，大家一起喝酒话别，易学习被降职到道口县当县长，王大路下海经商，李达康连连赔礼道歉，觉得对不起大家，他最对不起的是王大路，就和易学习一起给王大路凑了5万块钱，王大路自己东挪西撮了5万块，开始下海经商。没想到后来王大路竟然做得风生水起。沙瑞金觉得他们三人，在困难时期还能以沫相助，很不容易。沙瑞金向毛娅打听他们家在京州的别墅，毛娅笑着说，王大路事业有成之后，要给欧阳菁和她公司的股权，她们没有要，王大路就在京州帝豪园买了三套别墅，可是李达康和易学习都不要，这些房子都在王

手把手教你如何将图标文件的英文名改为中文

手把手教你如何将图标文件的英文名改为中文如果你在小[font=Times New Roman]P[/font] 中安装了许多应用软件和游戏，而这些程序的图标名称大部分都是英文的，看起来未免费劲，本文教你如何将它们改成中文，不需要懂得太多，一步一步的照着图示去做就是了。 ★所需基本制作工具：[font=Times New Roman]Hex Workshop [/font]和[font=Times New Roman]UltraEdi [/font] [font=Times New Roman][/font]图一:[img=99,109]https://www.doczj.com/doc/8f5260812.html,/catchimg/20070303/608340_0.jpg[/img] 图二:[img=94,98]https://www.doczj.com/doc/8f5260812.html,/catchimg/20070303/608340_1.jpg[/img] [font=Times New Roman]Hex Workshop[/font] 下载链接：[font=Times New Roman]https://www.doczj.com/doc/8f5260812.html,/yyrj/yyrj13/yyrj1300018.htm[/font] [font=Times New Roman]UltraEdit [/font]下载链接：[font=Times New Roman]https://www.doczj.com/doc/8f5260812.html,/soft/2249.html [/font] ★[font=Times New Roman]PC[/font] 操作系统：[font=Times New Roman]WIN98[/font] 或[font=Times New Roman]WINxp[/font] ★开始制作：以一个大家熟悉的屏幕截图软件[font=Times New Roman]Screenshot[/font] 为例，安装后在桌面显示的图标英文名称如图三： [img=209,321]https://www.doczj.com/doc/8f5260812.html,/catchimg/20070303/608340_2.jpg[/img] [font=Times New Roman]1、[size=3][/size][/font]通过[font=Times New Roman]PC[/font] 端软件[font=Times New Roman]PC_filemanager_Full[/font] 进入[font=Times New Roman]Screenshot[/font] 安装路径，找到它的图标文件[font=Times New Roman]Screenshot.aif,[/font] 将它复制后保存在[font=Times New Roman]PC[/font] 文件夹中待用[font=Times New Roman].[/font] [align=center]图四[font=Times New Roman]:[/font] [/align] [img=400,141]https://www.doczj.com/doc/8f5260812.html,/catchimg/20070303/608340_3.jpg[/img] [font=Times New Roman]2[/font] 、用[font=Times New Roman]Hex Workshop[/font] 打开该图标文件[font=Times New Roman]Screenshot.aif[/font] ，共[font=Times New Roman]10[/font] 个字节： [align=center]图五[font=Times New Roman]:[/font] [/align] [img=400,308]https://www.doczj.com/doc/8f5260812.html,/catchimg/20070303/608340_4.jpg[/img] [font=Times New Roman]3、[size=3][/size][/font]运行[font=Times New Roman]UltraEdit[/font] 软件，点击文件[font=Times New Roman]/[/font] 新建，进入操作界面，输入“屏幕抓图”四个汉字，然后点击[font=Times New Roman]10/16[/font] 进制选择按钮： [align=center]图六：[/align] [img=400,302]https://www.doczj.com/doc/8f5260812.html,/catchimg/20070303/608340_5.jpg[/img] [font=Times New Roman]4[/font] 、依次点击文件[font=Times New Roman]/[/font] 转换[font=Times New Roman]/ASII[/font] 转[font=Times New Roman]Unicode[/font] （[font=Times New Roman]I[/font] ）选项： [align=center]图七：[/align]

文本素材处理

第2章文本素材处理学习指南：本章介绍文本素材采集、编辑、加工处理的有关知识。主要内容有：文本素材的基础知识，文本素材的采集与处理方法，文本素材创作实例。学习本章，要求掌握以下知识：掌握文本在计算机中的表示方法，了解文本素材的主要特点；熟悉常见的文本文件的格式，并能正确地选择文本文件的存储格式；了解常用的文本素材采集方式，熟悉扫描仪+OCR文字识别输入方法；了解常用的文字处理软件，掌握Word文字处理的方法；会用相关的文字处理软件制作多媒体作品中需要的文本素材。在多媒体作品中，文本是最基本也是最常用的素材。一些说明、介绍、作品中的文字资料都会用到文本，作为多媒体系统的组成元素，它和其它素材同样重要。文本素材处理包含文本的采集、录入、编辑等加工处理，本章将介绍文本素材处理的相关知识。 2．1 文本素材概述文本是人们早已熟知的信息表示方式，如一篇文章、一段程序、一个文件都可用文本描述。它通常以字、句子、段落、节、章为单位，记录自然现象、表述思想感情、传达某种信息。人们在阅读时，通常是一字一句、一行一页顺序地浏览。文本是文字、字母、数字和各种功能符号的集合。在现实生活中，人们对事情的讲述、逻辑的推理、数学公式的表述等都主要用文字和数字来准确的表达。在多媒体应用系统中，虽然有图形、声音、视频影像等多种媒体形式，但是对于一些复杂而抽象的事件，文本表达却有它不可替代的独到之处。 2．1．2 文本素材基础知识在多媒体应用系统中，文本作为重要的基本素材而被广泛应用，它具有信息表达清楚、计算机处理方便、存储容易、传输快捷等优势。具体来说：（1）编码形式简单在计算机中，西文字符最常用的编码是ASCII码，即American Standard Code For Information Interchange（美国信息交换标准代码）。它用7位二进制数进行编码，可以表示27即128个字符，其中包括数字字符0～9、大小写英文字符、运算符号、标点符号、标识符号和一些控制符号。这些字符种类大致能够满足各种计算机语言、西方文字、常见命令的需要。一个ASCII码字符在内存中占一个字节。汉字字符在计算机中也是以编码形式处理的，汉字输入用输入编码，汉字存储用机内码，汉字输出用字型码。在计算机中存储时，一个汉字占2个字节。（2）易于获取，存储、处理和传输容易多媒体计算机系统中，文本资料可以用多种方式获取，可采用多种输入编码录入，还

C++比较全面的文件操作(支持中文文件名)

比较全面的文件操作，支持中文文件名// #include "stdafx.h" #include #include #include #include #include #include "atltime.h" #include using namespace std; #define NDEBUG int gcd(int v1,int v2); bool createDir(const char* dir); bool createFile(const char* fileName); void findFile(); bool isExistFile(const char* filePath); bool isExistFileW(const char* filePath);

int main() { #ifndef NDEBUG cerr << "error" << endl; #endif int n = gcd(12,9); cout << n << endl; /*char dir[] = "c:\\日涨跌"; bool b = createDir(dir); if(b) { cout << "创建目录成功" << endl; } else { cout << "创建目录失败" << endl; }*/

/*bool bRes = createFile(""); if(bRes) { cout << "创建文件成功" << endl; } else { cout << "创建文件失败" << endl; } */ //findFile(); bool bExist = isExistFile("c:\\日志.txt"); if(bExist) { cout << "文件存在" << endl; } else { cout << "文件不存在" << endl; } isExistFileW("c:\\日志.txt");

中文文本预处理

常见文件名后缀大全

常见文件名后缀大全什么是文件名后缀说起来Windows工作界面下的文件名简直是随心所欲，比如：某编辑部的2000年工作计划。文件名即可用中文直接表达，而且长度最长可达256个字符，让人看起来真是一目了然。然而在Windows环境中，安装的软件中却大量存在着类似CALENDAR.EXE、GAMES.GRP等等的文件名，这又是为什么呢？原来这些文件名都是根据DOS环境的文件名命名规则而定的。 DOS环境下的文件名在DOS下，文件名采用8＋3结构，即：最长8位的文件名，由小数点分隔后再跟上最长3位的后缀名，如：READ.ME、SETUP.EXE，一般情况下文件名不允许使用汉字，只能由字母、数字和一些符号组成。如READ.ME用中文理解就是"读我"，即提示用户在使用软件前先看看这个文件的内容，以获取更多的提示信息。而更重要的是，DOS下规定用后缀名来区分各种不同的文件。在DOS下最容易遇到的首先是可执行文件，后缀名有两类：*.exe、*.com（此处的*表示文件名任意），它们是由汇编语言或其它高级语言编出的程序经过编译后直接在DOS下运行的文件。有时由于软件功能多、内存偏小，不能一次性全部调入内存还可能有同文件名的ovl文件，如ws.exe、ws.ovl。另外还有一种文件可以直接运行，*.bat,即批处理文件，其中有许多命令或可执行文件名，主要用于提高工作效率，其中最有用的是Autoexec.bat，这个文件在开机时会被自动执行（自动执行在英文中就是Automaticallyexecute）。而另外一种可以加载但不能直接运行的文件即是系统扩展管理文件*.sys（sys即系统system），它主要提供某些非标准设备如鼠标、扩充内存等的驱动程序，如mouse.sys、himem.sys。为了统一管理还专门规定了一个config.sys的文本文件来一次性地在开机时自动调入这些必需的设备驱动程序，这些文件一旦被误删或换名或被病毒侵袭则将直接导致系统工作不正常。 DOS下字处理产生的文件原本是可以不用后缀的，但人们常用*.txt表示（txt 即文本text）。被所有的平台和所有应用程序支持。而为了管理方便，人们也可以用自己的名字做后缀来表示是自己建的文本文件，如我输入的很多文章即为*.mcj，为了便于用户在意外删掉原文件的情况下能尽快恢复原文件，许多字处理系统都提供了一种自动备份的功能，如我第二次编辑JIHUA.MCJ时（JIHUA:计划的汉语拼音），系统会先拷贝一份原文件为JIHUA.BAK。使用具有特殊格式功能的字处理软件，如求伯君先生早年推出的WPS，就会规定其后缀为.wps，用以标识是用WPS生成的文本文件。当使用字处理软件编辑高级语言程序时，后缀通常为相应语言的前三个字母（如：*.BAS即BASIC语言源程序，*.PAS为PASCAL 语言程序，*.FOR为Fortran语言程序，*.C即为C语言，*.ASM即为汇编语言程序）。

第三章中文文字处理软件Word

第三章中文文字处理软件Word 2000 一、判断题 1.在Word中，必须先选定操作的内容，然后才能对选定的对象进行操作。( ) 2.Word文档中的工具栏可由用户根据需要显示或隐藏。( ) 3.在“打印预览”窗口中，通过浏览文档可以观察文章段落在页面上的整体布局，但不能对其进行编辑。( ) 4.在Word文档中，通常先选定操作对象，再右击它可弹出快捷菜单。( ) 5.把选定的文本删除掉，可以按Delete键。( ) 6.剪切板上的内容可粘贴到文挡中的多个位置。( ) 7.Word是一种所见即所得的文字处理软件。( ) 8.保存一个新建的Word文档时，默认的文档扩展名是doc。( ) 9.Word 2000软件既可以用于文字处理，也可以进行表格处理，因而又称为电子表格软件。（） 10.Word只用于文字处理，在文字中无法插入图形或表格。( ) 11.用Word进行文字编辑有多种方法，其中包括使用剪贴板。( ) 12.Word的视图工具栏总是出现在文档编辑区的左下角，不能任意移动它的位置。( ) 13.在编辑一个旧文档的过程中单击“保存”按钮，会弹出“保

存”对话框，设置文件的位置、文件名和扩展名。( ) 14.在使用Word的“查找”功能查找文档中的字串时，可以使用通配符。( ) 15.在Word的替换对话框中，可以同时替换所有找到的字串。( ) 16.设置字符的字号时，当要设置的字号列表中没有时，可以在“字号”组合框中输入字号数字。( ) 17.在Word的字符格式化中，可以把选定的文本设置成上标或下标的效果。( ) 18.新建一个Word文档可以从“文件”菜单中选择“新建”，也可以点击“常用”工具栏上的“新建”按钮。( ) 19.如果所选定的文本中包含了英文字体，而且设置字体格式时都设置为中文字体，则文本中的英文字符将显示不出来。( ) 20.文档的页面设置一般不是只指当前页面，而是指整个文档的所有页面。( ) 21.在页面上插入页码，可以放在页面的页眉位置或页脚位置。( ) 22.在Word页面设置中可以设置装订线的位置。( ) 23.在Word中不但可以编辑文字，还可以插入图形，编辑表格，直到打印出文稿。( ) 24.段落缩进的距离是从打印纸的纸边到文字的距离。( ) 25.段落的首行缩进就是指段落的第一行向里缩进一定的距离。

常用电脑文件名后缀

什么是文件后缀名？我们使用电脑的时候，常会看到文件名（中文或英文最长8位）的后面有一个点，这点后面有几个英文字（最长3位数）例如：某某.zip、某某.txt，那么这点后面的英文字是什么意思呢？这个就是后缀名，表示这个文件的格式，就像.zip就是解压缩格式的文件。比如READ.ME用中文理解就是“读我”，即提示用户在使用软件前先看看这个文件的内容，以获取更多的提示信息。相应的格式必需要相应的程序来打开，这就是我们有时打开下载好的电影、歌曲或图片等，却出现了一个打开方式的选择框，其表示系统内没有安装打开此类文件的程序或者是程序没有自动关联。因此，认识一些常用后缀名，对我们找到正确的运行程序和判别木马等恶意程序有着重要的作用。首先，我们可以将电脑设置其显示文件的后缀名，方便我们平时认识学习。打开“我的电脑”→选择菜单栏“工具”→文件夹选项“查看”→给高级设置框内的“隐藏已知文件类型的扩展名”的勾取消→“确定”。下面将常用后缀名分类说明如下。(*表示任意文件名) 一.系统文件类 *.exe、*.com可执行文件 *.bat即批处理文件如Autoexec.bat，这个文件在开机时会被自动执行 *.sys系统扩展管理文件如config.sys一次性在开机时自动调入 *.CFG即配置文件(config) *.dll动态链接文件，起到软件与系统桥梁的作用有时候，如损坏会提示找不到某某.dll文件。 *.ini为初始化信息文件(Initiation) *.pif为DOS环境下的可执行文件在Windows下执行时所需要的文件格式 *.grp为分组文件(Group) *.rec即记录器宏文件(Record) *.txt文本文档文件（txt即文本text） *.clp是剪贴板中的文件格式 *.wri即文本文件(Write)，它是字处理write.exe生成的文件 *.ttf字体格式文件。 *.ime输入法文件 *.fon、*.fot都是字库文件 *.crd即卡片文件(Card) *.cal为日历文件 *.DAT即数据文件(data) *.HLP即帮助文件(help) *.LOG即日志文件(log)

中文信息处理

中文信息处理技术浅谈摘要：随着科学技术的发展，中文信息处理已经深入到了社会生活的各方面。广泛的应用对中文信息处理技术也提出了较高的要求。本文从主流技术、新技术展望等，对中文信息处理技术进行了初步探索。关键词：中文信息处理N元模型语音识别词性标注中文信息处理是中文（包括汉语和少数民族语言）语言学和信息技术的融合，它是一门用计算机对汉语(包括口语和书面语)进行转换、传输、存贮、分析等加工的科学。中文信息处理与语言学、计算机科学、心理学、数学、控制论、信息论、声学、自动化技术等多种学科相联系，是自然语言信息处理的一个分支，需要以大量的语言知识、背景知识为依据，对中文信息的人脑处理过程进行模拟。其中，“中文”是指中国通用的所有语言种类，包括汉语及其他少数民族的语言:但一般都是指汉语。“信息”是指能通过视觉、听觉、嗅觉、味觉、触觉等器官或仪器获取，并有一定交际功能的东西，“信息”是不确定性的减少，是负熵。所谓“处理”，是指用计算机对信息进行各种加工，主要的是图像信息和语言信息的识别、模拟、分析、转换和传输。一、中文信息处理的特点及难点中文信息处理在许多方面有自己的特点。 1、汉字的特殊性西方语言只有几十个字母。而汉字由于数量大且字形复杂,也给计算机处理带来了困难。汉字信息处理是中文信息处理的关键和基础,包括汉字信息的输入、汉字信息的加工和汉字信息的输出等方面,其难点是汉字编码问题。根据在汉字信息处理过程中的不同要求,汉字有多种编码,主要可以分为四类,即汉字输入编码,汉字标准编码,汉字内码和汉字形码。 2、书面汉语的特殊性书面汉语中,词跟记号之间没有分隔标记,自动分词成为书面汉语分析的第一道难关。分词就是将连续的字序列按照一定的规范重新组合成词序列的过程。在英文的行文中,单词之间是以空格作为自然分界符的,而中文只是字、句和段可以通过明显的分界符来简单划界,唯独词没有一个形式上的分界符,虽然英文也同样存在短语的划分问题,但是在词这一层上,中文比之英文要复杂的多、困难的多。 3、汉语语音的特殊性汉语语音的特点是音节结构简单,音节界限分明,但有声调和变调等问题,对于语音识别和语音合成来说,既有有利的一面, 也有不利的一面。 4、汉语语法的特殊性汉语形态贫乏,难以凭借形态来确定词的句法功能,词序和虚词是主要的语法手段,句法歧义特别复杂,使得汉语语句自动分析这一关键技术迟迟不能取得

文本素材处理

文本素材处理学习指南：本章介绍文本素材采集、编辑、加工处理的有关知识。主要内容有：文本素材的基础知识，文本素材的采集与处理方法，文本素材创作实例。学习本章，要求掌握以下知识：掌握文本在计算机中的表示方法，了解文本素材的主要特点；熟悉常见的文本文件的格式，并能正确地选择文本文件的存储格式；了解常用的文本素材采集方式，熟悉扫描仪+OCR文字识别输入方法；了解常用的文字处理软件，掌握Word文字处理的方法；会用相关的文字处理软件制作多媒体作品中需要的文本素材。在多媒体作品中，文本是最基本也是最常用的素材。一些说明、介绍、作品中的文字资料都会用到文本，作为多媒体系统的组成元素，它和其它素材同样重要。文本素材处理包含文本的采集、录入、编辑等加工处理，本章将介绍文本素材处理的相关知识。 2．1 文本素材概述文本是人们早已熟知的信息表示方式，如一篇文章、一段程序、一个文件都可用文本描述。它通常以字、句子、段落、节、章为单位，记录自然现象、表述思想感情、传达某种信息。人们在阅读时，通常是一字一句、一行一页顺序地浏览。文本是文字、字母、数字和各种功能符号的集合。在现实生活中，人们对事情的讲述、逻辑的推理、数学公式的表述等都主要用文字和数字来准确的表达。在多媒体应用系统中，虽然有图形、声音、视频影像等多种媒体形式，但是对于一些复杂而抽象的事件，文本表达却有它不可替代的独到之处。 2．1．2 文本素材基础知识在多媒体应用系统中，文本作为重要的基本素材而被广泛应用，它具有信息表达清楚、计算机处理方便、存储容易、传输快捷等优势。具体来说：（1）编码形式简单在计算机中，西文字符最常用的编码是ASCII码，即American Standard Code For Information Interchange（美国信息交换标准代码）。它用7位二进制数进行编码，可以表示27即128个字符，其中包括数字字符0～9、大小写英文字符、运算符号、标点符号、标识符号和一些控制符号。这些字符种类大致能够满足各种计算机语言、西方文字、常见命令的需要。一个ASCII码字符在内存中占一个字节。汉字字符在计算机中也是以编码形式处理的，汉字输入用输入编码，汉字存储用机内码，汉字输出用字型码。在计算机中存储时，一个汉字占2个字节。（2）易于获取，存储、处理和传输容易多媒体计算机系统中，文本资料可以用多种方式获取，可采用多种输入编码录入，还

音频视频文件格式中文名称

中文名称：音频---视频文件格式版本：原创发行时间：2007年地区：大陆语言：普通话简介：音频---视频文件格式一、影音文件 ●AVI格式：它的英文全称为Audio Video Interleaved，即音频视频交错格式。它于1992年被Microsoft公司推出，随Windows3.1一起被人们所认识和熟知。所谓“音频视频交错”，就是可以将视频和音频交织在一起进行同步播放。这种视频格式的优点是图像质量好，可以跨多个平台使用，其缺点是体积过于庞大，而且更加糟糕的是压缩标准不统一，最普遍的现象就是高版本Windows媒体播放器播放不了采用早期编码编辑的AVI格式视频，而低版本Windows媒体播放器又播放不了采用最新编码编辑的AVI格式视频，所以我们在进行一些AVI格式的视频播放时常会出现由于视频编码问题而造成的视频不能播放或即使能够播放，但存在不能调节播放进度和播放时只有声音没有图像等一些莫名其妙的问题，如果用户在进行AVI格式的视频播放时遇到了这些问题，可以通过下载相应的解码器来解决。 ●nAVI格式：newAVI的缩写，是一个名为ShadowRealm的地下组织发展起来的一种新视频格式(与我们上面所说的AVI格式没有太大联系)。它是由Microsoft ASF压缩算法的修改而来的，但是又与下面介绍的网络影像视频中的ASF视频格式有所区别，它以牺牲原有ASF 视频文件视频“流”特性为代价而通过增加帧率来大幅提高ASF视频文件的清晰度。 ●DV-AVI格式：其英文是Digital Video Format，是由索尼、松下、JVC等多家厂商联合提出的一种家用数字视频格式。目前非常流行的数码摄像机就是使用这种格式记录视频数据的。它可以通过电脑的IEEE 1394端口传输视频数据到电脑，也可以将电脑中编辑好的的视频数据回录到数码摄像机中。这种视频格式的文件扩展名一般是.avi，所以也叫DV-AVI格式。 ●MPEG格式：其全称为Moving Picture Expert Group，即运动图像专家组格式，家里常看的VCD、SVCD、DVD就是这种格式。MPEG文件格式是运动图像压缩算法的国际标准，它采用了有损压缩方法减少运动图像中的冗余信息，说的更加明白一点就是MPEG的压缩方法依据是相邻两幅画面绝大多数是相同的，把后续图像中和前面图像有冗余的部分去除，从而达到压缩的目的(其最大压缩比可达到200:1)。目前MPEG格式有三个压缩标准，分别是MPEG－1、MPEG－2、和MPEG－4，另外，MPEG-7与MPEG-21仍处在研发阶段。MPEG－1：制定于1992年，它是针对1.5Mbps以下数据传输率的数字存储媒体运动图像及其伴音编码而设计的国际标准。也就是我们通常所见到的VCD制作格式。经过MPEG-1标准压缩后，视频数据压缩率为1/100-1／200，音频压缩率为1／6.5。MPEG-1提供每秒30帧352*240分辨率的图像，当使用合适的压缩技术时，具有接近家用视频制式（VHS）录像带的质量。MPEG-1允许超过70分钟的高质量的视频和音频存储在一张CD-ROM盘上。VCD采用的就是MPEG-1的标准，该标准是一个面向家庭电视质量级的视频、音频压缩标准。其文件扩展名包括.mpg、.mlv、.mpe、.mpeg及VCD光盘中的.dat文件等 MPEG－2：制定于1994年，设计目标为高级工业标准的图像质量以及更高的传输率。其文件扩展名包括.mpg、.mpe、.mpeg、.m2v及DVD光盘上的.vob文件等。MPEG-2主要针对高清晰度电视（HDTV）的需要，传输速率为10Mbps，与MPEG-1兼容，适用于1.5-60Mbps 甚至更高的编码范围。MPEG-2有每秒30帧704*480的分辨率，是MPEG-1播放速度的四倍。它适用于高要求的广播和娱乐应用程序，如DSS卫星广播和DVD，MPEG-2是家用视频制式（VHS）录像带分辨率的两倍。

Windows系统文件名称及其中文详解

Windows系统文件名称及其中文详解 A ↑ ACCESS.CHM - Windows帮助文件 ACCSTAT.EXE - 辅助状态指示器 ADVAPI32.DLL - 高级Win32应用程序接口 AHA154X.MPD - SCSI驱动程序 AM1500T.VXT - 网卡驱动程序 AM2100.DOS - 网卡驱动程序 APPSTART.ANI - 动画光标 APPS.HLP - Windows帮助文件 AUDIOCDC.HLP - "易码编码解码器"帮助文件 AWARDPR32.EXE - 增加打印机工具 B ↑ BIGMEM.DRV - BIGMEM虚拟设备 BILLADD.DLL - 动态链接库(支持MSW) BIOS.VXD - 即插即用BIOS接口 BUSLOGIC.MPD - SCSI驱动程序 C ↑ CALC.EXE - 计算器应用程序 CANNON800.DRV - 佳能打印机驱动程序 https://www.doczj.com/doc/8f5260812.html, - MSDOS命令 CHS16.FON - 字体文件(16点阵文) CANYON.MID - MIDI文件例子 CARDDRV.EXE - PCMCIA支持程序 CDFS.VXD - CDROM文件系统 CDPLAYER.EXE - CD播放器应用程序 CDPLAYER.HLP - CD播放器帮助文件 CHIPS.DRV - 芯片技术显示驱动程序 CHKDSK.EXE - DOS磁盘检查工具 CHOOSUSR.DLL - 网络客户 CHOKD.WAV - 声音文件例子 CIS.SCP - 脚本文件(演示如何建立与CompuservePPP连接) CLAIRE~1.RMI - MINI序列 CLIP.INF - 安装信息文件(剪粘板查看器) CLOSEWIN.AVI - 影片剪辑(AVI)(如何关闭窗口) CMC.DLLail - API1.0公共信息调用 COMBUFF.VXD - COM端虚拟设备 COMCTL32.DLL - 32位Shell组件 COMDLG32.DLL - 32位公共对话库 COMIC.TIF - TrueType字体文件(Comic Sans Ms) https://www.doczj.com/doc/8f5260812.html, - 公共对话库

图解Linux虚拟机如何挂载U盘并显示中文目录和文件名

图解Linux虚拟机如何挂载U盘并显示中文目录和文件名LinuxU图解虚拟机如何挂载盘并显示中文目录和文件名 VMware Workstation 7redhat 首先介绍一下我的环境，虚拟机版本是，虚拟系统是9.02.4.20-8 # rpm -qa|grep ，内核版本是。如果不清楚的话，可以用下面的命令查一下:kernel 我看到的是如下界面: 。 UFAT32 首先声明一下，我的盘是文件系统。 ULinuxlocale 为了使盘中的中文文件可以正常显示。首先要确认所用的系统的(这个localeLinux locale包括了系统使用的语言和字符的编码等信息)。中文常用的是zh_CN.gb2312zh_CN.gbkzh_CN.gb18030 zh_CN.UTF-8 ，，和。通过如下命令可以查询系 locale#echo $LANG统的: localezh_CN.gb18030 可见，我所用系统的是。准备好，后续使用。 #fdisk -l U 接下来，可以通过命令查询虚拟机是否识别盘了，如下:

U 在这儿，可以看到，虚拟机系统并没有识别盘。有两种处理办法，如下: 1windows XPU )在主系统(我的是)中弹出盘，点击虚拟系统界面，将活动光USB标置于虚拟系统中，找到右下角和相关的图标，点击右键在弹出的菜单，选择Connection”UU“。此时再次插入盘，可以看到主系统右下角弹出虚拟机识别盘的消息提 U示，否则，重新上述操作，直到虚拟机识别盘为止。这种方法比较笨的，大家可以采取 ,第二种方法如下: 2VM )在虚拟机界面的菜单选项中设置即可，如下: XPUSB 此时，可以看到系统右下角弹出安全退出设备的消息提示，说U明盘已被虚拟系统识别。 #fdisk -lU 再次通过命令确认虚拟系统是否识别盘，如下:

Windows系统文件名中英文对照表

Windows系统文件名中英文对照表 Windows系统文件名中英文对照表 (1) A↑ (1) B↑ (1) D↑ (2) E↑ (3) F↑ (4) G↑ (4) H↑ (4) I↑ (5) J↑ (6) K↑ (6) L↑ (6) M↑ (6) N↑ (8) O↑ (9) P↑ (9) Q↑ (9) R↑ (9) S↑ (10) T↑ (12) U↑ (13) V↑ (13) W↑ (14) X↑ (15) 当您电脑有问题时候，（比如中毒），您想把问题的文件找出来，可千万千万不要删错文件，下面的系统文件详解或许对您解决问题有很大帮助。注：很多病毒都会跑到system32目录下，假如确定了，您就可以在windows安全模式下把它删掉了，在杀毒软件没升级之前，您也可以安全无忧！ A↑ ACCESS.CHM - Windows帮助文件 ACCSTAT.EXE - 辅助状态指示器 ADVAPI32.DLL - 高级Win32应用程序接口 AHA154X.MPD - SCSI驱动程序 AM1500T.VXT - 网卡驱动程序 AM2100.DOS - 网卡驱动程序 APPSTART.ANI - 动画光标

APPS.HLP - Windows帮助文件 AUDIOCDC.HLP - "易码编码解码器"帮助文件 AWARDPR32.EXE - 增加打印机工具 B↑ BIGMEM.DRV - BIGMEM虚拟设备 BILLADD.DLL - 动态链接库(支持MSW) BIOS.VXD - 即插即用BIOS接口 BUSLOGIC.MPD - SCSI驱动程序 C↑ CALC.EXE - 计算器应用程序 CANNON800.DRV - 佳能打印机驱动程序 https://www.doczj.com/doc/8f5260812.html, - MSDOS命令 CHS16.FON - 字体文件(16点阵中文) CANYON.MID - MIDI文件例子 CARDDRV.EXE - PCMCIA支持程序 CDFS.VXD - CDROM文件系统 CDPLAYER.EXE - CD播放器应用程序 CDPLAYER.HLP - CD播放器帮助文件 CHIPS.DRV - 芯片技术显示驱动程序 CHKDSK.EXE - DOS磁盘检查工具 CHOOSUSR.DLL - 网络客户 CHOKD.WAV - 声音文件例子 CIS.SCP - 脚本文件(演示如何建立与Compuserve的PPP连接) CLAIRE~1.RMI - MINI序列 CLIP.INF - 安装信息文件(剪粘板查看器) CLOSEWIN.AVI - 影片剪辑(AVI)(如何关闭窗口) CMC.DLL:Mail - API1.0公共信息调用 COMBUFF.VXD - COM端虚拟设备 COMCTL32.DLL - 32位Shell组件 COMDLG32.DLL - 32位公共对话库 COMIC.TIF - TrueType字体文件(Comic Sans Ms) https://www.doczj.com/doc/8f5260812.html, - 公共对话库 COMMDLG.DLL - 16位公共对话库 COMMON.HLP - OLE帮助文件 COMPOBJ.DLL - OLE16/32互*作库 CONAGEN.EXE - 32位控制支持 CONFAPI.DLL - Microsoft网络组件 CONFIG.SYS - 配置文件 CONFIG.TXT - 自述文件(配置文件中如何使用命令) CONTROL.EXE - "控制面板"应用程序

下载中文文件名乱码问题

下载中文文件名乱码问题原来处理下载的代码如下： response.setHeader("Content-Disposition", "attachment; filename=" + https://www.doczj.com/doc/8f5260812.html,.URLEncoder.encode(fileName, "UTF-8")); 下载的程序里有了这句，一般在IE6的下载提示框上将正确显示文件的名字，无论是简体中文，还是日文。一. 上面方式，也就是先用URLEncoder编码，当中文文字超过17个时，IE6 无法下载文件。这是IE的bug，参见微软的知识库文章KB816868 。原因可能是因为ie在处理Response Header 的时候，对header的长度限制在150字节左右。而一个汉字编码成UTF-8是9个字节，那么17个字便是153个字节，所以便会报错。微软提供了一个补丁。这个补丁需要先安装ie6 sp1。二. 我尝试使用javamail 的MimeUtility.encode()方法来编码文件名，也就是编码成=?gb2312?B?xxxxxxxx?= 这样的形式，并从RFC1522 中找到对应的标准支持。不过很遗憾，IE6并不支持这一个标准。我试了一下，Firefox是支持的。三. 按网上很多人提供的解决方案：将文件名编码成ISO8859-1似乎是有效的解决方案，代码如下： response.setHeader( "Content-Disposition", "attachment;filename="+new String(fileName.getBytes("gb2312"), "ISO8859-1" ) ); 在确保附件文件名都是简体中文字的情况下，那么这个办法确实是最有效的，不用让客户逐个的升级IE。如果台湾同胞用，把gb2312改成big5就行。但现在的系统通常都加入了国际化的支持，普遍使用UTF-8。如果文件名中又有简体中文字，又有繁体中文，还有日文。那么乱码便产生了。另外，在我的电脑上Firefox (v1.0-en)下载也是乱码。折中考虑，我结合了一、三的方式，代码片断如下： String fileName = URLEncoder.encode(atta.getFileName(), "UTF-8");

文件下载中文名称乱码问题

package com.hs.es.action; import java.io.File; import https://www.doczj.com/doc/8f5260812.html,mons.io.FileUtils; import org.apache.struts2.ServletActionContext; import com.hs.es.GlobalVar.GlobalVar; import com.hs.es.business.TaskBusiness; import com.hs.es.filter.AppcontextEvent; public class FileUpLoad extends ActionClass{ private static final long serialVersionUID = 572146812454l; /************************************************ 类属性区**************************************************/ private static final int BUFFER_SIZE = 16 * 1024;// 流反冲区大小 private File myFile;// 文件 private String contentType;// 文件类型 private String fileName;// 文件名 private String imageFileName;// 文件最终路径和名称 private String caption; private Integer userid;// 用户ID private Integer taskid;// 任务id // private String fileContentType;//文件类型 // private String fileFileName;//文件名 /**************************************************** get set 方法区*******************************************/ // 特别方法 public void setMyFileContentType(String contentType) { this.contentType = contentType; } // 特别方法 public void setMyFileFileName(String fileName) { this.fileName = fileName; } public File getMyFile() { return myFile; } public void setMyFile(File myFile) {

文档之家

ipsec中文RFC

中文文本挖掘预处理流程总结

手把手教你如何将图标文件的英文名改为中文

文本素材处理

C++比较全面的文件操作(支持中文文件名)

中文文本预处理

常见文件名后缀大全

第三章 中文文字处理软件Word

常用电脑文件名后缀

中文信息处理

文本素材处理

音频视频文件格式中文名称

Windows系统文件名称及其中文详解

图解Linux虚拟机如何挂载U盘并显示中文目录和文件名

Windows系统文件名中英文对照表

下载中文文件名乱码问题

文件下载中文名称乱码问题

第三章中文文字处理软件Word