圧縮
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
このドキュメントは、Update API（v4）: threatListUpdates.fetch メソッドに適用されます。
圧縮について
圧縮は、セーフ ブラウジング API（v4）の重要な機能です。圧縮を使用すると、帯域幅の要件が大幅に削減されます。これは、モバイル デバイスに特に関連しますが、これに限定されません。セーフ ブラウジング サーバーは現在、Rice 圧縮をサポートしています。今後、追加の圧縮方法が追加される可能性があります。
圧縮は、supportedCompressions フィールドと CompressionType を使用して設定されます。クライアントは RICE 圧縮タイプと RAW 圧縮タイプを使用する必要があります。圧縮タイプが設定されていない場合、セーフ ブラウジングは COMPRESSION_TYPE_UNSPECIFIED タイプを使用します（RAW 圧縮が代わりに使用されます）。
クライアントが正しい HTTP 圧縮ヘッダーを設定している限り（Wikipedia の記事 HTTP 圧縮を参照）、選択された圧縮タイプに関係なく、セーフ ブラウジング サーバーは標準の HTTP 圧縮を使用してレスポンスをさらに圧縮します。
Rice 圧縮
前述のとおり、セーフ ブラウジング サーバーは現在、Rice 圧縮をサポートしています（Golomb-Rice コーディングの詳細については、Wikipedia の記事の Golomb コーディングをご覧ください）。
圧縮 / 解凍
RiceDeltaEncoding オブジェクトは、Rice-Golomb でエンコードされたデータを表し、圧縮された削除インデックスまたは圧縮された 4 バイトのハッシュ プレフィックスを送信するために使用されます。（4 バイトを超えるハッシュ プレフィックスは圧縮されず、未加工の形式で配信されます）。
削除インデックスの場合、インデックスのリストは昇順で並べ替えられ、RICE エンコードを使用してデルタ エンコードされます。また、4 バイトのハッシュ プレフィックスは、リトル エンディアンの uint32 として再解釈され、昇順で並べ替えられ、RICE エンコードを使用してデルタ エンコードされます。RICE 圧縮と RAW のハッシュ形式は異なります。未加工のハッシュは辞書順で並べ替えられたバイトですが、Rice ハッシュは昇順（解凍後）で並べ替えられた uint32 です。
つまり、整数のリスト [1、5、7、13] は 1（最初の値）として、デルタは [4、2、6] としてエンコードされます。
最初の値は firstValue フィールドに格納され、デルタは Golomb-Rice エンコーダを使用してエンコードされます。Rice パラメータ k（下記参照）は、riceParameter に保存されます。numEntries フィールドには、Rice エンコーダでエンコードされたデルタの数が含まれます（上記の例では 4 ではなく 3）。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 は切り捨てられたバイナリ エンコードを使用してエンコードされます。r の最下位の k ビットのみがビット ストリームから書き込まれます（つまり、読み取られます）。残りの r は q をデコードした後にデコードされます。
ビット エンコーダ / デコーダ
Rice エンコーダは、ビット エンコーダに単一のビットを追加できるビット エンコーダ/デコーダに依存しています。つまり、2 ビット長の除算の商 q をエンコードします。
ビット エンコーダは（8 ビット）バイトのリストです。ビットは最初のバイトの最下位ビットから最初のバイトの最上位ビットに設定されます。バイトのすべてのビットがすでに設定されている場合、新しいバイト（ゼロに初期化）がバイトリストの末尾に追加されます。最後のバイトが完全に使用されていない場合、その最上位ビットはゼロに設定されます。例:
| 追加されたビット |
ビットを追加した後の BitEncoder |
|
[] |
| 0 |
[00000000] |
| 1 |
[00000010] |
| 1 |
[00000110] |
| 1,0,1 |
[00101110] |
| 0,0,0 |
[00101110, 00000000] |
| 1,1,0 |
[00101110, 00000110] |
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-07-25 UTC。
[null,null,["最終更新日 2025-07-25 UTC。"],[[["\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\\] |"]]
