압축
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이 문서는 다음 Update API (v4):
threatListUpdates.fetch 메서드에 적용됩니다.
압축 정보
압축은 세이프 브라우징 API (v4)의 주요 기능입니다. 압축은 특히 휴대기기와 관련이 있는 대역폭 요구사항을 크게 줄여줍니다.
현재 세이프 브라우징 서버는 Rice 압축을 지원합니다. 향후 추가 압축 방법이 추가될 수 있습니다.
압축은 supportedCompressions 필드와 CompressionType을 사용하여 설정됩니다.
클라이언트는 RICE 및 RAW 압축 유형을 사용해야 합니다. 압축 유형이 설정되지 않은 경우 Safe Browsing에서 COMPRESSION_TYPE_UNSPECIFIED 유형을 사용합니다 (RAW 압축이 대체됨).
Safe Browsing 서버는 선택된 압축 유형에 관계없이 클라이언트가 올바른 HTTP 압축 헤더를 설정하는 한 표준 HTTP 압축을 사용하여 응답을 추가로 압축합니다 (위키백과 문서 HTTP 압축 참고).
Rice 압축
언급한 바와 같이 현재 세이프 브라우징 서버는 Rice 압축을 지원합니다 (Golomb-Rice 코딩에 대한 자세한 내용은 위키백과 문서 Golomb 코딩 참고).
압축/압축 해제
RiceDeltaEncoding 객체는 Rice-Golomb으로 인코딩된 데이터를 나타내며 압축된 삭제 색인 또는 압축된 4바이트 해시 프리픽스를 보내는 데 사용됩니다. (4바이트보다 긴 해시 프리픽스는 압축되지 않으며 대신 원시 형식으로 제공됩니다.)
삭제 색인의 경우 색인 목록이 오름차순으로 정렬된 다음 RICE 인코딩을 사용하여 델타 인코딩됩니다. 또한 4바이트 해시 프리픽스는 little-endian 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은 n = (q<<k) + r(또는 n = q * (2**k) + r)인 q 및 r로 인코딩됩니다. k는 상수이며 Rice 인코더/디코더의 매개변수입니다. q 및 r 값은 다른 인코딩 스키마를 사용하여 비트 스트림에 인코딩됩니다.
몫 q는 단항 코딩으로 인코딩되고 뒤에 0이 붙습니다. 즉, 3은 1110, 4는 11110, 7은 11111110으로 인코딩됩니다. 몫 q가 먼저 디코딩됩니다.
나머지 r은 잘린 바이너리 인코딩을 사용하여 인코딩됩니다. r의 최하위 k 비트만 비트 스트림에서 쓰여지고 읽혀집니다. 나머지 r은 q가 디코딩된 후 디코딩됩니다.
비트 인코더/디코더
Rice 인코더는 비트 인코더에 단일 비트를 추가할 수 있는 비트 인코더/디코더를 사용합니다. 즉, 길이가 2비트일 수 있는 몫 q를 인코딩합니다.
비트 인코더는 (8비트) 바이트의 목록입니다. 비트는 첫 번째 바이트의 최하위 비트에서 첫 번째 바이트의 최상위 비트로 설정됩니다. 바이트에 이미 모든 비트가 설정된 경우 0으로 초기화된 새 바이트는 바이트 목록의 끝에 추가됩니다. 마지막 바이트가 완전히 사용되지 않는 경우 최상위 비트는 0으로 설정됩니다. 예:
| 추가된 비트 |
비트 추가 후 BitEncoder |
|
[] |
| 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 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2025-07-25(UTC)
[[["이해하기 쉬움","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(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\\] |"]]
