ZIP Uncompressed Size は、ZIP アーカイブ内のファイルが再展開されたときに持つバイト数のことで、アーカイブ内にある間の通常はより小さい Compressed Size（圧縮サイズ）とは対照的な値です。メタデータリーダー ExifTool では、この値は ZipUncompressedSize として表示されます。
どのファイルに含まれているのか、その数値はどこから来ているのか
この値はアーカイブ内に記録されます。ZIP ファイルや、内部的に ZIP コンテナである日常的な形式（.docx、.xlsx、.pptx の各文書、.odt ファイル、.epub 電子書籍、.jar および .apk パッケージなど）には含まれています。RAR、7z などの他のアーカイブ形式も、それぞれ独自の形式で同じ値を保存します。ファイル自体には記録されていても、レポート上では .odt や .epub ファイルについてこの値が表示されない場合があります。
アーカイブは通常、複数のファイルを1つにまとめるために存在しますが、1つのファイルだけをアーカイブしても問題ありません。圧縮プログラムは、パックするときに各ファイルの元のサイズを記録します。これは、アーカイブを作成したどのアプリでも自動的に行われます。例えば、7-Zip、WinRAR、WinZip、macOSのArchive Utility、Windowsの圧縮フォルダー機能、またはzipコマンドラインツールなどです。
この値は「宣言」であることを理解しておくと役に立ちます。アーカイブは、展開時にコンテンツがどれくらいの大きさになるはずかを示しているだけで、実際に展開してみるまで検証はされません。展開時に、実際に取り出されたデータのサイズと保存されているチェックサムが照合されます。
典型的な値の例
値はバイト単位の整数で、多くのアプリでは表示用にKBやMBに変換して見せます。短いWord文書の本文であれば、.docxファイル内部ではそのごく一部の容量しか使っていないのに、「非圧縮で 48219 バイト」などと表示されることがあります。
圧縮後のサイズをこの値で割ると、圧縮率が求められます。この差がどれだけ大きくなるかは、コンテンツの種類と使用した方式に依存します。ZIPファイルの標準方式はDeflateで、代替としてBZIP2やLZMAなどがあります。知っておくとよい注意点として、元のZIPフィールドは32ビットしか保持できないため、4,294,967,295バイト、つまり約4 GB弱までしか扱えません。より大きなコンテンツはZIP64拡張に依存しており、真の値は追加レコードに保存されます。そのため、ZIP64に対応していない非常に古いアプリでは、大きなファイルに対して打ち切られた値や意味のない数値を報告することがあります。
それが重要な理由
最も実用的な使い道は「事前の見積もり」です。この値によって、展開する前に中身が保存先に収まるかどうかを判断できます。特に、テキストやログファイルの小さなアーカイブが、展開すると数ギガバイトに膨れ上がる場合もあり、差が大きくなることがあります。また、圧縮後のサイズと比較することで、圧縮がどれだけ有効だったかも分かります。2つの値がほとんど同じであれば、JPEG、MP3、MP4ファイルのようにもともと圧縮されているコンテンツであり、再圧縮しても容量はほとんど減らないということです。
この値は整合性チェックにも使えます。数百キロバイト程度のアーカイブなのに、非常に大きな非圧縮サイズを宣言している場合は注意が必要です。そのようなアーカイブは、意図的にそう作られており、展開した人のディスク容量を埋め尽くす目的で使われることがあるためです。長期保存用途では逆方向のチェックが有効です。宣言されているサイズと、実際に展開されて得られたサイズを照合することで、古いアーカイブが今も完全であるかを簡単に確認できます。
この値には個人情報は含まれません。データ量の大きさだけを示すものであり、それを作成した人に関する情報は一切含まれません。