아마 우리가 인코딩과 디코딩의 정확한 정의를 몰라도 무엇인지 대충 유추 할 수 있는 이유는 동영상을 다룰 때 자주 접할 수 있는 단어이기 때문일 것이다. 그러나 아쉽게도 이번 포스팅은 동영상 인코딩이 아닌 문자 인코딩을 중점적으로 다루어보려고 한다. (내 맴)
인코딩 (Encoding)
우리가 사용하는 컴퓨터는 0과 1밖에 모르는 바보녀석이다. 따라서, 우리가 일상적으로 사용하는 모든 것을 컴퓨터로 표현하기 위해서는 약속된 규칙에 따라서 0과 1로 변환하는 과정이 필요하다. 이 과정을 “인코딩(Encoding)” 이라고 한다. 디코딩(Decoding)은 그 반대이다.
문자 인코딩 (Character encoding)
문자 인코딩은 사람이 사용하는 문자를 컴퓨터에 표현하기 위해 약속된 규칙에 따라 변환하는 과정을 말한다. 초창기 컴퓨터에서는 0과 1, 즉 기계어만을 사용하였으니.. 생각만해도 고통스러울 것 같지 않은가? 최초의 문자 인코딩. ASCII (아스키) 가 등장한다.
아스키(ASCII)
아스키는 미국에서 만들어졌으므로, 영문을 사용하기 적합한 형태로 이루어져있다. 7비트를 사용하며, 따라서 128개(2⁷)의 부호를 표현한다. 여기서 왜 8비트가 아닌 7비트를 사용할까? 1바이트(=8비트) 단위의 통신에서 7비트를 제외한 나머지 1비트는 통신 에러를 감지하기 위한 체크섬으로 사용되었다고 한다.
어.. 그러면.. 다른 나라의 문자는 어떻게 표현하지?
확장된 아스키코드 (ANSI)
위 아스키코드 표에 정의되지않은 여러 문자들(주로 프로그램에서 테두리 등을 그리기 위한 선문자)을 표현하기 위해 8비트로 확장된 아스키 코드가 등장한다. 확장된 영역은 국가마다 다르게 정의 되었는데, 128 자 이내로 자국의 문자를 넣을 수 있는 경우에는 이 영역을 사용했다고 한다. (따라서 국가간 이메일을 주고 받는 경우.. 글자가 와장창 깨지는 호환성 이슈가 발생했다;;) 자국의 문자가 128 자 이내로 표현이 안되는 경우, 특히, 동북아시아권(한, 중, 일) 에서 사용하는 문자는 그 개수가 매우 많기 때문에 (한글의 경우, 자모 조합 11172자) MBCS 방식을 사용하게 된다.
MBCS (Multi-Byte Character Set)
MBCS 는 이후에 설명할 유니코드를 제외한 문자 인코딩에서 두 개 이상의 바이트를 사용하여 문자를 표현하는 방식이다. 한 개의 바이트를 사용하는 방식 (예. 아스키 코드) 은 SBCS (Single-Byte Character Set) 라고 한다. 한글 같은 경우, 대표적으로 완성형인 EUC-KR, 조합형인 한컴 2바이트 코드가 MBCS 에 해당한다. 확장된 아스키코드 영역의 문자를 두 개 합쳐서 표시하며, 역시 국가간 다르게 정의하므로 호환성 이슈는 여전하다. (뷁뷄뷁 알면 옛날사람)
호환성 논란이 불거지자, 필연적으로 전 세계의 모든 문자를 다룰 수 있도록 설계된 문자 인코딩 방식. 유니코드가 등장한다.
유니코드 (Unicode)
유니코드는 전 세계의 모든 문자를 컴퓨터에서 일관되게 표현하고 다룰 수 있도록 설계된 산업 표준이다. 주요 구성 요소는 ISO/IEC 10646 문자셋과 UCS, UTF 등의 인코딩 방식, 문자 처리 알고리즘 등이다. 유니코드의 목적은 파편화된 문자 인코딩 방법을 모두 유니코드로 단일화하는 것이다. 그렇다면, 기존에 아스키코드로 작성된 문서는 어떻게되었을까? 아스키코드와 완벽 호환되는 가변길이 문자 인코딩(UTF-8)을 도입하여 이를 해결했다.
UTF-8
UTF-8은 유니코드를 위한 문자 인코딩 방식으로, 가장 많이 사용되는 가변 길이 문자 인코딩이다. 유니코드는 한 문자를 나타내기 위해서, 1바이트부터 4바이트까지 사용한다. 이 중, 1바이트 영역은 아스키코드와의 호환을 위한 영역으로 그 이후의 문자는 아스키코드와의 구별을 위하여 최상위 비트를 1로 표기한다.
예) ‘가’ = U+AC00 (유니코드) = 11101010 10110000 10000000 (UTF-8)
EUC-KR 과 UTF-8
과거 인터넷 익스플로러 옵션 중 ‘URL을 항상 UTF-8로 보내기’ 옵션을 끄는 것을 권장하던 시절이 있었다. (나도 껐었는데..) URL 에 올 수 없는 문자열이 포함된 경우 (주로 한글), UTF-8 인코딩 후 퍼센트 인코딩하여 웹 서버에 요청하는 옵션이지만 그 당시에는 EUC-KR 로 작성된 웹 서버가 대다수였기 때문에 자원을 찾을 수 없는 문제가 있었기 때문이었단다. (아하 그랬군) 그땐 그랬지만, 지금은 저 옵션을 켜두는 것이 좋겠다!
번외품
- Base 64
이진 데이터를 문자 코드에 영향을 받지 않는 공통 아스키 문자들로 이루어진 문자열로 바꾸는 인코딩이다. (이진 데이터 -> 문자열) 아스키 문자 하나가 64 진법의 숫자 하나와 매핑된다.
8 비트 이진 데이터 3개 (3바이트)를 6 비트 씩 4 개로 나눈뒤, 각 6 비트에 해당하는 문자를 Base 64 색인표에서 찾아서 매핑한다. 남은 비트가 6 비트보다 적다면 “=” (패딩문자)로 채운다. 이에 따르면, 6 비트마다 2 비트의 오버헤드가 발생한다.
그럼 이걸 왜써?
아스키 코드에서 지원하지 않는 언어와 이진 데이터로 구성된 실행 파일, 미디어 파일을 메일로 전송하기 위해 MIME (Multipurpose Internet MailExtensions) 이 탄생했다. MIME 에 따르면, 송신 측에서는 메일을 전송하기 전에 이진 데이터를 아스키 코드로 변환해주어야 하며, 수신 측에서는 원래 형식으로 역변환해야한다. Base 64 는 바로 이 과정에서 사용되는 인코딩 방법 중 하나이다. (HTTP 에서도 사용된다!)
참고 링크
https://namu.wiki/w/%EC%9D%B8%EC%BD%94%EB%94%A9#s-2
https://namu.wiki/w/%EC%95%84%EC%8A%A4%ED%82%A4%20%EC%BD%94%EB%93%9C
