Local Database
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يتوقّع الإصدار 5 من ميزة "التصفح الآمن من Google" أن يحافظ العميل على قاعدة بيانات محلية، إلا عندما يختار العميل وضع "الوقت الفعلي بدون تخزين". يُرجى العِلم أنّ تنسيق هذه قاعدة البيانات المحلية وتخزينها يعتمدان على العميل. يمكن اعتبار محتوى هذه قاعدة البيانات المحلية من الناحية المفاهيمية كملف مجلد يحتوي على قوائم مختلفة، ومحتوى هذه الملفات هو تجزئات SHA256 أو بادئاتها المقابلة التي تكون بادئة التجزئة المكونة من أربعة بايت هي طول التجزئة الأكثر استخدامًا.
القوائم المتاحة
يتم تحديد القوائم من خلال أسمائها الفريدة التي تتبع اصطلاح تسمية يتضمّن الاسم إضافة تشير إلى طول التجزئة التي تتوقّع ظهورها في القائمة. ستكون قوائم التجزئة التي تتضمّن نوع التهديد نفسه ولكن بطول تجزئة مختلف قائمة تحمل اسمًا منفصلاً ومُحدَّدة بلاحقة تشير إلى طول التجزئة.
تتوفّر القوائم التالية للاستخدام مع طرق قائمة التجزئة.
| اسم القائمة |
التعداد ThreatType المقابل في الإصدار 4 |
الوصف |
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".
تتيح كلّ من طريقة hashList.get وطريقة hashLists.batchGet إجراء تعديلات تدريجية. ويؤدي استخدام التحديثات المتزايدة إلى توفير النطاق الترددي وتحسين الأداء. تعمل التعديلات المتزايدة من خلال تقديم فرق بين إصدار القائمة لدى العميل وأحدث إصدار منها. (إذا تم نشر عميل حديثًا ولم يكن لديه أي إصدارات متوفّرة، يتوفّر تحديث كامل). يحتوي التحديث المتزايد على مؤشرات الإزالة والإضافات. من المتوقّع أن يزيل العميل أولاً الإدخالات في الفهارس المحدّدة من قاعدة بياناته المحلية، ثم يطبّق الإضافات.
أخيرًا، لمنع التلف، يجب أن يتحقّق العميل من البيانات المخزّنة مقارنةً بقيمة التجزئة المقدَّمة من الخادم. عندما لا يتطابق الملخّص، على العميل إجراء تحديث كامل.
فك ترميز محتوى القائمة
فك ترميز قيم التجزئة وبادئات قيم التجزئة
يتم إرسال جميع القوائم باستخدام ترميز خاص لتقليل حجمها. يعمل هذا الترميز من خلال التعرّف على أنّ قوائم "التصفح الآمن من Google" تحتوي، من الناحية المفهومية، على مجموعة من التجزئات أو بادئات التجزئة، والتي لا يمكن تمييزها إحصائيًا عن الأعداد الصحيحة العشوائية. إذا أردنا ترتيب هذه الأعداد الصحيحة وأخذ الفرق المجاور لها، من المتوقّع أن يكون هذا الفرق المجاور "صغيرًا" إلى حدّ ما. يستغل ترميز Golomb-Rice هذا الصغر.
لنفترض أنّه يجب نقل ثلاثة تعبيرات بادئة لمسار اللاحقة للمضيف، وهي 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 إلى حقيقة أنّ البايت الأول من التجزئة الكاملة يصبح البايت الأكثر أهمية من الرقم الصحيح 32 بت. تؤدي هذه الخطوة إلى الحصول على الأعداد الصحيحة 0x291bc542 و0x1d32c508 و0xf7a502e5.
يجب أن يُجري الخادم ترتيبًا أبجديًا لهذه البادئات الثلاث للتشفير (ما يعادل الترتيب الرقمي بالتنسيق الكبير والصغير)، وتكون نتيجة الترتيب هي 0x1d32c508 و0x291bc542 و0xf7a502e5. يتم تخزين بادئة التجزئة الأولى بدون تغيير في حقل first_value.
بعد ذلك، يحتسِب الخادم الفرقَين المجاورَين، وهما 0xbe9003a و0xce893da3 على التوالي. بما أنّه تم اختيار k= 30، يقسم الخادم هذين الرقمين إلى جزءين، جزء حاصل القسمة وجزء المتبقي، بطول 2 و30 بت على التوالي. بالنسبة إلى الرقم الأول، يكون جزء القسمة صفرًا والباقي هو 0xbe9003a. بالنسبة إلى الرقم الثاني، يكون جزء القسمة 3 لأنّ أهم وحدتَي بت هما 11 في النظام الثنائي والباقي هو 0xe893da3. بالنسبة إلى حاصل القسمة المحدَّد q، يتم ترميزه إلى (1 << q) - 1 باستخدام 1 + q بت بالضبط، ويتم ترميز المتبقي مباشرةً باستخدام k بت. يتم ترميز جزء القسمة من الرقم الأول على النحو التالي 0، وجزء المتبقي بالتنسيق الثنائي 001011111010010000000000111010. ويتم ترميز جزء القسمة من الرقم الثاني على النحو التالي 0111، وجزء المتبقي هو 001110100010010011110110100011.
عند تحويل هذه الأرقام إلى سلسلة بايت، يتم استخدام تنسيق little endian. من الناحية النظرية، قد يكون من الأسهل تخيل سلسلة بتات طويلة يتم إنشاؤها بدءًا من البتات الأقل أهمية: نأخذ جزء القسمة من الرقم الأول ونضيف إليه الجزء المتبقي من الرقم الأول، ثم نضيف الجزء المتبقي من الرقم الثاني. من المفترض أن يؤدّي ذلك إلى ظهور العدد الكبير التالي (تمّت إضافة فواصل أسطر وتعليقات للوضوح):
001110100010010011110110100011 # Second number, remainder part
0111 # Second number, quotient part
001011111010010000000000111010 # First number, remainder part
0 # First number, quotient part
إذا كتبت هذا الرمز في سطر واحد، سيظهر على النحو التالي:
00111010001001001111011010001101110010111110100100000000001110100
من الواضح أنّ هذا العدد يتجاوز بكثير الـ 8 بتات المتوفّرة في بايت واحد. بعد ذلك، يأخذ ترميز little endian الثماني بتات الأقل أهمية في هذا الرقم ويعرضها كأول بايت وهو 01110100. للتوضيح، يمكننا تجميع سلسلة البتات أعلاه في مجموعات من ثمانية بتات بدءًا من البتات الأقل أهمية:
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 واستخدامها لجدولة التعديل التالي لقاعدة البيانات. من المحتمل أن تكون هذه القيمة صفرًا (الحقل minimum_wait_duration غير متوفّر تمامًا)، وفي هذه الحالة، على العميل إجراء تعديل آخر على الفور.
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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."]]
