LZW 압축 단계 계산기

보내지 않습니다. 이것이 LZW의 핵심입니다. 압축하는 쪽과 푸는 쪽이 정확히 같은 규칙으로 사전을 키우기 때문에, 푸는 쪽은 부호 목록만 받아도 같은 사전을 스스로 다시 만들어 냅니다. 사전을 붙여 보내야 한다면 압축한 보람이 크게 줄어들 것입니다.

사전이 커지면 부호 번호도 커져서 더 많은 비트가 필요하기 때문입니다. 사전이 256개일 때는 9비트로 충분하지만 512개가 되는 순간 10비트가 필요합니다. 이 시점을 반영하지 않고 «전부 12비트»처럼 세면 압축률이 실제와 어긋납니다.

«직전에 푼 것 + 그 첫 글자»가 답입니다. 푸는 쪽 사전은 압축하는 쪽보다 한 항목 늦기 때문에 이런 부호가 실제로 날아옵니다. ababababa가 그 예로, 세 번째 부호가 여기에 해당합니다. 이 갈래를 빠뜨린 구현은 대부분의 입력에서 잘 돌다가 이런 입력에서만 깨집니다.

반복이 없으면 사전이 쓸모가 없어 한 바이트(8비트)를 9비트 부호로 바꾸기만 하기 때문입니다. abcdef 여섯 글자는 48비트에서 54비트로 늘어납니다. 무손실 압축은 어떤 방식이든 모든 입력을 줄일 수 없고, 어떤 입력은 반드시 늘어납니다.

됩니다. 다만 UTF-8에서 한글 한 글자가 3바이트라, 사전 항목이 글자 경계에 맞지 않는 경우가 많습니다. 그런 항목은 글자 대신 16진 바이트로 보여 줍니다. GIF·TIFF가 바이트 단위로 다루기 때문이며, 반복이 있으면 압축은 잘 됩니다.

전송되지 않습니다. 압축과 복원은 전부 브라우저 안에서 이뤄지고, 입력값은 이 브라우저의 localStorage에만 남습니다.