複数のサーバーに部分的に保存されているファイルをダウンロードする必要があるプロジェクトに取り組んでいます。
要件：
自分の「自転車」を発明する前に、既存の解決策があるかどうかを確認したいと思います。googleとgithubの検索で十分なものが見つかりませんでした。
そのような解決策がない場合は、新しいファイルAPIの制限に関するアドバイスがあります。そんなに大きなファイルも扱えるのでしょうか？
率直に言って、私はあなたがこれをやってのけることができるだろうと真剣に疑っています。
使用しているサイズのファイルの場合、エンドユーザーにBitTorrentクライアントをインストールして、その方法でダウンロードを配布するように依頼する方がはるかに良いでしょう。
とはいえ、考慮すべきいくつかの障害：
2つのファイル関連のAPIがあります。オブジェクトですが、これは、によって選択されたファイル、またはドラッグアンドドロップによってドロップさFileれたファイルを読み取るためだけのものです。<input type="file">
必要なのはFileSystemAPIですが、非常に重要な注意点が1つあります。このAPIは、コンテンツがユーザーから隠されている仮想ファイルシステムを提供します。実際には、これは、ディスクに書き込むファイルがユーザーにはわからない場所（など\Users\Me\AppData\Local\Chrome\User Data\Default\File System\000\）に保存されることを意味し、ユーザーは、ブラウザーの通常のファイルダウンロードメカニズムを開始する特別に構築されたリンクをクリックする必要があります（この場合は、ファイルを「仮想」ファイルシステムからユーザーのダウンロードフォルダーにコピーすることを意味します。
仮想ファイルシステムにサンドボックス化され、ファイルを宛先にコピーする必要があるため、ユーザーは2* nバイトの空き容量が必要です。したがって、50GBのファイルをダウンロードするには100GBが必要です。
仮想ファイルシステムはクォータを要求する必要があり、書き込みを開始する前にユーザーが要求を承認する必要があります。良いニュースはそれですが...
webkitStorageInfo.requestQuota(webkitStorageInfo.PERSISTENT, 53687091200);
...私にとっては成功しているように見えましたが、ブラウザがこのような大量のストレージスペースの要求を常に許可するという保証はありません。
Blobオブジェクトを使用して仮想ファイルシステムにsを書き込むことができFileEntryます。ドキュメントは不完全ですが、ファイル内の任意の位置に書き込むことができるといいのですが。
XHRでは、応答データをストリーミングできないようです。 XHRに（新機能）として応答を返すように要求する場合、応答Blob全体をメモリにバッファリングする必要があります。
XHRオブジェクトをポーリングして応答データを取得できるようにするハックがありますが、前のバイトを既に読み取っていても、ブラウザーは必ず応答全体をバッファーに入れます。
これは、個々のファイル部分が数メガバイトを超えてはならないことを意味します。800バイトの平均HTTP要求/応答ヘッダーオーバーヘッド-1kBで、50GBのネットワーク上のHTTPヘッダーだけで追加の50MBを見ています。（.1％はごくわずかなオーバーヘッドであり、考慮すべき点です。）
繰り返しますが、それをしないでください。ジョブに適したツール（この場合はBitTorrent）を使用してください。どこかに、事前設定されたトレントのダウンロードを自動的に開始するように設定できるスタンドアロンのBTクライアントがあると思います。したがって、ユーザーはダウンロードリンクをクリックして、EXEを開始し、途中で実行するだけです。