الضغط
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
ينطبق هذا المستند على الطريقة التالية:
Update API (الإصدار 4):
threatListUpdates.fetch.
لمحة عن الضغط
يُعدّ الضغط ميزة أساسية في واجهات برمجة التطبيقات للتصفّح الآمن (الإصدار 4). يقلّل الضغط بشكل كبير من متطلبات معدل نقل البيانات، وهو أمر مهم بشكل خاص، ولكن ليس حصريًا، للأجهزة الجوّالة.
يتوافق خادم "التصفّح الآمن" حاليًا مع ضغط Rice. وقد تتم إضافة طرق ضغط إضافية في المستقبل.
يتم ضبط الضغط باستخدام الحقل
supportedCompressions
وCompressionType.
يجب أن يستخدم العملاء نوعَي الضغط RICE وRAW. يستخدم "التصفّح الآمن" النوع COMPRESSION_TYPE_UNSPECIFIED عندما لا يتم ضبط نوع الضغط (سيتم استبداله بضغط RAW).
سيستخدم خادم "التصفّح الآمن" أيضًا ضغط HTTP العادي لضغط الردود بشكل أكبر، بغض النظر عن نوع الضغط الذي تم اختياره، طالما أنّ العميل يضبط عنوان ضغط HTTP الصحيح (راجِع مقالة ضغط HTTP على Wikipedia).
ضغط الأرز
كما ذكرنا، يتيح خادم "التصفّح الآمن" حاليًا استخدام ضغط Rice (راجِع مقالة ويكيبيديا حول ترميز Golomb للحصول على مناقشة كاملة حول ترميز Golomb-Rice).
الضغط/فك الضغط
يمثّل العنصر
RiceDeltaEncoding
البيانات المشفرة باستخدام Rice-Golomb ويُستخدم لإرسال فهارس الحذف المضغوطة أو بادئات التجزئة المضغوطة المكوّنة من 4 بايت. (لن يتم ضغط بادئات التجزئة التي تزيد عن 4 بايت، وسيتم عرضها بالتنسيق الأولي بدلاً من ذلك).
بالنسبة إلى فهارس الإزالة، يتم ترتيب قائمة الفهارس بترتيب تصاعدي ثم يتم ترميزها باستخدام الترميز الدلتا
باستخدام ترميز RICE. بالنسبة إلى عمليات الإضافة، تتم إعادة تفسير بادئات التجزئة المكوّنة من 4 بايتات على أنّها أعداد صحيحة غير سالبة من 32 بتًا بترتيب تصاعدي، ثم يتم ترميزها باستخدام الترميز التفاضلي باستخدام ترميز RICE.
يُرجى ملاحظة الفرق في تنسيق التجزئة بين ضغط RICE وRAW: تجزئات RAW هي وحدات بايت مرتبة معجميًا، بينما تجزئات Rice هي أعداد صحيحة غير سالبة من 32 بت مرتبة بترتيب تصاعدي (بعد فك الضغط).
أي أنّ قائمة الأعداد الصحيحة [1, 5, 7, 13] سيتم ترميزها على النحو التالي: 1 (القيمة الأولى) والفروق [4, 2, 6].
يتم تخزين القيمة الأولى في الحقل firstValue ويتم ترميز الفروق باستخدام أداة ترميز Golomb-Rice. يتم تخزين المَعلمة k الخاصة بنموذج Rice (راجِع ما يلي) في riceParameter. يحتوي الحقل numEntries على عدد دلتا المشفرة في برنامج ترميز Rice (3 في مثالنا أعلاه، وليس 4). يحتوي الحقل encodedData على دلتا مشفّرة فعلية.
برنامج الترميز/فك الترميز
في برنامج الترميز/فك الترميز Rice، يتم ترميز كل فرق n كـ q وr حيث n = (q<<k) + r
(أو n = q * (2**k) + r). k هو ثابت ومَعلمة في برنامج الترميز/فك الترميز Rice. يتم ترميز قيمتَي q وr في دفق البت باستخدام مخططات ترميز مختلفة.
يتم ترميز خارج القسمة q باستخدام الترميز الأحادي متبوعًا بالرقم 0. أي أنّ الرقم 3 سيتم ترميزه على النحو التالي: 1110، والرقم 4 على النحو التالي: 11110، والرقم 7 على النحو التالي: 11111110. يتم أولاً فك ترميز خارج القسمة q.
يتم ترميز الباقي r باستخدام الترميز الثنائي المختصر. يتم كتابة (وبالتالي قراءة) أقل k بتات أهمية من r فقط من دفق البتات. يتم فك ترميز الباقي r بعد فك ترميز q.
برنامج ترميز/فك ترميز البتات
يعتمد برنامج الترميز Rice على برنامج ترميز/فك ترميز للبتات، حيث يمكن إلحاق بتات فردية ببرنامج ترميز البتات، أي لترميز حاصل القسمة q الذي يمكن أن يكون بطول بتتين فقط.
برنامج ترميز البت هو قائمة من وحدات البايت (8 بت). يتم ضبط البتات من البت الأقل أهمية في البايت الأول إلى البت الأكثر أهمية في البايت الأول. إذا كانت جميع وحدات البايت مضبوطة، تتم إضافة وحدة بايت جديدة (تم ضبطها على صفر) إلى نهاية قائمة وحدات البايت. إذا لم يتم استخدام البايت الأخير بالكامل، يتم ضبط وحدات البت الأكثر أهمية على صفر. مثال:
| تمت إضافة "بتات" |
BitEncoder After Adding Bits |
|
[] |
| 0 |
[00000000] |
| 1 |
[00000010] |
| 1 |
[00000110] |
| 1,0,1 |
[00101110] |
| 0,0,0 |
[00101110, 00000000] |
| 1,1,0 |
[00101110, 00000110] |
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eSafe Browsing APIs (v4) utilize compression, primarily Rice compression, to minimize bandwidth usage, especially beneficial for mobile devices.\u003c/p\u003e\n"],["\u003cp\u003eClients should specify RICE or RAW compression types using the \u003ccode\u003esupportedCompressions\u003c/code\u003e field and \u003ccode\u003eCompressionType\u003c/code\u003e enum; if unspecified, RAW is used by default.\u003c/p\u003e\n"],["\u003cp\u003eIn addition to Rice or RAW compression, Safe Browsing servers employ standard HTTP compression if the client sets the appropriate HTTP compression header.\u003c/p\u003e\n"],["\u003cp\u003eRice compression involves encoding data using the Rice-Golomb method, where data is delta-encoded and represented using the \u003ccode\u003eRiceDeltaEncoding\u003c/code\u003e object.\u003c/p\u003e\n"],["\u003cp\u003eThe Rice encoder/decoder utilizes unary coding for the quotient and truncated binary encoding for the remainder, relying on a bit encoder/decoder to append individual bits to a byte list.\u003c/p\u003e\n"]]],["The Safe Browsing API uses compression to reduce bandwidth, supporting Rice and RAW compression. Clients specify compression types using `supportedCompressions` and `CompressionType`. Rice compression encodes removal indices and 4-byte hash prefixes by sorting values as uint32s, delta encoding them, and storing them in `RiceDeltaEncoding`. This involves unary coding quotients and truncated binary encoding remainders. A bit encoder manages bit streams, packing bits into bytes, adding new bytes as needed. The API also uses HTTP compression.\n"],null,["# Compression\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\nAbout compression\n-----------------\n\nCompression is a key feature of the Safe Browsing APIs (v4). Compression significantly reduces\nbandwidth requirements, which is particularly, but not exclusively, relevant for mobile devices.\nThe Safe Browsing server currently supports Rice compression. Additional compression methods may\nbe added in the future.\n\nCompression is set using the\n[supportedCompressions](/safe-browsing/reference/rest/v4/threatListUpdates/fetch#constraints)\nfield and\n[CompressionType](/safe-browsing/reference/rest/v4/threatListUpdates/fetch#compressiontype).\nClients should use the RICE and RAW compression types. Safe Browsing uses the\nCOMPRESSION_TYPE_UNSPECIFIED type when the compression type is not set (RAW compression will be\nsubstituted).\n\nThe Safe Browsing server will also use standard HTTP compression to further compress responses,\nregardless of the compression type selected, as long as the client sets the correct HTTP compression\nheader (see the Wikipedia article [HTTP compression](https://en.wikipedia.org/wiki/HTTP_compression)).\n\nRice compression\n----------------\n\nAs noted, the Safe Browsing server currently supports Rice compression (see the Wikipedia article\n[Golomb coding](https://en.wikipedia.org/wiki/Golomb_coding)\nfor a full discussion of Golomb-Rice coding).\n\n### Compression/decompression\n\nThe\n[RiceDeltaEncoding](/safe-browsing/reference/rest/v4/threatListUpdates/fetch#RiceDeltaEncoding)\nobject represents the Rice-Golomb encoded data and is used to send compressed removal indices or compressed\n4-byte hash prefixes. (Hash prefixes longer than 4 bytes will not be compressed, and will be served in raw\nformat instead.)\n\nFor removal indices, the list of indices is sorted in ascending order and then delta encoded\nusing RICE encoding. For additions, the 4-byte hash prefixes are re-interpreted as\nlittle-endian uint32s, sorted in ascending order, and then delta encoded using RICE encoding.\nNote the difference in hash format between RICE compression and RAW: raw hashes are\nlexicographically sorted bytes, whereas Rice hashes are uint32s sorted in ascending order (after\ndecompression).\n\nThat is, the list of integers \\[1, 5, 7, 13\\] will be encoded as 1 (the first value) and the\ndeltas \\[4, 2, 6\\].\n\nThe first value is stored in the `firstValue` field and the deltas are encoded using a Golomb-Rice\nencoder. The Rice parameter k (see below) is stored in riceParameter. The `numEntries` field\ncontains the number of deltas encoded in the Rice encoder (3 in our example above, not 4). The\n`encodedData` field contains the actual encoded deltas.\n\n### Encoder/decoder\n\nIn the Rice encoder/decoder every delta n is encoded as q and r where n = (q\\\u003c\\\u003ck) + r\n(or, n = q \\* (2\\*\\*k) + r). k is a constant and a parameter of the Rice encoder/decoder. The\nvalues for q and r are encoded in the bit stream using different encoding schemes.\n\nThe quotient q is encoded in unary coding followed by a 0. That is, 3 would be encoded as 1110, 4\nas 11110 and 7 as 11111110. The quotient q is decoded first.\n\nThe remainder r is encoded using truncated binary encoding. Only the least significant k bits\nof r are written (and therefore read) from the bit stream. The remainder r is decoded after having\ndecoded q.\n\n### Bit encoder/decoder\n\nThe Rice encoder relies on a bit encoder/decoder where single bits can be appended to the bit\nencoder; that is, to encode a quotient q that could be only two bits long.\n\nThe bit encoder is a list of (8-bit) bytes. Bits are set from the lowest significant bit in the\nfirst byte to the highest significant bit in the first byte. If a byte has all its bits already\nset, a new byte (initialized to zero) is appended to the end of the byte list. If the last byte\nis not fully used, its highest significant bits are set to zero. Example:\n\n| Bits Added | BitEncoder After Adding Bits |\n|------------|------------------------------|\n| | \\[\\] |\n| 0 | \\[00000000\\] |\n| 1 | \\[00000010\\] |\n| 1 | \\[00000110\\] |\n| 1,0,1 | \\[00101110\\] |\n| 0,0,0 | \\[00101110, 00000000\\] |\n| 1,1,0 | \\[00101110, 00000110\\] |"]]
