.whl 文件格式，代表“Wheel”，是一种基于 ZIP 的存档格式，专为分发和安装 Python 包而设计。它在 PEP 427 中作为旧 .egg 格式的替代品引入。与源代码分发相比，.whl 格式提供了一种更有效、更快速且与平台无关的方式来分发 Python 包。
.whl 文件本质上是一个 ZIP 存档，遵循特定的目录结构和命名约定。该存档包含 Python 包的源代码、已编译的字节码以及安装所需元数据文件。.whl 格式允许更快的安装，因为它消除了在安装期间执行 setup.py 和编译包的需要。
.whl 文件的命名约定遵循特定模式：{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl。让我们分解每个组件： - {distribution}：Python 包的名称。 - {version}：包的版本号。 - {build tag}（可选）：指示包的特定版本。 - {python tag}：指示 Python 实现和版本，例如 CPython 3.8 的 cp38。 - {abi tag}：指定应用程序二进制接口 (ABI)，例如具有 Unicode UCS-4 的 CPython 3.8 的 cp38m。 - {platform tag}：指定目标平台，例如 64 位 Windows 的 win_amd64。 例如，名为 mypackage-1.0.0-cp38-cp38-win_amd64.whl 的 .whl 文件表示为 64 位 Windows 上的 CPython 3.8 构建的“mypackage”的 1.0.0 版本。
.whl 存档中的目录结构遵循特定的布局。在顶层，有一个“{distribution}-{version}.dist-info”目录，其中包含元数据文件。实际的包代码和资源存储在一个名为“{distribution}-{version}.data”的单独目录中。 在“.dist-info”目录中，您通常会找到以下文件： - METADATA：包含包元数据，例如名称、版本、作者和依赖项。 - WHEEL：指定 Wheel 规范的版本和包的兼容性标记。 - RECORD：.whl 存档中包含的所有文件的列表以及用于完整性验证的哈希值。 - entry_points.txt（可选）：定义包的入口点，例如控制台脚本或插件。 - LICENSE.txt（可选）：包含包的许可信息。 “.data”目录保存实际的包代码和资源，根据包的内部结构进行组织。
要创建 .whl 文件，您通常使用 setuptools 或 pip 等工具。这些工具会根据包的 setup.py 文件或 pyproject.toml 配置自动生成必要的元数据文件，并将代码打包到 .whl 格式中。例如，在包的目录中运行 `python setup.py bdist_wheel` 或 `pip wheel .` 将在“dist”目录中生成一个 .whl 文件。
从 .whl 文件安装包时，pip 等工具会处理安装过程。它们会提取 .whl 存档的内容，使用 RECORD 文件中的信息验证文件的完整性，并将包安装到 Python 环境中的适当位置。“.dist-info”目录中的元数据文件用于跟踪已安装的包及其依赖项。
.whl 格式的主要优点之一是它能够提供预构建的、特定于平台的包。这意味着用户可以安装包，而无需具有兼容的构建环境或从源代码编译包。.whl 文件可以针对不同的平台和 Python 版本进行构建和分发，从而更容易将包分发给广泛的用户。
与源代码分发相比，.whl 格式的另一个好处是其更快的安装速度。由于 .whl 文件包含预构建的字节码，并且在安装期间不需要执行 setup.py，因此安装过程明显更 快。对于具有复杂构建过程或依赖项的包，这一点尤其明显。
.whl 格式还支持各种功能和扩展。例如，它允许在存档中包含已编译的扩展（例如 C 扩展），从而方便分发带有本机代码的包。它还支持“直接 URL 引用”（PEP 610）的概念，该概念允许为包依赖项指定 URL，从而实现更灵活的分发机制。
总之，.whl 存档格式是一种标准化且高效的分发 Python 包的方式。与源代码分发相比，它提供了一个与平台无关且更快的安装过程。通过遵循特定的目录结构和命名约定，.whl 文件将包代码、元数据和依赖项封装在一个存档中。.whl 格式的广泛采用极大地简化了 Python 包的分发和安装，使开发人员更容易共享他们的库，也使用户能够无缝地安装它们。
檔案壓縮透過減少冗餘，讓相同的資訊佔用更少的位元。可壓縮的上限受資訊理論約束：對於無失真壓縮，上界是信源熵（參見香農的信源編碼定理以及他於 1948 年發表的《通信的數學理論》）。對於有失真壓縮，碼率與感知品質之間的權衡由率失真理論描述。
多數壓縮器分兩個階段。首先，模型會預測或揭露資料中的結構。接著，編碼器把這些預測轉成近乎最優的位元型態。經典的建模家族是 Lempel–Ziv：LZ77 (1977)及 LZ78 (1978) 會偵測重複子字串並輸出參照而非原始位元組。編碼面則由霍夫曼編碼（見原始論文1952）為較常出現的符號分配更短的碼字。算術編碼與範圍編碼再進一步逼近熵極限，而現代的非對稱數值系統（ANS）則用查表方式取得相似壓縮率。
DEFLATE（被 gzip、zlib 與 ZIP 採用）把 LZ77 和霍夫曼編碼結合。其規格完全公開：DEFLATERFC 1951、zlib 封裝RFC 1950以及 gzip 檔案格式RFC 1952。Gzip 針對串流設計並明確不提供隨機存取。PNG 影像則把 DEFLATE 規範為唯一的壓縮方式（視窗最多 32 KiB），詳見 PNG 規格「Compression method 0… deflate/inflate… at most 32768 bytes」與W3C/ISO PNG 第二版。
Zstandard (zstd)： 針對高壓縮率與極快解壓而設計的通用壓縮器。格式記載於RFC 8878（以及HTML 鏡像）和 GitHub 上的參考規格文件。與 gzip 類似，基本框架並不追求隨機存取。zstd 的絕招是字典：從語料擷取的小樣本能大幅改善許多小型或相似檔案的壓縮（參閱python-zstandard 字典文件與Nigel Tao 的示例）。各實作同時支援「非結構化」與「結構化」字典（討論）。
Brotli： 為網頁內容（如 WOFF2 字體、HTTP）優化，結合靜態字典與類 DEFLATE 的 LZ+熵編碼核心。規格載於RFC 7932，文件同時指出滑動視窗為 2WBITS-16，WBITS 介於 [10, 24]（1 KiB-16 B 至 16 MiB-16 B），並且不嘗試隨機存取。Brotli 常在網頁文字上優於 gzip，解碼也相當快速。
ZIP 容器： ZIP 是一種檔案封存格式，可存放使用多種壓縮法（deflate、store、zstd 等）的項目。權威規格是 PKWARE 的 APPNOTE（參見APPNOTE 入口、托管副本以及美國國會圖書館的概覽ZIP File Format (PKWARE)/ZIP 6.3.3）。
檔案壓縮是一個減少檔案或檔案群大小的過程，通常用於節省儲存空間或加速網路傳輸。
檔案壓縮運作原理，透過識別並移除數據中的冗餘資訊。它使用演算法將原始數據編碼在較小的空間裡。
兩種主要的檔案壓縮類型是無失真及有失真壓縮。無失真壓縮可以完美地恢復原始檔案，然而有失真壓縮在一些資料品質的損失下能得到更大的壓縮程度。
一個常見的檔案壓縮工具範例是WinZip，它支援多種壓縮格式包括ZIP與RAR。
在無失真壓縮中，質量保 持不變。然而，在有失真壓縮中，可能會有顯著的質量下降，因為它刪除了一些較不重要的數據以便更大程度地減少檔案大小。
是的，相對於資料的完整性來說，檔案壓縮是安全的，尤其是無失真壓縮。然而，如同所有檔案，被壓縮的檔案也可能受到惡意軟體或病毒的攻擊，所以總是需要有專業的安全軟體以保護。
幾乎所有種類的檔案都可以被壓縮，包括文字檔案、圖像、音訊、視頻和軟體檔案。然而，壓縮程度可以因檔案類型而有顯著的不同。
ZIP檔是一種使用無失真壓縮以減少一個或多個檔案大小的檔案格式。在ZIP檔中的多個檔案被有效地打包為單一的檔案，這也讓分享變得更加容易。
技術上可行，儘管額外的大小減少可能非常小或甚至適得其反。壓縮一個已經壓縮過的檔案有時可能會增加其大小，原因在於壓縮演算法所增加的metadata。
解壓壓縮的檔案，通常需要一個解壓縮或解zip的工具，像是WinZip或7-Zip。這些工具可以从壓縮格式中提取原始檔案。