Favicon Extractor 開源圖示工具，一次攤開網站宣告的全部尺寸

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

要拿某個網站的 favicon，工程師之間流傳一條免費捷徑：直接開 Google 的 s2 圖示服務網址，把網域名稱接在後面，指定尺寸，瀏覽器就會給你一張圖。開發者要放書籤列、做網站列表、塞進側邊欄，這一行網址多數時候就夠了。既然如此，一個叫 Favicon Extractor 的工具還有存在價值嗎？有的，而且價值剛好長在那一行網址做不到的地方：它會去讀目標網站的原始碼，把網站自己宣告過的圖示全部列出來，幾種尺寸、什麼格式、放在哪個網址，一次攤開，還給你一份任何人都能呼叫的 JSON API。

先給判決。它適合的人：需要一次拿到某網站全部圖示尺寸的人，例如經營網站目錄或書籤服務，要幫大量站點挑解析度夠高的版本；想用程式批次抓圖示的開發者，它的 API 不用金鑰、不用註冊；還有想自架一套的人，整個網站 MIT 授權開源，Docker 跟 Cloudflare Pages 兩條部署路都鋪好了。它不適合的人：以為它有什麼神奇管道的人。它拿到的東西，完全等於目標網站在原始碼裡自己宣告的內容，站方沒寫的它變不出來，查無此站的時候它也不會告訴你查無此站。這篇文章的觀察怎麼來的先交代清楚：它的公開 API 我實際打了七個網域，其中四個是台灣網站；整個原始碼倉庫抓下來逐檔讀過；網站的歷史版本跟討論區也翻過。

比 Google 一行網址多的，是整份尺寸清單

把兩條路擺在一起看就清楚了。Google 的 s2 服務給你的是「一張圖」：不管對方網站準備了幾種尺寸，你拿到的都是 Google 幫你縮放出來的單一版本，而且它快取裡的圖可能落後網站現況。Favicon Extractor 走的是另一條路：它真的去抓目標網站的頁面，解析 HTML 裡所有跟圖示有關的 link 標籤，把網站原生生產的每一張圖列出來，含 apple-touch-icon 這種手機加到主畫面時用的高解析版本。以電商 PChome 為例，一次列出 8 張，從 favicon.ico 一路到 180×180 的觸控圖示；有的網站甚至一次給 13 張。

先幫不熟這塊的讀者補個背景，為什麼一個網站會準備那麼多張圖。瀏覽器分頁用的是 16 或 32 像素的小圖；iPhone 把網站加到主畫面時，iOS 要的是 180×180 的蘋果觸控圖示；做成了安裝級網頁應用的站，還會宣告 192×192 跟 512×512 給安裝畫面用。這些圖在原始碼裡各有一條宣告，各有指定網址，平常散在頁面開頭一大片原始碼裡，手工找等於撈針。這個工具做的事就是把那片原始碼掃一遍，把宣告過的全部集中成一張清單，順便標好每張的尺寸跟格式，.ico、.png、.svg 混著出現也照單全收。

這份清單還附贈兩樣開發者會用到的東西。現成的 HTML 片段，預設尺寸跟大尺寸各一段，貼進自己網站就能用；JSON API 則是它最慷慨的地方：不用金鑰、不用註冊，網址列打好網域就給你完整清單，內容包含目標網址、狀態碼、每張圖的尺寸跟原始網址，連這次查詢花了幾秒都附上。官方還提供了一個書籤小工具的作法，把一小段程式碼存成書籤，在別的網站上點一下，就跳出那個站的圖示資料，做網站調查的時候很順手。想整包帶走也有打包下載，把清單裡的圖整批收成壓縮檔。網站頁尾還掛著一整排姊妹工具，字型產生器、結構驗證器、網域狀態檢查之類，同一個站長工具家族的作品。

不過要提醒一件挑剔但重要的事：網站首頁寫著「13 種尺寸可下載」，這個數字看看就好。他們自己的常見問答就承認，尺寸是動態檢查的，每個網站能拿到什麼端視對方宣告了什麼。13 這個漂亮的數字，其實是他們說明文件裡範例網站恰好宣告的數量。拿這工具的人該有的正確認知是：它是放大鏡，不是魔術師。

拿自家網站驗它：三條宣告，三張圖，一張不多

實測最好用的素材就是自己。TechMoon 首頁的原始碼裡，圖示相關的設定就三條：32×32 一張、192×192 一張、還有一張給蘋果裝置的觸控圖示。把 techmoon.xyz 丟進它的 API，答案就是那三張，網址、尺寸全部對得上，一張不多一張不少。PChome 的例子也一樣，八張圖每一張都對應原始碼裡真實存在的宣告。這驗證了它的工作原理：清單的內涵由目標網站決定，工具只負責找出來、排整齊。

Pin

