KR20180006011A

KR20180006011A - Utf-8 코드 문자체계에 있어서, byte 1 에 대한 3비트 압축을 통한 한글메시지의 집중적 압축방법 및 그 장치

Info

Publication number: KR20180006011A
Application number: KR1020160086509A
Authority: KR
Inventors: 김정훈
Original assignee: 김정훈
Priority date: 2016-07-08
Filing date: 2016-07-08
Publication date: 2018-01-17

Abstract

본 발명에서는
특히 SNS 상에서 한국의 경우 한글이 포함된 유니코드의 범위는 (U+AC00~U+D7A3) 으로서 UTF-8 의 byte의 헤더는 “1110” 인데, 한국어의 기반 SNS 서비스등에서는 한글이 다빈도로 출현하므로, 보다 짧은 압축헤더비트를 “10”으로 매핑한다. 이와 같은 매핑은 사실상 U+8000~U+FFFF에 해당하는 문자에는 문다 적용할 수 있다. 또한 U+0800~U+7FFF 에 있어서도 header bit는 그대로 유지하나, 최상위 4비트가 항상"0"으로 시작하므로 이를 이용하여, 최상위 "0"을 제거하여 결합함으로써 BYTE 1을 7비트로 압축할수있다.
이 경우, BYTE 1의 헤더가 다빈도로 출현하지 않는 다른 문자들에 있어서는 이익이 없으나(물론 손해도 없다), 한글이 포함되는 영역에 대하여는 높은 첫번째 바이트에서 헤더비트를 "10"으로 치환하여 2비트의 이익을 얻은뒤, 다시 이후 byte 1의 잔여비트 4비트와 결합하여 처리하는 과정에서 1비트를 추가로 압축하여 전체 3비트의 이익을 얻을 수 있다. 물론 byte 2~ byte 6에 대해서는 2비트 씩 반드시 이익을 보도록 설계된다.

Description

UTF-8 코드 문자체계에 있어서, BYTE 1 에 대한 3비트 압축을 통한 한글메시지의 집중적 압축방법 및 그 장치{HANGUL ON UTF-8 character set COMPRESSION Method and Appratus Thereof}

단문압축, SNS압축, 비트연산

발명을 실시하기 위한 구체적인 내용에 상술

UTF_8 코드 체계의 경우 아래와 같이 유니코드의 값의 범위에 따라, byte 1의 헤더비트를 달리하면서, byte 2~byte 6을 가변적으로 읽어들일수 있게 하였고,

byte 2이후부터는 최상위 비트앞에 “10”을 규칙적으로 부가한 코드이다.

아래 표의 x 표로 표기한 부분이 유니코드 포인터인 First code point ~ Last code point의

이진화된 비트가 순서대로 표기된 내용을 나타낸다.

예를들어, U+07FF 는 이진수로 111 1111 1111 으로서 전체 11비트이며, 아래 표1에서처럼

110 xxxxx 10 xxxxxx 안에 110 11111 10 111111 형태로 포함되어 2바이트의 UTF코드로 변환되는

원리이다.

bits of	First	Last	Bytes in	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6
code point	code point	code point	sequence	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6
7	U+0000	U+007F	1	0xxxxxxx
11	U+0080	U+07FF	2	110xxxxx	10xxxxxx
16	U+0800	U+FFFF	3	1110xxxx	10xxxxxx	10xxxxxx
21	U+10000	U+1FFFFF	4	11110xxx	10xxxxxx	10xxxxxx	10xxxxxx
26	U+200000	U+3FFFFFF	5	111110xx	10xxxxxx	10xxxxxx	10xxxxxx	10xxxxxx
31	U+4000000	U+7FFFFFFF	6	1111110x	10xxxxxx	10xxxxxx	10xxxxxx	10xxxxxx	10xxxxxx

본 발명은 기존의 본 발명가의 다른 발명에 따르면 이러한 UTF-8

코드에 정의된 byte 1의 헤더비트(0, 110, 1110, 11110, 111110, 1111110) 를 아래 표2와 같이 특정 패턴의 비트로 변환하고, byte 2 이후의 최상위 2비트인 “10”들은 제거함으로서 압축이 되도록 한다.

