WeReadScan：把微信讀書已購書籍掃成 PDF 的開源工具實測

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

在微信讀書買了書之後，很多人會撞到同一面牆：書是花錢買的，但它活在 App 裡。想在 iPad 上用筆記 App 手寫註記、想在自己整理的資料庫留一份能搜尋的副本、想換一台裝置離線讀，平台都沒有給你匯出鍵。WeReadScan 就是為了這面牆出現的工具：2020 年放上 GitHub 的 Python 開源專案，用瀏覽器自動化把你已購的書掃成 PDF 或 HTML，累積到一千顆星、一百七十幾個 fork。

Pin

先講這次實測的結論。套件現在還裝得到，倉庫也還在，但拿 2026 年 10 月的微信讀書網頁版逐項對照，這套掃描器依賴的登入入口和翻頁按鈕已經從頁面上消失，程式碼裡等待這些元素的步驟會直接逾時。更關鍵的是內容層的變化：書籍文字改用 Canvas 畫上畫面，不再以文字節點留在 HTML 裡。所以這不像伺服器抖一下的暫時故障：頁面把這類工具賴以維生的兩條命脈同時抽走了。下面把斷點逐一攤開，順著回答更實用的問題：現在還想把已購書籍搬出微信讀書的人，該看哪些還活著的工具，以及帳號與授權的界線在哪。

一套程式碼，兩種掃法：截圖成 PDF 與抽取 HTML

WeReadScan 有兩個版本，思路完全不同。主要分支（pip 套件叫 WeReadScan，最後一版發布於 2022 年 10 月）走截圖路線：用 selenium 起一個無頭瀏覽器打開微信讀書網頁版，把登入二維碼截圖存檔、用 matplotlib 視窗秀出來讓你用手機掃，登入後前往書籍網址，自動把閱讀主題切成亮色、字級調到最小（一頁塞進更多字，整本書要掃的頁數就少），然後進入主迴圈：等頁面渲染完成、把整個內容區塊截成一張 PNG、找到頁尾的下一頁按鈕點下去，整本書跑完再把所有 PNG 串成單一 PDF，中間還做一道二值化處理（把畫面壓成黑白兩色，門檻值寫死在參數預設的 200）來壓檔案大小。

這條路的產物特性很直接：每一頁都是點陣圖，不能選字、不能搜尋，放大會糊。倉庫的 issue 清單裡，2021 年就有人反映掃出來的圖片和字是模糊的，這是截圖法的天生限制，跟哪一次的偶發品質無關。

另一個叫 html-variant 的分支（套件 WeReadScan-HTML，2023 年 9 月推出最後一版）換了思路。微信讀書網頁版有個設計：它會把章節內容預先放進一個隱藏的預渲染容器，翻頁時直接取用，速度才快。這個分支的核心，就是在頁面注入一段瀏覽器端的觀察器程式，每當預渲染容器出現就把裡面的內容複製出來、把圖片的延遲載入屬性換成真實網址，最後把整本書組合成一個 HTML 檔。產物是活的文字，可編輯、可再轉檔，品質比截圖版高一個層級。

這段觀察器程式取自另一位開發者 Sec-ant 的 weread-scraper 專案，WeReadScan 注入的 JavaScript 檔頭至今保留著對方的署名與版本號，作者自己在 README 也說是在對方建議下整合的。而那個上游原始倉庫現在已經打不開，網址只剩別人 fork 的副本還活著。

要拿到這套程式，現在還是有路：兩個套件都還在 PyPI 上裝得到（截圖版停在 0.8.7、HTML 版停在 0.1.1），GitHub 倉庫與 gitee 鏡像也都活著。所謂官網文件，其實是 GitHub Pages 自動把 README 轉出來的一頁式網站，而且凍結在早期版本，連後來 HTML 分支的段落都沒有跟上，不用期待有額外文件。依賴清單不算輕：selenium 之外還掛了 numpy、matplotlib、opencv，截圖、影像處理、顯示二維碼視窗各用一塊，裝完等於半個小型科學運算環境。

