[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","root",{"_11":-5,"_69":70,"_71":72,"_73":74},"routes/user.$name.collections",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20},"topics",[36,37],"user",{"_21":22,"_13":14,"_23":24,"_25":26,"_27":28,"_29":30,"_31":16,"_32":33,"_34":35},"loginname","jackliu8722","page",1,"limit",20,"total",2,"id","3543","avatar_url","http://www.gravatar.com/avatar/4fed4059108076c003bcac779fbd62ac?size=48","githubUsername","","create_at","2012-04-25T12:15:20.409Z","score",25,"topic_count","reply_count",4,"is_star",false,{"_21":58,"_39":59,"_41":-5,"_42":60,"_44":61,"_46":62,"_48":35,"_49":35,"_32":63,"_51":64,"_27":65,"_54":66},{"_21":38,"_39":40,"_41":-5,"_42":43,"_44":45,"_46":47,"_48":35,"_49":35,"_32":50,"_51":52,"_27":53,"_54":55},"28","author_id","1631","tab","content","

前言

\r\n
最近在研究nodejs如何实现文件上传功能，偶然读到《nodejs-post文件上传原理详解》这篇教程，感觉非常给力。教程中详细解读了post数据格式，以及通过分析node-formidable模块的源代码来解读文件上传的原理。\r\n
\r\n
可是，在源码分析的过程中，作者并没有解释得很到位，从而导致在看完整篇教程后某些地方还有些云里雾里，在潜心研究一番后，终于明了，然而这也催生了我写这篇文章的想法。\r\n
\r\n
由于该文章是在上文所提教程的基础之上补充的，因此，建议读之前先看以上教程。\r\n

详解post数据的格式

\r\n
使用post提交表单后，传递过来的数据到底是什么样的呢？\r\n
\r\n
上篇教程中已经讲解过，可是，为了使之能更好地与后面的数据解析部分的代码相结合，我对Post数据进行了一个详细的标注\r\n

HTML

\r\n

 \r\n
    \r\n
     What is your name? 
\r\n
\t What files are you sending? 
\r\n
\t \r\n
  
\r\n

\r\n

该html中有一个表单，其中包含了一个text文本框和一个file多文件上传控件。

\r\n
\r\n

POST HEADER

\r\n
$\"post_header\"$ \r\n
\r\n
这是Post的header信息，请注意Content-Type后面的boundary数据，这就是边界字符串，用于分隔每个字段数据。\r\n

POST DATA

\r\n
$\"POST_DATA\"$ \r\n
\r\n
上图便是传递过来的POST数据部分，图中对各部分已经作了详细的表示，每一行其实隐含着一个\\r\\n（CR LF）。上面提到的教程中其实已经总结过POST数据的规则，这里再总结一次：\r\n

每一部分数据包括字段部分和数据部分，比如文本框数据，字段部分是ContentPosition，数据部分是huli;字段部分和数据部分使用一个空行分隔；每一行后面实际隐含这一个\\r\\n（CR LF）

每一部分数据以边界字符串分隔，假设post_header中定义的边界为Aa03x，那么一般的边界字符串为--Aa03x\\r\\n（程序中称这样的边界字符串为PART_BOUNDARY,表示后面还有数据需要解析），最后面的边界字符串为--Aa03x--（程序中称这样的边界字符串为LAST_BOUNDARY，表示所有的数据都解析完毕）

在每一部分数据中，数据部分（记得前面提到过的，每一部分数据包括字段部分和数据部分吗？）是和接下来的边界字符串紧挨在一起的！

\r\n
\r\n
\r\n
更加详细的信息可参考W3C文档的FORMS\r\n

POST数据解析流程

\r\n
模块中将POST数据的解析分成多个不同的状态，接着它会遍历buffer中每个字符的状态，进行相应的处理。这些状态分为：\r\n

PARSER_UNINITIALIZED：系统尚未初始化

TART：开始解析

START_BOUNDARY：开始解析边界字符串

HEADER_FIELD_START：解析HEADER_FIELD前的预处理

HEADER_FIELD：开始解析HEADER_FIELD

HEADER_VALUE_START：解析HEADER_VALUE前的预处理

HEADER_VALUE：开始解析HEADER_VALUE

HEADER_VALUE_ALMOST_DONE:header_value部分解析完毕

HEADERS_ALMOST_DONE：所有的header解析完毕

PART_DATA_START：解析数据段前的预处理

PART_DATA：开始解析数据段

ART_END：数据段解析完毕

END:所有的POST_DATA解析完

\r\n
结合POST_DATA中的图示来看这些状态，注意：状态的流转是从上到下的。\r\n

源码详解

\r\n
下面，我会按照文件上传的原理把整个流程重新走一遍，以便大家更加理解。其中，我会省略一些源码中对本篇文章来说并不太需要的部分，比如容错处理等等。首要工作是进行一些基本模块的引入\r\n

var http=require('http'),\r\n
    fs=require('fs'),\r\n
\tpath=require('path'),\r\n
\tStringDecoder = require('string_decoder').StringDecoder,\r\n
\tEventEmitter = require('events').EventEmitter,\r\n
\tutil=require('util');

\r\n

//首先创建一个服务器\r\n
http.createServer(function(request,response){\r\n
\t//处理文件上传:TODO\r\n
}).listen(8080);\r\n
\r\n
//处理文件上传，首先定义一个用于文件上传的类,用于一些初始化设置\r\n
function IncomingForm(){\r\n
\tif (!(this instanceof IncomingForm))\r\n
\t{\r\n
\t\t return new IncomingForm();\r\n
\t}\r\n
\tEventEmitter.call(this);//使对象可以调用事件函数\r\n
\r\n
\tthis.maxFieldsSize=2*1024*1024;//设定最大文件限制\r\n
\tthis.upLoadDir='/tmp';//设定上传文件路径\r\n
\tthis.encoding=\"utf-8\";//设定文件的编码\r\n
\tthis.headers=null;//post数据的头部信息，可以使用request.headers获得\r\n
\tthis.type=null;\r\n
\r\n
\tthis.bytesReceived=null;//收到的字节数\r\n
\tthis.bytesExpected=null;//预计的字节数，一般只有最终收到的字节数等于预计的字节数，传输才是正确的，否则，传输出错\r\n
\r\n
\tthis._parser=null;//用于初始化处理post数据的类，等下会定义，类名为multipart_parser.js\r\n
\tthis.filedsSize=0;\r\n
}\r\n
\r\n
util.inherits(IncomingForm,EventEmitter);\r\n
exports.IncomingForm=IncomingForm;//导出

\r\n

//我想用过node-formidable的童鞋都应该知道parser这个方法的重要性，没错，他正是上传文件模块的入口\r\n
//它有两个参数，第一个是request对象（大家都懂的），另一个就是一个自定义的回调函数cb\r\n
IncomingForm.prototype.parser=function(req,cb){\r\n
\t//定义两个函数，用于请求的暂定和继续。由于前一篇文章已经提到过，node-formidable是采用边接收边解析的方式\r\n
\t//而接收到的文件数据往往先存放到buffer缓冲区，然后再写入指定路径的文件之中。。因此，在写文件的过程中，最后先\r\n
\t//暂定请求（req.pause），等文件写入完毕，再继续请求（req.resume）,这是为了避免文件数据传输速度快于写入速度而导致\r\n
\t//缓冲区溢出，从而使得数据丢失\r\n
\tthis.pause=function(){ req.pause();};\r\n
\tthis.resume=function(){ req.resume();};\r\n
\tthis.writeHeaders(req.headers);//存储Post头部信息，因为要使用其中的content-type字段来判断传输的是字符串还是文件，稍后会定义\r\n
\r\n
\tvar self=this;\r\n
\t//对这个我想大家不会陌生，由于传输的数据是分包的，而并非所有的数据一齐全部传过来，因此，没接收到一部分数据，就会触发一次\r\n
\t//data事件\r\n
\treq.on('data',function(buffer){\r\n
\t\tself.write(buffer);//用于处理传过来的数据\r\n
\t});\r\n
\t//如果定义了回调\r\n
\tif (cb)\r\n
\t{\r\n
\t\tvar fields={},files={};\r\n
\t\t//定义一个field事件，当接收到一个完整字段时手动触发，该字段是指非文件字段数据。\r\n
\t\t//比如一个文本框中的值\r\n
\t\tthis.on('field',function(name,value){\r\n
\t\t\tfields[name]=value;\r\n
\t\t});\r\n
\t\t//与上面的事件类似，区别是它只有接受完一个文件数据才手动触发，文件数据都是二进制数据，而字段数据往往是字符串\r\n
\t\tthis.on('file',function(name,file){\r\n
\t\t\tfiles[name]=file;\r\n
\t\t});\r\n
\t\t//由事件名我们可以看出来，end事件是在接受完所有的数据后触发\r\n
\t\t//例：(new IncomingForm()).parse(request,function(error,field,files){\r\n
\t\t//\t         fs.renameSync(files.upload.path,/tmp);用于重命名上传的文件\r\n
\t\t//     })\r\n
\t\tthis.on('end',function(){\r\n
\t\t   cb(null,field,files);\r\n
\t\t})\r\n
\t}\r\n
};

\r\n

//下面就定义刚刚提到的self.write函数，该函数用于处理传过来的数据\r\n
IncomingForm.prototype.write=function(buffer){\r\n
\tthis.bytesReceived+=buffer.length;\r\n
\t//由于处理post数据是个非常复杂的过程，因此，我们把它放在另个模块里来处理，模块名为multipart_parser\r\n
\t//而这里的this._parser就是new mulipartParser()的一个实例化对象\r\n
\tvar bytesParsed=this._parser.write(buffer);\r\n
}

\r\n

//好的，这里先暂定IncomingForm模块的编写，让我们来探究一下神秘的post数据是到底是如何处理的呢\r\n
\r\n
//multipart_parser.js\r\n
var s=0,\r\n
    S={ //定义数据解析的各个阶段\r\n
\t\tPARSER_UNINITIALIZED: s++,\r\n
\t\tSTART:s++,\r\n
\t\tSTART_BOUNDARY:s++,\r\n
\t\tHEADER_FIELD_START:s++,\r\n
\t\tHEADER_FIELD:s++,\r\n
\t\tHEADER_VALUE_START:s++,\r\n
\t\tHEADER_VALUE:s++,\r\n
\t\tHEADER_VALUE_ALMOST_DONE:s++,\r\n
\t\tHEADERS_ALMOST_DONE:s++,\r\n
\t\tPART_DATA_START:s++,\r\n
\t\tPART_DATA:s++,\r\n
\t\tPART_END:s++,\r\n
\t\tEND:s++\r\n
\t},\r\n
\tf=1,\r\n
    //由上图可知，不同的字段数据之间是以边界字符串分隔开的，\r\n
\t//而中间的边界字符串和最终的边界字符串不一样,最终的边界字符串的最后面多了两个'--'，因此，\r\n
\t//F对象的两个属性是为了识别当前的边界是中间的边界（PART_BOUNDARY）还是最后的边界（LAST_BOUNDARY）\r\n
\tF={\r\n
\t\t\tPART_BOUNDARY:f,//用二进制表示为01\r\n
\t\t\tLAST_BOUNDARY:f*=2//用二进制表示为10\r\n
\t},\r\n
\t//每个特殊字符对应的ascaii码\r\n
\tLF=10,\r\n
\tCR=13,\r\n
\tSPACE=32,\r\n
\tHYPHEN=45,//短横杠'-'\r\n
\tCOLON=58;//冒号':'

\r\n

//定义的MultipartParser类，用于一些初始化设置\r\n
function MultipartParser(){\r\n
\tthis.boundary=null;//边界字符串\r\n
\tthis.boundaryChars=null;//一个边界字符串对，字符串中每个字母为它的一个键，值都是true\r\n
\tthis.lookbehind=null;//稍后会讲到，是为了防止错误地识别边界字符串\r\n
\tthis.state=S.PARSER_UNINITIALIZED;\r\n
\r\n
\tthis.index=null;\r\n
\tthis.flags=0;\r\n
}\r\n
\r\n
exports.MultipartParser=MultipartParser;\r\n
\r\n
//该函数用于初始化边界字符串，一般在刚开始的时候调用一次\r\n
MultipartParser.prototype.initWithBoundary=function(str){\r\n
\t//一般，真正的边界字符串会在boundary字段值后另外加四个字母'--\\r\\n'\r\n
\t//例如，boundary=AaB03x，那么中间的边界字符串将会是--AaBo3x\\r\\n,结尾的\r\n
\t//边界字符串是--AaBo3x--,如上图\r\n
\tthis.boundary=new Buffer(str.length+4);\r\n
    //可以看到，代码中把boundary写成\\r\\n--str,与事实--str\\r\\n不相符，这是出于什么考虑呢，在write函数中会有介绍\r\n
\tthis.boundary.write('\\r\\n--','ascaii',0);\r\n
\tthis.boundary.write(str, 'ascii', 4);\r\n
\tthis.lookbehind=new Buffer(this.boundary.length+8);\r\n
\t//初始化为边界字符串后，buffer的解析状态流转为START\r\n
\tthis.state=S.START;\r\n
\r\n
}

\r\n

//这是今天的主角，也是最重要的处理逻辑，还记得IncomingForm模块中德self._write(buffer)吗，没错\r\n
//它实际调用的正是这个函数。\r\n
MultipartParser.prototype.write=function(buffer){\r\n
\t//首先进行一些初始化设置,定义一些局部变量\r\n
\tvar self=this;\r\n
\tlen=buffer.length,\r\n
\tprevIndex=this.index,\r\n
\tindex=this.index,\r\n
\tstate=this.state,\r\n
\tflags=this.flags,\r\n
\tlookbehind=this.lookbehind,\r\n
\tboundary=this.boundary,\r\n
\tboundaryChars=this.boundaryChars,\r\n
\tboundaryLength=this.boundaryLength,\r\n
\t//刚开始一直不明白为什么定义一个boundaryEnd,不过看到后面的代码，再自己琢磨一会，终于弄明白鸟\r\n
\tboundaryEnd=boundaryLength-1,\r\n
\tbufferLength=buffer.length,\r\n
\tc,\r\n
\t//这个函数在上面提到的文章中也有讲过，实际上就是作一个起点标识的。。\r\n
\t//比如，我现在字段数据（headerField）读取完毕，要开始读字段值（headerValue）数据,那么我便使用一个mark('headerValue')来作一个\r\n
\t//字段值数据的起点标识,存储我是从哪一个字符开始读取字段值的\r\n
\tmark=function(name){\r\n
\t\tself[name+'Mark']=i;\r\n
\t},\r\n
\t//顾名思义，该函数的作用是为了删除起点标识的，那何时该删除标识呢？\r\n
\t//当解析的数据部分的末尾在buffer内部时，这个时候，在读取完该部分数据后，需将起点标识删除\r\n
\t//例如我现在读取的是字段数据部分，headerField,如果headerField部分在当前的buffer内部结束时，就应该\r\n
\t//删除该headerField的起点标识\r\n
\tclear=function(name){\r\n
\t   delete self[name+'Mark'];\r\n
\t},\r\n
\t//每解析完一段数据（我说的一段数据指的是一段有意义的数据，例如headerField,headerValue,partData都算是一段数据）\r\n
\t//就要调用相应的回调进行处理，该函数会传递四个参数，第一个参数为该段数据名（headerField等）,第二个参数为当前的buffer,\r\n
\t//最后两个参数分别为该数据段的起始位置和结束位置。。这里又要分为两种情况：\r\n
\t//1.该段数据在当前的buffer内结束，那么start=mark(name),end=i;\r\n
\t//2.当前的buffer内，解析的该段数据尚未解析完毕，例如当前是个headerField字段数据，它有一部分在当前的buffer内，剩余的部分在\r\n
\t//  下一个buffer内，这时候，start=mark(name),end=buffer.length\r\n
\tcallback=function(name,buffer,start,end){\r\n
\t\tif(start!=undefined && start===end){\r\n
\t\t\treturn;\r\n
\t\t}\r\n
\t\t//这是形成回调函数名\r\n
\t\tvar callbackSymbol = 'on'+name.substr(0, 1).toUpperCase()+name.substr(1);\r\n
        if (callbackSymbol in self) {\r\n
\t\t  //这些回调函数是在哪定义的呢？别急，等我们再次回到IncomingForm中时你就会明白了\r\n
          self[callbackSymbol](buffer, start, end);\r\n
        }\r\n
\t},\r\n
\t//这是对callback的一个封装，目的是为了给callback传递start和end\r\n
\t//这个clear代表什么呢？\r\n
\t//没错，它代表我在讲callback时提到的两种情况，可以看下源码对照一下这两种情况。\r\n
    dataCallback = function(name, clear) {\r\n
      var markSymbol = name+'Mark';\r\n
      if (!(markSymbol in self)) {\r\n
          return;\r\n
      }\r\n
\r\n
      if (!clear) {\r\n
        callback(name, buffer, self[markSymbol], buffer.length);\r\n
        self[markSymbol] = 0;\r\n
      } else {\r\n
          callback(name, buffer, self[markSymbol], i);\r\n
          delete self[markSymbol];\r\n
      }\r\n
    };\r\n
\t//该进入主题部分了，在当前buffer内，逐个字符地判断，然后根据每个字符地当前状态\r\n
\t//进行相应地操作。这里提到的每个字符的状态是指上就是指当前字符出于哪一个数据段中\r\n
\tfor(i=0;i\t\tc=buffer[i];//当前字符\r\n
\t\tswitch(state){\r\n
\t\t\tcase S.PARSER_UNINITIALIZED:\r\n
\t\t\t\treturn i;\r\n
\t\t\t//注意，该case并没有break语句，说明可以直接执行下一个case,在该case中，只是起到一个初始化作用，不涉及到字符的处理\r\n
\t\t\tcase S.START://数据开始进入解析阶段，一般是在初始化完边界字符串后，可以看initWithBoundary代码\r\n
\t\t\t\tindex=0;\r\n
\t\t\t\tstate=S.START_BOUNDARY;//状态流转，开始解析解析数据区域的边界字符串\r\n
\t\t\tcase S.START_BOUNDARY:\r\n
\t\t\t\tif(index==boundary.length-2){\r\n
\t\t\t\t\tif (c!=CR)//边界的倒数第二个字符串应该为CR（最后两个字符为\\r\\n）,如果不是，则说明解析出错\r\n
\t\t\t\t\t{\r\n
\t\t\t\t\t\treturn i;\r\n
\t\t\t\t\t}\r\n
\t\t\t\t\tindex++;//若正确，则继续解析下一个字符\r\n
\t\t\t\t\tbreak;\r\n
\t\t\t    }else if(index-1==boundary.length-2){\r\n
\t\t\t\t\tif(c!=LF){//如果边界的最后一个字符部位LF,则说明解析出错\r\n
\t\t\t\t\t\treturn i;\r\n
\t\t\t\t\t}\r\n
\t\t\t\t\t//否则，说明边界字符串解析完毕，开始解析下面的字段数据\r\n
\t\t\t\t\tindex=0;\r\n
\t\t\t\t\t//触发onPartBegin事件（在IncomingForm中定义）,目的是为了初始化一些变量，方便接下来的解析过程\r\n
\t\t\t\t\t//可以看到，它没有传递buffer,start,end，因此不涉及传输数据的处理\r\n
\t\t\t\t\tcallback('partBegin');\r\n
\t\t\t\t\tstate=S.HEADER_FIELD_START;//状态流转\r\n
\t\t\t\t\tbreak;\r\n
\t\t\t\t}\r\n
\t\t\t\t//为什么index要加2呢，还记得initWithBounday中如何初始化边界字符串吗？\r\n
\t\t\t\t//没错，它解析成\\r\\n--boundary,与实际的字符串--boundary\\r\\n对比一下，\r\n
\t\t\t\t//明白为什么要加上2了吧，是为了跳过CR和LF\r\n
\t\t\t\tif (c!=boundary[index+2])\r\n
\t\t\t\t{\r\n
\t\t\t\t\treturn i;\r\n
\t\t\t\t}\r\n
\t\t\t\tindex++;\r\n
\t\t\t\tbreak;\r\n
\t\t\t//可以看到，该case同样没有break,因此，可以看出，凡是START区域都是\r\n
\t\t\t//起到一个起始点标识和状态流转的作用\r\n
\t\t\tcase S.HEADER_FIELD_START:\r\n
\t\t\t\tstate=S.HEADER_FIELD;//状态流转\r\n
\t\t\t    mark('headerField');//标识字段数据的起始点\r\n
\t\t\t\tindex=0;\r\n
\t\t\tcase S.HEADER_FIELD:\r\n
\t\t\t\t//这里的CR指的是所有的HEADER结束后于DATA区域之间的那一个空行\r\n
\t\t\t    //因为有些数据有两个header,比如文件数据，它不仅有Content-Disposition\r\n
\t\t\t\t//还有Content-Type,如上图。可能这里还不太明白，等到下面的S.HEADER_VALUE_ALMOST_DONE状态\r\n
\t\t\t\t//再回过头来看这一段代码\r\n
\t\t\t\tif(c==CR){\r\n
\t\t\t\t\tclear('headerField');\r\n
\t\t\t\t\tstate=S.HEADERS_ALMOST_DONE;\r\n
\t\t\t\t\tbreak;\r\n
\t\t\t    }\r\n
\t\t\t\tindex++;\r\n
\t\t\t\t//如果字符是'-',例如Content-Diposition:中间的'-',则继续检测下一个字符的状态\r\n
\t\t\t\tif(c==HYPHTN){\r\n
\t\t\t\t\tbreak;\r\n
\t\t\t\t}\r\n
\t\t\t\t//如果字符是':'则表明header_field部分结束，可看图示\r\n
\t\t\t\tif(c==COLON){\r\n
\t\t\t\t\tif(index==1){//是个空字段\r\n
\t\t\t\t\t\treturn i;\r\n
\t\t\t\t\t}\r\n
\t\t\t\t\t//header_field部分结束，调用相关的回调处理该部分数据，\r\n
\t\t\t\t\t//注意，它是在同一个buffer内部结束的，所有第二个参数为true\r\n
\t\t\t\t\tdataCallback('headerField',true);\r\n
\t\t\t\t\tstate=S.HEADER_VALUE_START;//状态流转，开始处理field_value的数据\r\n
\t\t\t\t\tbreak;\r\n
\t\t\t\t}\r\n
\t\t\t\tbreak;\r\n
\t\t\t//不用解释了吧，呵呵\r\n
\t\t\tcase S.HEADER_VALUE_START:\r\n
\t\t\t\tmark('headerValue');\r\n
\t\t\t    state=S.HEADER_VALUE;\r\n
\t\t\tcase S.HEADER_VALUE:\r\n
\t\t\t\t//如果当前字符是CR，则HEADER_VALUE解析完毕，还记得每一行的最后是\\r\\n（CR LF）吗?\r\n
\t\t\t\tif(c==CR){\r\n
\t\t\t\t\tdataCallback('headerValue', true);\r\n
\t\t\t\t\tcallback('headerEnd');//改行header结束后进行回调\r\n
\t\t\t\t\tstate = S.HEADER_VALUE_ALMOST_DONE;\r\n
\t\t\t    }\r\n
\t\t\t\tbreak;\r\n
\t\t\tcase S.HEADER_VALUE_ALMOST_DONE:\r\n
\t\t\t\t//由于上一状态最后的字符是CR，所以当前字符应该是LF，否则就是解析出错\r\n
\t\t\t\tif(c!=LF){\r\n
\t\t\t\t\treturn i;\r\n
\t\t\t    }\r\n
\t\t\t\t//为什么这里又要重新回滚状态呢？\r\n
\t\t\t\t//前面已经提到过，有的数据段可能有两行header，比如文件和图片。。\r\n
\t\t\t\t//现在再讲前面HEADER_FIELD中的解释联系起来，是不是懂了呢\r\n
\t\t\t\tstate=S.HEADER_FIELD_START;\r\n
\t\t\t\tbreak;\r\n
\t\t\t//这是在某个数据段的所有Header全部解析完毕时的状态\r\n
\t\t\tcase S.HEADERS_ALMOST_DONE:\r\n
\t\t\t\t//回过头去看header_field状态，在header都解析完成时的字符是CR，所以当前字符应该是LF\r\n
\t\t\t    //否则就是解析错误\r\n
\t\t\t\tif(c!=LF){\r\n
\t\t\t\t\treturn i;\r\n
\t\t\t\t}\r\n
\t\t\t\tcallback('headersEnd');\r\n
\t\t\t\tstate = S.PART_DATA_START;\r\n
\t\t\t\tbreak;\r\n
\t\t\tcase S.PART_DATA_START:\r\n
\t\t\t\tstate=S.PART_DATA;\r\n
\t\t\t\tmark('partData');\r\n
\t\t\t//数据段的解析，这是最难懂的一部分，当初也是看了很久\r\n
\t\t\tcase S.PART_DATA:\r\n
\t\t\t\tprevIndex=index;\r\n
\t\t\t    //index上一次的设置是在header_field_start中，设置为0\r\n
\t\t\t\tif(index==0){\r\n
\t\t\t\t\t//这一段代码有些难懂，它的目的是尽快地跳过数据区域。因为数据区域一般\r\n
\t\t\t\t\t//有很多地字符，而我们所需要的仅仅是该数据区域的起始位置和结束位置。\r\n
\t\t\t\t\t//起始位置我们在PART_DATA_START中已经设置了。该如何找到数据区域的结束位置呢？\r\n
\t\t\t\t\t//如果像前面的headerField,headerValue一样，逐个字符进行遍历，那太影响效率，因此\r\n
\t\t\t\t\t//这里采用边界跳跃法使我们能更快地接近数据区域的结束位置。。\r\n
\t\t\t\t\t//如何跳跃呢？\r\n
\t\t\t\t\t//此时i指向的是数据其余的第一个字符，而数据区域和下一个字段其余的边界是连在一起的。\r\n
\t\t\t\t\t//这时候，我们用i加上一个boundaryEnd(它比真实的边界少一个字符)可以上我们往前跳一部分，\r\n
\t\t\t\t\t//但是它又同时保证了我们不会跳出边界之外，就算数据区域只有一个字符，我加上一个boundaryEnd,\r\n
\t\t\t\t\t//也只会跳到边界字符串的最尾部。大家可以按照post数据格式，假设一段数据来照着流程走一遍\r\n
\t\t\t\t\ti+=boundaryEnd;\r\n
\t\t\t\t\twhile(i < bufferLength && !(buffer[i] in boundaryChars)){\r\n
\t\t\t\t\t\ti+=boundaryLength;\r\n
\t\t\t\t\t}\r\n
\t\t\t\t\ti -= boundaryEnd;\r\n
\t\t\t\t\tc=buffer[i];\r\n
\t\t\t\t}\r\n
\t\t\t\tif(index\t\t\t\t\tif(boundary[index]==c){\r\n
\t\t\t\t\t\t//表示数据区域解析完毕，这里同时也说明了作者当时在初始化边界时为什么要把\r\n
\t\t\t\t\t\t//\\r\\n放在首部，在数据区域结尾的部分正好是\\r\\n，因此，如果两者相等，则正好\r\n
\t\t\t\t\t\t//说明了当前指针走到了数据区域的尾部\r\n
\t\t\t\t\t\tif(index==0){\r\n
\t\t\t\t\t\t\tdataCallback('partData',true);\r\n
\t\t\t\t\t\t}\r\n
\t\t\t\t\t\t//这里开始解析下一个boundary，也就是紧接着data区域之后的boundary,可以边看代码边看\r\n
\t\t\t\t\t\t//图示\r\n
\t\t\t\t\t\tindex++;\r\n
\t\t\t\t\t}\r\n
\t\t\t\t\telse{\r\n
\t\t\t\t\t\tindex=0;\r\n
\t\t\t\t\t}\r\n
\t\t\t\t}else if(index==boundary.length){\r\n
\t\t\t\t\t//当解析到边界字符串的倒数第二个字符\r\n
\t\t\t\t\t//注意，因为index是从1开始的，所以当它等于boundary.length时\r\n
\t\t\t\t\t//应该是倒数第二个字符\r\n
\t\t\t\t\tindex++;\r\n
\t\t\t\t\tif(c==CR){\r\n
\t\t\t\t\t\t//如果倒数第二个字符为CR,表名下面还有数据需要解析\r\n
\t\t\t\t\t\t//前面已经解释过，边界字符串有两种情况，可以看上面的图示\r\n
\t\t\t\t\t\tflags |=F.PART_BOUNDARY;//flag为F.PART_BOUNDARY\r\n
\t\t\t\t\t}else if(c==HYPHEN){\r\n
\t\t\t\t\t\t//如果倒数第二个字符为'-',表明所有的post数据解析完毕\r\n
\t\t\t\t\t}else{\r\n
\t\t\t\t\t\tindex=0;\r\n
\t\t\t\t\t}else if(index-1==boundary.length){\r\n
\t\t\t\t\t\t//如果当前的边界字符串为PART_BOUNDARY\r\n
\t\t\t\t\t\tif(flags & F.PART_BOUNDARY){\r\n
\t\t\t\t\t\t\tindex=0;\r\n
\t\t\t\t\t\t\tif(c==LF){\r\n
\t\t\t\t\t\t\t\t//因为下面还有数据需要解析\r\n
\t\t\t\t\t\t\t\t//所以重新初始化flags的值\r\n
\t\t\t\t\t\t\t\tflags &= ~F.PART_BOUNDARY;\r\n
\t\t\t\t\t\t\t\tcallback('partEnd');\r\n
\t\t\t\t\t\t\t\tcallback('partBegin');\r\n
\t\t\t\t\t\t\t\t//状态重新流转到header_field_start进行下一个字段的解析\r\n
\t\t\t\t\t\t\t\tstate = S.HEADER_FIELD_START;\r\n
\t\t\t\t\t\t\t\tbreak;\r\n
\t\t\t\t\t\t\t}\r\n
\t\t\t\t\t\t}\r\n
\t\t\t\t\t\telse if(flags & F.LAST_BOUNDARY){\r\n
\t\t\t\t\t\t\t//如果当前边界字符串为LAST_BOUNDARY\r\n
\t\t\t\t\t\t\tif(c==HYPHEN){\r\n
\t\t\t\t\t\t\t\tcallback('partEnd');\r\n
\t\t\t\t\t\t\t\tcallback('end')\r\n
\t\t\t\t\t\t\t\t//状态流转，解析结束\r\n
\t\t\t\t\t\t\t\tstate = S.END;\r\n
\t\t\t\t\t\t\t}else{\r\n
\t\t\t\t\t\t\t\tindex=0;\r\n
\t\t\t\t\t\t\t}\r\n
\t\t\t\t\t\t}\r\n
\t\t\t\t\t\telse{\r\n
\t\t\t\t\t\t\tindex=0;\r\n
\t\t\t\t\t\t}\r\n
\t\t\t\t\t}\r\n
\t\t\t\t\tif(index>0){\r\n
\t\t\t\t\t\t//这里是在干吗呢？\r\n
\t\t\t\t\t\t//实际上它就是个日志功能，在解析遇到错误的时候，可以通过它来回滚错误。。\r\n
\t\t\t\t\t\t//例如，在跳跃边界那一部分，当数据区域中有一段字符和边界字符串中的某一段字符\r\n
\t\t\t\t\t\t//相同时，就会错误地把它认为是边界字符串，等到解析到后来发现了错误时怎么办呢？\r\n
\t\t\t\t\t\t//就是用这里保存的数据来进行回滚操作\r\n
\t\t\t\t\t\tlookbehind[index-1]=c\r\n
\t\t\t\t\t}else if(prevIndex>0){\r\n
\t\t\t\t\t\t//可以看前面part_data部分的代码，在发现解析错误时，总是把index置0，\r\n
\t\t\t\t\t\t//如果这时候prevIndex不为0,那么说明有数据需要回滚\r\n
\t\t\t\t\t\tcallback('partData', lookbehind, 0, prevIndex);\r\n
\t\t\t\t\t\tprevIndex = 0;\r\n
\t\t\t\t\t\tmark('partData');\r\n
\t\t\t\t\t\ti--;\r\n
\t\t\t\t\t}\r\n
\t\t\t\t\tbreak;\r\n
\t\t\t\tcase S.END:\r\n
\t\t\t\t\tbreak;\r\n
\t\t\t\tdefault\r\n
\t\t\t\t\treturn i;\r\n
\t\t\t\t}\r\n
\t\t}\r\n
\t\t//这里是在当前buffer完全解析完后调用的\r\n
\t\t//如果一个数据部分（比如如field信息）已经在上面的解析过程中解析完毕，那么自然已经调用过clear方法，那下面的dataCallback将什么也不做\r\n
\t\t//否则，下面的调用将会把这次数据段中的数据部分传递到回调函数中\r\n
\t\t//看看上面提到的调用dataCallback的两种情况\r\n
\t\tdataCallback('headerField');\r\n
\t\tdataCallback('headerValue');\r\n
\t\tdataCallback('partData');\r\n
\r\n
\t\tthis.index = index;\r\n
\t\tthis.state = state;\r\n
\t\tthis.flags = flags;\r\n
\r\n
\t\treturn len;\r\n
\t}\r\n
}

\r\n

到这里，已经完成了整个数据解析部分的流程，如果大家有些地方还没弄明白，可以使用实例数据照着流程多走几次\r\n
这里，还有一个问题是，在解析的过程中，触发的这些回调都是在哪里定义的呢？\r\n
让我么能再回到IncomingForm模块中\r\n
\r\n
想一想，该何时定义这些回调。。。在post数据传过来时，会先传递头部信息，就是那些键值对，然后才是实际的数据部分（数据部分中又分header和data,上面的流程就是解析这两块）\r\n
因此，我们可以在处理头部信息时来定义这些回调函数.\r\n
\r\n
还记得parser中的this.writeHeaders(req.headers)这一句吗，不错，这正是处理Header信息的入口

\r\n

IncomingForm.prototype.writeHeaders=function(headers){\r\n
\tthis.headers=headers;\r\n
\t//调用一个私有方法\r\n
\tthis._parseContentType();\r\n
}\r\n
IncomingForm.prototype._parseContentType = function(){\r\n
\t//headers中的content-type有application/x-www-form-urlencoded和multipart/form-data两种\r\n
\t//由于这里专注讲文件上传，所以我们只讲multipart/form-data部分\r\n
\tif(this.headers['content-type'].match(/multipart/i)){\r\n
\t\tvar m;\r\n
\t\tif(m = this.headers['content-type'].match(/boundary=(?:\"([^\"]+)\"|([^;]+))/i)){\r\n
\t\t\t//获得boundary字段的指，也就是边界字符串\r\n
\t\t\tthis._initMultipart(m[1] || m[2]);\r\n
\t\t}\r\n
\t\treturn\r\n
\t}\r\n
}\r\n
IncomingForm.prototype._initMultipart(boundary){\r\n
\tthis.type = 'multipart';\r\n
\t//初始化一个MultipartParser的实例，用于在后面定义multipart_parser中执行的回调\r\n
\tvar parser = new MultipartParser(),\r\n
\t\tself = this,\r\n
\t\theaderField,\r\n
\t\theaderValue,\r\n
\t\tpart;\r\n
\t//初始化边界字符串，initWithBoundary是在multipart_parser中定义的\r\n
\tparser.initWithBoundary(boundary);\r\n
\t//该函数是在状态流转到S.HEADER_FIELD_START时执行。\r\n
    parser.onPartBegin = function() {\r\n
\t\tpart = new EventEmitter();\r\n
\t\tpart.headers = {};\r\n
\t\tpart.name = null;\r\n
\t\tpart.filename = null;\r\n
\t\tpart.mime = null;\r\n
\t\theaderField = '';\r\n
\t\theaderValue = '';\r\n
  };\r\n
  //header_field解析完毕时执行\r\n
  parser.onHeaderField = function(b, start, end) {\r\n
    headerField += b.toString(self.encoding, start, end);\r\n
  };\r\n
  //header_value解析完毕时执行\r\n
  parser.onHeaderValue = function(b, start, end) {\r\n
    headerValue += b.toString(self.encoding, start, end);\r\n
  };\r\n
  //headr_value解析完毕时执行,用于存储该行header中的一些信息\r\n
  //例如name,filename,filetype等等\r\n
  parser.onHeaderEnd = function() {\r\n
    headerField = headerField.toLowerCase();\r\n
    part.headers[headerField] = headerValue;\r\n
\r\n
    var m;\r\n
    if (headerField == 'content-disposition') {\r\n
      if (m = headerValue.match(/name=\"([^\"]+)\"/i)) {\r\n
        part.name = m[1];\r\n
      }\r\n
\r\n
      part.filename = self._fileName(headerValue);\r\n
    } else if (headerField == 'content-type') {\r\n
      part.mime = headerValue;\r\n
    }\r\n
\r\n
    headerField = '';\r\n
    headerValue = '';\r\n
  };\r\n
  //所有的header解析完毕时执行\r\n
  parser.onHeadersEnd = function() {\r\n
    self.onPart(part);\r\n
  };\r\n
  //当找到data的结束位置时执行\r\n
  parser.onPartData = function(b, start, end) {\r\n
\t //触发data事件，该事件是在哪侦听的呢，稍后会说明\r\n
    part.emit('data', b.slice(start, end));\r\n
  };\r\n
  //当解析完紧接data区域之后的边界字符串时执行\r\n
  parser.onPartEnd = function() {\r\n
\t//同理，触发end事件\r\n
    part.emit('end');\r\n
  };\r\n
  //当解析完last_boundary时执行\r\n
  parser.onEnd = function() {\r\n
    self.ended = true;\r\n
    self._maybeEnd();\r\n
  };\r\n
  this._parser = parser;\r\n
}

\r\n

到此，已经定义了所有需要的回调函数,可是上面代码中提到的data和end事件是在哪定义的呢？\r\n
让我们按照刚才需找\"回调函数定义之处\"的方式思维来思考,由于在onPartData和onPartEnd函数执行之前会先执行onHeadersEnd,\r\n
而onHeadersEnd中只有一条语句,self.onPart(part)，不难看到，这两个事件应该是在onPart中定义的。。

\r\n

IncomingForm.prototype.onPart=function(part){\r\n
\t//真纠结啊\r\n
\tthis.handlePart(part);\r\n
}\r\n
//这个函数很重要，目的是处理header_field和header_value,以及\r\n
//定义上文提到的事件\r\n
IncomingForm.prototype.handlePart = function(part){\r\n
\tvar self=this;\r\n
\t//如果当前的数据部分不是文件\r\n
\tif(part.filename==undefined){\r\n
\t\t//这里可以看源代码,不讲解了\r\n
\t\treturn;\r\n
\t}\r\n
\t//这里的File是另一个模块，用于写文件，很简单，\r\n
\t//这里就不讲了，可以看一下源码，我想应该都能看懂\r\n
\tvar file=new File({\r\n
\t\tpath:'tmp/'+path.filename,\r\n
\t\tname: part.filename,\r\n
\t\ttype: part.mime,\r\n
\t});\r\n
\tfile.open();\r\n
\t//这里就是刚才提到的data事件，当文件数据解析完毕后，会触发这个事件\r\n
    part.on('data', function(buffer) {\r\n
\t\t//文件写入过程中，暂定request请求，写入完毕后，回复请求\r\n
\t\t//原因前面已经将结果\r\n
\t\tself.pause();\r\n
\t\tfile.write(buffer, function() {\r\n
\t\tself.resume();\r\n
    });\r\n
\t//end事件\r\n
   part.on('end', function() {\r\n
\t\tfile.end(function() {\r\n
\t\t\tself.emit('file', part.name, file);\r\n
\t\t\tself._maybeEnd();\r\n
\t\t});\r\n
  });\r\n
});\r\n
}

","title","node-formidable详解","last_reply_at","2017-08-09T03:30:45.600Z","good","top",14,"visit_count",55112,"2011-12-21T07:05:30.000Z","author",{"_13":56,"_23":57},"skindhu","http://www.gravatar.com/avatar/6ddd3b7257f5eca8f760151d1100bf04?s=48","34","19","有同学肯定觉得只看了静态文件服务器是不过瘾的。必须来点动态服务器才行，甚至MVC框架之类的才能摆上台面。但是冰冻三尺，非一日之寒；千寻之塔，也是起于砂石啊。所以这一章的目的是用来构建一个动态服务器的基础，下一章会在这个基础上，构建一个MVC框架。\r\n
\r\n
一门后端动态语言要达到Web的可用水平需要满足那些条件呢。让我们来想想，通常的PHP或是ASP/ASP.NET，甚至是JSP。一些基本的东东是什么呢。\r\n

Get/Post 数据获取，这个是最基本的

Cookie你都不支持，你让Session如何混。

Session，对于无状态的HTTP协议，Session的实现帮助后端太多了。

\r\n
以上这些支持几乎是必须的。缺少一部分，这个服务器都会缺胳膊少腿的。那么有了这些需求之后，我们就来实现吧。\r\n
\r\n
Anyway，架子搭起来先。我们的动态服务器并不是在静态服务器的基础上再增强的，所以需要一个全新的架子。\r\n

var http = require(\"http\");\r\n
\r\n
var server = http.createServer(function (request, response){\r\n
    response.setHeader(\"Content-Type\", \"text/plain\");\r\n
    response.writeHead(200, \"Ok\");\r\n
    // TODO\r\n
    // response.write(\"\");\r\n
    response.end();\r\n
});\r\n
\r\n
server.listen(8000);

\r\n
嗯，还是很简单很朴素的感觉。\r\n

Get/Post支持

\r\n
HTTP请求协议主要包含以下几种请求类型：\r\n

POST

HEAD

DELETE

OPTIONS

TRACE

\r\n
其中最常见的就是GET和POST了。其次，PUT和DELETE在RESTful请求中也是十分常见的。在这里，我们只讨论GET和POST方法。客户端向服务端传递数据也是主要通过这两种方法。那么我们来进一步剖析GET和POST方法吧。\r\n
\r\n
GET方法最为常见，其形式大致如下：\r\n

http://localhost:8000/?foo=bar

\r\n
用CURL工具来查看下协议的细节吧:\r\n

curl  -v http://localhost:8000/?foo=bar

\r\n
看看请求头是什么样子：\r\n

GET /?foo=bar HTTP/1.1\r\n
\r\n
User-Agent: curl/7.20.1 (i686-pc-cygwin) libcurl/7.20.1 OpenSSL/0.9.8r zlib/1.\r\n
Host: localhost:8000\r\n
Accept: */*

\r\n
Get支持只需要分析问号后面的foo=bar部分就ok的。在写出我们Node的代码之前，可以少许的看看PHP和ASP.NET是如何调用的。\r\n
\r\n
PHP：\r\n

$_GET[\"name\"]

\r\n
ASP.NET：\r\n

Request.QueryString(\"name\")

\r\n
嗯，接口不错，那我们为Node也写一个接口吧，保持简单，request.get(name)就可以了。Node在处理这个问题上，提供了URL模块和QueryString模块，用于解析URL和QueryString部分（参见：http://nodejs.org/docs/v0.6.1/api/http.html#request.url）。\r\n
\r\n
引入url和querystring模块吧。\r\n

var url = require(\"url\");\r\n
var qs = require(\"querystring\");

\r\n
对于URL的解析，由于每一个请求进来，并不是每个程序员都需要获取query上的值的。这种场景下，我们没必要为其浪费解析URL的CPU时间，所以延迟解析吧。\r\n

var _urlMap;\r\n
\r\n
request.get = function (key) {\r\n
    if (!_urlMap) {\r\n
        urlMap = url.parse(request.url, true);\r\n
    }\r\n
    return urlMap.query[key];\r\n
};

\r\n
只有后续有代码调用到了get方法，才会解析一次。如果没有用到，这里就不占用空间和CPU时间了。\r\n
\r\n
接下来搞定Post方法，接口依然保持一致，那就是request.post(name)。POST请求与GET请求略有不同在于GET请求是不用向服务端发送body部分的报文的。这里有点类似条件请求的响应，如果是304，只有头信息，没有body信息；如果是200，才会将body和头信息一起发回给客户端。这里反之，get请求不用发送body信息，只有post才会发送body信息。所以这里对于前端来说，如果不发送数据到服务端，用get方法可以节省一些带宽的。对于小数据量的发送，通过URL请求发送时携带就足够了。（URL的最大长度在IE下是2k，超过此额度，请用post吧）。\r\n
\r\n
具体参见YSlow的这条Rule：http://developer.yahoo.com/performance/rules.html#ajax_get。\r\n
\r\n
一般而言，POST请求都是通过表单发送出来的。浏览器会自动的将数据编码为foo=bar&baz=xxx这样的格式。而且与get方法不同的是，在接受数据的时候，需要通过监听data事件接受所有数据，因为客户端可能是通过chunk方式逐步发送过来的。\r\n

if (request.method === \"POST\") {\r\n
    var _postData = \"\",\r\n
        _postMap = \"\";\r\n
\r\n
    request.on('data', function (chunk) {\r\n
        _postData += chunk;\r\n
    })\r\n
    .on(\"end\", function () {\r\n
        request.postData = _postData;\r\n
        request.post = function (key) {\r\n
            if (!_postMap) {\r\n
                _postMap = qs.parse(_postData);\r\n
            }\r\n
            return _postMap[key];\r\n
        };\r\n
    });\r\n
}

\r\n
之所以有request.postData = _postData这样一句，因为客户端上传的并不一定是key=value&key=value的方式，或者是一个json对象，或者是一个xml文档。这个时候这个数据留给程序员自己去再解析。\r\n
\r\n
相同的，一切为了性能，所以延迟解析，并且只在请求方法为POST的时候才有这些方法。\r\n
\r\n
最终的代码大致如下：\r\n

var server = http.createServer(function (request, response) {\r\n
    var handle = function () {\r\n
        response.setHeader(\"Content-Type\", \"text/plain\");\r\n
        response.writeHead(200, \"Ok\");\r\n
        response.write(request.get(\"foo\"));\r\n
        response.write(request.post(\"foo\"));\r\n
        response.end();\r\n
    };\r\n
\r\n
    var _urlMap;\r\n
    request.get = function (key) {\r\n
        if (!_urlMap) {\r\n
            urlMap = url.parse(request.url, true);\r\n
        }\r\n
        return urlMap.query[key];\r\n
    };\r\n
\r\n
    if (request.method === \"POST\") {\r\n
        var _postData = \"\",\r\n
            _postMap = \"\";\r\n
\r\n
        request.on('data', function (chunk) {\r\n
            _postData += chunk;\r\n
        })\r\n
        .on(\"end\", function () {\r\n
            request.postData = _postData;\r\n
            request.post = function (key) {\r\n
                if (!_postMap) {\r\n
                    _postMap = qs.parse(_postData);\r\n
                }\r\n
                return _postMap[key];\r\n
            };\r\n
            handle();\r\n
        });\r\n
    } else {\r\n
        handle();\r\n
    }\r\n
});

\r\n
我们通过curl来模拟一次同时带有post数据和get数据的请求吧：\r\n

curl --data \"foo=postdata\" http://localhost:8000/?foo=getdata

\r\n
看看响应：\r\n

getdata\r\n
postdata

\r\n
嗯，完全满足需求。（注意：处理文件上传的请求会更复杂，再次不做讨论，如需深入，请移步http://cnodejs.org/blog/?p=2207）\r\n

Cookie支持

\r\n
尽管身为前端工程师，对Cookie有着相当多的怨言。比如不方便调用；每次都会附带在请求中，占用带宽。一个经典的面试题目是，假如客户端禁用了Cookie，Session是否有效？如何有效？\r\n
\r\n
不知各位是否有答案。关于Cookie与Session之间的关系，我们下一节再来详述。先来解释下Cookie是如何工作的吧，在协议里是怎么传递的。\r\n

请求传递Cookie\r\n
如果当前域名下存在Cookie，浏览器在每次发起HTTP请求的时候，都会在请求头中带上这样一项：\r\n
Cookie: UserCookie=AgiTOOpJet; RegisteredUserCookie=PXLgvDECVD; JSESSIONID=BF0844821;\r\n
注意，是每次。

响应传递Cookie

\r\n
如果服务端设置了Cookie，则会在相应头里发出这样一项：\r\n
\r\n
Set-Cookie:JSESSIONID=D211F624077921CEACD202C1ACDD30C6; Path=/\r\n
注意，这里只是单次的，有需求才发送。浏览器端在接受到这个header之后，会将这项存在客户端，下次发送请求时会带在请求头中。\r\n
\r\n
那么我们要在Node中取得客户端发送过来的cookie就很简单了，从header中读取cookie就ok。\r\n
\r\n
var cookieStr = request.headers.cookie || \"\";\r\n
\r\n
再次看看别的语言中是如何做cookie获取和调用的:\r\n

PHP:\r\n
```
$_COOKIE[\"user\"];
```
\r\n

ASP:\r\n
```
Request.Cookies(\"firstname\")
```
\r\n

\r\n
中和一下，那么我们要的API就是：request.cookie(key)。\r\n

var _cookieMap;\r\n
\r\n
request.cookie = function (key) {\r\n
    if (!_cookieMap) {\r\n
        _cookieMap = cookie.parse(request.headers.cookie || \"\");\r\n
    }\r\n
    return _cookieMap[key];\r\n
};

\r\n
嗯，还是延迟解析的老把戏。等等，cookie.parse从哪里来的？\r\n

var cookie = require(\"./cookie\");

\r\n
嗯，没有枪，没有炮，我们自己造。在写这个具体的parse函数之前，有必要研究一下cookie的格式。老规矩，还是按标准协议（http://www.w3.org/Protocols/rfc2109/rfc2109）来：\r\n

av-pairs        =       av-pair *(\";\" av-pair)\r\n
av-pair         =       attr [\"=\" value]        ; optional value\r\n
attr            =       token\r\n
value           =       word\r\n
word            =       token | quoted-string

\r\n
如果你看不懂以上这段描述的话，我来简单介绍吧。\r\n

通过;分割多个属性/值对。

属性值对由属性，等号，和值构成。等号和值是可选的，也就是说可能只有属性，没有值。

\r\n
嗯，仅此而已。那么实现吧。\r\n

exports.parse = function (cookie) {\r\n
    var map = {};\r\n
    var pairs = cookie.split(\";\");\r\n
    pairs.forEach(function (pair) {\r\n
        var kv = pair.split(\"=\");\r\n
        map[kv[0]] = kv[1] || \"\";\r\n
    });\r\n
\r\n
    return map;\r\n
};

\r\n
由于Node使用的是V8，所以可以放心大胆的用这些来自ES5的方法。\r\n
\r\n
在之前的代码中加入响应Cookie：\r\n

response.write(request.cookie(\"foo\") + \"\\n\\r\");

\r\n
然后通过curl伪装cookie测试一下吧：\r\n

curl -i --cookie \"foo=cookiedata\" --data \"foo=postdata\" http://localhost:8000/?foo=getdata

\r\n
响应：\r\n

HTTP/1.1 200 Ok\r\n
Content-Type: text/plain\r\n
Connection: keep-alive\r\n
Transfer-Encoding: chunked\r\n
\r\n
getdata\r\n
postdata\r\n
cookiedata

\r\n
嗯，just so so。\r\n
\r\n
再来看看响应cookie吧。同样先对比下API吧：\r\n

ASP.NET\r\n

Response.Cookies(\"firstname\")=\"Alex\"

\r\n

PHP\r\n

setcookie(name, value, expire, path, domain);

\r\n

\r\n
对比了一下，取个中间的而且符合JavaScript的接口吧：response.setCookie(name, value, expire, path, domain)。\r\n
\r\n
然后再看看响应的cookie头在协议标准里是怎样定义的呢。\r\n

set-cookie      =       \"Set-Cookie:\" cookies\r\n
   cookies         =       1#cookie\r\n
   cookie          =       NAME \"=\" VALUE *(\";\" cookie-av)\r\n
   NAME            =       attr\r\n
   VALUE           =       value\r\n
   cookie-av       =       \"Comment\" \"=\" value\r\n
                   |       \"Domain\" \"=\" value\r\n
                   |       \"Max-Age\" \"=\" value\r\n
                   |       \"Path\" \"=\" value\r\n
                   |       \"Secure\"\r\n
                   |       \"Version\" \"=\" 1*DIGIT

\r\n
继续用我们能够看懂的语言解释吧：\r\n

响应头是Set-Cookie做key的，值由多个cookie组成。

每个cookie的必须包含的部分是name和value。

每个cookie还有一部分选项对，选项对之间通过;来分割。这些选项包含：\r\n
1. Comment，注释【可选】
2. Domain，域【可选】
3. Max-Age，标明这个cookie在客户端的最大存活时间，单位时间是秒。如果是0，则直接被禁掉【可选】
4. Path，标明在域下的那些路径下有效【可选，默认为当前路径】
5. Secure，这个比较特殊的选项标明的是否是https。【可选】
6. Version，版本号。【必选】
\r\n

\r\n
看到这么多可选项，看起来假定的接口要去适配这么多可选参数，是有点麻烦了（JavaScript没有那么方便的重载函数呀）。那么JSON搞起吧。\r\n

response.setCookie(cookie);

\r\n
这个cookie对象必选值是name和value。那么我们为这个cookie生成需要的字符串写一个stringify函数吧。\r\n
\r\n
最后要申明一下的是现行的Cookie格式，貌似几乎不包含Comment，Version之类的了。我参考了一些实现后，最后给出的实现是如下这样的。\r\n

exports.stringify = function (cookie) {\r\n
    var buffer = [cookie.key, \"=\", cookie.value];\r\n
    if (cookie.expires) {\r\n
        buffer.push(\" expires=\", (new Date(cookie.expires)).toUTCString(), \";\");\r\n
    }\r\n
\r\n
    if (cookie.path) {\r\n
        buffer.push(\" path=\", cookie.path, \";\");\r\n
    }\r\n
\r\n
    if (cookie.domain) {\r\n
        buffer.push(\" domain=\", cookie.domain, \";\");\r\n
    }\r\n
\r\n
    if (cookie.secure) {\r\n
        buffer.push(\" secure\", \";\");\r\n
    }\r\n
\r\n
    if (cookie.httpOnly) {\r\n
        buffer.push(\" httponly\");\r\n
    }\r\n
\r\n
    return buffer.join(\"\");\r\n
};

\r\n
包装了工具方法之后，对于response.setCookie方法就比较简单了：\r\n

response.setCookie = function (cookieObj) {\r\n
    response.setHeader(\"Set-Cookie\", cookie.stringify(cookieObj));\r\n
};

\r\n
由于一次请求可能会设置多个cookie，那个这个代码需要增强一下：\r\n

var _setCookieMap = {};\r\n
\r\n
response.setCookie = function (cookieObj) {\r\n
    _setCookieMap[cookieObj.key] = cookie.stringify(cookieObj);\r\n
    var returnVal = [];\r\n
    for(var key in _setCookieMap) {\r\n
         returnVal.push(_setCookieMap[key]);\r\n
    }\r\n
    response.setHeader(\"Set-Cookie\", returnVal.join(\", \"));\r\n
};

\r\n
Have a try：\r\n

response.setCookie({key: \"username\", value: \"Jackson\"});\r\n
response.setCookie({key: \"password\", value: \"xxxxxx\"});

\r\n
用浏览器的网络工具或者curl看看响应头：\r\n

Set-Cookie: username=Jackson, password=xxxxxx

\r\n
再刷新浏览器检查是否将这两个cookie存储了（存储之后，下次请求会在request头中包含）。\r\n
\r\n
至此，Cookie的底层实现和包装都完成了。\r\n
\r\n
注意：由于Cookie的协议较多，有RFC2109，RFC2965，Netscape标准等，这里主要参考RFC2109标准，然后再根据现有浏览器和服务器的做法再中和实现的，在Chrome下测试通过。\r\n

Session支持

\r\n
上一节提到的如果Cookie被禁用了，那么Session是否可用这个问题。不知各位是否有答案。之所以有这样的一个面试题，其主要的原因是因为大多数的Session的实现，都是依赖Cookie的。而Cookie的作用，很大部分的功劳可以解决HTTP协议是种无状态协议，无法追踪和保持与用户的会话功能。这也是我们要先实现Cookie的一个原因。\r\n
\r\n
下面我们来看一眼截取自某网站的一段响应头：\r\n

Set-Cookie: sid=qwSsRlaZcQqFWC11ojBKW7Jc.vCqINHUqTnWEsH7VB4throHfZnNONt%2FKXwFx5xObRkA; path=/; expires=Tue, 15 Nov 2011 14:21:36 GMT; httpOnly

\r\n
实际上这段响应头被人拿到手里，甚至是可以构成帐号攻击的，具体细节不解释。\r\n
\r\n
还是继续老规矩吧，看看别的语言中Session的调用接口吧：\r\n

PHP\r\n

$_SESSION['views']\r\n
unset($_SESSION['views']);\r\n
session_destroy();

\r\n

ASP\r\n

Session(\"date\")=\"2001/05/05\"\r\n
Session.Contents.Remove(\"test2\")\r\n
Contents.RemoveAll()\r\n
Session.Abandon

\r\n

\r\n
那么我们的调用API也是很简单的：session.get(name)/session.set(name, value)/session.remove(name)/session.removeAll()/session.abandon()。所以在session.js文件中创建如下内容吧。\r\n

exports.Session = function () {\r\n
    this._map = {};\r\n
};\r\n
\r\n
Session.prototype.set = function (name, value) {\r\n
    this._map[name] = value;\r\n
};\r\n
\r\n
Session.prototype.get = function (name) {\r\n
    return this._map[name];\r\n
};\r\n
\r\n
Session.prototype.remove = function (key) {\r\n
    delete this._map[key];\r\n
};\r\n
\r\n
Session.prototype.removeAll = function () {\r\n
    delete this._map;\r\n
    this._map = {};\r\n
};

\r\n
再回顾一下Session的一些特性：\r\n

服务器与每一个用户之间保持一个Session。

两个用户之间的Session不会被共享。

Session有过期时间。如果在过期时间之前没有更新会话时间，则会超时。

\r\n
所以我们需要一个Session的管理器来维护客户端与服务端的联系，以及处理超时。像大多数服务器一样，我们的timeout也是可配置的。\r\n

exports.Timeout = 20 * 60 * 1000;

\r\n
SessionManager因为需要管理全局的Session，所以算是服务器级别的。而Session存在于请求级别中，可以供程序员后续调用。\r\n

$\"\"$

\r\n
Session Manager干的事情，其实就是检查session，如果不存在或者已经过期了，就重新创建一个新的session，给后续调用。以下是这个流程图的代码实现：\r\n

var sessionId = request.cookie(session.SESSIONID_KEY);\r\n
var curSession;\r\n
\r\n
if (sessionId && (curSession = sessionManager.get(sessionId))) {\r\n
    if (curSession.isTimeout()) {\r\n
        sessionManager.remove(sessionId);\r\n
        curSession = sessionManager.renew(response);\r\n
    } else {\r\n
        curSession.updateTime();\r\n
    }\r\n
} else {\r\n
    curSession = sessionManager.renew(response);\r\n
}

\r\n
至于获取session，判断session是否timeout，以及重新创建一个session的方法实现，直接看代码吧：\r\n

var SessionManager = function (timeout) {\r\n
    this.timeout = timeout;\r\n
    this._sessions = {};\r\n
};\r\n
\r\n
SessionManager.prototype.renew = function (response) {\r\n
    var that = this;\r\n
    var sessionId = [new Date().getTime(), Math.round(Math.random() * 1000)].join(\"\");\r\n
    var session = new Session(sessionId);\r\n
    session.updateTime();\r\n
    this._sessions[sessionId] = session;\r\n
    var clientTimeout = 30 * 24 * 60 * 60 * 1000;\r\n
    var cookie = {key: SESSIONID_KEY, value: sessionId, path: \"/\", expires: new Date().getTime() + clientTimeout};\r\n
    response.setCookie(cookie);\r\n
    return session;\r\n
};\r\n
\r\n
SessionManager.prototype.get = function (sessionId) {\r\n
    return this._sessions[sessionId];\r\n
};\r\n
\r\n
SessionManager.prototype.remove = function (sessionId) {\r\n
    delete this._sessions[sessionId];\r\n
};\r\n
\r\n
SessionManager.prototype.isTimeout = function (session) {\r\n
    return (session._updateTime + this.timeout) < new Date().getTime();\r\n
};

\r\n
业务逻辑代码上起来，常常session的味道吧：\r\n

var handle = function (session) {\r\n
    response.setHeader(\"Content-Type\", \"text/plain\");\r\n
    response.writeHead(200, \"Ok\");\r\n
    if (!session.get(\"username\")) {\r\n
        session.set(\"username\", request.get(\"username\"));\r\n
    }\r\n
    response.write(\"Hi, \" + session.get(\"username\") + \"\\n\\r\");\r\n
    response.end();\r\n
};

\r\n
我们首先访问http://localhost:8080/，看看有什么响应：\r\n

Hi, undefined

\r\n
继续访问http://localhost:8080/?username=jacksontian ：\r\n

Hi, jacksontian

\r\n
再继续访问http://localhost:8080/，看看是否成功：\r\n

Hi, jacksontian

\r\n
其实如果你用Chrome来测试这一段的话，也许是不成功的。因为浏览器会同时发送2个请求到服务端，你不知道的那一个是/favicon.ico。为了不影响你的测试，首先干掉这个调皮鬼吧：\r\n

if (request.url == \"/favicon.ico\") {\r\n
    response.writeHead(404, \"Not Found\");\r\n
    response.end();\r\n
    return;\r\n
}

\r\n
至此，session部分打造完毕。\r\n
\r\n
最后值得注意的是，由于Cookie不能被不同的浏览器共享，所以服务端每次给不同的客户端分配的Session ID是不同的，导致多个浏览器之间不能共享会话。也因为服务端与同一个客户端只根据一个Session ID来做判断，所以通常一个站点不能支持多帐号在一个客户端中同时登陆。\r\n

动态服务器与静态服务器对比

\r\n
一般而言，一个服务器是能够Handle所有的动态静态请求的，比如Apache（添加了PHP模块支持的）。但是我们还是可以简单的分析一下动静态服务器之间的需求差别的。\r\n
\r\n
静态文件服务器:\r\n

不需要Cookie，Session之类来保证状态

不需处理GET，POST方法上传的数据

通常具可备缓存性

版本有效性

\r\n
动态服务器：\r\n

需要追踪状态，验证身份

需要处理请求上传的数据，来动态响应

响应不具备可缓存性

永远只有现在一个版本

\r\n
所以对于Cookie，Session一类的检测和判断，完全不必要放到静态文件服务器上。而动态服务器也是不需要304之类的条件请求和Expires之类的头的。为了提高各自的性能，所以彼此之间不必交叉满足所有需求。\r\n
\r\n
下一章节将会在这部分Get/Post处理，cookie处理，session处理的基础上介绍如何搭建一个MVC框架。\r\n
\r\n
本文代码可于https://github.com/JacksonTian/ping/zipball/dynamic_server 下载\r\n
\r\n
项目地址：https://github.com/JacksonTian/ping 项目改名字为ping了。","构建动态服务器基础","2012-05-14T06:30:58.500Z",9,17798,"2011-12-07T04:29:32.000Z",{"_13":67,"_23":68},"JacksonTian","https://avatars.githubusercontent.com/u/327019?v=4","zones",[117],"tabs",[88,89,90,91,92,93],"publicConfig",{"_75":76,"_77":26,"_78":79},"apiBaseUrl","https://api.cnodejs.org","turnstileSiteKey","build",{"_80":81,"_82":83,"_84":85,"_86":87},"service","cnode-web","version","0.1.0","commit","9ab83f39eed6b4a14eedbb8fbadfefe40dba3d45","buildTime","2026-07-30T19:01:36Z",{"_21":16,"_95":115,"_97":116,"_99":108,"_100":16,"_102":109},{"_21":20,"_95":113,"_97":114,"_99":108,"_100":20,"_102":109},{"_21":110,"_95":111,"_97":112,"_99":108,"_100":110,"_102":109},{"_21":33,"_95":48,"_97":107,"_99":108,"_100":33,"_102":109},{"_21":63,"_95":104,"_97":105,"_99":35,"_100":106,"_102":103},{"_21":94,"_95":96,"_97":98,"_99":35,"_100":101,"_102":103},10,"key","test","label","测试","visible","sort_order",91,"scope","admin","dev","开发",90,"精华",true,"public",3,"job","招聘","ask","问答","share","分享",{"_21":16,"_118":119,"_120":112,"_121":122,"_123":124,"_99":108,"_100":16},"slug","jobs","name","description","Node.js 招聘信息专区","icon","briefcase"]