Bzip2
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
Bzip2는 1996년에 처음 공개된 데이터 압축 프로그램이다. 여러 계층의 압축 기법을 사용하여 데이터를 압축하며, 런 길이 인코딩, Burrows-Wheeler 변환, 앞으로 이동 변환, 허프만 코딩 등을 차례로 적용한다. Gzip이나 ZIP보다 압축률이 높지만, 압축 속도는 느리다. Bzip2는 파일 형식으로도 사용되며, 압축된 블록을 병렬로 압축 해제할 수 있어 빅 데이터 응용 프로그램에 활용되기도 한다.
더 읽어볼만한 페이지
- 유닉스 보관 및 압축 관련 유틸리티 - Gzip
gzip은 DEFLATE 알고리즘을 기반으로 데이터를 압축하는 파일 형식으로, 매직 넘버, 헤더, 압축된 페이로드 등을 포함하며, 단일 파일 압축에 주로 사용되고 HTTP 압축 및 다양한 응용 분야에서 활용된다. - 유닉스 보관 및 압축 관련 유틸리티 - XZ Utils
XZ Utils는 xz 및 lzma 파일 형식의 압축 및 압축 해제를 위한 소프트웨어로, 높은 압축률을 제공하며, 2024년에는 백도어 삽입으로 인한 보안 취약점이 발생했다. - 자유 압축 소프트웨어 - Gzip
gzip은 DEFLATE 알고리즘을 기반으로 데이터를 압축하는 파일 형식으로, 매직 넘버, 헤더, 압축된 페이로드 등을 포함하며, 단일 파일 압축에 주로 사용되고 HTTP 압축 및 다양한 응용 분야에서 활용된다. - 자유 압축 소프트웨어 - XZ Utils
XZ Utils는 xz 및 lzma 파일 형식의 압축 및 압축 해제를 위한 소프트웨어로, 높은 압축률을 제공하며, 2024년에는 백도어 삽입으로 인한 보안 취약점이 발생했다. - 1996년 소프트웨어 - Xfce
Xfce는 올리비에 푸르당이 1996년에 시작한 GTK+ 기반의 자유 소프트웨어 데스크톱 환경으로, 가벼운 사용감과 모듈화된 구조, 사용자 정의 용이성이 특징이며 낮은 사양의 컴퓨터에서도 원활하게 실행되도록 설계되었다. - 1996년 소프트웨어 - 인터넷 익스플로러 3
인터넷 익스플로러 3은 마이크로소프트가 무료로 배포한 웹 브라우저로, 넷스케이프 플러그인 기술, ActiveX, 프레임, JScript를 지원하고 CSS를 처음 도입했으며, 윈도우 외 솔라리스 버전과 인터넷 메일, 뉴스, 주소록 소프트웨어를 통합 제공했으나 보안 문제에 직면하여 업데이트를 통해 해결하고 암호화 기능을 강화했다.
| Bzip2 - [IT 관련 정보]에 관한 문서 | |
|---|---|
| 일반 정보 | |
 | |