兩種掃法看起來一個求快一個求質，其實共享同一個命門：前進的動力都是「在頁面上找到下一頁的按鈕，然後點它」。按鈕沒了，兩台機器一起熄火。

實測現行頁面：容器還在，按鈕沒了

我用無頭瀏覽器匿名載入微信讀書首頁，以及 README 示範的兩本書閱讀頁（不登入帳號、只看免費試讀的部分），把掃描器原始碼裡依賴的元素逐項拿出來對照。結果分成兩半，一半還活著，一半已經不在：

以 2026 年 10 月的匿名頁面實測為基準，逐項用瀏覽器查證元素是否存在。

登入這關就過不去。現行首頁的登入入口是右上角一個純文字連結，掃描器等待的那顆按鈕和它後面彈出的二維碼對話框，在頁面上都找不到對應元素。登入流程的第一個動作就會等到逾時。

Pin

翻頁這關也一樣。閱讀頁上，內容區、渲染容器、書名、目錄按鈕、字級按鈕這些節點都還在，甚至連閱讀設定列都還有七個可用的控制項；但兩種掃法迴圈裡賴以前進的頁尾按鈕，以及跳章用的章節清單項目，都已經沒有對應元素。截圖版會在第一次找不到按鈕時直接結束，HTML 版則是把當下抓到的內容存檔就收工，換句話說，就算你把登入修好，它最多吐給你第一個畫面。

更深一層的發現，解釋了為什麼這不是改個元素名稱就能救回來的事：預渲染內容的節點還掛在頁面上，但在匿名試讀頁裡它是空的，文字長度是零，一張圖也沒有；同時頁面上出現了兩個 Canvas 畫布元素。骨架還在，靈魂已經搬家。

順帶一提，兩個示範書頁本身都開得很正常，看得到書名、目錄側欄與閱讀設定列，匿名狀態下顯示的是版權頁與試讀部分。壞的不是頁面，是頁面與程式之間的約定：程式認的是舊合約上的條款，頁面早就換約了。

用戶留言拼出來的失效時間線

這個倉庫的 issue 清單，剛好把整個死亡過程記錄了下來。

2023 年 7 月，有使用者回報掃碼登入後被要求二次驗證、要到網頁版輸入驗證碼（作者回覆表示自己沒遇過）。作者在 2023 年 9 月 6 日回了這則 issue，這也是他在問題追蹤區最後一次公開出面；同一天，PyPI 上出現 HTML 版的最後一個版本，9 月 19 日倉庫迎來最後一次 commit，內容只是更新 README。之後的故事全由使用者接手：

2023 年 10 月底有人開 issue 問大家現在還爬得出東西嗎。12 月，一位用戶留言說近日微信讀書的爬蟲都失效了，建議回頭試截圖合成 PDF 的舊版，效果差一點但搞不好還能動。2024 年 4 月，另一位用戶留言給出關鍵診斷：可以，但要改庫，因為前端改了、原本的元素定位不好使了。這句話跟我的實測完全對上，斷點就是元素定位。同一時間，同一位用戶在另一則 issue 補充：爬不動有時只是 chromedriver 版本太舊，要抓跟瀏覽器對應的版本，說明當時的故障訊號混雜了環境問題與真實改版。

2024 年 5 月 1 日，倉庫迎來最後一則新 issue（許願把書裡別人公開的想法也一併抽出來），之後整個倉庫靜默，沒有新問題、沒有回覆、沒有 commit。2025 年 5 月，還有人留言貼出完整的錯誤堆疊，程式死在登入函式的第一個等待上，沒有人回。

把這條線跟我的實測接起來看：2024 年 4 月改一改元素定位還有機會動，2025 年 5 月卡在登入，2026 年 10 月連登入入口和翻頁按鈕的元素都不在了。它不是一次斷掉，是被平台一次次的改版磨斷的，而維護者在上半場就離場了。

為什麼救不回來：文字搬進 Canvas 了