UTF-8 의 byte 1 의 헤더비트	code point	code point	byte 1 의 압축 헤더비트
0	U+0000	U+007F	0
110	U+0080	U+07FF	110
1110	U+0800	U+FFFF	10
11110	U+10000	U+1FFFFF	1110
111110	U+200000	U+3FFFFFF	11110
1111110	U+4000000	U+7FFFFFFF	111110

그런데 본 발명에서는

특히 SNS 상에서 한국의 경우 한글이 포함된 유니코드의 범위는 (U+AC00~U+D7A3) 으로서 UTF-8 의 byte의 헤더는 “1110” 인데, 한국어의 기반 SNS 서비스등에서는 한글이 다빈도로 출현하므로, 보다 짧은 압축헤더비트를 “10”으로 매핑한다. 이와 같은 매핑은 사실상 U+8000~U+FFFF에 해당하는 문자에는 문다 적용할 수 있다.

이 경우, 아래 표3에서처럼 BYTE 1의 헤더가 다빈도로 출현하지 않는 다른 문자들에 있어서는 이익이 없으나(물론 손해도 없다), 한글이 포함되는 영역에 대하여는 높은 첫번째 바이트에서 헤더비트를 "10"으로 치환하여 2비트의 이익을 얻은뒤, 표4와 같이 다시 이후 byte 1의 잔여비트 4비트와 결합하여 처리하는 과정에서 1비트를 추가로 압축하여 전체 3비트의 이익을 얻을 수 있다.

UTF-8 의 byte 1 의 헤더비트	code point	code point	byte 1 의 압축 헤더비트
0	U+0000	U+007F	0
110	U+0080	U+07FF	110
1110	U+0800	U+7FFF	1110
1110	U+8000	U+FFFF	10
11110	U+10000	U+1FFFFF	11110
111110	U+200000	U+3FFFFFF	111110
1111110	U+4000000	U+7FFFFFFF	1111110

이과정을 좀 더 자세히 살펴보면

한글의 경우 유니코드가 U+AC00~U+D7A3 으로서,

이진수로는 1010 1100 00000000 ~ 1101 0111 10100011 범위이며,

특히 주의해서 볼 부분은 각 한글 유니코드의 최상위 4 비트가 "1"로 시작하는 점이다.

즉 "1010" ~ "1101" 의 범위에서 움직임을 알수있다.

이러한 특성을 갖는 영역은 U+0800~U+FFFF 영역에서 U+8000~U+FFFF까지는 모두 해당된다. 즉 "1000" ~ "1111" 까지 최상위 4비트가 움직이고 반드시 "1"로 시작하게 되어 있다.

한편, UTF-8 표준 규칙에 따르면 상기 유니코드가 U+AC00~U+D7A3 에 위치한 한글은 UTF8 코드 규칙에 따르면 아래와 같이 구성된다.

1110 1010 10 110000 10 000000 ~ 1110 1101 10 011110 10 100011.

이제 상기 표3과 같은 방식으로 BYTE 1을 구성하는 헤더비트를 압축헤더비트로 변경하고, 이후 BYTE 1의 잔여비트들을 결합하면서 압축하여 BYTE 1을 압축하고, 이후 바이트들의 최상위 2비트들을 제거하여 압축하면 다음과 같다.

1110 1010 10 110000 10 000000 ~ 1110 1101 10 011110 10 100011.

===>

10 1010 110000 000000 ~ 10 1101 011110 100011.

이때 압축결과에서 보면, 각 한글 코드의 중간 압축결과는

10 1 010 110000 000000 ~ 10 1 101 011110 100011.

101XXX 과 같이 처음이 한글의 경우 반드시 101로 시작함을 알 수 있다.

따라서, U+AC00~U+D7A3 의 경우 (넓게보면 U+8000~ U+FFFF 영역)에 대하여 압축헤더비트를 "10"으로 해서 압축하면 BYTE 1 부분이 반드시 "101"로 시작하므로,

이부분을 추가적을 "101" ==> "10" 으로 변경하면 아래와 같이 1비트를 추가압축하면서도 반드시 다시 “10"으로 시작하게 된다.

10 1010 110000 000000 ~ 10 1101 011110 100011.

1 0 010 110000 000000 ~ 1 0 101 011110 100011.

