転送後にファイルが破損？データ損失を防ぐ方法

最新のHTTPSベースのサービスでは、TCPチェックサム、TLS 1.3の完全性、AES-GCM認証タグがすべて転送中のビットエラーを検出するため、転送後のファイル破損はまれです。破損が発生する場合、通常はエンドポイント側です。中断されたダウンロードが部分ファイルを書き込んだ、書き込み中のディスクエラー、またはストリームを切り詰めるクライアントのバグなどです。両側でSHA-256ハッシュを検証してください。ハッシュが一致すればファイルは同一です。一致しない場合は再転送です。AES-256-GCMを使用するサービスは組み込み認証を提供するため、復号の成功自体が完全性の証明となります。

転送中の破損がまれな理由

すべてのHTTPSリクエストはTLS完全性チェックを持ちます。AES-256-GCMやChaCha20-Poly1305などのAEAD暗号を使うTLS 1.3は、レコードごとに認証タグを生成します。通信線上でビットが反転すると、タグ検証が失敗し、アプリケーションに到達する前にレコードが拒否されます。TCPはセグメントごとに独自の16ビットチェックサムを追加します。両方のチェックを通過する無音の破損の確率は天文学的に低く、TLS単独でおよそ 2^128 分の1です。

暗号化されていないプロトコル（FTP、プレーンHTTP）は堅牢性が低いです。TCPのチェックサムは一部のエラーを見逃します。不良RAMを持つ中間ハードウェアでビットが無音で反転することがあります。これは、資格情報漏洩の問題を超えて、大容量転送でプレーンFTPを避ける実際の理由です。

破損が実際に発生する場所

転送後の破損の一般的な原因を、おおまかな頻度順に示します。

中断されたダウンロードが部分ファイルとして保存される。 75パーセントで接続を失うブラウザのダウンロードは、しばしば75パーセント完了したファイルを保存し、ダウンロードフォルダに「存在」するように見えるが開くと壊れています。ChromeとFirefoxは現在、通常これらを .crdownload または .part としてフラグ付けしますが、古いバージョンや一部のサードパーティマネージャーはそうしません。

ローカルディスクの書き込みエラー。 故障しかけた外付けドライブ、満杯のディスク、または不良セクタにより、ファイルが部分的に書き込まれます。Windowsは常にこれを明確に表示するわけではありません。macOSは時々表示します。

ウイルス対策の隔離によるファイル変更。 リアルタイムAVは、ダウンロード途中でアーカイブを「サニタイズ」するために実行可能セクションを削除したりアーカイブを変更したりすることがあり、技術的にはファイルが存在するが論理的には破損した状態になります。

ストリームを切り詰めるクライアントのバグ。 よくメンテナンスされたクライアントではまれですが、一部のレガシーFTPクライアント、古いSyncToyのバージョン、またはカスタムアップロードスクリプトには既知の切り詰めバグがあります。

SHA-256ハッシュで検証する

ファイルが無傷で転送されたことを証明する唯一の信頼できる方法は、両側で暗号学的ハッシュを計算して比較することです。SHA-256は普遍的で、高速（AES-NI搭載の最新CPUで500MB/秒）、衝突耐性があります。

macOS/Linux: shasum -a 256 file.mov。Windows 10以降: certutil -hashfile file.mov SHA256。どちらも64文字の16進文字列を生成します。リンクと一緒にハッシュを送信する（「SHA256: a1b2c3...」）ことで、受信者はダウンロード後に検証できます。

ハッシュが一致すれば、ファイルはビット単位で同一です。異なる場合は再転送します。

AES-GCMで完全性を無料で得る

AES-256-GCM（関連データ付き認証暗号）で暗号化するサービスは、すべてのブロックに認証タグを含めます。受信者が復号するとき、タグ検証の失敗は暗号文が改ざんまたは破損したことを意味し、復号は「GCM authentication failed」のようなエラーで即座に失敗します。