要理解這類工具為什麼集體陣亡，得先講網頁渲染的兩種做法。傳統做法裡，書的每一段文字都是 HTML 的文字節點，瀏覽器讀檔就有了，任何讀 DOM 的程式都拿得到。Canvas 渲染是另一條路：文字不再以節點存在，而是被 JavaScript 一筆一筆畫上畫布，畫完就是像素。讀者看起來一樣，對程式來說是天壤之別，像素沒有字串可以抽取。

這不是我的推測。今年仍見推送的匯出工具 lbq110/weread-exporter 在 README 直接寫明：微信讀書網頁版用 Canvas 渲染書籍文字，而非 DOM 文字節點。我在匿名試讀頁實測到的空殼預渲染容器加上兩個 Canvas 畫布，就是同一件事的頁面層證據。

對照兩種掃法的死法也更有意思了。截圖版理論上不怕 Canvas，因為它拍的本來就是畫面，文字是畫出來的還是節點來的都一樣拍得到，它死在登入與翻頁這兩個流程元素。HTML 版死得更徹底，因為它的抽取目標（預渲染的文字內容）已經沒有東西可以抽。

現在還活著的工具，共同解法是換一個攔截點：不去讀 DOM，而是鉤住 Canvas 的繪圖函數，在文字被畫上畫布的那一刻，把字串與座標攔下來重組成文件。具體做起來相當手工：lbq110 那套的工具鏈自述，是注入程式攔截每次 fillText 呼叫、記下每個字元的座標；微信讀書會在同一個畫布上同時畫目前頁和下一頁，工具就靠偵測縱座標重置的位置把兩頁切開；插圖不走畫布而是 DOM 的圖片元素，工具按可見範圍過濾、再跟文字行一起用座標排序，讓圖落在正確的段落之間；最後把 Canvas 斷行的碎字合回自然段落。星數最高的 drunkdream/weread-exporter 走同一類原理，攔下文字與樣式後轉 Markdown，再組 epub 或 PDF。這是 DOM 時代掃描器與 Canvas 時代匯出器的分水嶺，也是 WeReadScan 這類老工具回不來的原因：不是沒人想救，是救法要整個換掉。

帳號、授權，以及「已購」到底是買到什麼

工具本身之外，有幾條界線值得先想清楚。

作者在 README 的免責聲明寫得很明白（這是作者單方的定位宣稱）：這套腳本僅限用於已購圖書的爬取、供私人學習目的，禁止商業用途與在網路上散布，並強調不當使用的責任由使用者自負。這個定位把工具放在「個人備份」而不是「取得內容」的位置，你本來就買了書，它只是幫你換個存放形式。但兩件事不會因為這段聲明而改變：微信讀書的服務條款怎麼看待自動化存取，是平台與你之間的事；以及，實際跑起來可能觸發驗證碼等風控，2023 年那則二次驗證的回報就是例子。帳號風險沒有人能替你量化，使用前要有心理準備。實際的風險量級跟行為走：掃一本自己買的書留檔，跟掛著帳號整夜批次掃整個書架，在平台眼裡是不同等級的訊號，而這套工具除了示範程式裡一條關閉瀏覽器自動化特徵的啟動參數，沒有內建任何節流或更進一步的偽裝，迴圈就是老實地等頁面、按按鈕，跑多快全看使用者自己的腳本怎麼寫。

授權狀態則是一團互相矛盾的訊號。倉庫裡沒有 LICENSE 檔案，GitHub 自動偵測顯示無授權；兩個分支的主要程式檔開頭都寫著版權所有、保留一切權利；PyPI 套件頁的授權欄卻標了 GPL。三個地方三種說法，實務上的意思是：想 fork 來改、改完再散布，沒有一段清楚可依的授權條文，保守看待就是把它當「作者公開展示、未授予再利用權利」的程式碼。

