Local Database
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
Google Safe Browsing v5 คาดหวังว่าไคลเอ็นต์จะดูแลรักษาฐานข้อมูลในเครื่อง ยกเว้นกรณีที่ไคลเอ็นต์เลือกโหมดเรียลไทม์แบบไม่มีพื้นที่เก็บข้อมูล รูปแบบและพื้นที่เก็บข้อมูลของฐานข้อมูลในเครื่องนี้ขึ้นอยู่กับลูกค้า เนื้อหาของฐานข้อมูลในเครื่องนี้อาจเปรียบเสมือนโฟลเดอร์ที่มีรายการต่างๆ เป็นไฟล์ และเนื้อหาของไฟล์เหล่านี้คือแฮช SHA256 หรือคำนำหน้าที่เกี่ยวข้องซึ่งมีคำนำหน้าแฮช 4 ไบต์ซึ่งเป็นความยาวแฮชที่ใช้กันมากที่สุด
รายการที่ใช้ได้
รายการจะระบุด้วยชื่อที่ไม่ซ้ำกันซึ่งเป็นไปตามรูปแบบการตั้งชื่อที่มีนามสกุลที่บ่งบอกความยาวของแฮชที่คุณควรเห็นในรายการ รายการแฮชที่มีประเภทภัยคุกคามเดียวกันแต่มีความยาวแฮชต่างกันจะเป็นรายการที่มีชื่อแยกต่างหากซึ่งจะมีนามสกุลที่ระบุความยาวแฮช
รายการต่อไปนี้พร้อมให้ใช้งานกับวิธีการรายการแฮช
| ชื่อรายการ |
ThreatType Enum ของ v4 ที่สอดคล้องกัน |
คำอธิบาย |
gc-32b |
ไม่มี |
รายการนี้เป็นรายการแคชส่วนกลาง ซึ่งเป็นรายการพิเศษที่ใช้ในโหมดการดำเนินการแบบเรียลไทม์เท่านั้น |
se-4b |
SOCIAL_ENGINEERING |
รายการนี้มีภัยคุกคามประเภท SOCIAL_ENGINEERING |
mw-4b |
MALWARE |
รายการนี้มีภัยคุกคามประเภทมัลแวร์สำหรับแพลตฟอร์มเดสก์ท็อป |
uws-4b |
UNWANTED_SOFTWARE |
รายการนี้มีภัยคุกคามประเภท UNWANTED_SOFTWARE สำหรับแพลตฟอร์มเดสก์ท็อป |
uwsa-4b |
UNWANTED_SOFTWARE |
รายการนี้มีภัยคุกคามประเภท UNWANTED_SOFTWARE สำหรับแพลตฟอร์ม Android |
pha-4b |
POTENTIALLY_HARMFUL_APPLICATION |
รายการนี้มีภัยคุกคามประเภท POTENTIALLY_HARMFUL_APPLICATION สำหรับแพลตฟอร์ม Android |
รายการเพิ่มเติมอาจพร้อมใช้งานในภายหลัง เมื่อถึงเวลานั้น ตารางด้านบนจะขยายออก และผลลัพธ์จากเมธอด hashList.list จะแสดงผลลัพธ์ที่คล้ายกับรายการล่าสุด
การอัปเดตฐานข้อมูล
โดยไคลเอ็นต์จะเรียกเมธอด hashList.get หรือเมธอด hashLists.batchGet เป็นประจำเพื่ออัปเดตฐานข้อมูล เนื่องจากไคลเอ็นต์ทั่วไปต้องการอัปเดตหลายรายการพร้อมกัน เราจึงขอแนะนำให้ใช้เมธอด hashLists.batchGet
ระบบจะไม่เปลี่ยนชื่อรายการ นอกจากนี้ เมื่อรายการปรากฏขึ้นแล้ว ระบบจะไม่นำรายการนั้นออก (หากรายการไม่มีประโยชน์แล้ว รายการจะว่างเปล่าแต่จะยังคงอยู่ต่อไป) ดังนั้น การเขียนโค้ดชื่อเหล่านี้แบบฮาร์ดโค้ดในโค้ดไคลเอ็นต์ Google Safe Browsing จึงเหมาะสม
ทั้งเมธอด hashList.get และเมธอด hashLists.batchGet รองรับการอัปเดตแบบเพิ่ม การใช้การอัปเดตแบบเพิ่มจะประหยัดแบนด์วิดท์และปรับปรุงประสิทธิภาพ การอัปเดตแบบเพิ่มจะทำงานโดยการส่งค่า Delta ระหว่างรายการเวอร์ชันของลูกค้ากับรายการเวอร์ชันล่าสุด (หากติดตั้งใช้งานไคลเอ็นต์ใหม่และไม่มีเวอร์ชันใดๆ ให้เลือก ให้อัปเดตแบบสมบูรณ์) การอัปเดตแบบเพิ่มมีดัชนีการนำออกและการเพิ่ม ลูกค้าจะต้องนำรายการในดัชนีที่ระบุออกจากฐานข้อมูลในเครื่องก่อน แล้วจึงใช้รายการที่เพิ่ม
สุดท้าย ไคลเอ็นต์ควรตรวจสอบข้อมูลที่จัดเก็บเทียบกับการตรวจสอบผลรวมที่เซิร์ฟเวอร์ระบุไว้เพื่อป้องกันความเสียหาย เมื่อใดก็ตามที่การตรวจสอบผลรวมไม่ตรงกัน ลูกค้าควรทำการอัปเดตอย่างเต็มรูปแบบ
การถอดรหัสเนื้อหารายการ
การถอดรหัสแฮชและคํานําหน้าแฮช
ระบบจะส่งรายการทั้งหมดโดยใช้การเข้ารหัสพิเศษเพื่อลดขนาด การเข้ารหัสนี้ทํางานโดยพิจารณาว่ารายการ Google Safe Browsing มีชุดแฮชหรือคำนำหน้าแฮช ซึ่งแยกแยะไม่ได้จากจำนวนเต็มแบบสุ่มทางสถิติ หากเราจัดเรียงจำนวนเต็มเหล่านี้และนำผลต่างที่อยู่ติดกัน ผลต่างที่อยู่ติดกันดังกล่าวควรจะ "เล็ก" ในบางแง่ จากนั้น การเข้ารหัส Golomb-Rice จะใช้ความเล็กนี้
สมมติว่าต้องส่งนิพจน์คำนำหน้าเส้นทางที่มีนามสกุลของโฮสต์ 3 รายการ ได้แก่ a.example.com/, b.example.com/ และ y.example.com/ โดยใช้คำนำหน้าแฮช 4 ไบต์ ต่อไปสมมติว่าพารามิเตอร์ Rice ซึ่งแสดงด้วย k มีค่าเป็น
- เซิร์ฟเวอร์จะเริ่มด้วยการคำนวณแฮชแบบเต็มสำหรับสตริงเหล่านี้ ซึ่งได้แก่
291bc5421f1cd54d99afcc55d166e2b9fe42447025895bf09dd41b2110a687dc a.example.com/
1d32c5084a360e58f1b87109637a6810acad97a861a7769e8f1841410d2a960c b.example.com/
f7a502e56e8b01c6dc242b35122683c9d25d07fb1f532d9853eb0ef3ff334f03 y.example.com/
จากนั้นเซิร์ฟเวอร์จะสร้างคำนำหน้าแฮช 4 ไบต์สําหรับรายการข้างต้นแต่ละรายการ ซึ่งเป็น 4 ไบต์แรกของแฮชแบบเต็ม 32 ไบต์ ซึ่งตีความเป็นจำนวนเต็ม 32 บิตแบบ Big Endian รูปแบบ Big Endian หมายถึงการที่ไบต์แรกของแฮชแบบเต็มกลายเป็นไบต์ที่มีนัยสำคัญมากที่สุดของจำนวนเต็ม 32 บิต ขั้นตอนนี้จะทำให้เกิดจำนวนเต็ม 0x291bc542, 0x1d32c508 และ 0xf7a502e5
เซิร์ฟเวอร์จำเป็นต้องจัดเรียงคำนำหน้าแฮช 3 รายการนี้ตามลําดับตัวอักษร (เทียบเท่ากับการจัดเรียงตัวเลขใน Big Endian) และผลลัพธ์ของการจัดเรียงคือ 0x1d32c508, 0x291bc542, 0xf7a502e5 ระบบจะจัดเก็บคำนำหน้าแฮชแรกไว้โดยไม่มีการเปลี่ยนแปลงในช่อง first_value
จากนั้นเซิร์ฟเวอร์จะคํานวณผลต่าง 2 รายการที่อยู่ติดกัน ซึ่งได้แก่ 0xbe9003a และ 0xce893da3 ตามลําดับ ในกรณีที่เลือก k เป็น 30 เซิร์ฟเวอร์จะแยกตัวเลข 2 ตัวนี้ออกเป็นส่วนผลหารและส่วนเศษที่มีความยาว 2 และ 30 บิตตามลำดับ สำหรับตัวเลขแรก ส่วนผลหารคือ 0 และส่วนที่เหลือคือ 0xbe9003a ส่วนตัวเลขที่ 2 ส่วนผลหารคือ 3 เนื่องจาก 2 บิตที่มีค่ามากที่สุดคือ 11 ในฐาน 2 และส่วนที่เหลือคือ 0xe893da3 สำหรับผลหาร q หนึ่งๆ ระบบจะเข้ารหัสเป็น (1 << q) - 1 โดยใช้บิต 1 + q บิตพอดี ส่วนเศษจะเข้ารหัสโดยตรงโดยใช้บิต k ส่วนผลหารของจำนวนแรกเข้ารหัสเป็น 0 และส่วนเศษที่เหลือเป็นฐาน 2 001011111010010000000000111010 ส่วนผลหารของจำนวนที่ 2 เข้ารหัสเป็น 0111 และส่วนเศษที่เหลือคือ 001110100010010011110110100011
เมื่อตัวเลขเหล่านี้อยู่ในรูปแบบสตริงไบต์ ระบบจะใช้รูปแบบ Little Endian ในทางแนวคิด คุณอาจจินตนาการได้ง่ายขึ้นว่าสตริงบิตยาวๆ สร้างขึ้นโดยเริ่มจากบิตที่มีนัยสำคัญน้อยที่สุด โดยเราจะนำส่วนเศษของตัวเลขแรกไปไว้ข้างหน้าส่วนเศษของตัวเลขแรก จากนั้นนำส่วนเศษของตัวเลขที่ 2 ไปไว้ข้างหน้าส่วนเศษของตัวเลขแรก ซึ่งควรให้ผลลัพธ์เป็นตัวเลขขนาดใหญ่ต่อไปนี้ (มีการเพิ่มการแบ่งบรรทัดและคําอธิบายเพื่อให้ชัดเจน)
001110100010010011110110100011 # Second number, remainder part
0111 # Second number, quotient part
001011111010010000000000111010 # First number, remainder part
0 # First number, quotient part
เมื่อเขียนเป็นบรรทัดเดียวจะมีลักษณะดังนี้
00111010001001001111011010001101110010111110100100000000001110100
ตัวเลขนี้มากกว่า 8 บิตที่มีให้ในไบต์เดียวอย่างเห็นได้ชัด จากนั้นการเข้ารหัส Little Endian จะนำบิตที่มีนัยสำคัญน้อยที่สุด 8 บิตของตัวเลขนั้น และแสดงผลเป็นไบต์แรกซึ่งเป็น 01110100 เพื่อความชัดเจน เราจะจัดกลุ่มสตริงบิตข้างต้นเป็นกลุ่มละ 8 บิตโดยเริ่มจากบิตที่มีนัยสำคัญน้อยที่สุด
0 01110100 01001001 11101101 00011011 10010111 11010010 00000000 01110100
จากนั้นการเข้ารหัส Little Endian จะนําไบต์แต่ละรายการจากด้านขวาไปใส่ไว้ในสตริงไบต์
01110100
00000000
11010010
10010111
00011011
11101101
01001001
01110100
00000000
จะเห็นได้ว่าเนื่องจากแนวคิดของเราคือใส่ส่วนหน้าให้กับตัวเลขขนาดใหญ่ทางด้านซ้าย (กล่าวคือ เพิ่มบิตที่มีนัยสำคัญมากขึ้น) แต่เราเข้ารหัสจากด้านขวา (กล่าวคือ บิตที่มีนัยสำคัญน้อยที่สุด) การเข้ารหัสและการถอดรหัสจึงทําได้ทีละส่วน
ซึ่งสุดท้ายแล้วจะทำให้
additions_four_bytes {
first_value: 489866504
rice_parameter: 30
entries_count: 2
encoded_data: "t\000\322\227\033\355It\000"
}
ลูกค้าเพียงทำตามขั้นตอนข้างต้นย้อนกลับเพื่อถอดรหัสคำนำหน้าแฮช
การถอดรหัสดัชนีการนำออก
ดัชนีการนําออกได้รับการเข้ารหัสโดยใช้เทคนิคเดียวกันกับด้านบนโดยใช้จำนวนเต็ม 32 บิต
ความถี่ในการอัปเดต
ไคลเอ็นต์ควรตรวจสอบค่าที่เซิร์ฟเวอร์แสดงผลในฟิลด์ minimum_wait_duration และใช้ค่าดังกล่าวเพื่อกำหนดเวลาการอัปเดตฐานข้อมูลครั้งถัดไป ค่านี้อาจเป็น 0 (ช่อง minimum_wait_duration หายไปโดยสมบูรณ์) ซึ่งในกรณีนี้ ลูกค้าควรทำการอัปเดตอีกครั้งทันที
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-25 UTC
[null,null,["อัปเดตล่าสุด 2025-07-25 UTC"],[],[],null,["# Local Database\n\nGoogle Safe Browsing v5 expects the client to maintain a local database, except when the client chooses the [No-Storage Real-Time Mode](/safe-browsing/reference#no-storage-real-time-mode). It is up to the client the format and storage of this local database. The contents of this local database can conceptually be thought of as a folder containing various lists as files, and the contents of these files are SHA256 hashes, or their corresponding prefixes with four byte hash prefix being the most commonly used hash length.\n\n### Available Lists\n\nLists are identified by their distinct names which follows a naming convention where the name contains a suffix that signifies the length of the hash you should expect in the list. Hash lists with the same threat type but different hash length will be a separately named list that's qualified with a suffix that indicates the hash length.\n\nThe following lists are available for use with the hash list methods.\n\n| List Name | Corresponding v4 `ThreatType` Enum | Description |\n|-----------|------------------------------------|------------------------------------------------------------------------------------------------------|\n| `gc-32b` | None | This list is a Global Cache list. It is a special list only used in the Real-Time mode of operation. |\n| `se-4b` | `SOCIAL_ENGINEERING` | This list contains threats of the SOCIAL_ENGINEERING threat type. |\n| `mw-4b` | `MALWARE` | This list contains threats of the MALWARE threat type for desktop platforms. |\n| `uws-4b` | `UNWANTED_SOFTWARE` | This list contains threats of the UNWANTED_SOFTWARE threat type for desktop platforms. |\n| `uwsa-4b` | `UNWANTED_SOFTWARE` | This list contains threats of the UNWANTED_SOFTWARE threat type for Android platforms. |\n| `pha-4b` | `POTENTIALLY_HARMFUL_APPLICATION` | This list contains threats of the POTENTIALLY_HARMFUL_APPLICATION threat type for Android platforms. |\n\nAdditional lists can become available at a later date, at which time the above table will be expanded, and the results from the [hashList.list method](/safe-browsing/reference/rest/v5/hashList/list) will show a similar result with the most up to date lists.\n\n### Database Updates\n\nThe client will regularly call the [hashList.get method](/safe-browsing/reference/rest/v5/hashList/get) or the [hashLists.batchGet method](/safe-browsing/reference/rest/v5/hashLists/batchGet) to update the database. Since the typical client will want to update multiple lists at a time, it is recommended to use [hashLists.batchGet method](/safe-browsing/reference/rest/v5/hashLists/batchGet).\n\nThe list names will never be renamed. Furthermore, once a list has appeared, it will never be removed (if the list is no longer useful, it will become empty but will continue to exist). Therefore, it is appropriate to hard code these names in the Google Safe Browsing client code.\n\nBoth the [hashList.get method](/safe-browsing/reference/rest/v5/hashList/get) and the [hashLists.batchGet method](/safe-browsing/reference/rest/v5/hashLists/batchGet) support incremental updates. Using incremental updates saves bandwidth and improves performance. Incremental updates work by delivering a delta between client's version of the list and the latest version of the list. (If a client is newly deployed and does not have any versions available, a full update is available.) The incremental update contains removal indices and additions. The client is first expected to remove the entries at the specified indices from its local database, and then apply the additions.\n\nFinally, to prevent corruption, the client should check the stored data against the checksum provided by the server. Whenever the checksum does not match, the client should perform a full update.\n\n### Decoding the List Content\n\n#### Decoding Hashes and Hash Prefixes\n\nAll lists are delivered using a special encoding to reduce size. This encoding works by recognizing that Google Safe Browsing lists contain, conceptually, a set of hashes or hash prefixes, which are statistically indistinguishable from random integers. If we were to sort these integers and take their adjacent difference, such adjacent difference is expected to be \"small\" in a sense. [Golomb-Rice encoding](https://en.wikipedia.org/wiki/Golomb_coding) then exploits this smallness.\n\nSuppose that three host-suffix path-prefix expressions, namely `a.example.com/`, `b.example.com/`, and `y.example.com/`, are to be transmitted using 4-byte hash prefixes. Further suppose that the Rice parameter, denoted by k, is chosen to be\n\n1. The server would start by calculating the full hash for these strings, which are, respectively:\n\n 291bc5421f1cd54d99afcc55d166e2b9fe42447025895bf09dd41b2110a687dc a.example.com/\n 1d32c5084a360e58f1b87109637a6810acad97a861a7769e8f1841410d2a960c b.example.com/\n f7a502e56e8b01c6dc242b35122683c9d25d07fb1f532d9853eb0ef3ff334f03 y.example.com/\n\nThe server then forms 4-byte hash prefixes for each of the above, which is the first 4 bytes of the 32-byte full hash, interpreted as big-endian 32-bit integers. The big endianness refers to the fact that the first byte of the full hash becomes the most significant byte of the 32-bit integer. This step results in the integers 0x291bc542, 0x1d32c508, and 0xf7a502e5.\n\nIt is necessary for the server to sort these three hash prefixes lexicographically (equivalent to numerical sorting in big endian), and the result of the sorting is 0x1d32c508, 0x291bc542, 0xf7a502e5. The first hash prefix is stored unchanged in the `first_value` field.\n\nThe server then calculates the two adjacent differences, which are 0xbe9003a and 0xce893da3 respectively. Given that k is chosen to be 30, the server splits these two numbers into the quotient parts and remainder parts that are 2 and 30 bits long respectively. For the first number, the quotient part is zero and the remainder is 0xbe9003a; for the second number, the quotient part is 3 because the most significant two bits are 11 in binary and the remainder is 0xe893da3. For a given quotient `q` it is encoded into `(1 \u003c\u003c q) - 1` using exactly `1 + q` bits; the remainder is encoded directly using k bits. The quotient part of the first number is encoded as 0, and the remainder part is in binary 001011111010010000000000111010; the quotient part of the second number is encoded as 0111, and the remainder part is 001110100010010011110110100011.\n\nWhen these numbers are formed into a byte string, little endian is used. Conceptually it may be easier to imagine a long bitstring being formed starting from the least significant bits: we take the quotient part of the first number and prepend the remainder part of the first number; we then further prepend the quotient part of the second number and prepend the remainder part. This should result in the following large number (linebreaks and comments added for clarity): \n\n 001110100010010011110110100011 # Second number, remainder part\n 0111 # Second number, quotient part\n 001011111010010000000000111010 # First number, remainder part\n 0 # First number, quotient part\n\nWritten in a single line this would be \n\n 00111010001001001111011010001101110010111110100100000000001110100\n\nObviously this number far exceeds the 8 bits available in a single byte. The little endian encoding then takes the least significant 8 bits in that number, and outputs it as the first byte which is 01110100. For clarity, we can group the above bitstring into groups of eight starting from the least significant bits: \n\n 0 01110100 01001001 11101101 00011011 10010111 11010010 00000000 01110100\n\nThe little endian encoding then takes each byte from the right and puts that into a bytestring: \n\n 01110100\n 00000000\n 11010010\n 10010111\n 00011011\n 11101101\n 01001001\n 01110100\n 00000000\n\nIt can be seen that since we conceptually *prepend* new parts to the large number on the left (i.e. adding more significant bits) but we encode from the right (i.e. the least significant bits), the encoding and decoding can be performed incrementally.\n\nThis finally results in \n\n additions_four_bytes {\n first_value: 489866504\n rice_parameter: 30\n entries_count: 2\n encoded_data: \"t\\000\\322\\227\\033\\355It\\000\"\n }\n\nThe client simply follows the above steps in reverse to decode the hash prefixes.\n\n#### Decoding Removal Indices\n\nRemoval indices are encoded using the exact same technique as above using 32-bit integers.\n\n### Update Frequency\n\nThe client should inspect the server's returned value in the field `minimum_wait_duration` and use that to schedule the next update of the database. This value is possibly zero (the field `minimum_wait_duration` is completely missing), in which case the client SHOULD immediately perform another update."]]
