favicon 雜湊值是網站 favicon 檔案原始位元組經 MurmurHash3 演算法計算後的校驗和，以整數形式表示，Shodan、Censys 和 VirusTotal 這類工具會用它來將共用同一個圖示的網站分組。這個雜湊值與圖片的檔名、替代文字或 HTML 包裹標籤無關——它只取決於瀏覽器在請求 /favicon.ico 或依照你在文件 head 中放置的 link 元素時，所下載到的精確位元組序列。這就是為什麼要得到一個有用的雜湊值，第一步就是產出一個位元組乾淨且可預期的 favicon 檔案，內容完全是你打算發佈的位元組。在瀏覽器中運作的 PNG 產生器可以幫你取得這個檔案，而無需把來源圖片上傳給任何人，當你想要雜湊的圖示是 logo、個人標誌或仍在保密的設計時，這點非常重要。一旦 PNG 存到磁碟，後續的工作流程就只是算術：讀取位元組、將它們送進 MurmurHash3 演算法，再把產生的 32 位元帶正負號整數轉成你的偵察工具所期望的格式。本指南會逐步帶你走完這個工作流程的兩半，從建立圖示到產出可重現的雜湊值，讓你能直接貼進 Shodan、Censys 或 VirusTotal 的查詢中。
favicon 雜湊值是如何計算出來的
各大網路掃描平台所使用的 favicon 雜湊值，是 MurmurHash3 演算法的一個特定應用方式。MurmurHash3 是一種快速的非加密雜湊函式，能將任意位元組流轉換成固定長度的摘要。在 favicon 的應用情境中，輸入的是伺服器回傳的 favicon 檔案原始解碼內容——不是 URL，不是包圍它的 HTML，也不是載入它的頁面。這些平台所使用的演算法是 MurmurHash3 的 32 位元 x86 變體，其原生輸出是一個 32 位元帶正負號整數。
因為雜湊值純粹是檔案位元組的函式，所以只有當兩個網站的 favicon 檔案逐位元組完全相同時，它們才會回傳相同的雜湊值。即使圖示肉眼看起來一模一樣，一個像素的顏色變更、不同的 PNG 編碼器設定，或多出一塊 metadata 區塊，都可能讓雜湊值改變。這種敏感性正是重點：它讓研究人員能把雜湊值當作某個圖示部署版本的獨特簽章。
所謂的標準雜湊值，就是真實瀏覽器會請求的 favicon URL，完整下載後，再用標準的 MurmurHash3 實作進行雜湊。不同平台對於要抓取哪個 favicon URL 有稍微不同的慣例（有些用 /favicon.ico，有些用找到的第一個 <link rel="icon">），這代表同一個圖示依據掃描器解析方式的不同，可能產生不同的雜湊值。當你在本機重現一個雜湊值時，唯一能比對第三方資料庫的方法，就是從頭到尾掌控整個位元組流。
為什麼 favicon 檔案會先於雜湊值
雜湊值是一個衍生出來的值，而不是你自行撰寫的內容。你不能直接在搜尋框裡打一個 favicon 雜湊值，然後期待它有任何意義，除非某處伺服器上有一個產生它的檔案。這就是為什麼任何談論「取得 favicon 雜湊值」的工作流程，實際上都從同一個上游決定開始：你要雜湊哪一個 favicon 檔案？
在本機產生的 PNG favicon 會給你最乾淨的答案。Favicon 產生器會在你的瀏覽器分頁中解碼 PNG、JPEG 或 WebP 來源，透過 Canvas 縮放器繪製後，再把每個選定的尺寸匯出為全新的 image/png Blob，全程不經過額外的伺服器往返。因為沒有任何東西被上傳，你下載到的位元組完全由你的來源圖片和你選定的尺寸決定。不會有共用後端造成的編碼變化，不會有在輸入與輸出之間可能重新壓縮你 PNG 的轉檔管線，也不會有某些圖片主機悄悄移除的意外 metadata。
這種可重現性很重要，因為 MurmurHash3 對位元組變化極為敏感。兩個視覺上看起來相同的 PNG 檔案，只要一個是用不同編碼器儲存、壓縮等級不同，或帶著稍微不同的色彩描述檔區塊，雜湊結果就可能不同。在本機執行產生作業，能消除最常見的變異來源：遠端圖片管線的未知行為。
在本機產生 favicon PNG
邁向 favicon 雜湊值的第一個具體步驟，就是產出一個你可以存到磁碟上進行雜湊的正方形 PNG。Favicon 產生器是最簡單、且無需上傳任何檔案的做法。
- 挑一張主體接近畫面中央的 PNG、JPEG 或 WebP 來源圖片；這個工具接受最大 25 MB 的檔案，且會拒絕解碼後超過 4000 萬像素的圖片，所以超出這些限制的來源會在任何輸出繪製之前就被擋下。產生器使用中央覆蓋裁切，因此任何靠近角落的重要內容會在正方形被裁出之前被切掉。
- 打開產生器並載入你的來源檔案。解碼作業完全在你目前的瀏覽器分頁中執行，所以檔案不會離開你的電腦。
- 挑選你真正希望存到磁碟上的正方形 PNG 尺寸。可選項目為 16、32、48、64、128、256 和 512 像素。如果只要一個可雜湊的圖示，32×32 是最常被引用的參考尺寸，因為大多數瀏覽器在標準 DPI 下顯示分頁時就是請求這個大小。
- 產生檔案。每個選定的尺寸都會從解碼後的來源以其原生尺寸獨立繪製——這個工具不會把小尺寸預覽當成較大下載的基礎，所以 512×512 的檔案確實是 512 像素的全新繪製結果。
- 下載每個 PNG，並用建議的檔名儲存，例如 favicon-32x32.png。把這些檔案放在你能掌控的資料夾裡；它們的位元組就是你將要雜湊的內容。
一旦檔案存到磁碟上，你就擁有下一個階段穩定且可重現的輸入。雜湊值純粹是這些位元組的函式，所以從這一刻起你對檔案做的任何事——重新命名、重新編碼、加上 metadata——都可能改變最後的雜湊結果。
把 PNG 轉成雜湊值
手邊有了穩定的 favicon 檔案後，計算雜湊值只需要短短一段腳本。社群標準的做法是把檔案以原始位元組讀入，再送進 MurmurHash3 實作，最後以 32 位元帶正負號整數的形式印出結果。
這段腳本的基本架構如下：
- 以二進位模式開啟 favicon 檔案，並讀取每一個位元組。
- 使用你的目標偵察平台指定的種子值來初始化 MurmurHash3。Shodan、Censys 和 VirusTotal 都在各自的開發者參考文件中記載了它們選用的種子值，要重現已發佈的雜湊值就必須符合該值。
- 把位元組緩衝區送進雜湊函式。
- 把 32 位元摘要解讀為帶正負號的 32 位元整數。
Python、JavaScript 和 Go 都有可參考的實作。一段典型的 Python 程式碼會讀取 favicon 位元組、啟用帶正負號整數旗標後將它們傳給 mmh3 函式庫，再把得到的整數印出來。這個整數就是你貼進 Shodan 篩選條件 (http.favicon.hash:)、Censys 搜尋 (favicon.urn:) 或 VirusTotal 查詢的內容。不同平台有時會用不同的識別前綴包裹整數，但底層的值其實是同一個。
因為雜湊值只是檔案的函式，重現第三方雜湊值的唯一方法就是把同樣的位元組送進同一個演算法。這就是為什麼前面那個本機產生步驟很重要：它給你一個已知的輸入，讓你隨時重新雜湊，而不必依賴第三方伺服器的編碼選擇。
檢視並發佈結果
在你把圖示視為定稿之前，請以實際尺寸打開最小的那幾張下載檔。16×16 和 32×32 的檔案最能看出中央覆蓋裁切和瀏覽器重採樣濾鏡的效果。如果主體在 32 像素下顯得模糊、偏柔或無法辨認，檔案本身仍然是有效的，但產生的雜湊值會指向一個模糊的圖示——而這通常不是你想要的。
| 正方形像素尺寸 | 通常出現的位置 | 典型使用情境 |
|---|---|---|
| 16×16 | 瀏覽器分頁、書籤列 | Chrome、Firefox、Edge、Safari 的網址列圖示 |
| 32×32 | 高 DPI 分頁、Windows 工作列 | Retina 分頁圖示、Windows 捷徑目標 |
| 48×48 | Windows 網站圖示 | 釘選網站磚、傳統桌面捷徑 |
| 64×64 | macOS Dock、較大的磚 | 書籤表面與捷徑圖示疊層 |
| 128×128 | Chrome 線上應用程式商店、擴充功能圖示 | 較大的書籤與應用程式啟動器情境 |
| 256×256 | macOS Finder、現代啟動器 | 應用程式風格圖示與高解析度表面 |
| 512×512 | PWA 商店上架頁、適應性圖層 | 商店素材與高密度啟動器格點 |
當圖示看起來沒問題時，把選定的 PNG 檔案上傳到你希望它們被服務的路徑。產生器所產生的 HTML 使用相對根目錄的檔名，請編輯 href 以對應你實際放置檔案的位置。如果你只是為了離線偵察而需要雜湊值，並不打算把圖示對外發佈，可以完全跳過這個步驟——雜湊值在一個從未進入瀏覽器的檔案上也能正常運作。
若需要涵蓋 manifest 檔案、根目錄路徑與快取破壞的完整部署流程，請參閱如何在你的網站上設定 favicon。
疑難排解最常見的雜湊不符問題
當你在本機計算出的雜湊與偵察平台回報的內容不符時，原因幾乎都是位元組上的差異。MDN 參考資料中關於 rel="icon" 屬性 的說明，記載了 HTML 產生器所輸出的精確連結格式，包括 type="image/png" 屬性與 sizes 權杖，但雜湊本身與該 HTML 無關——它純粹是該連結所指檔案的函數。
| 功能 | 涵蓋範圍內 | 超出範圍 |
|---|---|---|
| PNG、JPEG、WebP 來源輸入 | 是 | — |
| ICO 容器輸出 | — | 是 |
| SVG 網站圖示輸出 | — | 是 |
| Apple 觸控圖示輸出 | — | 是 |
| 網頁應用程式資訊清單產生 | — | 是 |
| MurmurHash3 計算 | — | 是 |
| <link rel="icon"> 程式碼片段 | 是 | — |
| 來源影像的伺服器上傳 | — | 是 |
最常見的不符情況，是你雜湊的檔案在上傳後被你的 CDN、影像主機或代管服務商重新編碼過。請使用 curl 或 wget 從公開 URL 重新下載該檔案，並對下載結果進行雜湊——那才是偵察平台實際看到的位元組串流。第二常見的不符情況，是你雜湊的尺寸與平台預設的不同;大多數掃描器會先嘗試最小的 declared sizes 值，因此同一個邏輯圖示的 16×16 雜湊與 32×32 雜湊會是不同的值。
第三個不符來源是中心覆蓋裁切。如果你的來源影像主體偏離中心，產生器會從長邊等量裁剪以成為正方形。產生的圖示是正確的，但如果你想重現一個略有不同的圖示雜湊，裁切後的輸出就會不相符。若需要與參考網站圖示達到精確的位元組一致性，請先在影像編輯器中預先裁切來源。
最後，在部署新的網站圖示後，請清除瀏覽器快取以及任何 service-worker 快取——否則你的本機瀏覽器會持續顯示舊的圖示，即使伺服器上的位元組已經更新，看起來仍像是雜湊沒有改變。雜湊會忠實反映位元組;唯一的問題是你實際查看的到底是哪些位元組。
想進一步了解，請參閱 在線將 JPG 轉成 PNG 是否安全?一項隱私檢查。