ByteScope

RAR5 檔案格式

採用 RAR 5.0 格式的 RAR 壓縮檔。

MIME 類型
application/x-rar-compressed
副檔名
.rar
分類
壓縮與封存

Magic number(檔案簽章)

0x00000000526172211A070100Rar!····'Rar!' RAR5 signature

關於 RAR5 格式

RAR 5.0 是目前的 WinRAR 專有格式,提供修復記錄與強力加密。它 8 位元組的簽章以 01 00 結尾,可藉此和較舊的 4.x 版面配置分辨開來。簽章之後整個檔案是一連串帶型別的區塊,區塊裡幾乎每個欄位都是可變長度整數——每個位元組只用 7 個位元存資料,最高位元當作「還有下一個位元組」的旗標——所以過了位移 12 之後,沒有任何東西固定在同一個位置。這種設計讓小檔案真的小,代價是逐位元組讀檔的程式只能一路解碼往前走,沒辦法直接跳到某個位移。

檔頭結構,一個位元組一個位元組看

位移長度欄位意義
08RAR 5.0 signature52 61 72 21 1A 07 01 00——'Rar!' 這四個字母,後面接 1A 07 01 00。其中 1A 是 DOS 的檔案結束字元,所以把壓縮檔直接 cat 到終端機時會停在這裡,不會把二進位內容整個吐出來。
84Header CRC-32規格把它定義為從 header size 欄位開始、一路涵蓋到選用的 extra area 為止的 CRC32——也就是說它保護的是自己後面的所有內容,而不是整個區塊。
121-10Header size (variable-length integer)第一個可變長度欄位,也是最後一個位在固定位移的欄位。編碼方式是小端序 base 128:每個位元組低 7 位元放資料,最高位元代表後面還有一個位元組。這個欄位吃掉幾個位元組,後面所有位移就跟著移動。
variable1+Header type1 主壓縮檔標頭、2 檔案標頭、3 服務標頭、4 壓縮檔加密標頭、5 壓縮檔結尾標頭。一般壓縮檔在位移 8 的區塊是型別 1;標頭有加密的則是型別 4,沒有密碼就再也讀不下去。
variable1+Header flags所有區塊型別共用。0x0001 代表旗標後面接著 extra area 大小欄位,0x0002 代表接著 data area 大小欄位——換句話說,這兩個位元決定後面那兩個可變長度整數到底存不存在。
variable1+Archive flags (main header only)0x0001 這個壓縮檔是多卷集合的其中一卷、0x0002 有卷號欄位、0x0004 solid(連續)壓縮、0x0008 含修復記錄、0x0010 壓縮檔已鎖定不可修改。
variablevariableFile headers (type 2)每個存進去的檔案各一個區塊,分別帶著該檔內容的 CRC-32、壓縮後與壓縮前大小、屬性、修改時間與壓縮資訊,緊接在後面的就是這個檔案的資料區。
variablevariableEnd of archive header (type 5)檔案裡的最後一個區塊。它自己的旗標 0x0001 代表這一卷不是多卷集合的最後一卷,解壓縮工具就是靠這個知道該去要下一片,而不是回報壓縮檔被截斷。

怎麼跟長得像的格式分開

容易搞混的怎麼分
RAR(4.x)這兩個目錄項目存在的理由就是這個差別,而差別只有一個位元組加一個長度。RAR 4.x 是 7 個位元組的 52 61 72 21 1A 07 00;RAR 5.0 是 8 個位元組的 52 61 72 21 1A 07 01 00。兩者都拼出 'Rar!' 再接 1A 07,決勝點在第 7 個位元組——00 還是 01。簽章以下完全沒有共通處:區塊配置、欄位編碼、壓縮演算法全都不同,所以解析前一定要先在那個位元組分岔。
7-Zip另一個高壓縮率的 Windows 壓縮工具,開頭是 37 7A BC AF 27 1C。兩者常被混用、副檔名也常被互換,但只有 RAR 有修復記錄和原生多卷分割,也只有 7z 可以自由實作。
ZIP50 4B 03 04 對上 52 61 72 21。WinRAR 兩種都能讀能寫,所以副檔名是 .rar、內容其實是 ZIP 的情況很常見;看前四個位元組就結案。另外和 ZIP 不同的是,RAR 不會在離檔尾固定距離處放一份目錄。
Self-extracting .exe規格允許簽章前面放任何資料——SFX 模組的大小與內容明確定義為未指定——並要求讀取端從檔頭開始往後找,建議搜尋範圍不超過 SFX 模組的最大長度,也就是 1 MB。所以一個開頭是 4D 5A('MZ')的檔案,在幾十 KB 之後才出現 RAR 簽章,是完全合法的。
Multi-volume parts同一組多卷檔案的每一卷都帶著相同的 8 位元組簽章,所以 .part1.rar、.part2.rar 和舊式的 .r00 全都會被認成完整的 RAR 壓縮檔。要分辨某一片和一個完整檔案,只能看主標頭的壓縮檔旗標——位元 0x0001 代表分卷、0x0002 代表有卷號——以及壓縮檔結尾區塊的旗標。

