如何對網站進行歸檔
導讀我最近深入研究了網站歸檔，因為有些朋友擔心遇到糟糕的系統管理或惡意刪除時失去對放在網上的內容的控制權。這使得網站歸檔成為系統管理員工具箱中的重要工具。事實證明，有些網站比其他網站更難歸檔。本文介紹了對傳統網站進行歸檔的過程，並闡述在面對最新流行單頁面應用程式（SPA）的現代網站時，它有哪些不足。
轉換為簡單網站
手動編碼 HTML 網站的日子早已不復存在。現在的網站是動態的，並使用最新的 Java、PHP 或 Python 框架即時構建。結果，這些網站更加脆弱：資料庫崩潰、升級出錯或者未修復的漏洞都可能使資料丟失。在我以前是一名 Web 開發人員時，我不得不接受客戶這樣的想法：希望網站基本上可以永久工作。這種期望與 web 開發“快速行動和破除陳規”的理念不相符。在這方面，使用Drupal 內容管理系統（CMS）尤其具有挑戰性，因為重大更新會破壞與第三方模組的相容性，這意味著客戶很少承擔的起高昂的升級成本。解決方案是將這些網站歸檔：以實時動態的網站為基礎，將其轉換為任何 web 伺服器可以永久服務的純 HTML 檔案。此過程對你自己的動態網站非常有用，也適用於你想保護但無法控制的第三方網站。
對於簡單的靜態網站，古老的 Wget 程式就可以勝任。然而映象儲存一個完整網站的命令卻是錯綜複雜的：
$ nice wget --mirror --execute robots=off --no-verbose --convert-links \
--backup-converted --page-requisites --adjust-extension \
--base=./ --directory-prefix=./ --span-hosts \
--domains=www.example.com,example.com https://www.example.com/
以上命令下載了網頁的內容，也抓取了指定域名中的所有內容。在對你喜歡的網站執行此操作之前，請考慮此類抓取可能對網站產生的影響。上面的命令故意忽略了 robots.txt 規則，就像現在歸檔者的習慣做法，並以儘可能快的速度歸檔網站。大多數抓取工具都可以選擇在兩次抓取間暫停並限制頻寬使用，以避免使網站癱瘓。
上面的命令還將獲取 “頁面所需（LCTT 譯註：單頁面所需的所有元素）”，如樣式表（CSS）、影象和指令碼等。下載的頁面內容將會被修改，以便連結也指向本地副本。任何 web 伺服器均可託管生成的檔案集，從而生成原始網站的靜態副本。
以上所述是事情一切順利的時候。任何使用過計算機的人都知道事情的進展很少如計劃那樣；各種各樣的事情可以使程式以有趣的方式脫離正軌。比如，在網站上有一段時間很流行日曆塊。內容管理系統會動態生成這些內容，這會使爬蟲程式陷入死迴圈以嘗試檢索所有頁面。靈巧的歸檔者可以使用正則表示式（例如 Wget 有一個 --reject-regex 選項）來忽略有問題的資源。如果可以訪問網站的管理介面，另一個方法是禁用日曆、登入表單、評論表單和其他動態區域。一旦網站變成靜態的，（那些動態區域）也肯定會停止工作，因此從原始網站中移除這些雜亂的東西也不是全無意義。
Java 噩夢
很不幸，有些網站不僅僅是純 HTML 檔案構建的。比如，在單頁面網站中，web 瀏覽器通過執行一個小的 Java 程式來構建內容。像 Wget 這樣的簡單使用者代理將難以重建這些網站的有意義的靜態副本，因為它根本不支援 Java。理論上，網站應該使用漸進增強技術，在不使用 Java 的情況下提供內容和實現功能，但這些指引很少被人遵循 —— 使用過 No 或 uMatrix 等外掛的人都知道。
傳統的歸檔方法有時會以最愚蠢的方式失敗。在嘗試為一個本地報紙網站（pamplemousse.ca）建立備份時，我發現 WordPress 在包含 的 Java 末尾添加了查詢字串（例如：?ver=1.12.4）。這會使提供歸檔服務的 web 伺服器不能正確進行內容型別檢測，因為其靠副檔名來發送正確的Content-Type 頭部資訊。在 web 瀏覽器載入此類歸檔時，這些指令碼會載入失敗，導致動態網站受損。
隨著 web 向使用瀏覽器作為執行任意程式碼的虛擬機器轉化，依賴於純 HTML 檔案解析的歸檔方法也需要隨之適應。這個問題的解決方案是在抓取時記錄（以及重現）伺服器提供的 HTTP 頭部資訊，實際上專業的歸檔者就使用這種方法。
建立和顯示 WARC 檔案
在 網際網路檔案館Internet Archive 網站，Brewster Kahle 和 Mike Burner 在 1996 年設計了ARC （即 “ARChive”）檔案格式，以提供一種聚合其歸檔工作所產生的百萬個小檔案的方法。該格式最終標準化為 WARC（“Web ARChive”）規範，並在 2009 年作為 ISO 標準釋出，2017 年修訂。標準化工作由國際網際網路保護聯盟International Internet Preservation Consortium（IIPC）領導，據維基百科稱，這是一個“為了協調為未來而保護網際網路內容的努力而成立的國際圖書館組織和其他組織”；它的成員包括美國國會圖書館US Library of Congress和網際網路檔案館等。後者在其基於 Java 的 Heritrix crawler（LCTT 譯註：一種爬蟲程式）內部使用了 WARC 格式。
WARC 在單個壓縮檔案中聚合了多種資源，像 HTTP 頭部資訊、檔案內容，以及其他元資料。方便的是，Wget 實際上提供了 --warc 引數來支援 WARC 格式。不幸的是，web 瀏覽器不能直接顯示 WARC 檔案，所以為了訪問歸檔檔案，一個檢視器或某些格式轉換是很有必要的。我所發現的最簡單的檢視器是 pywb，它以 Python 包的形式執行一個簡單的 web 伺服器提供一個像“時光倒流機網站Wayback Machine”的介面，來瀏覽 WARC 檔案的內容。執行以下命令將會在 https://localhost:8080/ 地址顯示 WARC 檔案的內容：
$ pip install pywb
$ wb-manager init example
$ wb-manager add example crawl.warc.gz
$ wayback
順便說一句，這個工具是由 Webrecorder 服務提供者建立的，Webrecoder 服務可以使用 web 瀏覽器儲存動態頁面的內容。
很不幸，pywb 無法載入 Wget 生成的 WARC 檔案，因為它遵循的 1.0 規範不一致，1.1 規範修復了此問題。就算 Wget 或 pywb 修復了這些問題，Wget 生成的 WARC 檔案對我的使用來說不夠可靠，所以我找了其他的替代品。引起我注意的爬蟲程式簡稱 crawl。以下是它的呼叫方式：
$ crawl https://example.com/
（它的 README 檔案說“非常簡單”。）該程式支援一些命令列引數選項，但大多數預設值都是最佳的：它會從其他域獲取頁面所需（除非使用 -exclude-related 引數），但肯定不會遞迴出域。預設情況下，它會與遠端站點建立十個併發連線，這個值可以使用 -c引數更改。但是，最重要的是，生成的 WARC 檔案可以使用 pywb 完美載入。
未來的工作和替代方案
這裡還有更多有關使用 WARC 檔案的資源。特別要提的是，這裡有一個專門用來歸檔網站的 Wget 的直接替代品，叫做 Wpull。它實驗性地支援了 PhantomJS 和 youtube-dl 的整合，即允許分別下載更復雜的 Java 頁面以及流媒體。該程式是一個叫做 ArchiveBot 的複雜歸檔工具的基礎，ArchiveBot 被那些在 ArchiveTeam 的“零散離群的歸檔者、程式設計師、作家以及演說家”使用，他們致力於“在歷史永遠丟失之前儲存它們”。整合 PhantomJS 好像並沒有如團隊期望的那樣良好工作，所以 ArchiveTeam 也用其它零散的工具來映象儲存更復雜的網站。例如，snscrape 將抓取一個社交媒體配置檔案以生成要傳送到 ArchiveBot 的頁面列表。該團隊使用的另一個工具是 crocoite，它使用無頭模式的 Chrome 瀏覽器來歸檔 Java 較多的網站。
如果沒有提到稱做“網站複製者”的 HTTrack 專案，那麼這篇文章算不上完整。它工作方式和 Wget 相似，HTTrack 可以對遠端站點建立一個本地的副本，但是不幸的是它不支援輸出 WRAC 檔案。對於不熟悉命令列的小白使用者來說，它在人機互動方面顯得更有價值。
同樣，在我的研究中，我發現了叫做 Wget2 的 Wget 的完全重製版本，它支援多執行緒操作，這可能使它比前身更快。和 Wget 相比，它捨棄了一些功能，但是最值得注意的是拒絕模式、WARC 輸出以及 FTP 支援，並增加了 RSS、DNS 快取以及改進的 TLS 支援。
最後，我個人對這些工具的願景是將它們與我現有的書籤系統整合起來。目前我在 Wallabag 中保留了一些有趣的連結，這是一種自託管式的“稍後閱讀”服務，意在成為 Pocket（現在由 Mozilla 擁有）的免費替代品。但是 Wallabag 在設計上只保留了文章的“可讀”副本，而不是一個完整的拷貝。在某些情況下，“可讀版本”實際上不可讀，並且 Wallabag 有時無法解析文章。恰恰相反，像 bookmark-archiver 或 reminiscence 這樣其他的工具會儲存頁面的螢幕截圖以及完整的 HTML 檔案，但遺憾的是，它沒有 WRAC 檔案所以沒有辦法更可信的重現網頁內容。