介面上有個小細節做得不錯：每張圖顯示的尺寸是瀏覽器實際載入後量到的解析度，不是網站宣稱的數字。有的網站會在設定裡寫 512×512，實際給的圖卻沒那麼大，這個工具會把真相量給你看。每張圖旁邊都有單獨下載和複製網址的按鈕，不用整包抓。

速度也實測了一下。查 TechMoon 花了 0.99 秒，查 GitHub 是 0.49 秒，查 PChome 跟中央社都在半秒上下，最慢的一個是那份 13 張清單的範例網站，要等上好幾秒，因為它得等目標網站自己把頁面送完。這組數字的意思是：工具的快慢主要取決於目標網站，而不是它自己。API 的應答內容也設計得算誠實，除了圖示清單，還帶最終網址、狀態碼、耗時，寫腳本的人拿到的就是一份可以直接判斷的資料，不用再猜。

查不到的站，它不會說查不到

這是使用上最需要知道的行為。拿一個不存在的網域去查，API 照樣給你 HTTP 200 的成功狀態，內容是一張 100×100 的灰色方塊，中間用網域的第一個字母充當圖示。這不是抓到的圖，是它現場畫出來的占位圖，格式是嵌在資料裡的 SVG。站方在常見問答裡也自己說了：找不到圖示的時候，工具不會讓你空手而歸，會自動生成一張。對人來說看一眼就識破，但如果你是用程式批次呼叫，拿到 200 就當成功存檔，事後清點收藏夾才會發現混進一堆灰底字母。腳本要記得檢查圖片網址是不是它自家的資料格式，是的話就是占位圖。

另外一種情況是網站活著、但原始碼裡沒有宣告圖示。拿 python.org 實測最有代表性：我自己抓它首頁的原始碼，圖示設定一條都沒有，工具端顯然也一樣，因為它直接跳過自己解析的階段，給了兩張 100 像素的 Google 與 DuckDuckGo 代理版本。東西還是有的，只是那個「攤開網站原生尺寸」的賣點，在這種網站上就縮水成兩張縮放圖。備援順序寫在原始碼裡，先試著自己解析，失敗才輪到這兩家。

PTT 的圖示會拿到一條死連結

原始碼裡有個很具體的瑕疵，拿台灣最大的批踢踢實業坊正好可以示範。PTT 首頁宣告圖示用的寫法，網址開頭是兩條斜線，這在網頁開發裡叫協定相對網址，意思是沿用它目前連線用的 http 或 https。這是非常正統的寫法。但這個工具拼接網址的邏輯沒有處理這種格式，直接把整串接在 PTT 的網域後面，拼出一個中間有雙斜線的錯誤網址。我實際打開那條網址，伺服器給 404；把錯誤的雙斜線拿掉、用正確網址再連一次，圖片好好的，一張 SVG。也就是說，用這個工具查 PTT，清單裡那張圖的連結是壞的。

還有一個同源的小缺口：它解析原始碼用的規則運算式，認不得「shortcut icon」這種中間有空格的舊式宣告寫法。拿 PChome 對照最清楚，它首頁同時用新舊兩種寫法宣告同一張圖，工具只抓到新的那條，舊的那條被略過。PChome 因為兩種都寫所以沒有損失，但不少老網站只寫舊式宣告，這種網站進來就會直接落到 Google 與 DuckDuckGo 的備援，原生尺寸清單全部看不到。這兩個缺口都藏在做為核心的解析邏輯裡，照原始碼的版本紀錄推算，短時間內不會有人修，原因下面會講。

倉庫停在 2025 年 2 月，網站卻還在長新東西

這個專案給了一個觀察開源工具的好案例：倉庫跟網站是兩個生命。程式碼倉庫 2024 年 8 月 20 日建立，同一天網際網路檔案館出現第一筆網站快照，作者 Sead Feng 幾乎一人包辦的作品，MIT 授權，累積 337 顆星。但最後一次提交停在 2025 年 2 月 16 日，變更日誌的最後一個版本是 2024 年 12 月的 0.3.1。有人問過能不能發個 npm 套件讓大家直接引用，作者親自答覆這是 Next.js 應用不是套件、有需要就自己部署，討論隨後關閉，至今沒有套件可裝。討論區的節奏也很看緣分：2025 年 5 月底一口氣關掉三個提問，之後就安靜了，2025 年 8 月有人許願支援 emoji 圖示，到今天零答覆。

Pin

可是網站本身活得很好，而且明顯走在倉庫前面。首頁有單一網域跟批次檢查兩種分頁，線上版自己的說明文字寫著批次一次最多 50 個網域；結果頁還有匯出 JSON 與 CSV 的按鈕。這些我翻遍整個原始碼倉庫，一行都找不到對應的實作。更鮮的是法律文件：網站的隱私權政策跟服務條款，生效日期寫著 2026 年 10 月 6 日，是非常新的日期，可見站方仍在積極維運。附帶一提他們網站自己的小疏失：網站地圖裡列了一個 API 文件頁，點進去是他們自己的 404 頁面。

