# Thư mục xứng đáng được đối xử tốt hơn ZIP

Source: https://help.strongfolder.com/vi/blog/folders-deserve-better-than-zip/
Updated: 2026-11-05

> Chúng tôi nghĩ bạn nên ngừng nén thư mục chỉ để chia sẻ. Đóng gói một thư mục lớn tốn thời gian và gấp đôi dung lượng ổ đĩa, file media hầu như không nhỏ đi, còn file nén khổng lồ dễ hỏng hoặc làm sai đường dẫn dài. StrongFolder gửi thư mục dưới dạng thư mục, từ trình duyệt sang trình duyệt, nên người nhận có đúng các thư mục con và tên file.

Nhấp chuột phải, “Nén”, chờ, đính kèm, gửi. Rồi người nhận tải về, nhấp chuột phải, “Giải nén”, lại chờ. Hầu hết
chúng ta làm vậy mà không cần nghĩ — đó là cách thư mục được gửi đi suốt nhiều thập kỷ. Tôi nghĩ đã đến lúc ngừng
nén thư mục chỉ để chia sẻ. Định dạng ZIP ra đời từ năm 1989, khi bài toán là nhét tài liệu vừa đĩa mềm và modem
chậm. Thư mục của chúng ta ngày nay là dự án video, buổi chụp ảnh và kho mã nguồn, và thói quen cũ tốn nhiều hơn
những gì nó tiết kiệm được.

## Vì sao chúng ta lại nén thư mục?

Vì hầu hết các kênh chia sẻ chỉ mang được từng file. Tệp đính kèm e-mail là một file. Tải lên trong chat là một
file. Một link tải về kiểu cũ trỏ tới một file. Thư mục là một cây file, nên phải được đóng gói thành một file
trước khi đi qua những đường ống đó.

Nén dữ liệu là lý do thứ hai, và vào năm 1989 nó rất quan trọng: văn bản và bảng tính co lại rất nhiều. Nhưng lý
do đó đã lặng lẽ biến mất với phần lớn thư mục mà mọi người gửi hôm nay.

## Nén thư mục thực sự tốn của bạn những gì?

Lấy một ví dụ thật: một thư mục 40 GB từ buổi chụp đám cưới — ảnh RAW, vài clip MP4, một số ảnh JPEG đã chỉnh.

- **Dung lượng ổ đĩa, gấp đôi.** Bạn cần khoảng 40 GB trống cho file nén bên cạnh bản gốc. Người nhận cần 40 GB
  cho file ZIP và thêm 40 GB để giải nén — 80 GB cho một thư mục 40 GB, ít nhất là cho đến khi họ xóa file nén.
- **Thời gian, gấp ba.** Bạn chờ lúc nén, rồi chờ lúc truyền, rồi người nhận chờ lúc giải nén. Trên laptop, nén
  và giải nén hàng chục gigabyte có thể lâu ngang việc truyền.
- **Gần như không nén được gì.** JPEG, MP4, MOV và hầu hết định dạng RAW vốn đã được nén. Nén ZIP chúng hầu như
  không đổi dung lượng. Bạn trả bằng thời gian và dung lượng ổ đĩa mà gần như không nhận lại được gì.
- **Không dùng được gì cho đến phút cuối.** Với một file nén lớn, người nhận không thể mở tấm ảnh đầu tiên cho
  đến khi byte cuối cùng về tới và toàn bộ được giải nén.

## Điều gì bị hỏng bên trong một file ZIP?

Chi phí là một chuyện. Mọi thứ còn trục trặc, và thường vào lúc tệ nhất.

**Đường dẫn dài.** Theo mặc định, Windows giới hạn độ dài đầy đủ của đường dẫn file ở 260 ký tự. Một thư mục dự án
tạo trên Mac với nhiều thư mục con lồng nhau và tên mô tả dài có thể bị lỗi hoặc mất file khi giải nén trên
Windows.

**File nén khổng lồ.** Định dạng ZIP gốc dừng ở 4 GB mỗi file và 65.535 mục. Phần mở rộng ZIP64 bỏ các giới hạn
đó, nhưng không phải công cụ nào trên máy nào cũng xử lý giống nhau. Một số ổ đám mây chia việc tải một thư mục
lớn thành nhiều file ZIP, mà người nhận sau đó phải ghép lại.

**Tên file.** File nén tạo bằng một công cụ và mở bằng công cụ khác có thể làm hỏng tên file không phải chữ Latin
— chữ Kirin, chữ Hy Lạp, chữ Hán, chữ có dấu. Cấu trúc thì đến nơi, nhưng tên thì không.

**Rác.** File nén tạo bằng Finder trên macOS có kèm thư mục `__MACOSX` và file `.DS_Store`, khiến người dùng
Windows bối rối và lẫn vào dự án của người nhận.

**Một lỗi, làm lại từ đầu.** Nếu lần tải 40 GB thất bại ở 95 %, file nén vô dụng. Nếu một byte bị hỏng, việc giải
nén có thể dừng giữa chừng.

Không có gì trong số này là hiếm gặp. Nếu bạn từng gửi một thư mục lớn hơn vài gigabyte, có lẽ bạn đã gặp ít nhất
một trong số đó.

## StrongFolder gửi thư mục dưới dạng thư mục như thế nào?

Chúng tôi xây dựng StrongFolder trên một ý tưởng đơn giản: nếu file đi trực tiếp từ trình duyệt của bạn sang
trình duyệt người nhận, chẳng có lý do gì phải gói chúng thành một file trước.

