272바이트를 압축하는 최선의 방법은...?
글쓴이: kaos / 작성시간: 금, 2003/02/21 - 11:59오전
네트웍으로 272바이트의 데이터를 보내야 합니다.
그런데 들어갈 내용이 이보다 16바이트정도가 더 커서 압축하여
272바이트 이하의 크기로 만들어 보낼려고 하는데 어떤 방법이 적당할까요..?
데이터에 한글이 포함되어 있어 어렵네요..
허프만 알고리즘을 통해서 압축을 해보았지만 한글이 많이 들어가 있을경우
압축하면 오히려 압축 테이블 사이즈 때문에 더 커지는 문제가 있었습니다.
base64로 인코딩후에 압축하여도 인코딩하는 자체가 사이즈가 커지니 압축
해봐야 별 효과가 없고요..
이런경우는 어떤 방법을 쓰는게 가장 효과적일까요..?
Forums:
zlib 를 써서 압축하세요. (gzip에서 쓰는 알고리즘입니다.)
zlib 를 써서 압축하세요. (gzip에서 쓰는 알고리즘입니다.)
그러나 모든 (272+16) 바이트짜리 메시지를 272 바이트로 압축할 수 있는 알고리즘은 세상에 없습니다. 그냥 300 바이트를 보내면 안 되나요?
허프만 코드를 이용하시면 한글을 많이쓰시든 영어를 많이 쓰시든...
허프만 코드를 이용하시면 한글을 많이쓰시든 영어를 많이 쓰시든...
다이나믹 허프만을 사용할 때, 압축 테이블이 커져서 272바이트는
쉽게 넘겨버립니다. 허프만 코드 같은 것은 도리어 작은 크기의
데이터에서는 불리하다고 볼 수 있습니다. 차라리
제 생각에는 Run-Length 나 Lempel-Ziv 를 쓰는게 더 효율이
좋을 듯 하네요. 어떤 방식이든지 같에, 데이터가 특이한 케이스라면
기본적인 크기보다 더 크게 나올 확률이 큽니다.
그럼 고운 하루..
=========================
CharSyam ^^ --- 고운 하루
=========================
빠른 압축, 더 빠른 decompression LZO
여기를 한번 참조하세요.. http://www.oberhumer.com/opensource/lzo/
저도 최근에 압축이 필요해서 찾은 건데 참 좋습니다. 압축률은 zlib보다 덜하지
만 속도나 메모리 사용량 등의 장점이 있습니다. 특히 좋은 점은 decompression이
compression의 1/6정도의 시간이 걸리고 별도의 메모리가 필요없습닌다.
minilzo라도 있는데 그것도 함 봐보세요..
그냥 데이터특성을 잘 고려하시는 것은 어떠실지요..??
만일 272+16바이트가 완전히 random한 내용이라면, 이 data가 100% 압축됨을 보장하는 알고리즘은 존재할 수가 없겠죠.... (272바이트의 압축된 데이터에 16바이트를 추가했을 때, 이를 다시 272바이트로 압축할 수 있는 알고리즘이 존재하지 않겠죠?)
그렇지 않다면, data를 잘 pack해서 줄이는 방법을 고려해 보시는 게 좋지 않을까요? 288바이트라는 소량의 데이터라면, 272까지 줄이는 데 약간의 꽁수만 쓰면 가능할 것 같은데요...
구체적으로 어떤 데이터가 들어가는지는 잘 모르겠지만요.. 어떤 struct라고 하면 거기의 어떤 값이 갖는 범위가 0~1023이면 이런 성격을 이용해서 줄인다던가... 하는 방법들이 있겠죠..
음... 이 272바이트의 특성에 대해서 좀 더 자세히 얘기해 주신다면 도움을 더 드릴 수 있을 꺼 같은데요....
Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24
한글코드가 많다면 이렇게 가능합니다.
안녕하세요~
먼저 한글코드가 어떻게 이루어지는지는 아실것입니다. 완성형은 잘모르겠는데..(한글코드를 직접 콘트롤해본적이 없어서 주워들은 풍월로) 조합형의 경우는 16bit 중에서 첫번째 1bit 가 1 이면 한글코드로 인식을 합니다.
그렇죠? 그러면 한글코드에서 각각 1bit 를 잘라낸 15bit 로 코드를 연속해서 저장하는 것입니다. 그래서 272byte 의 저장공간이라면 136개의 한글이 아닌 145개의 한글을 저장할수있지요.
영문자나 숫자가 들어간다면 좀 곤란해지겠지만 한글코드만이라면 이것으로 어느정도 해결이되지 않을까요?
음~ 지금 완성형한글코드를 몇개보니까 17번째 bit 도 1이군요.(이건 확실치 않아요.) 그렇다면 저장된 데이터중에서 8번째 비트가 1이면 한글코드로 인식해서 원상복귀시키면 될것 같습니다. 물론 영문자도 7bit 로 표시합니다.
예를 들어볼께요.(영문자 쓸때만 마지막에 0 bit로 구분해서 영문자는 결국 8bit입니다.)
가나다abc123 의 문자열의 경우입니다.
원래는
B0 A1 B3 AA B6 F3 61 62 63 31 32 33 의 코드지요.
2진수로
1011 0000 1010 0001 -> 가
1011 0011 1010 1010 -> 나
1011 0100 1101 1001 -> 다
0110 0001 -> a
0110 0010 -> b
0110 0011 -> c
0011 0001 -> 1
0011 0010 -> 2
0011 0011 -> 3
이렇게 표시됩니다. 총 12 byte 의 저장공간을 차지했습니다.
이것을 위에서 말한대로 바꾸면
011 0000 1010 0001 -> 가
011 0011 1010 1010 -> 나
011 0100 1101 1001 -> 다 -> 이건 앞 1bit 제거
110 00010 -> a
110 00100 -> b
110 00110 -> c
011 00010 -> 1
011 00100 -> 2
011 00110 -> 3 -> 이건 앞 1bit 제거 및 뒤 1bit 에 0추가
어느정도 이해가 가시나요? 보다시피 한글코드는 수정된 코드에서 8bit 자리는 항상 1입니다. 영문이나 숫자는(ascii코드) 0입니다. 코드를 읽을때 앞에서부터 8번째자리를 먼저 파악을 합니다. 1이라면 한글코드이니 15bit를 잘라내서 앞에 1을 붙이고 한글코드로 변환합니다.
계속 이렇게 하다가 8번째 bit 가 0이면 ascii 코드이니 8bit 자리를 잘라내고 앞에 0을 붙이고 ascii 로 인식하면 됩니다.
이렇게 하면 결과적으로 한글의 갯수만큼 bit 수를 줄일수 있습니다.
272byte 의 길이이고 한글이 많이 들어간다고 하셨으니 60%가 한글이라면
80bit 를 절약할수 있습니다. 10byte 정도 확보되는군요. 그럼 80%가 한글이라면 13.6byte 가 확보되구요.
전체가 한글이라야지만 17byte 를 줄일수 있겠네요. --; 좀 사용하기 곤란한가요??
방금 이 게시물을 대상으로 띄어쓰기 포함해서 288byte 를 만들어서 한글이 몇글자 들어가나 테스트해보니 120자 들어가는군요. 120bit 확보되었네요. 15byte 확보군요. 좀더 연구해보시면 더 좋은 결과가 있을 것입니다.
행복하세요~
Re: 한글코드가 많다면 이렇게 가능합니다.
음 위에 적으신 분들의 글을 보고 추가글을 적습니다.
어쩌면 넘어가는 데이터 문자열이 구조체의 형태를 가지고 있다면 각 구조의 문자열 형태에 따라 영문자를 7bit 로 만들어서 보낼수도 있습니다. 예를 들어서 전화번호, 우편번호, email주소 등은 숫자나 영문으로만 이루어져있으니 바로 7bit 코드만 보낼수 있겠네요.
압축이라..
텍스트만 사용하자나여..
그러니까.. 알파벳과 한글..
그럼 알파벳과 한글 코드만 분류를 해서 번호당 테이블 매칭을 만들고
입력이 들어오면 테이블로 만들어 쏘고..
소켓으루 데이터가 오면 그걸 다시 테이블 매핑해서 decode하면..
님이 원하시는 16바이트는 금방 해결될 것입니다.
Re: 한글코드가 많다면 이렇게 가능합니다.
저도 위에 적으신 분과 원래 문제를 제기하셨던 분의 고민을 종합해서 추가들을 적습니다.
모든 데이터가 7bit 로 만들수 있으면 MSB를 제거하는 꼴이 되므로 1/8 을 잘라 낼수 있는 것이 될수 있다는 것과,
한글이 들어가서 허프만 알고리즘의 테이블사이즈가 커진다고 하셨는데,
한글을 ISO-2022-KR 방식으로 표현하면 7bit로 표현됩니다. 물론 한글문자열 앞뒤로 escape code가 하나씩 들어가긴하지요.
한글 코드를 ISO-2022-KR로 표현한 뒤에 압축하면 어떨까요?
---
http://coolengineer.com
댓글 달기