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 giải thích chi tiết điều này.
Miễn phí · ngay trên trình duyệt · không cần đăng ký
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_moduleshay 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. Với các thư mục rất lớn, Cách gửi file lớn nói về tốc độ và cách thiết lập, còn Giới hạn và yêu cầu 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. Thư mục là lý do StrongFolder tồn tại, và tôi muốn biết.