짧은 텍스트 문자열을위한 효율적인 압축 알고리즘 [닫기]

126

작은 텍스트 문자열을 압축하는 알고리즘을 찾고 있습니다 : 50-1000 바이트 (예 : URL). 어떤 알고리즘이 가장 적합합니까?

algorithm  compression 
— 바실리 코롤 레프
소스
1
이 압축 된 문자열을 어디에 사용 하시겠습니까?
— Gumbo
1
이것이 tinyurls저장 공간과 관련이 있습니까?
— nik
6
URL 압축 알고리즘에 관심이 있는데, 운영 비용보다 최상의 압축 비율이 더 중요합니다. tinyurls 또는 tr.im과 같은 온라인 서비스에는 관심이 없습니다. 서비스가 아닌 알고리즘을 찾고 있습니다. 다른 정보가 유용하다고 생각하지 마십시오 ...
— Vasily Korolev
3
@Gumbo : "짧은 문자열을위한 텍스트 압축 알고리즘"은 알고리즘을 찾는 데 충분합니다. 왜 그들이 무엇을 알고 있는지에 관심이 있습니까? 나는 OP가 그가 원하는 것을하는 것을 찾을 수있을 것이라고 확신합니다.
— Dervin Thunk
7
@Vasily, 작은 힌트 : " 최고의 XYZ 란 무엇인가 ?" 의 형태로 SO에 대한 질문을 할 때마다 최고를 요구 하면 불필요한 제품으로 이어질 수 있기 때문에 마감에 대한 투표를받을 가능성이 거의 없습니다. 비교 또는 최악의 경우 화염 전쟁. (이를 피하기 위해 보통 아주 작은 변화가 필요합니다. "XYZ를 제안하십시오."와 같은 동일한 질문을하면 기본적으로 동일한 질문이지만 종료 투표 수가 많지 않습니다!
— stakx -더 이상

답변:

62

Smaz를 확인하십시오 :

Smaz는 매우 짧은 문자열을 압축하는 데 적합한 간단한 압축 라이브러리입니다.

— stvchu
소스
17
github.com/antirez/smaz/blob/master/smaz.c를 참조하십시오 -이것은 압축 자체가 아닌 (최소한은 아님) 코딩의 변형입니다. 그는 정적 단어 및 문자 사전을 사용합니다.
— Roy Tinker
7
참고 :이 프로젝트는 antirez의 프로젝트입니다. 그는 Redis의 주요 저자 중 하나이며 고품질의 프로덕션 코드를 발표 한 것으로 매우 유명합니다.
— Homer6
7
Smaz 알고리즘은 영어 텍스트에 최적화되어 있으므로 임의의 문자열에는 적합하지 않습니다. 다음은 몇 가지 샘플 (입니다 string:orig_size:compr_size:space_savings:) This is the very end of it.:27:13:52%, Lorem ipsum dolor sit amet:26:19:27%, Llanfairpwllgwyngyll:20:17:15%, aaaaaaaaaaaaa:13:13:0%, 2BTWm6WcK9AqTU:14:20:-43%,XXX:3:5:-67%
— mykhal
4
또한 낮은 압축에서 살펴하지만 빠른 알고리즘 shoco ed-von-schleck.github.io/shoco
— 당나귀 싱
내 라이브러리 Unishox를 github.com/siara-cc/unishox 목록에 추가하십시오 . Smaz 및 Shoco보다 성능이 우수하며 UTF-8 문자열 압축을 지원합니다.
— 아룬
28

허프만은 정적 비용 인 허프만 테이블을 가지고 있기 때문에 좋은 선택에 동의하지 않습니다.

이를 제거하는 적응 형 버전이 있지만 압축률이 저하 될 수 있습니다. 실제로, 질문해야 할 질문은 "이러한 특성을 가진 텍스트 문자열을 압축하는 알고리즘"입니다. 예를 들어, 긴 반복이 예상되는 경우 간단한 Run-Lengh Encoding으로 충분할 수 있습니다. 영어 단어, 공백, 문장 부호 및 가끔 나오는 숫자 만 표시되도록 보장 할 수있는 경우 사전 정의 된 허프만 테이블이있는 허프만은 좋은 결과를 얻을 수 있습니다.

일반적으로 Lempel-Ziv 제품군의 알고리즘은 압축 및 성능이 매우 우수하며 라이브러리가 풍부합니다. 나는 그와 함께 갈 것입니다.

압축되는 내용이 URL이라는 정보를 사용하면 압축하기 전에 알고리즘을 쉽게 사용할 수 있으므로 압축하기 전에 제안하는 것이 좋습니다. URL은 잘 정의 된 패턴을 따르며 일부는 매우 예측 가능합니다. 이 지식을 활용하면 URL을 더 작은 것으로 URL을 체계화 할 수 있으며 허프만 인코딩의 기본 아이디어가 도움이 될 수 있습니다.

예를 들어, URL을 비트 스트림으로 변환하는 경우 "http"를 비트 1로 바꾸고 다른 비트는 "0"으로 바꾸고 실제 프로 코톨을 붙일 수 있습니다 (또는 표를 사용하여 https와 같은 다른 일반적인 프로토콜을 얻을 수 있음) ftp, 파일). 프로토콜의 끝을 표시 할 수있는 한 ": //"를 모두 삭제할 수 있습니다. 기타 URL 형식에 대해 읽고 공간을 덜 차지하도록 어떻게 코드를 작성할 수 있는지 생각해보십시오.