Khi bạn chọn một thư mục, trình duyệt của bạn đọc cây thư mục — mọi thư mục con và tên file. Không có gì được tải
lên. Bạn gửi link; người nhận mở link và chọn nơi lưu. Sau đó file đi trực tiếp giữa hai trình duyệt qua một kết
nối WebRTC được mã hóa, mỗi file kèm đường dẫn tương đối của nó, và đúng cây thư mục đó xuất hiện trên ổ đĩa người
nhận.

Điều này thay đổi gì trên thực tế:

- **Không nén, không giải nén.** Lần truyền bắt đầu ngay khi người nhận mở link.
- **Không tốn thêm dung lượng ổ đĩa.** Người nhận cần chỗ cho thư mục, không phải cho thư mục cộng thêm file nén.
- **File đến từng cái một.** Những tấm ảnh đầu tiên đã nằm trên ổ đĩa người nhận trong khi phần còn lại vẫn đang
  trên đường.
- **Đường dẫn được xử lý minh bạch.** Nếu một đường dẫn quá dài với Windows, chúng tôi rút ngắn tên và thêm một
  file văn bản liệt kê mọi file đã bị đổi tên. Không có gì biến mất trong im lặng.
- **Chúng tôi không đặt giới hạn dung lượng.** StrongFolder không đặt giới hạn dung lượng. Giới hạn thực tế là dung lượng ổ đĩa còn trống của người nhận, tốc độ kết nối và thời gian cả hai thiết bị cùng trực tuyến.

Có hai điều kiện tôi luôn nhắc đến. Để lưu cả thư mục với nguyên cấu trúc, người nhận cần Chrome, Edge, Opera hoặc
một trình duyệt Chromium khác trên máy tính — các trình duyệt khác tải file từng cái một hoặc dưới dạng ZIP. Và tab
của bạn phải mở cho đến khi người nhận tải xong, vì file đến từ thiết bị của bạn, không phải từ máy chủ. Đó là sự
đánh đổi của việc không tải lên gì cả. [Vì sao người gửi phải trực tuyến](https://help.strongfolder.com/en/guides/why-sender-stays-online/)
giải thích chi tiết điều này.

[Gửi file ngay](https://strongfolder.com)
## Khi nào ZIP vẫn là công cụ đúng?

Tôi không chống lại ZIP. Đó là một định dạng tuyệt vời — chỉ là không nên là bước mặc định trước mỗi lần gửi. Tôi
vẫn nén khi:

- **Tôi lưu trữ.** Một file thì dễ cất giữ, tính checksum và giữ trong nhiều năm hơn.
- **Tôi cần mật khẩu.** Link StrongFolder không có mật khẩu. Với file nhạy cảm, một file nén mã hóa (ví dụ 7-Zip
  với AES-256) cùng mật khẩu gửi qua kênh khác sẽ thêm một lớp bảo vệ dùng được với mọi cách truyền.
- **Thư mục có hàng chục nghìn file rất nhỏ.** Một thư mục `node_modules` hay một bộ nhớ đệm ảnh nhỏ truyền nhanh
  hơn khi là một file, vì mỗi file đều có chi phí riêng.
- **Người nhận dùng điện thoại.** Điện thoại không lưu được cây thư mục từ trình duyệt, nên dù sao file cũng đến
  từng cái một hoặc dưới dạng ZIP.

Với mọi thứ còn lại — buổi chụp, bản dựng, dự án CAD, mod game, kho tài liệu scan — hãy gửi thư mục nguyên như
vốn có.

## Làm sao để ngừng nén thư mục hẳn?

Nếu bạn muốn bản hướng dẫn từng bước, với e-mail, ổ đám mây và dịch vụ chuyển file được so sánh cạnh nhau, hãy đọc
[Cách gửi thư mục không cần nén](https://help.strongfolder.com/en/guides/send-folder-without-zipping/).
Với các thư mục rất lớn, [Cách gửi file lớn](https://help.strongfolder.com/en/guides/send-large-files/) nói về tốc độ và cách thiết lập, còn
[Giới hạn và yêu cầu](https://help.strongfolder.com/en/limits/) liệt kê mọi chi tiết về trình duyệt.

Và nếu có lúc nào một thư mục đến nơi bị hỏng — sai tên, thiếu thư mục con, bất cứ điều gì — hãy viết cho tôi qua
[info@strongfolder.com](mailto:info@strongfolder.com). Thư mục là lý do StrongFolder tồn tại, và tôi muốn biết.

## FAQ

### Tôi có cần nén thư mục để gửi bằng StrongFolder không?

Không. Hãy chọn chính thư mục đó; StrongFolder đọc cây thư mục và gửi từng file kèm đường dẫn của nó. Thư mục được gửi nguyên dạng thư mục: giữ nguyên thư mục con và tên file, không nén gì cả.

### Người nhận cần gì để nhận lại nguyên thư mục?

Để lưu cả thư mục kèm cấu trúc, cần File System Access API: Chrome, Edge, Opera và các trình duyệt Chromium khác trên máy tính. Các trình duyệt khác có thể tải từng file hoặc tải dưới dạng một file ZIP.

### Có khi nào nén ZIP vẫn là lựa chọn tốt hơn không?

Có: khi lưu trữ lâu dài, khi cần file nén mã hóa có mật khẩu, hoặc với thư mục chứa hàng chục nghìn file rất nhỏ, vốn truyền nhanh hơn khi gói thành một file.