這對讀者意味著兩件事。用網站的人，享受的是持續維運的最新版，問題不大；想自架的人要有心理準備，你架起來的是 2025 年 2 月的那份程式，沒有批次模式、沒有匯出功能，而且倉庫不修的解析瑕疵，自架版也一樣帶著。部署資源兩種都有，但完整程度不同：Cloudflare Pages 有正式文件，Docker 則是 Dockerfile 跟 compose 檔案都在、說明缺席，要自己看得懂才架得起來。整個服務跑在邊緣運算環境上，技術棧是 Next.js 加 TypeScript。自架前還有兩個衛生檢查要做：原始碼設定檔裡，統計腳本的帳號識別碼是寫死的預設值，環境變數沒設好的話，你自架版的造訪數字會默默送進原作者的統計帳號；倉庫裡還躺著一個被提交進版本控制的 .env 檔，這在開源專案裡是常見的衛生扣分，取用前自己清一遍比較穩。

你查過哪些網域，站方都知道

資料流向也要講清楚，因為這工具的形態容易讓人誤會。它不是瀏覽器裡跑的純前端工具，你在首頁輸入網域按下去，瀏覽器是去呼叫它自家的 API，由它的伺服器去抓目標網站，再把清單送給你。換句話說，你查了哪些網站，站方的伺服器都看得到。首頁也掛著 Google Analytics 的統計腳本，帳號識別碼就寫在頁面原始碼裡。以一個免費網路工具來說這些都是常見做法，量級也輕，但「查詢紀錄會經過它的伺服器」這件事，值得在你決定把公司內部網域貼進去之前知道。

有趣的地方在於它的隱私權政策怎麼寫。政策裡說，你的查詢紀錄存在瀏覽器的本機儲存空間裡，除非你另外呼叫 API，否則不會送到伺服器。可是我把開源程式碼逐檔搜過，整個專案裡找不到任何使用本機儲存的程式碼，而網頁介面本身就是靠呼叫 API 運作的。政策描述的產品跟實際的產品之間，顯然有一段距離，也許線上版本後來加了對應功能，但公開的原始碼裡看不到證據。照開源版的實作，打包下載也會多繞一手：清單裡每張圖都先經過它的下載代理端點，再收進你的壓縮檔，瀏覽器並不直接向圖床索取。另外，介面支援 14 種語言，但中文只有簡體版，繁體使用者請直接用英文介面，功能都在明處。

跟 favicon.run 和 favicon.im 擺在一起怎麼選

站上先前評過另外兩個同類工具，加上這篇正好湊成三種取捨。favicon.run 走極簡路線，一行網址拿一張圖，適合「我只是要快速拿個圖示」的輕量情境；favicon.im 本身就是以 API 為主的服務，抓不到的時候有多層備援可以退。Favicon Extractor 的差異化在兩處：一是開源可自架，隱私顧慮可以自己扛，這是另外兩個閉源服務給不了的；二是它列出來的是網站原生宣告的完整尺寸清單，而不是縮放後的單張圖，要做高解析用途時差別就出來了。反過來說，如果你的需求就是一張 32×32 的小圖，老實講 Google 那一行網址最快，任何工具都是多餘的。

適合它的場景再具體一點：你在做一個會列出大量網站的頁面，要幫每個網站配圖示，想挑解析度最好的原生版本，那就用它的 API 批次拉清單；你在調查某個網站的圖示設定下了多少功夫，例如接手別人的網站、幫客戶做網站健檢，它是現成的檢查器，一眼看出對方有沒有把手機用的觸控圖示補齊；你要在自己團隊內部架一套不對外送的圖示服務，MIT 授權加 Docker 正好。不適合的場景：需要繁體中文介面的人、需要官方承諾維運等級的人（畢竟倉庫停擺近兩年）、以及會把機敏網域拿去查又在意紀錄的人。常見問答裡也提醒了版權問題：抓下來的圖示著作權屬於原網站，自己收藏參考通常沒事，商業使用前請先想清楚授權來源。站長工具的周邊需求，例如查中國網站的備案資訊，可以再搭配備案查詢工具一起用。

一句話收尾。Favicon Extractor 把「一個網站準備了哪些圖示」這件小事查得乾淨俐落，API 免費開放、授權乾淨，該給的都給了；它的三個真實邊界，清單內涵取決於對方宣告、查不到時不吭聲、公開的原始碼落後線上版一大截，也都不難記。知道這三件事再上車，它是一把好用的螺絲起子；不知道就上車，偶爾會被那張灰底字母圖騙到。