Memset 用来对一段内存空间全部设置为某个字符，一般用在对定义的字符串进行初始化为‘ ’或‘\0’；

主要应用是初始化某个内存空间

例:char a[100];memset(a, '\0', sizeof(a));

memset可以方便的清空一个结构类型的变量或数组。

如：

struct sample_struct
{
 char   csName[16];
 int    iSeq;
 int    iType;
};

对于变量
struct sample_strcut  stTest;

一般情况下，清空stTest的方法：

stTest.csName[0]='\0';
stTest.iSeq=0;
stTest.iType=0;

用memset就非常方便：
memset(&stTest,0,sizeof(struct sample_struct));

如果是数组：

 struct sample_struct   TEST[10];
则
memset(TEST,0,sizeof(struct sample_struct)*10);

memcpy 用来做内存拷贝，你可以拿它拷贝任何数据类型的对象，可以指定拷贝的数据长度。

memcpy是用于copy源空间的数据到目的空间中
例：char a[100],b[50]; memcpy(b, a, sizeof(b));注意如用sizeof(a)，会造成b的内存地址溢出。

Strcpy   就只能拷贝字符串了，它遇到'\0'就结束拷贝。

例：char a[100],b[50];strcpy(a,b);如用strcpy(b,a)，要注意a中的字符串长度（第一个‘\0’之前）是否超过50位，如超过，则会造成b的内存地址溢出。

strcpy用于字符串copy,遇到‘\0’，将结束

1：神马是Dll和Lib，神马是静态链接和动态链接

大家都懂的，DLL就是动态链接库，LIB是静态链接库。DLL其实就是EXE，只不过没main。

动态链接是相对于静态链接而言的。所谓静态链接就是把函数或过程直接链接到可执行文件中，成为可执行程序中的一部分，当多个程序调用同样的函数时，内存里就会有这个函数的多个拷贝，浪费内存资源。而动态链接则是提供了一个函数的描述信息给可执行文件（并没有内存拷贝），当程序被夹在到内存里开始运行的时候，系统会在底层创建DLL和应用程序之间的连接关系，当执行期间需要调用DLL函数时，系统才会真正根据链接的定位信息去执行DLL中的函数代码。

在WINDOWS32系统底下，每个进程有自己的32位的线性地址空间，若一个DLL被进程使用，则该DLL首先会被调入WIN32系统的全局堆栈，然后通过内存映射文件方式映射到这个DLL的进程地址空间。若一个DLL被多个进程调用，则每个进程都会接收到该DLL的一个映像，而非多份的拷贝。但，在WIN16系统下，每个进程需要拥有自己的一份DLL空间，可以理解为何静态链接没啥区别。

2：DLL和LIB区别和联系。

DLL是程序在运行阶段才需要的文件。

LIB是程序编译时需要链接的文件。

DLL只有一种，其中一定是函数和过程的实现。

LIB是有两种。若只生成LIB的话，则这个LIB是静态编译出来的，它内部包含了函数索引以及实现，这个LIB会比较大。若生成DLL的话，则也会生成一个LIB，这个LIB和刚才那个LIB不同，它是只有函数索引，没有实现的，它很小。但是这俩LIB依然遵循上个原则，是在编译时候是需要被链接的。若不链接第一个LIB的话，在程序运行时会无法找到函数实现，当掉。若不链接第二个LIB的话，在程序运行时依然会无法找到函数实现。但第二种LIB有一种替代方式，就是在程序里，使用LoadLibrary,GetProcAddress替代第二个LIB的功能。第一种LIB生成的EXE文件会很大，因为LIB所有信息被静态链接进EXE里了。第二种LIB生成的EXE文件会比较小，因为函数过程实现依旧在DLL内。

（啰嗦了一堆，某志希望大家能够明白两个LIB的区别。要再不行的话，我们可以将静态编译的LIB称为 静态链接库。但动态编译的LIB称为 引入库。可能会比较好一些。）

