无需登录 数据私有 本地保存

Compression Streams API 演示 - 前端实时压缩解压

压缩 开发工具 API 压缩 流 演示
0
0
0
0

Compression Streams API 演示

浏览器端实时流式压缩与解压 · Gzip / Deflate / Deflate-Raw

压缩设置
字符数：0
拖拽文本文件到此处，自动读取内容
解压设置
请确保选择与压缩时一致的格式
字符数：0
拖拽压缩文件（.gz等）到此处，自动解压
✅ 已复制到剪贴板
常见问题与知识点

Compression Streams API 是现代浏览器内置的流式压缩/解压接口，支持 Gzip、Deflate 和 Deflate-Raw 三种格式。它基于 ReadableStream 和 WritableStream，能够流式处理数据，无需一次性加载全部内容到内存，特别适合处理大文件或网络流。相比传统的 JavaScript 压缩库（如 pako），它是浏览器原生实现，性能更高、内存占用更少。

Gzip：最常用的格式，带有完整的 gzip 头部和尾部（包含 CRC32 校验和原始大小），文件扩展名通常为 .gz。HTTP 响应的 Content-Encoding: gzip 使用此格式。

Deflate (zlib)：使用 zlib 封装格式，有 2 字节头部（含压缩方法和窗口大小）和 4 字节 Adler-32 校验尾部。与 HTTP 的 Content-Encoding: deflate 对应。

Deflate-Raw：纯粹的 deflate 压缩数据流，没有任何封装头部或校验尾部。体积最小但缺乏完整性校验，适合自定义协议或已有校验机制的场合。

Compression Streams API 在主流现代浏览器中已得到广泛支持：Chrome 80+（2020年2月）、Edge 80+、Opera 67+、Firefox 113+（2023年5月）、Safari 16.4+（2023年3月）。对于不支持的旧浏览器，可降级使用 pako 等 JavaScript 库作为 polyfill。本工具会自动检测浏览器兼容性并给出提示。

压缩效果取决于数据的重复模式。高度重复的文本（如日志文件、JSON数据、HTML标记）压缩率可达 70%-95%。而随机字符串或已压缩过的数据（如加密数据、图片二进制）压缩效果很差，甚至可能体积反而增大（因压缩算法添加了头部和字典信息）。

小数据注意：对于非常小的文本（<100字节），压缩后的体积可能比原始数据更大，因为压缩格式本身有固定开销（gzip头部约20字节，zlib头部约6字节）。

HTTP 协议中的 Content-Encoding: gzip 或 Content-Encoding: deflate 正是使用这些压缩格式来减小传输体积。Compression Streams API 让开发者可以在客户端直接处理这些压缩数据——例如：
• 在前端压缩表单数据后再上传，节省带宽
• 解压服务端返回的压缩响应体（配合 fetch API）
• 在浏览器中处理 .gz 文件而无需后端服务

目前 Compression Streams API 不支持设置压缩级别（如 Node.js zlib 的 level: 1-9），浏览器会使用默认的平衡级别（通常对应 level 6 左右）。如果对压缩率有更高要求，建议：
• 在数据发送前进行预处理（如格式化JSON去掉多余空格后再压缩）
• 对于超大文件，考虑在 Web Worker 中使用 Compression Streams API 避免阻塞主线程
• 或使用 WebAssembly 版的高压缩率库（如 brotli-wasm）作为补充

流式处理的优势在于内存效率和响应速度：数据以小块（chunk）逐步处理，无需完整加载即可开始输出。适用场景包括：
• 大文件上传：边压缩边分块上传，减少内存峰值
• 实时数据流：WebSocket 消息压缩、日志流压缩
• 视频字幕/文本流：对持续产生的文本进行即时压缩
• Service Worker：在离线缓存中动态压缩资源

解压失败通常由以下原因导致：
• 格式不匹配：压缩时使用 Gzip，解压时却选择了 Deflate（或反之）
• Base64解码错误：输入的 Base64 字符串包含非法字符或格式不正确
• 数据损坏：压缩数据在传输/存储过程中被截断或修改
• 非压缩数据：尝试解压未经压缩的普通文本
• 校验失败：Gzip 的 CRC32 或 Zlib 的 Adler-32 校验不通过（数据损坏）
🔧 相关工具