[ 전공 지식 ] Character Encoding

Character Encoding이 뭘까?

 

 Character Encoding이란 Character를 컴퓨터에서 저장하거나 송출할 목적으로 Encoding 하는 것

ASCII(American Standard Code for Information Interchange) 코드는 C언어를 배운 개발자라면 대부분이 알고 있는 것이다. 이것이 위에서 정의내린 Character Encoding(문자 부호화)의 대표적인 예시이며 메커니즘을 이해하는 데 많은 도움이 될 것이다.

아래 그림과 같이 ASCII는 0~127(0x00~0x7F) 까지 표시한 코드 문자표이며 숫자, 알파벳, 특수 문자, 제어 문자 등 128개를 7bit(≒1byte)로 매핑하고있다.

128개의 ASCII 부호

위의 표를 바탕으로

'A' → '0x41'

라고 매핑이 되는 것이 Encoding(↔ Decoding)이고 'A'가 Chararcter(문자)인 것이다.

그리고 관점이 '0x41'이 된다면

'0x41' → 'A'

이것 또한 Encoding(≠ Decoding)이 되는 것이다. 

 

 

그럼 한글은?

 

전 세계 개발자가 ASCII만 사용한다면 전혀 문제 될 게 없다.

사실.. 문자나 기호의 의미는 나라마다 다르기 때문에 문제가 된다.. 이 문제는 밑에서 설명하겠다

하지만, 너무 단순한 생각이고 현재도 그렇지가 않다.

그래서 글로벌한 문자(CJK: 한자, 일본어, 한글)들을 표기할 수 있어야 한다.

이러한 문제를 해결하기 위해 등장한 것이 Multi Byte다. 말 그대로 1개 이상의 Byte로 Character를 표기한다는 것이다.

예를 들어, Windows에서는 한글을 Encoding 하기 위해 CP949(EUC-KR의 확장판)라는 Code Page를 사용한다.

여기서 Code Page는 ASCII 처럼 문자가 매핑되는 테이블이라 생각하면 된다. 그리고 EUC(Extended Unix Code)는 8bit 단위로 Charater Encoding을 하는 방식이다.

우선, CP949을 이용하면 "가나다"를 어떻게 Encoding이 되는지 살펴보자. (실습 환경은 C++)

cstr: char 버퍼

cstr 버퍼 메모리

아래 매핑 테이블을 참조하여 Decoding 해보면,

CP949 매핑 테이블 : http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP949.TXT

'0xB0A1' → '가' 

'0xB3AA' → '나'

'0xB4D9' → '다' 

인 것을 알 수 있다.

여기서 1byte는 Octet=8bit이며, 2byte(B0 A1: 8bit 8bit: 4bit+4bit 4bit+4bit)를 1개의 Character로 매핑한다.

이제는 이렇게 다수의 byte를 표현해서 전 세계의 Character를 표현할 수 있다는 사실을 알았다.

하지만 위에서 언급했듯이 같은 Character라도 다르게 해석하는 나라가 있을 것이다. 그래서 국가에 따라 지원하는 Code Page 들이 다르다. 그리고 맞지 않은 Code Page를 사용한다면 화면이 깨져서 보이게 되니 주의해야한다.

 

 

 

모든 문자를 담아보자!

 

사용환경마다 다른 Code Page를 사용하기 때문에 매번 서로가 사용하는 Code Page를 알리고 파악하는 데는 한계가 있다.

그래서 등장한 개념이 Unicode다.

"Unicode is a computing industry standard for the consistent encoding, representation, and handling of text expressed in most of the world's writing systems."

쉽게 말해서. Unicode는 전 세계의 모든 문자를 혼돈 없이(사용환경에 상관없이) 사용하도록 정의해놓은 표준이다.

그리고 Unicode 전체를 논리적으로 나눈 Plane(≒Code Page)이 있다. 대표적인 Plane은 BMP(Basic Multilingual Plane)이며 한글도 여기에 포함되어 있다.

또한, Unicode에서  'A'는 

'A' → 'U+0041'