静态链接LIB的优点是免除挂接动态链接库，缺点是EXE大，版本控制麻烦些。

动态链接DLL的优点是文件小，版本更换时换DLL就好了，缺点是多了点文件。动态链接若是被多个进程使用，会更加方便和节省内存。

3：为什么编译DLL时总会同时生成一个LIB？这个LIB有用吗？

若我们不是用静态链接，而使用DLL，那么我们也需要一个LIB，这个LIB的作用是被链接到程序里，在程序运行时告诉系统你需要什么DLL文件。这个LIB里保存的是DLL的名字和输出函数入口的顺序表。它是有意义的。

当然，若我们的应用程序里不链接这个LIB，则可以使用LoadLibrary,GetProcAddress来告诉系统我们在运行时需要怎么着DLL以及其内的函数。

4：DLL意义。

1：DLL真正实现了跨语言。各种语言都可以生成DLL，而对系统以及应用程序来说，哪种语言生成的DLL是没有区别的。

2：DLL有足够的封装性，对于版本更新有很大好处。因为DLL是运行期间才会使用，所以，即使DLL内函数实现有变化（只要参数和返回值不发生变化），程序是不需要进行编译的。大大提高了软件开发和维护的效率。

3：DLL被多个进程使用，因为有内存映射机制，无需占用更多内存。

5：创建DLL。（注意：某志就不再讲解使用MFC AppWizard[dll] 方式创建DLL了。有兴趣的自己去百度。这里创建DLL只指使用Win32 Dynamic-link Library创建Non-MFC DLL。呃，DLL的三种类型就不解释了，依旧那句话：百度一下你就知道。）

每个应用程序必须有一个main或者winmain函数作为入口，DLL一样，有自己的缺省的入口函数，就是DllMain。函数如下

BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved)
{
 switch (ul_reason_for_call)
 {
 case DLL_PROCESS_ATTACH:   // 进程被调用
 case DLL_THREAD_ATTACH:     // 线程被调用
 case DLL_THREAD_DETACH:   // 线程被停止
 case DLL_PROCESS_DETACH:  // 进程被停止
  break;
 }
 return TRUE;
}

一般情况下，我们不需要对这个缺省的入口函数进行什么修改，它就会使动态链接库得到正确的初始化。但是，当我们的DLL需要额外分配内存或者资源的时候，或者，DLL希望对调用自己的进程或线程进行初始化或清除的额外操作时，可以在上述代码case中加一些自己感冒的东东。（懒……不想细写了- -Orz，现在是晚上2点了，明天还一堆的事情）

DLL对于导出类和导出函数没啥不同。只要加上 __declspec( dllexport ) 修饰函数或者类就好了。

但是有查看过DLL代码的人员都会经常见到这么一段代码

#ifdef FK_DLL_EXPORTS

#define FK_DLL __declspec( dllexport )

#else

#define FK_DLL __declspec( dllimport )

#endif

意义很明显，但是，问题是  FK_DLL_EXPORTS 这个宏是应该在哪儿定义呢？在DLL项目内，还是在使用DLL的应用程序内？

这点某志曾迷糊很久，呵呵~其实后来想想，还是蛮明确的。export是导出。import是导入。对于DLL来说，是要导出这些函数给其他应用程序使用的，所以应当定义 FK_DLL_EXPORTS 宏。对于使用DLL的应用程序来说，是导入，是无需定义的。

使用时候也很简单。

class FK_DLL CMyDllClass{} ;

则整个类被导出。

FK_DLL void MyTestFun( int a );

则该函数被导出。

但是有时我们可以见到这样的代码

extern "C" FK_DLL void MyTestFun2( float b );

其中extern "C"的原理就是标示该函数要求以C形式去进行编译，不要以C++形式去编译。具体的编译原理就不罗嗦了，简而言之，被extern "C"定义函数，可以被C以及其他语言进行DLL调用，而未被extern "C"定义的函数，C是无法访问DLL中这个函数的。