最後是「已購」兩個字的份量。電子書買到的只有閱讀授權，著作財產權不會跟著移轉；把書搬出來自己讀、自己劃重點，跟把檔案傳給別人是兩件法律意義完全不同的事。前面那段作者免責禁止散布，與其說是道德姿態，更接近這條線的準確反映。

2026 年還想把書搬出來，看哪幾個

如果你現在的需求是「把我在微信讀書買的書變成自己機器上的檔案」，WeReadScan 已經不是答案，但這個需求本身有一批更年輕、還在動的工具在服務：

星數與推送時間為 2026 年 10 月 15 日查核值。

怎麼選，看你要的產物。要一本完整的電子書檔案，drunkdream 那套是目前的代表：倉庫複製下來裝成套件、給它書籍頁網址裡的書號、指定輸出格式，Canvas 攔下來的文字重組成 Markdown 後轉 epub，PDF 直出，mobi 再走 kindlegen 轉檔。要把書的內容餵進自己的筆記或知識庫，lbq110 的 Markdown 輸出強調文字與插圖按閱讀順序精確交錯，掃碼登入一次之後登入狀態留在本機、之後自動沿用，中途卡住還能從上次的章節續跑；油猴腳本那套則免裝 Python 環境、裝個瀏覽器擴充就能用；如果你其實只要讀書筆記和劃線，toolbox 直接對接 Notion，連書本體都不用搬。

要提醒的是，這些工具沒有一個能替你解決前面講的界線問題：它們全都要吃你自己的微信讀書登入，帳號與授權風險的性質與 WeReadScan 完全相同，差別只在引擎跟上了 Canvas 時代。免責聲明也幾乎是同一個模板：星數最高的那套自述僅供技術研究之用，侵權責任使用者自負，跟 WeReadScan 作者的寫法只是措辭差異。換工具不會換掉你的法律位置，這件事在挑選時就該算進成本。

同一個「把平台內容搬回自己手裡」的任務，TechMoon 先前也聊過幾個近親：微信讀書的評論區其實留在騰訊伺服器上，評論擴充套件只是薄薄一層殼；想把微信公眾號文章整批匯出，有專門的開源匯出器；B 站收藏備份和通用網頁爬蟲框架處理的是不同平台的同款焦慮；而下載影片這條線上，cobalt 的故事則是價值從網站搬進引擎的另一種結局。把書搬出微信讀書，是這個大家族裡版權敏感度最高的一支，工具再方便，散布那條線都不要跨。

還能用嗎、會出事嗎：直接的問答

WeReadScan 現在還能用嗎

以 2026 年 10 月的頁面狀態，現行程式碼跑不完一本書：登入入口的元素與翻頁按鈕都已消失，內容層的文字也搬進了 Canvas。2024 年 4 月還有使用者改一改元素定位後勉強能動，但那需要自己維護一套修補，而上游已經三年沒有動靜。真的想走這條路，等於接手一個孤兒專案。

用這類工具，帳號會被處理嗎

沒有公開的封號統計可以引用，但平台方確實有回應：2023 年的使用者回報顯示，掃碼登入後可能被要求二次驗證。帳號風險取決於你怎麼用（頻率、量級、時間點），無法事先保證。用主力帳號跑大流量掃描，是這類工具共同的忌諱。

把已購書籍轉成 PDF，合法嗎

法律上，自用備份與對外散布是重量級完全不同的兩件事，各地著作權法對自用重製的例外範圍規定也不一樣；但把檔案再傳給別人，幾乎在哪裡都踩線。工具作者的免責也只授權到個人學習為止。拿法律問題問工具是最危險的，答案永遠取決於你拿產物做什麼。

免費工具的壽命，從來是平台改版的函數。WeReadScan 一千顆星救不了它把整條命脈押在別人 DOM 上的設計，維護者離場之後，平台花三年把它磨斷。它的價值如今是教科書式的：想知道一個抓取工具會怎麼死，這裡有完整驗屍報告；想把書搬出來的人，答案在 Canvas 時代的現役工具，而那幾條界線，帳號、授權、散布，工具再新也不會替你扛。