로 매핑이 된다.

여기서 'U+'는 Unicode를 의미한다. 그리고 'U+0041'는 Code Point라는 추상문자를 담는 공간이자 매핑 값(≠Code Value)이다.
인코딩 방식에 따라서 'U+0041 ≠ 0x0041' 일 수도 있다.

 

 

 

더 이상 문제는 없을까?

 

그렇지 않다. Unicode는 단순히 개념일 뿐이다

이 개념을 실현시키기 위해서는 실제로 Encodiing 하는 방식이 존재해야 하고 이중 대표적인 방식이 UTF-8, UTF-16(UCS-2의 확장판)이다. 

UTF-8은 1byte 안으로 표기할 수 있는 문자는 1byte로 그 이상은 2byte, 그 이상은 3byte로 표기한다. (한글은 3byte)

UTF-16은 2 btye(16bit)로 문자를 표현한다.  (2byte 보다 크면 4byte 사용)

Windows 내부적으로는 유니코드 UTF-16LE를 사용한다.
UTF-16은 Little-Endian이냐, Big-Endian이냐에 따라 'A'가 '0x4100'이 될 수도, '0x0041'이 될 수도 있다.

우선, UTF-8과 UCS-2(≒UTF-16) 이용하면 "가나다"를 어떻게 Encoding이 되는지 살펴보자. (실습 환경은 C++)

UTF-8: char(1byte)형 버퍼 사용

cstr_utf8: char형 버퍼

cstr_utf8 버퍼 메모리

Windows는 UTF-8을 지원하지 않아 wchar_t(2byte)를 char(1byte)로 변환해주는 선행 작업을 해야 한다.

BMP를 참조하여 Decoding 해보면 (UTF-8 인코딩 방법은 생략하겠다)

Plane: https://en.wikipedia.org/wiki/Plane_(Unicode)

'0xEAB080' → 'U+AC00'  → '가'

'0xEB8298' → 'U+B098'  → '나'

'0xEB9BA4' → 'U+B2B4'  → '다'

인 것을 알 수 있다.

 

UCS-2: wchar_t(2byte) 형 버퍼 사용

wstr: wchar_t형 버퍼

wstr 버퍼 메모리

Windows 내부적으로는 유니코드 UTF-16LE 를 사용하기 때문에, '00 ac'는 'ac 00'와 같다.

BMP를 참조하여 Decoding 해보면 (UTF-16 인코딩 방법은 생략하겠다.)

Plane: https://en.wikipedia.org/wiki/Plane_(Unicode)

'0xAC00' → 'U+AC00'  → '가'

'0xB098' → 'U+B098'  → '나'

'0xB2B4' → 'U+B2B4'  → '다'

인 것을 알 수 있다.

 

 

 

뭔가 복잡하다

 

더 많은 Encoding 방식이 있지만, 위에서 딱 2가지만 실습해 봤는데도 너무 복잡하다.

그럼 더 효율적으로 보이고 세계적으로 많이 쓰이는 UTF-8로 통일하면 안 될까?

서두에도 말한 것처럼, 너무 단순한 생각이다.

아직도 CP949나 UTF-16으로 인코딩 되어 송출하는 장비들이 많다. 위의 실습에서 봤듯이 심지어 Windows가 UTF-8을 지원하지 않는다. (현재는 UTF-8 설정하는 가능을 BETA 버전으로 제공하고 있다.)

 

 

 

결론

 

전 세계 모든 개발자들이 UTF-8을 쓰기를 기다릴 수는 없다.

그렇기 때문에 UTF-8 뿐만 아니라 더 많은 Character Encoding 방식을 공부해야 한다.

그리고 트렌드는 돌고 돌기 때문에 배워두는 것도 좋은 자세라고 생각한다.

 

 

 

---

참고 자료

- https://nuli.navercorp.com/sharing/blog/post/1079940

- https://shaeod.tistory.com/228

- https://meetup.toast.com/posts/35

- https://en.wikipedia.org/wiki/Unicode

- https://en.wikipedia.org/wiki/Plane_(Unicode)