在VS中开发DLL还有一种方式，使用.def文件。

新建个文本文档，改后缀为FKDll.def，加入到工程里。

FKDll.def里加入以下代码

LIBRARY FKDll

EXPORTS

MyTestFun@1

MyTestFun2@2

就可以了。其中，LIBRARY语句是说明.def文件是属于FKDll这个Dll的。EXPORTS下面是我们需要导出的函数名。后面加的@+数字，是表示导出函数的顺序编号。这样就足够了。（详细的自己百度，好困，zzzZZZ）

6：使用DLL

使用DLL有两种方式。显式链接和隐式链接。

隐式链接很容易。直接#progam comment(lib, "FKDll.lib") 就可以。当然，也可以在项目工程->属性->链接库里加上库和路径（相对路径和绝对路径都可以）。

显式链接则麻烦些。在程序中使用LoadLibrary加载DLL，再GetProcAddress获取函数实现，在程序退出之前，调用FreeLibrary来动态释放掉链接库。

‍例如：

void Main()

{

     typedef void (*FKDllFun1)(int a);

    FKDllFun1 pFun1;

    HINSTANCE hDLL  = LoadLibrary("FKDll.dll");   // 若hDll为空则读取Dll失败。

    pFun1 = (pFun1)GetProcAddress(hDll, "MyTestFun1" );   // 从应用程序中的DLL镜像中获取名为 MyTestFun1 的函数指针

    pFun1( 100 );

    FreeLibrary(hDll);

}

当然，我们刚才.def里面还指定了导出函数的导出顺序，那么我们可以修改里面获取函数指针那一段为

‍pFun1 = (pFun1)GetProcAddress(hDll, MAKEINTERSOURCE(1) );  // 1 是刚才指定的MyTestFun1函数导出顺序编号。

这样可以更快，但是别将编号记混了，会导致诡异的错误。

7：比较显式链接和隐式链接。

可能的话，尽量使用显式链接。

显式链接可以在程序执行时动态的加载DLL和卸载DLL文件，隐式链接是做不到的。

显式链接LoadLibrary，GetProcAddress时能获知是否加载失败，我们可以对其进行检查错误处理。而显式链接可能是一个很恶劣的提示或是程序崩溃的结果。

对于有些Ex类型的加强函数，显式链接可以允许我们找到替代方案。也包括选择D3d9.dll和OpenGL.dll时也可采用同样处理。

例如：

if( GetProcAddress( hDll, "FKDllFunEx") == NULL )

{

‍    pFun = GetProcAddress( hDll, "FKDllFun");    // 然后使用pFun进行处理

}

8：导出类和导出函数

类和函数的导出方式上面给出了说明，原本极其类似的。

我们说下使用导出类。

若我们隐式的使用了一个导出类，则我们在应用程序里继承它的时候，就如同该类就在应用程序代码里一样，无需任何处理。

例如：

class FK_DLL CMyDllClass{} ;    // Dll文件内的代码

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

class CAppClass : public CMyDllClass      // 应用程序内代码，无需做任何处理。

{

       ....

}

也可以直接使用DLL导出类

void main

{

     CMyDllClass* pClass = new CMyDllClass ();

}

但是，若应用程序声明或者分类一个DLL中导出类的对象时会存在一个很讨厌的问题：这个操作会使内存跟踪系统失效，使其错误的报告内存分配和释放情况。

为解决这个问题，我们可以给出两个接口函数对DLL导出类进行创建销毁支持，就可以使内存跟踪系统正常了。例如

class FK_DLL CMyDllClass{} ; 

额外增加俩函数

FK_DLL CMyDllClass* CreateMyDllClass(){ return new CMyDllClass(); }

FK_DLL void DestoryMyDllClass( CMyDllClass* p_pClass ){ delete p_pClass; }

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