— 다니엘 C. 소브랄
소스
4
허프만 테이블이 모든 파일에 대해 동일한 경우에는 그렇지 않습니다. 파일이 모두 서로 유사한 경우에는 의미가 있습니다.
— finnw
1
유사하고 작은 파일이 많으면 모두 잘못한 것입니다. 먼저 tar와 같이 모두 연결 한 다음 압축하십시오. 압축률이 향상되고 문제는 "50-1000 바이트"로 중단됩니다.
— Daniel C. Sobral
8
@Daniel : 압축 된 데이터에 무작위로 액세스 할 것인지 여부에 따라 다릅니다. 모두 압축하면 대부분의 압축 시스템에서이를 방지 할 수 있습니다.
— Steve Jessop
22

나는 코드를 가지고 있지 않지만 항상 256 * 256 문자 ( RFC 1978 , PPP Predictor Compression Protocol ) 의 2D 룩업 테이블을 작성하는 접근법을 좋아했습니다 . 문자열을 압축하려면 각 문자를 반복하고 조회 테이블을 사용하여 현재 및 이전 문자를 테이블의 인덱스로 사용하여 '예측 된'다음 문자를 가져옵니다. 일치하는 항목이 있으면 단일 1 비트를 작성하고, 그렇지 않으면 0을 작성하고 룩업 테이블을 현재 문자로 업데이트하십시오. 이 방법은 기본적으로 데이터 스트림에서 가장 가능성이 높은 다음 문자의 동적 (조잡한) 조회 테이블을 유지합니다.

룩업 테이블을 0으로 시작할 수 있지만 영어와 같이 각 문자 쌍에 대해 가장 가능성이 높은 문자로 초기화 된 경우 매우 짧은 문자열에서 가장 잘 작동합니다. 초기 룩업 테이블이 압축 및 압축 해제에 대해 동일하다면 압축 된 데이터로 내 보내지 않아도됩니다.

이 알고리즘은 뛰어난 압축률을 제공하지는 않지만 메모리 및 CPU 리소스가 엄청나게 부담스럽고 ​​연속적인 데이터 스트림에서도 작동 할 수 있습니다. 압축되는 데이터 유형에 맞게 조정합니다.

— Redcalx
소스
그러나 예측자는 일반적인 영어 문장으로 어떻게 행동합니까? 주어진 예제는 매우 강력한 중복성을 가지며 이득은 최소입니다.
— Danubian Sailor
256 * 256 룩업 테이블에서 "메모리가 엄청나게 멍청하다"고 들리지 않습니다 ...!
— MikeW
@MikeW 글쎄, 그것은 65 킬로바이트입니다.
— redcalx
@redcalx 만약 65 바이트라면 나는 동의했을 것이다!
— MikeW
11

사전 설정 사전을 지원하는 알고리즘 / 라이브러리 (예 : zlib) .