常見的壞法

  • 多卷集合裡少了一卷。最後一個區塊不是壓縮檔結尾標頭,或者它的分卷旗標說後面還有,於是解壓縮工具跑來要下一個檔案,而不是宣告檔案損毀。這是最常見的「RAR 壞掉了」回報,而且通常根本沒有壞。
  • 有修復記錄的壓縮檔遇到位元衰減。RAR 是極少數內建前向錯誤更正的格式:只要建檔時加了修復記錄,修復指令真的能就地重建損壞的磁區。沒有修復記錄的話,每個檔案標頭裡的 CRC-32 只能偵測出損壞,救不回來。
  • solid 壓縮把局部損壞放大。主標頭的 0x0004 旗標一旦設起來,這些檔案就是當成一條連續資料流壓的,所以一個壞位元組毀掉的不是一個項目,而是同一個 solid 群組裡後面的每一個檔案。
  • 標頭加密被誤認成空壓縮檔。當位移 8 的區塊是型別 4,連檔名本身都是加密的,沒有密碼就列不出任何東西,工具因此顯示一棵空的樹。檔案是完好的,只是拒絕回答。
  • 文字模式傳輸或前面被塞了額外位元組。自解壓縮檔前面本來就允許有東西,會往後掃簽章的讀取端也應付得來,但只認位移 0 的偵測器會把檔案報成未知;而壓縮資料裡的換行字元被轉換過的話,簽章和標頭讀起來都完美無缺,解出來的每個檔案卻全部 CRC 不符。

這個格式現在還在用嗎

RAR 的處境很特別:技術上很強,卻注定小眾,因為它的專有程度是會影響實際使用的那種。只有 RARLAB 可以寫出這個格式——unrar 解碼器雖然公開原始碼,但授權條款明文禁止拿它去做壓縮器——所以它永遠不可能像 ZIP 那樣變成預設,也沒有任何作業系統內建能寫 RAR 的工具。撐住它的是數量龐大的既有壓縮檔,加上兩個其他常見格式都比不上的功能:修復記錄,等於幫壓縮檔加上真正的前向錯誤更正;還有原生的多卷分割,過去二十年大型檔案之所以都以編號分片散布就是這個原因。新的工作幾乎都已經轉移了——交換用 ZIP、Windows 上要壓縮率就 7z、Unix 上用 tar.zst 或 tar.xz——今天還需要懂這個格式,理由很單純:你還是會收到 .rar,還是得打開它。

在這個站上打開 RAR5 檔

這些全部在你的瀏覽器裡跑,檔案不會離開你的電腦。

相關格式

容易和 RAR5 搞混的格式,可以比對它們的開頭位元組。

格式開頭位元組副檔名
RAR(4.x)52 61 72 21 1A 07.rar
7-Zip37 7A BC AF 27 1C.7z
ZIP50 4B 03 04.zip

常見問題

檔案的 magic number 是什麼?

檔案開頭的前幾個位元組,不管檔名寫什麼,它標明的是真正的格式。PNG 一定以 89 50 4E 47 開頭,ZIP 則是 50 4B 03 04。作業系統、瀏覽器和 file 指令讀的都是這幾個位元組,而不是相信副檔名 — 這就是為什麼把檔案改名並不會改變它實際上是什麼。

我要怎麼自己檢查 magic number?

在 macOS 或 Linux 上,xxd -l 16 檔名 會印出前 16 個位元組;在 Windows 上,PowerShell 的 Format-Hex -Path 檔名 -Count 16。或者把檔案丟進本站的檔案類型辨識工具,它會在本機讀取位元組並告訴你是什麼格式,不會上傳任何東西。

為什麼兩種格式的 magic number 會一樣?

因為其中一種是建立在另一種之上。docx、xlsx、pptx、apk、jar 與 epub 骨子裡都是 ZIP 壓縮檔,所以全都以 ZIP 的簽章開頭;要分辨它們得看裡面的項目。Java class 檔和 macOS 的通用二進位檔都以 CA FE BA BE 開頭,靠緊接其後的欄位區分。

有完全沒有 magic number 的檔案嗎?

有。XML、HTML、JSON、SVG、CSV 這類以文字為基礎的格式沒有固定的位元組簽章,所以改用結構來辨識:開頭的 <?xml 宣告、<svg 元素,或是 { 後面接著帶引號的鍵。這種偵測是合理推測而非確定,因此本參考頁會把這些格式標示為結構偵測。

magic number 相符就代表檔案安全嗎?

不代表。它告訴你的是格式,不是內容是否無害 — 一個貨真價實的 PDF 或 docx 仍然可能夾帶惡意內容。辨識真實類型是有用的第一道檢查,尤其在副檔名和位元組不一致的時候,但它不是惡意軟體掃描。

手上有檔案可能是 RAR5?用檔案類型辨識工具查出來 — 它在本機讀取 magic number,不上傳任何東西。或者瀏覽所有格式。