上面的方法可以正确进行内存跟踪了，但是，因为DLL导出类CMyDllClass依旧是导出的状态，用户同样可以跳过我们提供的接口直接使用。那么怎么办呢。方法是不再对类进行DLL导出，而对类内的函数全部进行DLL导出即可，

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

但是若仅仅提供上面两个接口函数以及类内全部函数，的确功能可以实现，却无法进行类继承了。若这个类继承很重要，必须开放，那么就需要使用新的内存跟踪程序替换应用程序内的原有内存跟踪程序。或者使用下面的一个方法。（见模块9：复杂问题）

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

同样，我们也可以发现，在不导出DLL类本身，而只导出DLL类内函数也有一些好处，一些我们不希望外界知道的函数可以不设置导出标记，这进一步保护了DLL内函数的安全性。

9：复杂问题。

若我们使用LoadLibrary显式加载一个DLL，并尝试在应用程序中调用一个类内成员函数的话，无论该函数是否在头文件中有声明，VS会给出一个"unresolved external symbol（未解析的外部符号）"的错误。我们此时可以将项目属性中的内联函数扩展选项修改为"Only __inline"或"Any Suitable"即可。但，我们可能在调试连编的时候期望关闭内联函数扩展，那么另一种解决方案是，将希望导出的函数声明为虚函数，例如

class CMyDllClass

{

   FK_DLL virtual void MyTestFun( int a ){  dosth(); }  

   // 用上面代码替换 FK_DLL void MyTestFun( int a ){  dosth(); }  

}

这样做还有一个额外的好处。将导出的类成员函数设置为虚函数之后，该虚函数所在的类在应用程序中也如同被声明一样，可以接受继承。

例如若是上面的做法，应用程序就可以进行顺利继承，而不必要求CMyDllClass 被标示为导出。（原理不知，希望精通底层的高手协助解释。）

class CAppClass : public CMyDllClass      // 应用程序内代码，无需做任何处理。

{

       ....

}

 见到这两个符号的很多不同的用法，整理在一起

宏中"#"和"##"的用法

一、一般用法

我们使用#把宏参数变为一个字符串,用##把两个宏参数贴合在一起.

用法:

#include<cstdio>

#include<climits>

using namespace std;

#define STR(s)   #s

#define CONS(a,b) int(a##e##b)

int main()

{

 printf(STR(vck));       // 输出字符串"vck"

 printf("%d\n", CONS(2,3)); // 2e3 输出:2000

 return 0;

}

二、当宏参数是另一个宏的时候

需要注意的是凡宏定义里有用'#'或'##'的地方宏参数是不会再展开.

1, 非'#'和'##'的情况

#define TOW     (2)

#define MUL(a,b) (a*b)

printf("%d*%d=%d\n", TOW, TOW, MUL(TOW,TOW));

这行的宏会被展开为：

printf("%d*%d=%d\n", (2), (2), ((2)*(2)));

MUL里的参数TOW会被展开为(2).

2, 当有'#'或'##'的时候

#define A       (2)

#define STR(s)   #s

#define CONS(a,b) int(a##e##b)

printf("int max: %s\n", STR(INT_MAX));   // INT_MAX #include<climits>

这行会被展开为：

printf("int max: %s\n", "INT_MAX");

printf("%s\n", CONS(A, A));           // compile error

这一行则是：

printf("%s\n", int(AeA));

A不会再被展开, 然而解决这个问题的方法很简单. 加多一层中间转换宏.

加这层宏的用意是把所有宏的参数在这层里全部展开, 那么在转换宏里的那一个宏(_STR)就能得到正确的宏参数.

#define A       (2)

#define _STR(s)   #s

#define STR(s)     _STR(s)       // 转换宏

#define _CONS(a,b) int(a##e##b)

#define CONS(a,b)   _CONS(a,b)     // 转换宏

