2013-07-01 5 views
1

은 DEFLATE 인코딩이 어떻게 작동하는지 이해하는 데 도움이 필요합니다. 나는 그것이 LZSS 알고리즘과 허프만 코딩의 조합임을 압니다.DEFLATE 정적 허프 먼 코드로 인코딩

그래서 예를 들어 "Deflate late"로 인코딩하십시오. Params : [Search buffer : 8kb, Look-ahead buffer 4kb] LZSS 알고리즘의 출력은 "Deflate < 5, 4>"입니다. 다음 단계에서는 정적 허프만 코딩을 사용하여 중복성을 줄입니다. 여기 내 문제가있다, 나는이 쌍을 어떻게 인코딩해야하는지 모른다. < 5, 4> huffman.


[편집]

D 000
이에 따라

11 잘 001
L 010
011
t 100
_ 101
E, F table "Deflate"라는 문자열은 000 11 001 010 011 100 11 101로 쓰여진다. 다음 단계는 encode t 그는 쌍 (5, 4). "데이터 압축 - 전체 참조"책에 따라 길이 4의 고정 된 접두사 코드는 258이며, 그 뒤에 거리 5의 고정 된 접두사 코드 (코드 4 + 1 추가 비트)가옵니다. 요약하면

:

길이 4 -> 258 -> 0,000,010
거리 5 -> 4 + 1 추가 비트 -> 00100 | 0

는 따라서 부호화 된 문자열로 기록된다 [헤더 : 1 01] 000 11 001 010 011 100 11 101 0000010 001000 [end-of-block : 0000000],하지만 내가 허프만 트리를 만들면 정적 huffman이 아니지, 그렇지?

+0

, 당신은 이미 그 리터럴에 대한 허프만 코드를 방출하는 방법을 알고 있어야합니다. 리터럴 대신 4의 길이와 5의 거리 코드를내는 것과 똑같은 일을합니다. –

+0

이 테이블에 따르면 "Deflate"라는 문자열은 000 11 001 010 011 100 11 101 다음 단계로 쌍 (5, 4)을 인코딩 할 수 있습니다. 책 "데이터 압축 - 전체 참조"에 따라 길이 4의 고정 된 접두사 코드는 258이며, 그 뒤에 거리 5의 고정 된 접두사 코드가옵니다.0 따라서, 상기 인코딩 된 문자열 [헤더로서 기록된다 |> 00100> 258 - -> 0,000,010 [7 비트] 거리 - 5 -> 4 + 1 추가 비트 길이 4 : 1 는 [같이 요약] 01] 000 11 001 010 011 100 11 101 0000010 001000 [end-of-block : 0000000],하지만 허프만 트리를 만들면 정적 huffman이 아니지, 그렇지? – FewG

답변

8
D 000 
f 001 
l 010 
a 011 
t 100 
_ 101 
e 11 

좋은 하루가 공기를 빼다 정적 코드가 아닙니다. 정적 리터럴/길이 코드는 모두 7, 8 또는 9 비트이며 거리 코드는 모두 5 비트입니다. 당신은 정적 코드에 대해 물었다. 리터럴 '공기를 빼다'와 길이 4의 거리 정적 DEFLATE 포맷으로 인코딩

'공기를 빼다 후반 5 헥스 매치는 다음과 같이 세분화된다

73 49 4d cb 49 2c 49 55 00 11 00 

는 (비트로부터 읽어 먼저 각 바이트)의 최하위 부분은 : 당신은 "공기를 빼다"을 인코딩하는 방법을 요구하지 않았기 때문에

011 - 01 means fixed code, 1 means last block 
00101110 - D 
10101001 - e 
01101001 - f 
00111001 - l 
10001001 - a 
00100101 - t 
10101001 - e 
00001010 - space 
0100000 - length 4 
00100 - distance 5 or 6 depending on one extra bit 
0 - extra bit -> distance 5 
0000000 - end code 
0 - fill bit to byte boundary 
+0

00101110 = D와 10101001 = e를 왜 자세히 설명해 주시겠습니까? – TLJ

+2

RFC 1951, 3.2.6 절을 읽으십시오. D = 0x44. 0x30을 추가하여 0x74를 얻으십시오. 비트를 반대로하고 00101110을 얻습니다. e = 0x65. 0x30을 추가하여 0x95를 얻으십시오. 비트를 반전시켜 10101001을 얻으십시오. –

+0

RFC는 매우 혼동스럽고 바이너리가 아닌 10 진수로 된 테이블을 가지고 있으며 테이블이 파생 된 방법을 명확하게 설명하지 않습니다. 0x30은 어디서 났습니까? 항상 + 0x30입니까, 아니면 추가 할 값을 기준으로할까요? 왜 그걸 뒤집어 쓰고있어? 압축 된 데이터를 팽창시키는 명확한 예제를 제공하는 다른 리소스 (RFC 옆에 있음)에 대해 알고 있으며 고정 테이블이 왜 그런지 설명하십시오. – Dan