| 종류 | 데이터 압축 |
| 개발 | |
| 원작자 | 줄리안 수어드 |
| 개발자 | 마크 비엘라드 페데리코 메나 미카 스나이더 |
| 출시 | |
| 최초 출시일 | 1996년 7월 18일 |
| 최신 버전 출시일 | 2019년 7월 13일 (1.0.8) |
| 기타 정보 | |
| 저장소 | bzip2 GitLab 저장소 |
| 운영 체제 | 크로스 플랫폼 |
| 라이선스 | 수정된 zlib 라이선스 |
| 웹사이트 | bzip2 공식 웹사이트 |
| 파일 포맷 | |
| 확장자 | .bz2 |
| MIME 형식 | application/x-bzip2 |
| Uniform Type Identifier (UTI) | public.bzip2-archive |
| 타입 코드 | Bzp2 |
| 매직 넘버 | BZh |
2. 역사
줄리안 세워드는 1996년 7월 bzip2 버전 0.15를 최초로 공개했다. 압축기의 안정성과 인기는 그 후 몇 년 동안 증가했으며, 세워드는 2000년 말에 버전 1.0을 출시했다. 2010년 이후 9년 동안 프로젝트 업데이트가 중단된 후, 2019년 6월 4일 페데리코 메나가 bzip2 프로젝트의 유지 관리를 맡았다.[4] 2021년 6월부터 유지 관리자는 마이카 스나이더이다.[5]
bzip2는 여러 계층의 압축 기법을 겹쳐서 사용하며, 압축 시에는 정해진 순서대로, 압축 해제 시에는 그 역순으로 수행된다. bzip2의 핵심적인 압축 알고리즘은 Burrows-Wheeler 변환(BWT)이며, 가역적인 블록 정렬 방식이다. 이 외에도 런 길이 인코딩(RLE), 앞으로 이동(MTF) 변환, 허프만 코딩 등 다양한 기법들이 사용된다.
3. 구현
최악의 경우 1.25배의 확장을 유발할 수 있지만, 최상의 경우에는 입력 데이터를 0.02배 미만으로 줄일 수 있다. bzip2의 저자는 초기 RLE 단계가 역사적인 실수이며, 원래 BWT 구현을 특정 경우로부터 보호하기 위한 의도였다고 밝혔다.[6]
BWT 단계에서 블록은 완전히 자체 포함되며, 입력 및 출력 버퍼는 동일한 크기를 유지한다. bzip2에서 이 단계의 작동 제한은 이다.
MTF 변환은 처리된 블록의 크기를 변경하지 않으며, 자주 나타나는 심볼에 낮은 값을 할당하여 데이터 스트림을 효율적으로 인코딩할 수 있도록 돕는다.
허프만 코딩 단계에서는 0-258 범위의 고정 길이 심볼을 사용 빈도에 따라 가변 길이 코드로 대체한다. 더 자주 사용되는 코드는 짧게(2–3 비트) 끝나고, 희귀한 코드는 최대 20비트까지 할당될 수 있다.
여러 개의 허프만 테이블을 사용하여 압축 효율을 높일 수 있으며, 처리된 50개의 심볼마다 가장 적절한 테이블을 다시 선택한다. 이는 DEFLATE와 같이 새로운 테이블을 지속적으로 제공할 필요 없이 반응적인 허프만 역학을 갖는 장점이 있다.
허프만 코드 비트 길이의 델타 인코딩(Δ)과 사용된 심볼을 보여주는 희소 비트 배열을 통해 효율적인 압축을 달성한다.
3. 1. 단계
bzip2는 여러 단계의 압축 기법을 사용하며, 압축 시에는 다음 순서로, 압축 해제 시에는 역순으로 진행된다.
# 초기 데이터의 런 길이 인코딩(RLE).
# Burrows-Wheeler 변환(BWT).
# 앞으로 이동(MTF) 변환.
# MTF 결과의 런 길이 인코딩 (RLE).
# 허프만 코딩.
# 여러 허프만 테이블 간의 선택.
# 허프만 테이블 선택의 단항 base-1 인코딩.
# 허프만 코드 비트 길이의 델타 인코딩 (Δ).
# 사용된 심볼을 보여주는 희소 비트 배열.
1. 초기 데이터의 런 길이 인코딩 (RLE):4개에서 255개의 연속적인 중복 심볼은 처음 4개의 심볼과 0에서 251 사이의 반복 길이로 대체된다. 예를 들어, "AAAAAAABBBBCCCD"는 "AAAA\3BBBB\0CCCD"로 대체된다. (\3과 \0은 각각 3과 0을 나타내는 바이트 값이다.) 심볼의 런은 런 길이가 0으로 설정되어 있더라도 4개의 연속 심볼 이후에 항상 변환되어, 변환을 되돌릴 수 있도록 한다.
2. Burrows-Wheeler 변환 (BWT):bzip2의 핵심인 가역적인 블록 정렬이다. 블록은 완전히 자체 포함되며, 입력 및 출력 버퍼는 동일한 크기를 유지한다. bzip2에서 이 단계의 작동 제한은 900KB이다. 블록 정렬 시에는, (개념적인) 행렬이 생성되며, 여기서 행 ''i''는 버퍼 전체를 포함하고, i번째 심볼에서 시작하도록 회전된다. 회전 후 행렬의 행은 알파벳(숫자) 순서로 정렬된다. 블록이 변환되지 않을 때를 표시하는 24비트 포인터가 저장된다. 실제로 전체 행렬을 구성할 필요는 없으며, 버퍼의 각 위치에 대한 포인터를 사용하여 정렬이 수행된다. 출력 버퍼는 행렬의 마지막 열이며, 이 버퍼는 전체 버퍼를 포함하지만 동일한 심볼의 큰 런을 포함할 가능성이 있도록 재정렬된다.
3. 앞으로 이동 (MTF) 변환:처리된 블록의 크기를 변경하지 않는다. 문서에 사용된 각 심볼은 배열에 배치된다. 심볼이 처리되면 배열에서 해당 위치(인덱스)로 대체되고, 해당 심볼은 배열의 맨 앞으로 이동한다. 그 결과, 즉시 반복되는 심볼은 0 심볼로 대체되고(따라서 임의의 심볼의 긴 런은 0 심볼의 런이 됨), 다른 심볼은 해당 지역 빈도에 따라 다시 매핑된다.
4. MTF 결과의 런 길이 인코딩 (RLE):앞으로 이동 변환의 출력에서 0의 긴 문자열(BWT의 출력에서 반복되는 심볼에서 옴)은 런 길이를 이진 숫자로 나타내는 두 개의 특수 코드인 RUNA 및 RUNB로 대체된다. 실제 0은 출력에 절대 인코딩되지 않는다. 단일 0은 RUNA가 된다. MTF가 0을 생성할 때마다 카운터를 증가시켜 RUNA와 RUNB로 인코딩한다.
시퀀스 `0, 0, 0, 0, 0, 1`은 `RUNA, RUNB, 1`로 표시된다. `RUNA, RUNB`는 값 5를 나타낸다. 런 길이 코드는 다른 일반 심볼에 도달하면 종료된다. 이 RLE 프로세스는 초기 RLE 단계보다 더 유연하며, 임의로 긴 정수를 인코딩할 수 있다. 런 길이는 다음과 같은 방식으로 인코딩된다. 시퀀스에서 첫 번째 비트에 1, 두 번째 비트에 2, 세 번째 비트에 4 등을 할당하고, RUNB 위치의 각 위치 값을 2로 곱하고, 모든 결과 위치 값을 함께 더한다(RUNA 및 RUNB 값 모두). 이는 2진 전단사적 기수법과 유사하다. 따라서 시퀀스 `RUNA, RUNB`는 값 (1 + 2 × 2) = 5를 생성한다.
5. 허프만 코딩:0–258 범위의 고정 길이 심볼을 사용 빈도에 따라 가변 길이 코드로 대체한다. 더 자주 사용되는 코드는 짧게(2–3 비트) 끝나고, 희귀한 코드는 최대 20비트까지 할당될 수 있다. 코드는 비트 시퀀스가 다른 코드로 혼동될 수 없도록 신중하게 선택된다.
스트림 종료 코드는 특히 흥미롭다. 압축되지 않은 데이터에 사용된 서로 다른 ''n''개의 바이트(심볼)가 있는 경우, 허프만 코드는 두 개의 RLE 코드(RUNA 및 RUNB), ''n'' − 1개의 심볼 코드 및 하나의 스트림 종료 코드로 구성된다. 이전 두 단계에서 MTF 및 RLE 인코딩의 결합된 결과로 인해 MTF 테이블의 첫 번째 심볼을 명시적으로 참조할 필요가 없다(일반 MTF에서는 0이 됨). 따라서 스트림 종료 마커에 대한 하나의 심볼을 절약한다. 압축되지 않은 데이터에 단 하나의 심볼만 사용되는 극단적인 경우, 허프만 트리에는 심볼 코드가 전혀 없으며 전체 블록은 RUNA와 RUNB(단일 바이트를 암시적으로 반복)와 값 2의 스트림 종료 마커로 구성된다.
: 0: RUNA,
: 1: RUNB,
: 2–257: 바이트 값 0–255,
: 258: 스트림 종료, 처리 완료(2만큼 낮을 수 있음).
6. 여러 허프만 테이블 간의 선택:여러 개의 동일한 크기의 허프만 테이블은 사용에 따른 이득이 추가 테이블을 포함하는 비용보다 큰 경우 블록과 함께 사용할 수 있다. 최소 2개에서 최대 6개의 테이블이 존재할 수 있으며, 처리된 50개의 심볼마다 가장 적절한 테이블을 다시 선택한다. 이는 DEFLATE에서와 같이 새로운 테이블을 지속적으로 제공할 필요 없이 매우 반응적인 허프만 역학을 갖는 장점이 있다.
7. 허프만 테이블 선택의 단항 base-1 인코딩:여러 허프만 테이블이 사용 중인 경우, 각 테이블(0에서 5까지 번호가 매겨짐)의 선택은 길이가 1에서 6비트 사이의 0으로 종료되는 비트 런으로 목록에서 수행된다. 선택은 테이블의 MTF 목록으로 이루어진다.
8. 허프만 코드 비트 길이의 델타 인코딩 (Δ):사용된 각 정규 허프만 테이블을 재구성하려면 허프만 코드 비트 길이가 필요하다. 각 비트 길이는 이전 코드 비트 길이에 대한 인코딩된 차이로 저장된다. 0 비트(0)는 이전 비트 길이가 현재 코드에 대해 복제되어야 함을 의미하고, 1 비트(1)는 추가 비트를 읽고 해당 값에 따라 비트 길이를 증가시키거나 감소시켜야 함을 의미한다.
9. 사용된 심볼을 보여주는 희소 비트 배열:비트맵은 블록 내에서 사용되고 허프만 트리에 포함되어야 하는 심볼을 표시하는 데 사용된다. 이진 데이터는 바이트로 표현할 수 있는 모든 256개의 심볼을 사용할 가능성이 높지만, 텍스트 데이터는 사용 가능한 값의 작은 하위 집합만 사용할 수 있다. 대부분 사용되지 않는 경우 256개의 0 비트를 저장하는 것은 비효율적이다. ''희소'' 방법이 사용된다. 256개의 심볼은 16개의 범위로 나뉘며, 해당 블록 내에서 심볼이 사용되는 경우에만 16비트 배열이 포함된다. 이러한 16개의 각 범위의 존재는 앞에 추가 16비트 비트 배열로 표시된다.
3. 2. 상세 설명
bzip2는 여러 압축 기법을 겹쳐서 사용하며, 압축 시에는 다음 순서로, 압축 해제 시에는 역순으로 진행된다.
# 초기 데이터의 런 길이 인코딩 (RLE).
# Burrows-Wheeler 변환 (BWT).
# 앞으로 이동 (MTF) 변환.
# MTF 결과의 런 길이 인코딩 (RLE).
# 허프만 코딩.
# 여러 허프만 테이블 간의 선택.
# 허프만 테이블 선택의 단항 base-1 인코딩.
# 허프만 코드 비트 길이의 델타 인코딩 (Δ).
# 사용된 심볼을 보여주는 희소 비트 배열.
1. 런 길이 인코딩 (RLE)4개에서 255개의 연속적인 중복 심볼은 처음 4개의 심볼과 0에서 251 사이의 반복 길이로 대체된다. 예를 들어, "AAAAAAABBBBCCCD"는 "AAAA\3BBBB\0CCCD"로 대체된다. (\3과 \0은 각각 바이트 값 3과 0을 나타낸다.) 심볼의 런은 런 길이가 0으로 설정되어 있더라도 4개의 연속 심볼 이후에 항상 변환되어 변환을 되돌릴 수 있다.
bzip2의 저자는 RLE 단계가 역사적인 실수이며, 원래 BWT 구현을 병리적인 경우로부터 보호하기 위한 의도였다고 밝혔다.[6]
2. Burrows-Wheeler 변환 (BWT)bzip2의 핵심인 가역적인 블록 정렬이다. 블록은 완전히 자체 포함되어 있으며 입력 및 출력 버퍼는 동일한 크기를 유지한다. bzip2에서 이 단계의 작동 제한은 900KB이다. 블록 정렬 시, 행렬이 생성되며, 여기서 각 행은 버퍼 전체를 포함하고, i번째 심볼에서 시작하도록 회전된다. 회전 후 행렬의 행은 알파벳(숫자) 순서로 정렬된다. 블록이 변환되지 않을 때를 표시하는 24비트 포인터가 저장된다. 출력 버퍼는 행렬의 마지막 열이며, 동일한 심볼의 큰 런을 포함할 가능성이 있도록 재정렬된다.
3. 앞으로 이동 (MTF) 변환처리된 블록의 크기를 변경하지 않는다. 문서에 사용된 각 심볼은 배열에 배치된다. 심볼이 처리되면 배열에서 해당 위치(인덱스)로 대체되고 해당 심볼은 배열의 맨 앞으로 이동한다. 즉시 반복되는 심볼은 0 심볼로 대체되고(긴 런은 0 심볼의 런이 됨), 다른 심볼은 해당 지역 빈도에 따라 다시 매핑된다.
4. MTF 결과의 런 길이 인코딩 (RLE)MTF 변환의 출력에서 0의 긴 문자열(BWT의 출력에서 반복되는 심볼에서 옴)은 RUNA 및 RUNB로 대체된다. 0은 출력에 절대 인코딩되지 않으며, 단일 0은 RUNA가 된다. MTF가 0을 생성할 때마다 카운터를 증가시켜 RUNA와 RUNB로 인코딩한다.
`0, 0, 0, 0, 0, 1`은 `RUNA, RUNB, 1`로 표시된다. `RUNA, RUNB`는 값 5를 나타낸다. 런 길이 코드는 다른 일반 심볼에 도달하면 종료된다. 이 RLE는 초기 RLE 단계보다 더 유연하며, 임의로 긴 정수를 인코딩할 수 있다. 런 길이는 2진 전단사적 기수법과 유사하게 인코딩된다.
5. 허프만 코딩0–258 범위의 고정 길이 심볼을 사용 빈도에 따라 가변 길이 코드로 대체한다. 더 자주 사용되는 코드는 짧게(2–3 비트) 끝나고, 희귀한 코드는 최대 20비트까지 할당될 수 있다.
스트림 종료 코드는 압축되지 않은 데이터에 사용된 서로 다른 ''n''개의 바이트(심볼)가 있는 경우, 허프만 코드는 두 개의 RLE 코드(RUNA 및 RUNB), ''n'' − 1개의 심볼 코드 및 하나의 스트림 종료 코드로 구성된다.
6. 여러 허프만 테이블 간의 선택동일한 크기의 허프만 테이블은 사용에 따른 이득이 추가 테이블을 포함하는 비용보다 큰 경우 블록과 함께 사용할 수 있다. 최소 2개에서 최대 6개의 테이블이 존재할 수 있으며, 처리된 50개의 심볼마다 가장 적절한 테이블을 다시 선택한다.
7. 허프만 테이블 선택의 단항 base-1 인코딩여러 허프만 테이블이 사용 중인 경우, 각 테이블(0에서 5까지 번호가 매겨짐)의 선택은 길이가 1에서 6비트 사이의 0으로 종료되는 비트 런으로 목록에서 수행된다. 선택은 테이블의 MTF 목록으로 이루어진다.
8. 허프만 코드 비트 길이의 델타 인코딩 (Δ)각 정규 허프만 테이블을 재구성하려면 허프만 코드 비트 길이가 필요하다. 각 비트 길이는 이전 코드 비트 길이에 대한 인코딩된 차이로 저장된다. 0 비트(0)는 이전 비트 길이가 현재 코드에 대해 복제되어야 함을 의미하고, 1 비트(1)는 추가 비트를 읽고 해당 값에 따라 비트 길이를 증가시키거나 감소시켜야 함을 의미한다.
9. 사용된 심볼을 보여주는 희소 비트 배열비트맵은 블록 내에서 사용되고 허프만 트리에 포함되어야 하는 심볼을 표시하는 데 사용된다. 이진 데이터는 바이트로 표현할 수 있는 모든 256개의 심볼을 사용할 가능성이 높지만, 텍스트 데이터는 사용 가능한 값의 작은 하위 집합만 사용할 수 있다. ''희소'' 방법이 사용되며, 256개의 심볼은 16개의 범위로 나뉘며, 해당 블록 내에서 심볼이 사용되는 경우에만 16비트 배열이 포함된다. 이러한 16개의 각 범위의 존재는 앞에 추가 16비트 비트 배열로 표시된다.
4. 파일 형식
bzip2는 공식적인 명세가 없지만, 레퍼런스 구현을 통해 비공식적인 명세가 역설계되었다.[7]
`.bz2` 스트림은 4바이트 헤더, 0개 이상의 압축된 블록, 스트림 종료 마커(32비트 CRC 포함)로 구성된다. 압축된 블록들은 비트 단위로 정렬되며 패딩은 없다.
단일 900kB bzip2 블록은 RLE 압축의 첫 단계로 인해 최대 약 46MB(45,899,236 바이트)의 일반 텍스트를 포함할 수 있다. 이는 전체 텍스트가 반복되는 값으로 구성될 때 발생하며, 이때 `.bz2` 파일은 46바이트가 된다. 251의 값만 가지는 입력은 40바이트의 파일을 생성하여 1147480.9:1의 압축률을 보인다.
bzip2 압축 블록은 이전 블록 처리 없이 압축 해제가 가능하여, Hadoop, Apache Spark 같은 클러스터 컴퓨팅 프레임워크의 빅 데이터 응용 프로그램에 적합하다.[8]
4. 1. 구조
bzip2에 대한 공식적인 명세는 존재하지 않지만, 레퍼런스 구현으로부터 비공식적인 명세가 역설계되었다.[7]개략적으로 `.bz2` 스트림은 4바이트 헤더로 구성되며, 그 뒤에 0개 이상의 압축된 블록이 오고, 즉시 처리된 전체 스트림에 대한 32비트 CRC를 포함하는 스트림 종료 마커가 온다. 압축된 블록은 비트 정렬되며 패딩은 발생하지 않는다.
| 필드 | 설명 |
|---|---|
| .magic:16 | BZ 시그니처/매직 넘버 |
| .version:8 | Bzip2의 경우 h (Huffman 코딩), Bzip1의 경우 0 (더 이상 사용되지 않음) |
| .hundred_k_blocksize:8 | 1..9 블록 크기 100 kB-900 kB (압축되지 않음) |
| .compressed_magic:48 | 0x314159265359 (BCD (pi)) |
| .crc:32 | 이 블록에 대한 체크섬 |
| .randomised:1 | 0=>정상, 1=>랜덤화 (더 이상 사용되지 않음) |
| .origPtr:24 | untransform 후 BWT로의 시작 포인터 |
| .huffman_used_map:16 | 16바이트 범위의 비트맵, 존재/미존재 |
| .huffman_used_bitmaps:0..256 | 사용된 심볼의 비트맵, 존재/미존재 (16의 배수) |
| .huffman_groups:3 | 2..6 사용 중인 서로 다른 허프만 테이블 수 |
| .selectors_used:15 | 허프만 테이블이 교체된 횟수(각 50개 심볼) |
| *.selector_list:1..6 | MTF된 허프만 테이블의 0으로 끝나는 비트 런 (0..62) (*selectors_used) |
| .start_huffman_length:5 | 0..20 허프만 델타의 시작 비트 길이 |
| *.delta_bit_length:1..40 | 0=>다음 심볼; 1=>길이 변경 { 1=>길이 감소; 0=>길이 증가 } (*(symbols+2)*groups) |
| .contents:2..∞ | 블록 끝까지 허프만 인코딩된 데이터 스트림 (최대 7372800 비트) |
| .eos_magic:48 | 0x177245385090 (BCD sqrt(pi)) |
| .crc:32 | 전체 스트림에 대한 체크섬 |
| .padding:0..7 | 전체 바이트에 맞춤 |
첫 번째 단계 RLE 압축으로 인해 단일 900 kB bzip2 블록이 포함할 수 있는 일반 텍스트의 최대 길이는 약 46 MB (45,899,236 바이트)이다. 전체 일반 텍스트가 완전히 반복되는 값으로 구성된 경우(이 경우 결과 `.bz2` 파일의 길이는 46 바이트) 이 상황이 발생할 수 있다. 251의 값만 포함하는 입력을 사용하면 40 바이트의 훨씬 더 작은 파일을 얻을 수 있으며, 이는 1147480.9:1의 겉보기 압축률을 나타낸다.
bzip2의 압축된 블록은 이전 블록을 처리하지 않고도 압축 해제할 수 있다. 이는 bzip2 파일을 병렬로 압축 해제할 수 있음을 의미하며, 이는 Hadoop 및 Apache Spark와 같은 클러스터 컴퓨팅 프레임워크를 사용하는 빅 데이터 응용 프로그램에 사용하기에 좋은 형식이다.[8]
5. 압축 효율
bzip2는 버로우즈-휠러 변환을 써서 자주 반복되는 문자열을 같은 문자열로 변환한 다음 MTF 변환, 허프만 부호화를 차례대로 적용하는 구조이다.
bzip2는 gzip이나 ZIP에 비해 대체로 압축률이 좋지만 비교적 느리다. LZMA는 압축 속도가 훨씬 느린 대신 일반적으로 bzip2보다 공간 효율성이 더 높으며, 압축 해제 속도는 더 빠르다.[9]
bzip2는 100~900 kB 크기의 블록으로 데이터를 압축하며, Burrows–Wheeler 변환을 사용하여 자주 반복되는 문자 시퀀스를 동일한 문자의 문자열로 변환한다. 그런 다음 move-to-front 변환 및 허프만 코딩을 적용한다. bzip2의 성능은 비대칭적이며, 압축 해제 속도가 상대적으로 빠르다.
6. 활용
bzip2는 오래된 LZW (.Z) 및 Deflate (.zip 및 .gz) 압축 알고리즘보다 대부분의 파일을 더 효과적으로 압축하지만, 속도는 훨씬 느리다. LZMA는 압축 속도가 훨씬 느린 대신 일반적으로 bzip2보다 공간 효율성이 더 높으며, 압축 해제 속도는 더 빠르다.[9]
bzip2는 100~900 kB 크기의 블록으로 데이터를 압축하며, Burrows–Wheeler 변환을 사용하여 자주 반복되는 문자 시퀀스를 동일한 문자의 문자열로 변환한다. 그런 다음 move-to-front 변환 및 허프만 코딩을 적용한다. bzip2의 조상인 '''bzip'''은 허프만 대신 산술 코딩을 사용했다. 이 변경은 소프트웨어 특허 제한 때문에 이루어졌다.[10]
bzip2의 성능은 비대칭적이며, 압축 해제 속도가 상대적으로 빠르다. 압축에 오랜 시간이 걸린다는 점을 고려하여, 2003년에 여러 청크로 파일을 인코딩하기 위해 멀티스레딩을 사용하여 멀티 CPU 및 멀티 코어 컴퓨터에서 거의 선형적인 속도 향상을 제공하는 pbzip2라는 수정된 버전이 만들어졌다.[12]
gzip과 마찬가지로 bzip2는 데이터 압축기일 뿐이다. tar 또는 ZIP과 같은 아카이버가 아니다. bzip2 파일 형식은 여러 파일의 내용을 단일 압축 파일에 저장하는 것을 지원하지 않으며, 프로그램 자체는 여러 파일, 암호화 또는 아카이브 분할 기능을 제공하지 않는다. UNIX 전통에서, 아카이빙은 bzip2로 압축되는 아카이브를 생성하는 별도의 프로그램으로 수행할 수 있으며, 아카이브 해제는 bzip2로 압축된 아카이브 파일을 압축 해제하고 별도의 프로그램으로 압축 해제하여 수행할 수 있다. 일부 아카이버는 압축 및 압축 해제에 대한 내장 지원을 제공하므로 아카이브를 압축하거나 압축 해제하기 위해 bzip2 프로그램을 사용할 필요가 없다. GnuPG 역시 bzip2 압축 및 압축 해제에 대한 내장 지원을 제공한다.grep 기반 bzgrep 도구를 사용하면 먼저 내용을 압축 해제할 필요 없이 압축된 텍스트를 직접 검색할 수 있다.[13]
7. 한계
bzip2는 오래된 LZW(.Z) 및 Deflate(.zip 및 .gz) 압축 알고리즘보다 대부분의 파일을 더 효과적으로 압축하지만, 속도는 훨씬 느리다. LZMA는 압축 속도가 훨씬 느린 대신 일반적으로 bzip2보다 공간 효율성이 더 높으며, 압축 해제 속도는 더 빠르다.[9]
bzip2의 성능은 비대칭적이며, 압축 해제 속도가 상대적으로 빠르다. 압축에 오랜 시간이 걸린다는 점을 고려하여, 2003년에 여러 청크로 파일을 인코딩하기 위해 멀티스레딩을 사용하여 멀티 CPU 및 멀티 코어 컴퓨터에서 거의 선형적인 속도 향상을 제공하는 pbzip2라는 수정된 버전이 만들어졌다.[12]
gzip과 마찬가지로 bzip2는 데이터 압축기일 뿐이다. tar 또는 ZIP과 같은 아카이버가 아니다. bzip2 파일 형식은 여러 파일의 내용을 단일 압축 파일에 저장하는 것을 지원하지 않으며, 프로그램 자체는 여러 파일, 암호화 또는 아카이브 분할 기능을 제공하지 않는다.
참조
[1]
문서
bzip2/README
https://www.ncbi.nlm[...]
1996-07-18
[2]
웹사이트
bzip2 and libbzip2
https://sourceware.o[...]
[3]
웹사이트
bz2
https://developer.ap[...]
Apple Inc
[4]
웹사이트
Articles with tag bzip2
https://viruta.org/t[...]
[5]
웹사이트
Bzip2's experimental repository is changing maintainership - Federico's Blog
https://viruta.org/b[...]
2022-07-27
[6]
웹사이트
bzip2 and libbzip2, version 1.0.8
https://sourceware.o[...]
[7]
웹사이트
BZIP2 Format Specification
https://github.com/d[...]
2022-03-17
[8]
웹사이트
"[HADOOP-4012] Providing splitting support for bzip2 compressed files"
https://issues.apach[...]
2009
[9]
웹사이트
7-zip vs bzip2 vs gzip
http://compressionra[...]
2019-02-12
[10]
웹사이트
The bzip2 home page
http://www.muraroa.d[...]
2009-03-05
[11]
간행물
kspalaiologos/bzip3
https://github.com/k[...]
2022-10-13
[12]
웹사이트
compressionratings.com
http://ww1.compressi[...]
[13]
웹사이트
bzgrep command in Linux with examples
https://linux.die.ne[...]
[14]
웹사이트
bzip2 : Home
http://www.bzip.org/
Julian Seward
2008-09-27
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com