printf("int max: %s\n", STR(INT_MAX));       // INT_MAX,int型的最大值，为一个变量 #include<climits>

输出为: int max: 0x7fffffff

STR(INT_MAX) --> _STR(0x7fffffff) 然后再转换成字符串；

printf("%d\n", CONS(A, A));

输出为：200

CONS(A, A) --> _CONS((2), (2)) --> int((2)e(2))

三、'#'和'##'的一些应用特例

1、合并匿名变量名

#define ___ANONYMOUS1(type, var, line) type var##line

#define __ANONYMOUS0(type, line) ___ANONYMOUS1(type, _anonymous, line)

#define ANONYMOUS(type) __ANONYMOUS0(type, __LINE__)

例：ANONYMOUS(static int); 即: static int _anonymous70; 70表示该行行号；

第一层：ANONYMOUS(static int); --> __ANONYMOUS0(static int, __LINE__);

第二层：                 --> ___ANONYMOUS1(static int, _anonymous, 70);

第三层：                 --> static int _anonymous70;

即每次只能解开当前层的宏，所以__LINE__在第二层才能被解开；

2、填充结构

#define FILL(a)   {a, #a}

enum IDD{OPEN, CLOSE};

typedef struct MSG{

IDD id;

const char * msg;

}MSG;

MSG _msg[] = {FILL(OPEN), FILL(CLOSE)};

相当于：

MSG _msg[] = {{OPEN, "OPEN"},

        {CLOSE, "CLOSE"}};

3、记录文件名

#define _GET_FILE_NAME(f)   #f

#define GET_FILE_NAME(f)   _GET_FILE_NAME(f)

static char FILE_NAME[] = GET_FILE_NAME(__FILE__);

4、得到一个数值类型所对应的字符串缓冲大小

#define _TYPE_BUF_SIZE(type) sizeof #type

#define TYPE_BUF_SIZE(type)   _TYPE_BUF_SIZE(type)

char buf[TYPE_BUF_SIZE(INT_MAX)];

 --> char buf[_TYPE_BUF_SIZE(0x7fffffff)];

 --> char buf[sizeof "0x7fffffff"];

这里相当于：

char buf[11];

一、目录表（TOC）与分卷（Volume）

抛开压缩算法不谈，我认为zip、rar在文件格式上最大的差异就在目录表（Table of Contents，TOC）：zip有TOC，而rar没有。

TOC这个词其实是从出版界借用过来的，指的就是每一本书正文前面的“目录”，它的作用地球人都知道：如果想快速找到书中某一内容，可以先查TOC，然后按照TOC指明的页码直接翻即可。

在纸质书里TOC是印刷出来的一张表，而在电子文件里则是由结构化数据构成的一张表，它的目的同样是为了快速定位：如果想找文件中的某一内容，可以先查TOC，知道感兴趣的内容在文件的什么位置，直接跳过去就行了。最常见的运用就是avi、rm等多媒体文件：播放的时候经常有人在播放条上点来点去跳着看（即“随机访问”），如果没有TOC，在长达几百兆的文件里来回定位会慢死。

具体到zip文件里，TOC是放在文件尾部的一张表，里面列出了zip包中每一个文件的属性（文件名、长度等）和在zip包中的存放位置。如果需要随机访问zip包中的某一个文件，只需在TOC里找到这个文件的存放位置，直接跳过去即可。

而RAR文件里则没有TOC，在文件头之后所有文件按顺序连续存放。

这种差异造成的结果就是：随机访问时zip比rar快，而顺序访问时rar比zip快。

所谓随机访问，就是前面说过的随机访问压缩包中某个指定的文件。举一个简单的例子：一本反编译或下载到的网页电子书，有大量HTML、图像、css、js，然后打成压缩包。现在要求在不解包的情况下访问其中的页面：可以想象，打开每个HTML页面的时候，它所附带的图像、css、js等文件可能随机分布在整个压缩包里，如果没有TOC，查找每个文件的时候都要从头开始找，将会有多慢。 所以各位可以理解为什么jar包就是标准zip包，而我也只用zip格式保存反编译出来的电子书、漫画、PDG书等一切可能需要随机访问的东西。