이러한 효과는 한글뿐만 아니라, utf-8 BYTE 1의 헤더 비트 “1110”에 해당하는 유니코드의 범위중에 U+8000~U+FFFF 범위는 1000 0000 ~ 1111 1111 인데 (즉 최상위 4비트가 "1"로 시작하는 모든 경우) 이에 해당하는 범위의 utf-8 코딩일 경우에, 1비트 추가압축이 가능하다.

또한 유니코드 U+0800~U+ 7FFF 의 BYTE 1 은 0000 1000 ~ 0111 1111 의 범위를 가지는데 이 경우, 헤더비트 " 1110" 에 이어서 붙을 4비트에 대해서 보면 최상위 비트가 항상 "0" 이므로, 헤더비트 " 1110" 을 그대로 유지하되 최상위 비트의 "0" 을 제거하여 결합하여 BYTE 1 을 헤더 " 1110" 에 있어서도 1비트 추가적으로 감축할 수 있다.

따라서 다음과 같이 유니코드의 범위에 따라 언어 특성이 맞추어 압축헤더를 좀더 세분화하여 조정 매핑하여 효율을 높일 수 있다.

UTF-8 의 byte 1 의 헤더비트	code point	code point	Byte 1(첫번째 바이트)의 압축				Byte 2 이후~ Byte 6 까지
UTF-8 의 byte 1 의 헤더비트	code point	code point	byte 1 의 압축 헤더비트	Byte 1 의 헤더비트 이후	Byte 1의 최종압축결과	비고	Byte 2 이후~ Byte 6 까지
0	U+0000	U+007F	0	xxxxxxx	0xxxxxxx	변동없음	해당없음
110	U+0080	U+07FF	110	xxxxx	110xxxxx	변동없음	1바이트 읽어서 최상위 2비트 “10”제거하여 6비트로 함
1110	U+0800	U+ 7FFF	1110	0xxx	1110xxx	BYTE 1 의 헤더비트 다음에 오는 4비트의 최상위가 항상 "0"이므로, 이를 제거하여 결합	2바이트 읽어서 각 8비트 마다 최상위 2비트씩 “10”제거하여 결합하여 12비트로 함
1110	U+8000	U+ FFFF	10	1xxx	10xxx	압축헤더를 10으로 하여 2비트 압축뒤, byte 1의 나머지 4비트와 결합한뒤 최상위 3비트인 101을 10으로 바꾸어 1비트 추가압축	2바이트 읽어서 각 8비트 마다 최상위 2비트씩 “10”제거하여 결합하여 12비트로 함
11110	U+10000	U+1FFFFF	11110	xxx	11110xxx	변동없음	3바이트 읽어서 각 8비트 마다 최상위 2비트씩 “10”제거하여 결합하여 18비트로 함
111110	U+200000	U+3FFFFFF	111110	xx	111110xx	변동없음	4바이트 읽어서 각 8비트 마다 최상위 2비트씩 “10”제거하여 결합하여 24비트로 함
1111110	U+4000000	U+7FFFFFFF	1111110	x	1111110x	변동없음	5바이트 읽어서 각 8비트 마다 최상위 2비트씩 “10”제거하여 결합하여 30비트로 함

U+0800~U+7FFF 범위의 byte 1의 압축헤더가 1110 로 그대로 유지가 되나, 뒤에 byte 1을 구성하는 4비트의 최상위가 항상 "0" 인 경우이므로, 이를 제거하여 7비트로 압축이 된다.

이후 11110, 111110, 1111110 의 경우에는 압축 헤더 비트는 변경이 없는 방식으로 바뀐다.

다만 byte 2 이후의 최상위 비트가 “10”으로 시작되는 부분은 제거되므로, 이러한 경우에도 압축효과는 존재하게 되며(즉 UTF-8의 byte 1을 그대로 유지하되 이후 byte 2 ~ byte 6 을 구성할때는 최상위의 "10"을 각각 제거하여 2비트씩 압축된다.)

한글이 존재하는 영역의 UTF-8 코드부분이 byte 1에서 3비트의 압축, byte 2 및 byte 3에서 각 2비트씩 전체 7비트의 압축효과가 집중적으로 발생하여 한글을 다빈도로 사용하는 우리나라의 경우 압축효과가 커진다.

