为何将Uint8Array包裹在数组中生成的Blob体积更小？

Great question—this is a super common gotcha with the Blob constructor, so let’s break down exactly what’s happening here.

First, let’s get clear on the Blob constructor rules: its first parameter is designed to accept an array of data sources (each can be a Blob, ArrayBuffer, ArrayBufferView, string, etc.). It doesn’t work as intended when you pass a single ArrayBufferView (like your Uint8Array) directly.

What Goes Wrong with new Blob(compressedData)? #

When you pass the Uint8Array directly instead of wrapping it in an array, the Blob constructor treats it as an iterable object. It loops through every single byte in the Uint8Array, converts each byte to a string (using UTF-16 encoding by default), and then packages those strings into the Blob.

Since UTF-16 uses 2 bytes per character (and even more for non-ASCII values), this conversion blows up your file size. That’s why your Blob jumps from ~1.4MB to ~3.7MB—you’re turning every 1-byte binary value into a 2-byte (or larger) string character, which drastically inflates the total size.

Why new Blob([compressedData]) Works Correctly? #

By wrapping the Uint8Array in an array, you’re signaling to the Blob constructor: "This is a single binary data element I want you to process properly." The constructor recognizes the Uint8Array as an ArrayBufferView, reads its underlying binary data directly without any conversion, and creates a Blob that matches the exact size of your compressed data.

To sum it up:

• new Blob([compressedData]) → Reads binary data as-is, preserves your compressed file size.
• new Blob(compressedData) → Iterates over bytes, converts to strings, bloats the size unnecessarily.

Always remember: the Blob constructor expects an array of data sources, not a single source directly!

内容的提问来源于stack exchange，提问作者kodu