所谓顺序访问，就是将整个压缩包从头解到尾。在这方面RAR具有天然的优势。而且为了节省WinRAR列文件的时间，对于单个RAR我一般都直接通过右键菜单解压缩，很少双击压缩包打开再解压。解多个RAR时当然都用BatchUnRar。

由于rar的原作者已经去世，造成这种差异的确切原因我相信已不可考，但我个人猜测可能与DOS时代的备份软件之争有关：在DOS时代，电脑硬盘不像现在这样奢侈，20MB就算很大了。这样的容量用两盒软盘 即可备份，备份成本相对数据本身的价值来说非常低廉。因此在DOS时代，很多公司和机构都制定有定期硬盘备份政策，以免因为人为或非人为的因素 （早期硬盘可没有如今可靠）而造成不可挽回的数据损失。在备份软件方面，虽然微软已经随DOS提供了Backup/Restore工具，但是他们基本不具备数据压缩能力，因此在压缩软件中提供备份功能，就成为DOS时代的一个时尚。由于DOS时代的备份介质多为软盘，因此压缩 软件的备份功能其实就转化成如今很常见的一个功能：分卷压缩功能，即按照软盘容量进行分卷压缩，然后将分卷压缩文件备份（Backup）到软盘，需要的时候再解压，或恢复（Restore）到硬盘。

DOS时代最有名的zip工具是pkzip，出现得比DOS版的RAR早。在分卷压缩时，pkzip按照zip文件规范，将TOC存放在最后，即存储在最后一卷，由此带来如下问题：

1、恢复时，每解压一张盘，都要先将最后一张盘插进去一次，读一次TOC。
2、只要最后一张盘上的TOC坏了，就算其它盘都是好的，也不能正常解压。

这两个缺点，尤其是第一个缺点实在是太臭名昭著了，因此当时出现了非常强烈的改革呼声。在这个关键时刻，DOS版的RAR出现了：不仅压缩率比pkzip高（这点在DOS时代非常重要，毕竟软盘又贵容量又小），而且由于吸取了当时对zip格式的批评，取消了TOC，因此：

1、在恢复分卷压缩的备份文件时，不需要频繁插入带有TOC的分卷，按顺序换盘即可。
2、即使某个分卷损坏，也可以跳过，从完好的分卷再开始解压。

由于这些原因（当然还有其它原因），RAR推出后迅速取得了成功，pkzip在DOS时代就开始流失用户，到Windows时代基本消声匿迹。在Windows时代推出的Winzip，则彻底放弃了分卷压缩功能（zip格式永远的痛？）。 而从我看到的源自WinRAR的UnRAR源代码来看，现在WinRAR的解压思路明显还是把文件按顺序从头解到尾，看来当年备份/恢复工具之争的影响，还真是深远。

二、固实（solid）压缩方式

在压缩算法方面，我觉得rar格式最特色的是固实（solid）压缩方式。WinRAR v3.42的帮助文件中对固实压缩的说明如下：

固实压缩文件是 RAR 的一种特殊压缩方式存储的压缩文件，它把压缩文件中的全部文件都当成一个连续数据流来看待。

这段说明其实揭示了固实压缩格式能够提高压缩比的奥秘：数据压缩的基础是“重复”，例如aaaabbb这个字符串，里面就有重复，如果表示为a4b3，看起来是不是变短了？这就是“数据压缩”。“重复”是一个具有相对意义的概念，在某一范围内看起来没有重复，或重复不多的数据，把范围扩大，说不定就能找到更多重复的数据了，这就是固实压缩的奥秘。