이런 식으로 입력에 나타날 수있는 동일한 종류의 텍스트로 컴프레서를 프라이밍 할 수 있습니다. 파일이 어떤 방식 으로든 유사하면 (예 : 모든 URL, 모든 C 프로그램, 모든 StackOverflow 게시물, 모든 ASCII 아트 도면) 특정 하위 문자열이 대부분 또는 모든 입력 파일에 나타납니다.

하나의 입력 파일에서 동일한 하위 문자열이 여러 번 반복되는 경우 모든 압축 알고리즘은 공간을 절약합니다 (예 : 영어 텍스트의 "the"또는 C 코드의 "int").

그러나 URL의 경우 특정 문자열 (예 : " http : // www .", ".com", ".html", ".aspx")은 일반적으로 각 입력 파일에 한 번 표시되므로 파일간에 공유해야합니다. 파일 당 하나의 압축 발생이 아닌 사전 설정 사전에 배치하면이를 달성 할 수 있습니다.

— 지느러미
소스
2
사용자 지정 사전 사용에 대한 팁 : stackoverflow.com/questions/2011653
— Trenton
4

줄임말이 아니라 텍스트를 압축하는 것에 대해 이야기하고 있다면 deflate / gzip (gzip을 감싸는 래퍼), 작은 파일과 텍스트에 zip이 잘 작동합니다. 다른 알고리즘은 bzip2 등과 같은 더 큰 파일에 매우 효율적입니다.

Wikipedia 에는 압축 시간 목록이 있습니다. (효율 비교를 찾으십시오)

Name       | Text         | Binaries      | Raw images
-----------+--------------+---------------+-------------
7-zip      | 19% in 18.8s | 27% in  59.6s | 50% in 36.4s
bzip2      | 20% in  4.7s | 37% in  32.8s | 51% in 20.0s
rar (2.01) | 23% in 30.0s | 36% in 275.4s | 58% in 52.7s
advzip     | 24% in 21.1s | 37% in  70.6s | 57& in 41.6s
gzip       | 25% in  4.2s | 39% in  23.1s | 60% in  5.4s
zip        | 25% in  4.3s | 39% in  23.3s | 60% in  5.7s
— 라이언 크리스텐슨
소스
6
그는 파일이 아닌 텍스트를 압축하려고합니다.
— Gumbo
3
이 알고리즘으로 텍스트와 바이너리를 압축 할 수 있습니다. 실제로 파이썬에서 실행되는 cms 시스템 내에서 수축을 사용합니다.
— 라이언 크리스텐슨
문자열에 gzip을 사용하는 C #의 예는 다음과 같습니다. csharphelp.com/archives4/archive689.html
— Ryan Christensen
압축 문자열을 파이썬에서 ZLIB 모듈 : python.org/doc/2.5.2/lib/module-zlib.html
— 라이언 크리스텐슨
3
gzip (및 zlib)은 수축을 사용하고 래퍼 / 프레이밍 오버 헤드를 추가합니다. 직접 수축 / LZ77 (사전 오버 헤드 및 효율성은 여전히 ​​이러한 구현 및 설정의 구현에 따라 다름)로 손익 분기점을 줄일 수 있습니다. 이것은 물론 수십에서 수백 개의 문자로 된 "짧은"문자열을위한 것입니다 (데이터 확대를 피하기 위해 "이것은 압축 되었습니까?"를 나타내는 비트가 있어야합니다). 텍스트가 증가함에 따라 더 큰 추가 오버 헤드는 중요하지 않습니다. 숫자는 여기에 대한 것으로 보인다 게시 된 대형 - 영업 이익은 50 ~ 1000 개 헌장을 요구하면서, (! (초)을 실행하기 위해) 텍스트 파일을 매우 작은 비교한다.
— user2864740
2

유니 코드에 대한 표준 압축 체계를 살펴볼 수 있습니다 .

SQL Server 2008 R2는 내부적으로 사용하며 최대 50 % 압축을 달성 할 수 있습니다.

— 르 히보
소스
SCSU는 영어 이외의 유니 코드를 UTF-16 / MB 인코딩으로 '압축'합니다. 영어 기반 유니 코드 / 일반 ASCII 인 경우 UTF-8도 UTF-16의 50 %를 '압축'합니다.
— user2864740
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.