本機資料庫
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
這份文件適用於下列方法:Update API (v4):threatListUpdates.fetch。
資料庫設定
使用 Update API 的用戶端必須設定本機資料庫,以及對要使用的安全瀏覽清單執行初始下載作業。如要開始使用,您可以建構及部署 safebrowsing
Go 套件 (或使用套件模擬自己的實作項目)。詳情請參閱 https://github.com/google/safebrowsing/。
資料庫更新
為確保能防範最新威脅,強烈建議用戶端使用
threatListUpdates.fetch 方法定期更新本機安全瀏覽清單。
threatListUpdates.fetch 要求會指定要更新的清單。如果用戶端有記憶體或頻寬限制,也可以使用要求來設定更新限制 (請參閱「
更新限制」一節)。
threatListUpdates.fetch 回應會傳回每份清單的完整更新或部分更新,詳情請見下方說明。
完整更新
當用戶端離開 threatListUpdates.fetch 要求中的 state
欄位,或伺服器判斷需要進行完整的更新時,系統就會傳回完整更新。如果是完整更新,系統只會傳回「新增」。用戶端應先清除本機資料庫,再套用更新並執行驗證檢查。
空白狀態
在用戶端傳送清單的初始要求時,系統會傳回完整更新。在本例中,要求中的 state
欄位會留空 (因為沒有可提供的值),而回應中的 newClientState
欄位會傳回本機清單的初始狀態。如果用戶端刻意在後續要求中將 state
欄位留空,系統也會傳回完整更新。這會強制進行完整的更新,並在回應的 newClientState
欄位中傳回新狀態。
伺服器決策有時候,只有在用戶端要求部分更新時,安全瀏覽伺服器才會傳回完整更新。當用戶端最初下載某個版本的清單,然後更新為較大版本的清單時,就可能發生這種情況;伺服器只會傳回包含整個清單的完整更新。也可能會發生在用戶端長時間未下載資料並要求部分更新的情況下;同樣地,伺服器只會傳回包含整個清單的完整更新。
部分更新
當用戶端在 threatListUpdates.fetch 要求中為 state
欄位提供值時,系統會傳回部分更新 (例外情況如上所述,當伺服器確定需要完整的更新時)。如果是部分更新,系統會同時傳回新增和移除。用戶端會更新本機資料庫中的清單 (新增前套用移除),然後執行驗證檢查。
新增
附加內容是應新增至本機資料庫的 SHA256 雜湊前置字串。大多數雜湊前置字串的長度為 4 個位元組,但有些雜湊前置字串的長度可能介於 4 到 32 個位元組之間。因此,系統可能會傳回多組新增內容,例如一組包含 4 位元組的前置字串,另一個包含 5 位元組前置字串。
如果用戶端支援壓縮,回應可能會使用 Rice 壓縮技術壓縮。不過,只有 4 位元組雜湊的前置字串會經過壓縮。系統一律會以未壓縮的原始格式傳送較長的雜湊前置字串 (請參閱壓縮一節)。
移除
「移除」是指按照字母順序排序的用戶端資料庫中,從零為基礎的索引,指向應從本機資料庫中移除的項目。系統只會傳回一組移除項目。
如果用戶端支援壓縮,系統會傳回「riceHashhes」和「rice indices」。如果不支援壓縮,系統會傳回「原始雜湊」和「原始索引」(請參閱壓縮一節)。
驗證檢查
當系統傳回 threatListUpdates.fetch 回應 (無論是完整更新或部分更新) 時,用戶端應會執行驗證檢查。
用戶端會先更新本機資料庫中的清單 (在新增內容前套用移除)。接著,用戶端會計算 (依字母順序排序) 本機清單的 SHA256 雜湊,然後將其與回應中傳回的總和檢查碼進行比較。如果這兩個值相同,系統會將安全瀏覽清單視為「正確」。
如果這兩個值不相等,則會將安全瀏覽清單視為「損毀」。用戶端必須清除資料庫中的清單,並以空白字串的 state
欄位重新發出第二次更新;這會強製完成完整的更新,並傳回全新的清單和狀態。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-07-25 (世界標準時間)。
[null,null,["上次更新時間:2025-07-25 (世界標準時間)。"],[[["\u003cp\u003eThe Safe Browsing Update API (v4) allows clients to download and update local Safe Browsing lists for threat detection.\u003c/p\u003e\n"],["\u003cp\u003eClients need to set up a local database and perform an initial download of the desired Safe Browsing lists.\u003c/p\u003e\n"],["\u003cp\u003eRegular updates are crucial, and can be either full (requiring a local database clear) or partial (applying additions and removals).\u003c/p\u003e\n"],["\u003cp\u003eValidation checks using SHA256 hashes ensure the integrity of the local Safe Browsing lists after each update.\u003c/p\u003e\n"],["\u003cp\u003eIf validation fails, clients should clear the local list and request a full update to obtain a fresh copy.\u003c/p\u003e\n"]]],["Clients utilizing the Update API must establish a local database and download Safe Browsing lists. Regular updates are crucial via the `threatListUpdates.fetch` method, specifying desired lists and update constraints. The server responds with either full updates (client clears database and applies additions) or partial updates (client applies removals before additions). After each update, the local database's SHA256 hash is validated against the response checksum; mismatches trigger a full update.\n"],null,["# Local Databases\n\nThis document applies to the following method:\n[Update API (v4)](/safe-browsing/v4/update-api):\n[threatListUpdates.fetch](/safe-browsing/v4/update-api#example-threatListUpdatesfetch).\n\nDatabase setup\n--------------\n\nClients using the Update API are required to set up a local database and to perform an initial\ndownload of the Safe Browsing lists they want to work with. To get going, you can build and deploy\nthe `safebrowsing` Go package (or use the package to model your own implementation). For more information\nsee \u003chttps://github.com/google/safebrowsing/\u003e.\n\nDatabase updates\n----------------\n\nTo ensure protection against the latest threats, clients are strongly encouraged to regularly update their local Safe Browsing lists using the [threatListUpdates.fetch](/safe-browsing/reference/rest/v4/threatListUpdates/fetch) method. The [threatListUpdates.fetch request](/safe-browsing/v4/update-api#http-post-request) specifies the lists to be updated. If clients have memory or bandwidth limitations, they can also use the request to set update constraints (see [Update Constraints](/safe-browsing/v4/update-constraints)). The [threatListUpdates.fetch response](/safe-browsing/v4/update-api#http-post-response) returns either a full update or partial update for each list, as explained below.\n\n\u003cbr /\u003e\n\n### Full updates\n\nFull updates are returned when the client leaves the `state` field in the\n[threatListUpdates.fetch request](/safe-browsing/v4/update-api#http-post-request)\nempty or when the server determines a full update is required. For full updates, only\n[additions](/safe-browsing/v4/local-databases#additions) are returned. The client is\nexpected to *clear the local database* before applying the updates and performing the\n[validation check](/safe-browsing/v4/local-databases#validation-checks).\n**Empty state**\n\nFull updates are returned when the client sends the initial request for a list. In this case, the\n`state` field in the request is left empty (because there is no value to provide) and the `newClientState`\nfield in the response returns the initial state for the local list. Full updates are also returned\nwhen the client purposely leaves the `state` field empty on subsequent requests. This will force a full\nupdate and return a new state in the `newClientState` field of the response.\n**Server decision**\n\nOccasionally, the Safe Browsing server returns a full update when only a partial update\nwas requested by the client. This may happen when the client initially downloads a small version of the list\nand then updates to a larger version of the list; the server will simply return a full update with\nthe entire list. This may also happen if the client hasn't downloaded data in a long time and requests\na partial update; again, the server will simply return a full update with the entire list.\n\n### Partial updates\n\nPartial updates are returned when the client supplies a value for the `state` field in the\n[threatListUpdates.fetch request](/safe-browsing/v4/update-api#http-post-request)\n(the exception, as noted above, is when the server determines a full update is required). For\npartial updates, both [additions](/safe-browsing/v4/local-databases#additions) and\n[removals](/safe-browsing/v4/local-databases#removals) are returned. The client updates\nthe lists in the local database (applying the removals before the additions) and then performs the\n[validation check](/safe-browsing/v4/local-databases#validation-checks).\n\n### Additions\n\nAdditions are SHA256 hash prefixes that should be added to the local database. The vast majority\nof hash prefixes are 4 bytes long but some hash prefixes may have any length between 4 and 32 bytes.\nTherefore, multiple sets of additions could be returned; for example, one containing the 4-byte prefixes\nand one containing 5-byte prefixes.\n\nIf the client supports compression, the response may be compressed using Rice compression. However,\nonly 4-byte hash prefixes get compressed. Longer hash prefixes are always sent in uncompressed, raw\nformat (see [Compression](/safe-browsing/v4/compression)).\n\n### Removals\n\nRemovals are zero-based indices in the lexicographically-sorted client database pointing at entries\nthat should be removed from the local database. Only one set of removals will be returned.\n\nIf the client supports compression, \"rice hashes\" and \"rice indices\" are returned. If compression\nis not supported, \"raw hashes\" and \"raw indices\" are returned (see\n[Compression](/safe-browsing/v4/compression)).\n\nValidation checks\n-----------------\n\nWhen the [threatListUpdates.fetch response](/safe-browsing/v4/update-api#http-post-response)\nis returned---with either a full update or a partial update---the client is expected to perform a\nvalidation check.\n\nThe client first updates the lists in the local database (applying the removals before the\nadditions). The client then computes the SHA256 hash of the\n(lexicographically sorted) local list and compares it to the checksum returned in the response.\nIf the two values are equal, the Safe Browsing list is considered \"correct.\"\n\nIf the two values are not equal, the Safe Browsing list is considered \"corrupt.\" The client must\nclear the list from the database and reissue a second update with the `state` field set\nto the empty string; this will force a full update and return a brand new list and state."]]