举一个简单的例子：用zip和普通rar压缩一堆jpg文件，很难压下去，但是用固实压缩方式的rar就可以，其原因就在于：jpg文件本身已经是压缩格式了，单个jpg文件里很难再 找到可利用的重复数据，因此不论是用zip还是普通的rar都很难再压缩，因为他们都将需要压缩的文件分隔开来一个一个处理。但是对于固实rar来说，是将 所有需要压缩的jpg文件当作一个整体来压缩，这些jpg之间就存在重复的数据，如他们都有相同的文件头（其中包括各种数据表）等，这就出现了可压缩的空间。从我看到的资料来看，Flash文件也采用了类似的技术对jpg进行压缩：如果在Flash文件中使用了多个jpg文件，它们可以共用一个文件头。

当然天下不会有白吃的午餐，固实压缩方式在提高压缩比的同时，也有一些限制，在WinRAR v3.42帮助文件中的说法是：

固实压缩可增加压缩性能，特别是在添加大量的小文件的时候，但它也有一些重要的不利因素:

• 对已存在的固实压缩文件更新时较慢；
• 要从固实的压缩文件解压单个文件时，它之前的文件都需先经过分析。这造成当从固实的压缩文件内取出文件时会比一般压缩文件取出文件慢一些。但是，当从固实的压缩文件解压全部的文件时，解压速度并没有影响。
• 如果在固实压缩文件中的任何文件损坏了，要从损坏的范围中解压全部的文件是不可能的。因此，如果固实压缩文件是保存在例如软盘等媒介时，推荐你在制作时使用“恢复记录”。

固实压缩的适用场合为:

• 压缩文件很少更新的时候;
• 不需要经常从压缩文件中解压一个文件或是部分文件的时候;
• 压缩效率比压缩速度更为重要的时候。

与前面说的“随机访问”对应，固实压缩的RAR文件可能是世界上最不适合随机访问的：如果需要访问固实RAR包中的某个文件，就要从文件头开始解压，一直解到这个文件。

三、安全性

这里的安全性包含几个方面的含义：文件系统安全性、密码保护安全性和文件数据安全性。

由于制订zip格式规范的时候操作系统本身的文件安全性还没有引起足够的重视，因此zip格式只记录最基本的文件属性，包括只读属性等，没有其它附加的安全属性。

rar格式刚推出的时候，文件系统的安全性只能参照DOS，和zip差不多。但是rar毕竟是一种封闭的格式，想怎么改作者一个人说了就算，因此当Windows中出现NTFS，并且引入扩展的文件系统安全属性时，rar也积极跟进，所以现在应该说rar格式在这方面比zip强 。

在zip和rar格式中均提供了密码保护功能，但是密码保护的安全强度不同。

zip由于格式开放、代码开源，因此zip密码破解软件出现得比较早，也比较多。初期以暴力破解为主，威胁不大，真正对zip密码安全的致命一击是known plain text（已知明文）攻击法：如果知道加密zip文件中某段内容（密文，ciphertext）解密后的真正内容（明文，plain text），就可以反推出zip加密口令。在这种攻击方法的威胁，及某些国家的法律对密码技术的限制下， 著名开源组织zlib宣布永久放弃对加密zip的支持，详见zlib网站上的相关说明（不过在zlib发行的源代码里仔细找找，还是能找到原来的加/解密相关代码）。

记得rar刚推出的时候也和zip一样，虽然不能列出加密文件中的文件内容，但可以列出加密文件中的文件名。后来大概也是被known plain text攻击法吓到了，增加了一个“加密文件名”选项，干脆连加密rar文件里有哪些文件都看不见，让攻击者想猜明文都无从猜起。

rar格式比zip晚推出，在安全方面吸取了足够的教训，因此采用的是美国国家标准与技术局（National Institute of Standard and Technology, NIST）推荐的、目前公认安全程度比较高的AES对称加密算法 ，密钥长度128位。在ASE被攻破以前（NIST认为30年内无法攻破），大家都只能在暴力法上兜圈子，所以密码安全性应该说比zip高。对此WinRAR 3.42的帮助文件是这样描述的：

