런 길이 부호화(RLE) 압축률 계산기

같은 값이 이어지는 구간을 「값과 개수」 한 쌍으로 바꿉니다. AAAABBBCCD는 A4B3C2D1이 되어 10자가 8자로 줄어듭니다. 아이디어가 하나뿐이라 압축도 해제도 빠르고 구현이 짧아, 팩스와 BMP·PCX 같은 오래된 형식이 널리 썼습니다.

되풀이가 없기 때문입니다. 「항상 쌍으로」 규약에서는 런 하나가 두 자리를 차지하므로, 평균 런 길이가 2보다 짧으면 반드시 커집니다. 모든 글자가 다른 ABCDEF는 A1B1C1D1E1F1이 되어 정확히 두 배가 됩니다. 그래서 실제 형식들은 압축 결과가 더 크면 원본을 그대로 담는 「무압축」 표시를 따로 둡니다.

어디까지가 값이고 어디부터가 개수인지 알 수 없어 압축이 깨집니다. 「A3B」를 항상 쌍으로 적으면 A1·31·B1이 이어 붙어 A131B1이 되는데, 푸는 쪽은 131을 개수로 읽어 A가 131개인 문자열을 내놓습니다. 규약을 어떻게 잡아도 값과 개수를 같은 줄에 섞어 적는 한 이 모호함은 남으며, 실제 형식은 개수를 고정 길이 바이트에 담거나 이스케이프 바이트를 둡니다.

개수를 담는 칸의 크기만큼만 담고 나머지를 새 런으로 쪼갭니다. 개수를 1바이트에 담는다면 255가 한계이므로 같은 값이 600개 이어질 때 255+255+90 세 덩어리가 됩니다. 이 한계를 빼고 계산하면 압축률이 실제보다 좋게 나오므로, 이 계산기는 한계를 입력으로 노출합니다.

같은 값이 길게 이어지는 자료입니다. 배경이 넓은 그림, 스캔한 흑백 문서, 같은 타일이 되풀이되는 게임 맵이 대표적입니다. 반대로 사진처럼 이웃한 픽셀마다 값이 조금씩 흔들리는 자료에서는 런이 거의 생기지 않아 손해만 봅니다. 그런 자료에는 사전을 쓰는 LZ 계열이나 빈도를 쓰는 허프만이 어울립니다.

전송되지 않습니다. 모든 계산은 브라우저 안에서 이뤄지고, 입력값은 이 기기에만 남습니다.