つまり、ファイルが正常に復号されれば、変更されていないことが保証されます。受信者側で別途SHA-256チェックは不要です。HexaTransfer、SmashのSecureモード、SwissTransfer、Tresorit Send、Proton Driveはすべて、まさにこの理由でAES-GCMまたはXChaCha20-Poly1305（類似の認証モード）を使用します。

部分的なダウンロードを検出する

部分的なダウンロードの明白な兆候：ディスク上のファイルサイズが、転送ページで告知されたサイズよりも小さい。ダウンロードしたファイルを右クリックし、サイズを確認し、送信者が報告したサイズと比較します。一致しない場合、ダウンロードは完了していません。

メディアファイルはこれを浮き彫りにするのが得意です。部分的なMP4は1分再生されてから途切れます。部分的なZIPは展開時に「アーカイブが壊れています」を返します。部分的なPDFは最初の数ページを表示してからエラーになります。テキストファイルはしばしば正常に開きますが無音で切り詰められており、気づきにくい最悪のケースです。

不安定な接続のための再開可能なダウンロード

受信者の接続がダウンロード中に切れる場合、再開サポートが重要です。HTTPレンジリクエスト（RFC 7233）により、クライアントはオフセットから再開できます。curlは -C - で、wgetは -c で処理します。ブラウザベースのダウンロードマネージャーは様々です。FirefoxとChromeは、サーバーがレンジをサポートすれば同じセッション内で再開します。

プレーンPOSTを使用するサービスや、Rangeヘッダーを公開しないサービスは、切断時に完全な再スタートを強制します。20Mbpsのセルラー回線での10GBファイルでは、非常に厳しい時間です。

ウイルス対策の干渉

Windows Defender、Avast、Bitdefender、McAfeeは、スキャンのためにダウンロードをストリーム中にインターセプトすることがあります。通常、それは透過的です。時々、アーカイブ形式や実行ファイルについては、AVがファイルを「クリーン」にすることを決定し、内容を削除するかファイルを隔離スタブに置き換えます。

ファイルが受信者のマシンで一貫して破損してダウンロードされる場合、一時的にリアルタイムAVを無効にして再試行してもらいます。再試行が成功すればAVが原因です。転送サービスのドメインをAVの除外リストに追加します。

ディスク容量とファイルシステムの問題

宛先ディスクが書き込み中に満杯になると、ダウンロードが破損することもあります。macOSはAPFSスナップショット層を通じて書き込み、通常はエラーをクリーンに表示します。Windows NTFSは無音で切り詰める傾向があります。外付けドライブでは、10GBのダウンロードを開始する前に空き容量を確認してください。

ファイルシステムのバグはまれですが存在します。古いWindowsバージョンのexFATには、歴史的に4GB超のファイルで切り詰めバグがありました。ext4、NTFS、APFSは現在のOSバージョンで信頼できます。

メディア固有のバリデーターで確認する

動画ファイル：ffprobe -v error file.mp4 は無音でエラーを報告します。出力が空の場合、コンテナ構造は無傷です。詳細には、ffmpeg -v error -i file.mp4 -f null - ですべてのフレームを走査し、デコードエラーを報告します。

PDF：Acrobatの「検証」コマンドがオブジェクト構造をチェックします。qpdf --check file.pdf はコマンドラインで同じことをします。

DICOM医療画像：DCMTKの dcmdump file.dcm は必須タグと構造を検証します。これは無効なファイルを拒否する病院のPACSシステムにとって重要です。

アーカイブ：unzip -t file.zip と 7z t file.7z は展開せずにテストします。高速で、ほとんどの破損をキャッチします。

完全性が組み込まれたサービスを選ぶ

重要な転送には、暗号学的完全性を設計で提供するサービスを選んでください。エンドツーエンドのAES-GCM暗号化、ダウンロードページでのSHA-256ハッシュ表示、クライアントでの明示的なチェックサム検証はすべて、希望ではなく証拠を提供します。HexaTransferはAES-256-GCMを使用するため、復号の成功自体がファイルが変更されていないことを検証し、転送あたり10GBの上限でほとんどのプロフェッショナルな成果物をカバーします。

hexatransfer.comでお試しください — 無料、登録不要、最大10GB。