Summary

  • W3C 在 2009 年 11 月 17 日发布首份公开 File API 工作草案，描述了由用户选中的文件、FileList 和以事件报告读取进度的 FileReader。
  • 2013 年 Last Call 草案与 2015 年工作草案进一步细化了 Blob、异步读取和 blob URL。网页可以先在本地展示文件；把字节发往服务器是另一个动作。

照相馆的店员说：“请把要冲洗的照片给我。”顾客递过去一张。店员如果立刻搬来梯子，准备检查顾客家里的每个抽屉，大概开不了几天店。网页处理本地文件时也有这道界线。它需要一张图片的数据，不能因为想做个预览就要求浏览整台电脑。真正有用的设计，是把“这一张”写进浏览器和网页共同理解的接口。

2009 年 11 月 17 日的 W3C 首份公开工作草案从被选中的文件入手。熟悉的 <input type="file"> 可以唤起选择界面，FileList 则表示挑出来的文件。File 带着文件名和媒体类型，Blob 表示原始字节，并允许取其中一段。FileReader 把内容交给脚本，同时用事件报告读到哪里、是否失败。网页拿到的是有边界的对象，不是文件系统的通行证。

这改变了上传按钮的前半程。传统表单可以把文件送到服务器；选错照片的尴尬往往要等服务器收到以后才显现。File API 让页面在发送之前就能看一眼。2009 年草案列出 readAsBinaryString、readAsText 和 readAsDataURL 三种异步读取方式。文字可以在网页里打开，图片可以先显示缩略图。读文件与传文件被分成两个步骤，用户也因此多了一次发现错误的机会。

草案的需求示例并没有把网页想象成一个装快递箱的柜台。它提到歌词查看器：用户选一个播放列表文件，网页读取后可以把歌曲排序。它还提到日历：一个本地日历文件先在浏览器里解析、合并，之后才考虑是否同步到服务器。这里的文件是工作材料。应用可以利用它完成事情，而不是一拿到就打包寄走。

不过，柜台不能只会接文件，还得知道什么时候该拒收。2009 年草案的安全讨论假设 FileReader 处理的文件先经过人的选择，并点出了几种麻烦：网站反复弹出选择窗口逼人选一个，系统敏感文件被拿来读，文件在选中后又被本地程序改动。这些不是讲给法务听的尾注。一个真实文件不是静止的网页字符串，它有位置、有权限，也会变。浏览器必须在这片现实里把一次选择变成可用的对象。

到了2013 年 9 月 12 日的 Last Call 工作草案，各部件的分工更明白了。FileList 装着所选文件；不可变的 Blob 容纳字节，还能切片；File 增加文件名、修改时间等信息；FileReader 用异步方式读取，产生进度、完成和错误事件。规范中的例子把选中的文件当作文本来读，并更新进度条。碰到大文件或慢速挂载盘时，网页总算可以告诉人它在忙什么，不必像店员抱着照片进了后屋就再无消息。

另一个细节解决了网页的老习惯：网页上的图片通常要有 URL，可用户选的是本地对象。草案用 blob URL 把两者接起来。2015 年 4 月 21 日的工作草案示范了 URL.createObjectURL() 如何为选中的图片提供页面可用的引用，也示范了用 URL.revokeObjectURL() 在用完后撤销它。规范提醒，忘记撤销会让引用留下来。预览地址像柜台取件牌，拿完照片该把牌子收回，而不是当成永久门牌。

2015 年草案还有一个极其克制的规定：File.name 给出文件名，不把上层文件夹路径一并交给网页。页面要显示“旅行照.jpg”，知道这个名字足够了。它没有理由知道照片在电脑里经过了多少层抽屉。草案还把 blob URL 与来源关联，并让跨来源请求失败。接口的用处靠文件对象和读取能力实现，不靠窥视整条目录树。

从W3C 的正式发布历史看，2009 年是首份公开 File API 草案，2013 年是 Last Call，2015 年仍是工作草案。这个过程没有一个挥手就让所有网站突然变得可靠的时刻。它做的是更实在的事：把用户刚刚挑出的那份文件，用共同的格式交给网页。网页拿到字节以后，还可以在本地处理，也可以通过别的机制传往服务器；那是应用接下来要说明、要承担的选择。

于是，一张放错的照片可以在上传前被换掉；一份日历可以先被检查；一份文字可以先在浏览器里读。旧上传表单只有“挑选、发送”的单行队伍，File API 让中间长出一张工作台。柜门仍在用户身后，柜台上只有刚递出的文件。对每天处理文件的人来说，这比任何大词都管用。