右クリック、「圧縮」、待つ、添付、送信。すると受信者はダウンロードし、右クリック、「展開」、また待つ。私たちの多くは何も考えずにこれをしています。何十年もの間、フォルダはこうして送られてきたからです。でも、共有するためだけにフォルダを ZIP に圧縮するのは、もうやめる時期だと私は考えています。ZIP 形式が生まれたのは 1989 年で、当時の課題は文書をフロッピーディスクや遅いモデムに押し込むことでした。いまのフォルダは動画プロジェクト、写真撮影のデータ、コードのリポジトリです。この古い習慣は、得るものより失うもののほうが大きくなっています。
そもそもなぜフォルダを ZIP にするのか？
ほとんどの共有手段が、単一のファイルしか運べないからです。メールの添付はファイルです。チャットへのアップロードもファイルです。昔ながらのダウンロードリンクは 1 つのファイルを指します。フォルダはファイルのツリーなので、そうした経路を通すには、まず 1 つのファイルにまとめる必要がありました。
2 つ目の理由は圧縮で、1989 年には意味がありました。テキストや表計算のファイルは大きく縮むからです。しかしいま人々が送るフォルダの多くでは、この理由はいつの間にか消えています。
ZIP にすると実際に何を失うのか？
実例で考えてみましょう。結婚式の撮影データ 40 GB のフォルダです。RAW 写真、いくつかの MP4 クリップ、編集済みの JPEG が入っています。
- ディスク容量が 2 倍。 元のフォルダの横にアーカイブを作るため、約 40 GB の空きが必要です。受信者は ZIP 用に 40 GB、展開用にさらに 40 GB が必要で、40 GB のフォルダに 80 GB を使います。少なくともアーカイブを削除するまでは。
- 時間が 3 倍。 圧縮を待ち、転送を待ち、受信者が展開するのを待ちます。ノートパソコンでは、数十 GB の圧縮と展開に転送そのものと同じくらい時間がかかることがあります。
- ほとんど圧縮されない。 JPEG、MP4、MOV、そしてほとんどの RAW 形式は、すでに圧縮されています。ZIP にしてもサイズはほぼ変わりません。時間とディスク容量を払って、得るものはほぼゼロです。
- 最後まで何も使えない。 大きなアーカイブが 1 つだと、最後の 1 バイトが届き全体が展開されるまで、受信者は最初の写真すら開けません。
ZIP の中では何が壊れるのか？
コストだけの問題ではありません。トラブルも起こり、しかもたいてい最悪のタイミングで起こります。
長いパス。 Windows は標準で、ファイルパス全体の長さを 260 文字に制限しています。深いサブフォルダとわかりやすい長い名前で Mac 上に作ったプロジェクトフォルダは、Windows で展開するとエラーが出たりファイルが欠けたりすることがあります。
巨大なアーカイブ。 元々の ZIP 形式は、1 ファイルあたり 4 GB、エントリ数 65,535 が上限です。ZIP64 拡張でこの制限はなくなりますが、すべてのパソコンのすべてのツールが同じように扱えるわけではありません。クラウドドライブの中には、大きなフォルダのダウンロードを複数の ZIP ファイルに分割するものもあり、受信者はそれを組み立て直さなければなりません。
ファイル名。 あるツールで作ったアーカイブを別のツールで開くと、ラテン文字以外のファイル名が文字化けすることがあります。キリル文字、ギリシャ文字、中国語、アクセント付きの文字などです。日本語のファイル名でも同じことが起こりえます。構成は届いても、名前が届きません。
不要なファイル。 macOS の Finder で作ったアーカイブには __MACOSX フォルダや .DS_Store ファイルが含まれ、Windows のユーザーを混乱させ、受信者のプロジェクトに紛れ込みます。
1 つのエラーで最初からやり直し。 40 GB のダウンロードが 95 % で失敗すれば、アーカイブは使えません。1 バイトでも壊れていれば、展開が途中で止まることがあります。
どれも珍しいことではありません。数 GB を超えるフォルダを送ったことがあるなら、少なくとも 1 つは経験したことがあるはずです。
StrongFolder はどうやってフォルダをフォルダのまま送るのか？
StrongFolder はシンプルな考えで作りました。ファイルがあなたのブラウザから受信者のブラウザへ直接届くなら、先に 1 つのファイルにまとめる理由はない、ということです。
フォルダを選ぶと、ブラウザがそのツリー、つまりすべてのサブフォルダとファイル名を読み取ります。何もアップロードされません。あなたがリンクを送り、受信者がそれを開いて保存先を選びます。するとファイルは暗号化された WebRTC 接続で 2 つのブラウザ間を直接移動し、それぞれが相対パスを持って、同じフォルダツリーが受信者のディスクに再現されます。
実際に変わること：
- 圧縮も展開もなし。 受信者がリンクを開いた瞬間に転送が始まります。
- 余分なディスク容量は不要。 受信者に必要なのはフォルダ分の容量だけで、フォルダとアーカイブの両方の分は要りません。
- ファイルは 1 つずつ届く。 残りがまだ転送中でも、最初の写真はもう受信者のディスクにあります。
- パスを誠実に扱う。 パスが Windows には長すぎる場合は、名前を短くし、名前を変えたファイルをすべて記したテキストファイルを追加します。黙って消えるものはありません。
- 私たちによるサイズ上限なし。 StrongFolderによるサイズ制限はありません。実際の制約は、受信側デバイスの空き容量、回線速度、そして両方のデバイスがオンラインでいられる時間です。
私がいつも伝えている条件が 2 つあります。フォルダ全体を構成ごと保存するには、受信者がパソコンで Chrome、Edge、Opera などの Chromium 系ブラウザを使う必要があります。他のブラウザでは、ファイルが 1 つずつ、または ZIP としてダウンロードされます。そして、受信者が終えるまであなたのタブを開いたままにしておく必要があります。ファイルはサーバーからではなく、あなたのデバイスから届くからです。それが何もアップロードしないことのトレードオフです。詳しくは送信者がオンラインのままでいる理由で説明しています。
無料 · ブラウザで · 登録不要
それでも ZIP が正しい道具なのはどんなとき？
私は ZIP に反対しているわけではありません。優れた形式です。ただ、送信のたびに必ず踏む手順としては向いていない、ということです。私がいまでも ZIP にするのは次のような場合です。
- アーカイブとして保管するとき。 1 つのファイルのほうが、保存し、チェックサムを取り、何年も保管しやすいからです。
- パスワードが必要なとき。 StrongFolder のリンクにはパスワードがありません。機密性の高いファイルには、暗号化アーカイブ（たとえば AES-256 の 7-Zip）を作り、パスワードを別の手段で伝えることで、どの転送方法でも使える保護を一段追加できます。
- フォルダが何万もの小さなファイルでできているとき。
node_modulesフォルダや小さな画像のキャッシュは、ファイルごとにオーバーヘッドがあるため、1 つのファイルにまとめたほうが速く転送できます。 - 受信者がスマートフォンを使っているとき。 スマートフォンはブラウザからフォルダツリーを保存できないので、どのみちファイルは 1 つずつ、または ZIP として届きます。
それ以外のもの、つまり撮影データ、編集データ、CAD プロジェクト、ゲームの MOD、スキャンしたアーカイブは、フォルダのまま送ってください。
フォルダの ZIP 圧縮をきっぱりやめるには？
メール、クラウドドライブ、転送サービスを並べて比較した手順版をお求めなら、フォルダを ZIP にせずに送る方法をお読みください。非常に大きなフォルダについては、大きなファイルを送る方法で速度と設定を、制限と要件でブラウザの細かな条件をすべて紹介しています。
そして、もしフォルダが壊れて届いたら（名前の誤り、サブフォルダの欠落、どんなことでも）、info@strongfolder.com まで私に直接お知らせください。フォルダこそが StrongFolder の存在理由であり、ぜひ知りたいのです。