또한 한글을 포함한 한자, 일본어가 배치된 U+0800~U+7FFF 영역에 있어서도 byte 1의 헤더비트 "1110"은 유지되나, 이후 3비트만 결합됨으로서 1비트의 압축효과가 있고, 이후 2바이트의 각각 최상위 "10"이 압축되어 사라지므로, 전체적으로는 5비트의 압축효과가 생기며, U+8000~U+FFFF 영역에 일부배치된 한자의 경우에는 한글과 마찬가지로 7비트 압축효과가 발생된다.

특히 기준 산술부호화, 허프만 부호화, deflate, 7zip등 다양한 전통적인 압축알고리즘에서도 짧은 단문의 경우 압축효과가 없이 오히려 데이터가 커지는 문제점이 있었으나,

본 알고리즘을 통해 빠르고 간편하게 한글 한글자마다 7비트의 압축이득을 얻게 될 수 있다. 또한 한자와 일본어에 대해서도 5비트의 압축효과를 얻을수있다. 특히 일부한자의 경우 한글처럼 7비트의 압축효과를 얻을 수 있다.

특히 사전식이 아니므로, 상호 사전에 대한 정의가 불필요하며, 문장에 따라 압축률이 달라지는 점이 크게 극복되었다.

압축해제의 경우 먼저 압축데이터의

첫 번째 바이트의 최상위 첫 비트가 “0”일 경우, 이후 7비트를 읽어 8비트로 만들어 압축해제 하고,

첫 비트가 “1”로 시작할 경우,

“0”을 처음 만날 때 까지의 헤더비트를 읽어서, “11110”, “111110”, “1111110” 의 경우 별도의 byte1 에 대한 압축은 없으므로, 이후 각 3비트,2비트,1비트를 읽어서 결합하여 byte 1으로 하고, 이후 바이트들은 UTF-8의 규칙에 따라 헤더비트에 따라 읽어야할 바이트 수만큼 이후 6비트씩을 추가로 읽어 각 6비트 덩어리들마다 최상위 “10”을 추가하여 각 8비트로 하여 압축해제 한다.

이때 "1110"의 경우에는, 헤더비트에 대한 압축은 없지만, 이후에 4비트를 읽어오는 것이 아니라 3비트를 읽어온뒤, 그 읽어온 3비트앞에 1비트의 "0"을 결합시킨뒤, "1110" 다음에 결합하여 byte 1을 압축해제 한다. 즉 xxx 라는 3비트를 읽은뒤, "0xxx"로 만들고 이를 결합시켜 "11100xxx" 로 하여 byte 1을 압축해제한다.

이후 이트들은 UTF-8의 규칙에 따라 헤더비트에 따라 읽어야할 바이트 수만큼 이후 6비트씩을 추가로 읽어 각 6비트 덩어리들마다 최상위 “10”을 추가하여 각 8비트로 하여 압축해제 한다.

“10”일 경우에는, 예외적으로 이후 3비트를 추가적으로 읽어서, “10xxx"로 한뒤, 최상위 ”10“을 ”101“로 하여, "10xxx" ==> "101xxx" 로 변환하고 다시 최상위에 “11”을 추가하여 “11101xxx"로 8비트로 하여 byte1을 압축해제 한다. 특히 4번째 비트가 항상 "1"임을 알수 있다.

이후 6비트씩 두 번 읽어 각 6비트 앞에 “10”을 추가하여 8비트씩 2바이트를 압축 해제함은 header 비트 “1110”의 경우와 동일하다.

이제 다시 다음 비트부터 상기의 과정을 반복하며 압축해제한다.

본 발명을 사용할 경우, 특히 한글의 경우, 첫 번째 바이트에서 3비트 압축 및 이후 두 바이트에서 4비트를 압축하여 모두 7비트를 압축함으로써 실질적으로 UTF-8에서도 한글을 2바이트에 1비트 넘치는 정도로 압축된 형태로 송수신이 가능하여, 한글메시지의 트래픽 절감에 획기적으로 기여할 수 있다.

Claims

국내우선권 주장을 위한 선출원으로서 별도의 청구범위를 기재하지 않음