ASP无组件上传，组件说白了就是上传不用第三方控件，纯靠ASP自带的组件对象把文件从浏览器搬到服务器。这事搁现在听着简单，上传放在2005年前后，组件那可是上传无数站长半夜挠头的心病。

那时候想给网站加个上传功能，组件主流方案是上传装个ASPUpload或者LyfUpload组件。组件好用是组件好用，可人家是上传收费的，破解版又总带着莫名其妙的组件毛病。更气人的上传是，虚拟主机商动不动就禁止注册组件——你代码写得再漂亮，组件服务器不配合全白搭。上传我印象特深，组件有回帮朋友调一个报名系统，上传组件在本地测试一切正常，传到空间商那儿直接500错误。折腾到凌晨两点，最后发现是主机把组件给禁了。

无组件上传的原理其实不复杂。浏览器那边用multipart/form-data格式把文件切成一堆二进制块，ASP这边用Request.BinaryRead把这些块整个读进来，再自己动手从里面把文件内容抠出来。关键就在这个“抠”字上——你得知道文件数据在整段二进制流里的起止位置。方法土但管用：先读字节流，转成字符串，找到文件头的标记，再找到文件尾的标记，中间那段就是货真价实的文件内容。

具体写起来，核心代码就那么几十行。先定义一个字节数组，用BinaryRead把整个请求体装进去。然后要把字节数组转成字符串——这儿有个坑，直接用BytesToString转，碰上中文文件名或者非ASCII字符会乱码，得用ADODB.Stream的Type=1模式来读，或者用ChrB函数逐个字节处理。定位边界的时候，找的是“name=\"file\"”后面跟的filename字段，再往下数两行回车换行，就是文件内容起点。终点则是那一串特殊的boundary字符串。

我见过不少初学者的代码，上来就Response.BinaryWrite把整个流吐出来调试，结果浏览器直接给下载了一个乱码文件。其实调试有个笨办法，把读到的二进制流用Response.Write输出成文本，虽然会乱码，但能看出boundary和字段名的位置对不对。等定位逻辑跑通了，再换回BinaryWrite写文件。

写文件的时候还有个细节——不能用常规的FileSystemObject的CreateTextFile，那玩意儿是处理文本的，碰到二进制数据会悄悄改掉换行符。得用ADODB.Stream的Type=2模式，LoadFromFile或者直接Write，然后SaveToFile保存。这个Stream对象才是无组件上传的真正主力，既能读也能写，还能转编码。

说实话，这套方案现在看确实有点原始。性能一般，大文件传到一半断了没法续传，内存占用也吓人——整个请求体都塞进内存里再处理，传个100MB的文件服务器得先扛200MB的内存压力。但放在当年，它解决的是“能不能用”的问题，而不是“好不好用”。

后来到了ASP.NET时代，内置的FileUpload控件把这一切都封装好了，没人再手搓二进制解析。可那段折腾无组件上传的日子，倒逼着一批人把HTTP协议和字节流操作啃得透透的。我至今记得第一次成功从二进制流里抽出图片时的兴奋劲儿——屏幕上那朵小花终于显示出来了，虽然像素颗粒大得能数清楚，但那是自己一行行调试出来的。

现在偶尔翻到老代码，看到那些ChrB(13)和ChrB(10)的组合，还会想起当年对着十六进制编辑器数偏移量的夜晚。技术这东西更新换代快，但那种“不靠外部依赖，纯靠理解协议底层把事办成”的思路，放到今天依然不过时。