我已经编写了一个 CSS 服务器，它可以进行最小化和基本的解析/var 替换。服务器正在使用 node.js。
我想从这个服务器压缩我的响应。正如 IRC 中所说，node.js 目前没有 gzip 库，因此我尝试从命令行手动执行此操作（因为我只在不在缓存中时进行 gzip 压缩）。
我将文件数据推送到临时文件，然后使用 exec 调用'gzip -c -9 -q ' + tempFile. 我正确地恢复了压缩数据（似乎），并将正确的Content-Encoding标头发送为'gzip'，但 Chrome 报告：
Error 330 (net::ERR_CONTENT_DECODING_FAILED): Unknown error.
此外，一些独立的 gzip 在线测试人员也会失败（不仅仅是 Chrome）。
我假设这是一件简单的事情，我不知道为浏览器生成 gzip 块，因为我从未尝试过手动操作。
任何帮助都会有所帮助。服务器速度极快，但我需要对内容进行 gzip 压缩才能为最终用户获得最佳性能。
谢谢。
更新
我已经验证我Content-Length是正确的
Node 仍然处于最前沿，似乎还没有很好地处理二进制数据。
Node 的字符串编码有 ascii、binary 和 utf8。[...]“二进制”仅查看 16 位 JavaScript 字符串字符的前 8 位。问题是根据 ECMA 的字符串是 16 位字符串。如果您使用 UTF-8（这是默认值），则在读取字符串时会进行一些规范化，这会破坏 gzip。如果你使用ascii，它显然是行不通的。
如果您同时使用二进制编码读取和写入，它将起作用。只是没有使用 Javascript 字符串字符的高 8 位。如果没有，请尝试将文件直接发送到客户端，而不加载到 Javascript 字符串中，也许可以借助 Node.js 前面的代理服务器。
我自己希望 Google 的 V8 引擎实现真正的二进制字符串数据类型，类似于这个提案http://groups.google.com/group/nodejs/browse_thread/thread/648a0f5ed2c95211/ef89acfe538931a1?lnk=gst&q=binary+type#ef89acfe538931a1
CommonJS 也在提出Binary/B，并且由于 Node 试图跟随 CommonJS，所以对未来有一些希望。
编辑我刚刚发现了node 的 net2分支，其中包含一个二进制缓冲区（参见 src/node_buffer.h）。它似乎是网络全面改革的一部分。
您是否更新了 Content-Length 以匹配压缩后的大小？似乎这可能会破坏解码。