ZIP 格式使用私有加密算法。 RAR 压缩文件使用更强大的 AES-128 标准加密。如果你需要加密重要的信息，选择 RAR 压缩文件格式会比较好一些。为了确实的安全性，密码长度请最少要 8 个字符。不要使用任何语言的单词作为密码，最好是任意的随机组合字符和数字，并且要注意密码的大小写。请记住，如果你遗失你的密码，你将无法取出加密的文件，就算是 WinRAR 的作者本身也无法解压加密过的文件。

在数据安全性方面，RAR格式本身支持一种特殊的附加信息类型，叫做“恢复记录”。如果RAR文件有恢复记录，在介质物理损坏或其它原因造成数据丢失时，WinRAR可以按照“恢复记录”尝试对数据进行修复。而zip格式无恢复记录，因此在数据安全性方面应该说比RAR弱。

虽然RAR文件本身支持恢复记录，但是在WinRAR里此选项缺省是关闭的，而打开后会导致压缩出来的RAR文件体积增加（增加的百分比与设置有关），可能会令某些人感到不习惯（我就亲眼见到有人在论坛上抱怨为什么压出来的RAR文件会如此庞大），所以这个功能基本上形同虚设。

四、开放性

开放性的对比很明显：zip格式不仅文件格式完全公开，而且有专门的开源组织提供操作源代码，跨平台使用也没有多大限制；rar格式完全保密，作者只提供解压所需源代码，不提供压缩所需源代码 ，跨平台使用有点麻烦。

zip开源组织中，最出名的是zlib和InfoZip，二者各有侧重：zlib偏重对内存缓冲区的压缩，因此被png等开源组织用做内部压缩算法，连java的jar程序内核都来自zlib，打出来的jar包自然也是一个标准的zip文件；InfoZip偏重对文件的操作 （包括口令保护），应用似乎不如zlib广泛，但我个人觉得其实它还是满好用的，前提是需要对它的源代码进行一些必要的修改。

在png组织的网页中有说到png格式的来历，我觉得也很有意思：做png的一班人，其实原来都是做gif格式的，但是由于Unisys公司开始对gif格式的核心——LZW压缩算法征收专利费，这帮人怒了，干脆提出png格式：大结构方面还是采用分段结构，但是核心压缩算法采用开源的zlib，压缩 效果在多数情况下比gif的LZW更强。由于没有版权限制，在静态图形领域png得到广泛应用，如果不是及时提出动画支持并因此在web上大行其道，我估计gif早就死掉了。

RAR的解压源代码在其官方网站www.rarlab.com上提供，通常比WinRAR的正式版本晚一点，不过据说是直接从WinRAR的源代码中抠出来的，所以兼容性应该没有什么问题。

五、结论

以下观点纯属个人观点，仅供参考，不具有如何指导意义：

• 如果经常需要对压缩包进行随机访问，应该选zip而不是rar。虽然将下载到的rar重新压缩成zip会麻烦一次，但是以后会减少无数的麻烦。
• 如果需要分卷压缩（如某些网站对上传文件大小有限制），则只能用rar。事实上，这也是我唯一会使用rar格式的场合，其它时候一律zip没商量。

1char c;
2while((c = getchar()) != EOF){
3    putchar(c);
4}
5

输入值：abc后面跟个回车
本以为屏幕应该显示
a
a
b
b
c
c

实际上是:
abc
abc

这是因为只有当输入回车时，系统才认为是输入完毕

2.上面的代码还有一个问题
因为EOF是-1，所以c=getchar()这一句会出现问题
所以c应该是int c

二、EOF

只有在新的一行输入的时候输入EOF才算是文件结束符
假设输入：
abc^zqwer
输出为：
abc