我们的项目中有大批的图片上传和展现。我们选了七牛作为CDN。这个中一个比较主要的缘由是由于qiniu支撑前端直接上传。动辄4-5MB的图片不必到我们的app server转一圈照样很好的。为了支撑前端上传，qiniu供应了javascript SDK。然则我看了看代码。实在是太大了。7000多行javascript啊。真的有必要吗？有必要吗？有必要吗？遂决议DIY一个。讲真，qiniu供应林林总总SDK。并不引荐直接用REST API来上传。关于API的挪用也比较简朴。所以照样费了一点气力。因有此文。

像任何事情一样，搞定以后以为实在蛮简朴的。一样像任何事情一样，理解了big picture就会好办多了。

qiniu为了支撑大文件，许可用户将文件分块(block)上传。再一切的文件块上传完成以后，再将一切块构成一个完全的文件 – 最少逻辑上是云云。物理存储怎样只要qiniu本身知道。

我们以一个2.5MB的文件为例。将文件分红3个block上传。blockSize设为1MB。需要做以下的操纵：

1. 上传block 1。qiniu服务器返回一个ctx来标识这个block。比方abcd

2. 上传block 2。qiniu服务器返回一个ctx来标识这个block。比方efgh

3. 上传block 3。qiniu服务器返回一个ctx来标识这个block。比方ijk

4. 通知qiniu服务器这个新文件是有abcd, efgh 和 ijk 三个block构成。并给出key。就能够天生文件了。

详细到API的话，是如许：

1. POST /mkblk/1048576 上传肇端的1MB文件内容。服务器返回ctx以及别的内容。

2. POST /mkblk/1048576 上传中心的1MB文件内容。服务器返回ctx以及别的内容。

3. POST /mkblk/524288 上传末了的0.5MB文件内容。服务器返回ctx已别的内容。

4. POST /mkfile/2621440/key/<key>。建立文件。在POST的body中将上面的三个ctx顺次列出并以逗号离开。如许文件就产生了。如上例，POST的body的内容应为：abcd,efgh,ijk

末了补充两点：

1. 文件内容的读取，以及各个步骤之间的连接是经由过程plupload来完成的。这个和官方的SDK也一致。然则代码量要少的多。

2. qiniu在block内部还能够分chunk上传。只要用/bput API并指定ctx即可。由于有点庞杂而且没有什么迥殊的需求（或许是为了超大文件吧），所以没有采纳。