favicon 雜湊值（hash）是網站 favicon 檔案中原始位元組的 MurmurHash3 校驗和，以整數形式表示，像 Shodan、Censys 和 VirusTotal 這類工具會用它來將使用相同圖示的網站分組。這個雜湊值與影像的檔名、alt 文字或 HTML 包裹標籤無關，僅取決於瀏覽器在請求 /favicon.ico 或依照你放在文件 head 中的 link 元素時所下載到的確切位元組序列。這就是為什麼要得到一個有用的雜湊值，第一步是先產生一個乾淨、可預期、且位元組完全符合你預期出貨版本的 favicon 檔案。基於瀏覽器的 PNG 產生器可以讓你在不上傳原始影像給任何人的情況下取得該檔案，這在你想要雜湊的圖示是 logo、個人標記或仍在保密的設計時格外重要。當 PNG 存到磁碟後，剩下的工作流程就只是算術：讀取位元組、將它們送進 MurmurHash3 演算法，再把產生的 32 位元帶正負號整數轉成你的偵察工具所期望的格式。本指南會帶你走完這個工作流程的兩半，從建立圖示到產生一個可重現的雜湊值，讓你可以直接貼進 Shodan、Censys 或 VirusTotal 的查詢中。
favicon 雜湊值是如何計算出來的
各大網路掃描平台所使用的 favicon 雜湊值是 MurmurHash3 演算法的一個特定應用，這是一個快速的非加密雜湊函式，能將任意位元組串流轉換成固定長度的摘要。在 favicon 的使用情境中，輸入的是伺服器回傳的 favicon 檔案的原始解碼內容——不是 URL、不是圍繞它的 HTML，也不是載入它的網頁。這些平台所使用的演算法是 MurmurHash3 的 32 位元 x86 變體，其原生輸出是一個 32 位元帶正負號的整數。
因為雜湊值純粹是檔案位元組的函式，所以只有當兩個網站的 favicon 檔案逐位元組完全相同時，它們才會回傳相同的雜湊值。一個像素的顏色變更、不同的 PNG 編碼器設定，或多一個中繼資料區塊，都可能改變雜湊值，即使圖示在肉眼下看起來毫無差異。這種敏感性正是重點：它讓研究人員可以將雜湊值視為某個圖示特定部署方式的唯一簽章。
標準的雜湊流程是：真實瀏覽器會請求某個 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 的轉碼管線，也不會有某些影像主機悄悄剝掉的中繼資料。
這種可重現性很重要，因為 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。將這些檔案放在你掌控的資料夾中；它們的位元組就是你將要雜湊的內容。
一旦檔案存到磁碟上，你就擁有了一個穩定、可重現的輸入，可以進入下一個階段。雜湊值純粹是這些位元組的函式，所以從這一刻起你對該檔案做的任何事——重新命名、重新編碼、加上中繼資料——都可能改變最終的雜湊值。
將 PNG 轉換成雜湊值
手邊有了一個穩定的 favicon 檔案後，計算雜湊值只需要一小段腳本就能完成。社群標準的做法是將檔案以原始位元組讀取，送進 MurmurHash3 實作，再把結果以 32 位元帶正負號整數的形式印出。
這段腳本的基本架構如下：
- 以二進位模式開啟 favicon 檔案並讀取每個位元組。
- 使用你的目標偵察平台指定的種子值（seed）來初始化 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 觸控圖示輸出 | — | 是 |
| 網頁應用程式 manifest 產生 | — | 是 |
| MurmurHash3 計算 | — | 是 |
| <link rel="icon"> 程式碼片段 | 是 | — |
| 伺服器上傳來源影像 | — | 是 |
最常見的不符情況，是您雜湊的檔案在上傳後已被您的 CDN、影像代管服務或主機供應商重新編碼。請使用 curl 或 wget 從公開網址重新下載該檔案，再對下載結果進行雜湊——那才是偵察平台實際看到的位元組串流。第二常見的不符情況，是您雜湊的尺寸與平台預設的不同；多數掃描工具會先嘗試最小的 declared sizes 值，因此同一個邏輯圖示的 16×16 雜湊與 32×32 雜湊會是不同的值。
第三個不符來源是置中裁切。若您的來源影像主體偏離中心，產生器會從長邊等量裁去以形成正方形。產生的圖示本身是正確的，但若您試圖重現另一個略有不同的圖示之雜湊值，裁切後的輸出將無法相符。若需要與參考網站圖示達到精確的位元組一致性，請先在影像編輯器中預先裁切來源影像。
最後，在部署新的網站圖示後，請清除瀏覽器快取與所有 service-worker 快取——否則您的本地端瀏覽器會持續顯示舊的圖示，即便伺服器上的位元組已經更新，看起來仍像雜湊值沒有改變。雜湊值忠實反映位元組內容；唯一的問題在於您實際查看的究竟是哪些位元組。