익숙하지만 정확히 몰랐던 인코딩 정리

ASCII, UTF8, EUC-KR, UTF8MB4
2020-04-05

숫자만 아는 컴퓨터가 문자를 표현해야 했다.

  • 컴퓨터는 원래 계산기였다. 1+1 = 2; 의 수학적인 표현을 위한 것이었으나, 당연하게도 곧 지나 문자열을 표현해야 했다. 컴퓨터는 숫자밖에 모르는 바보였으므로, 문자열을 숫자와 연결하는 약속이 필요했다.
  • 가령 a 는 97, b는 98 이런식으로 숫자와 문자를 지정하여 약속하였다. 이것이 아스키 테이블(ASCCI TABLE) 이다. 초창기 아스키는 영어만 고려하여 128개의 문자만 표에 있었다. 따라서 1 byte 로 충분히 표현가능 했다.

다양한 문자열을 담는 유니코드, 그리고 인코딩

  • 아스키는 128개의 문자열만 고려되었지만, 유니코드는 세계의 다앙햔 문자열을 고려하기 위해 1byte 이상이 필요 했다. 이러다보니 유니코드는 1~4byte 의 가변적인 데이터 용량이 필요했다.
  • 가변적인 데이터 용량이라고 해서 마냥 4byte 씩 컴퓨터에 저장한다면 공간 낭비일 것이다. 이러한 유니코드를 저장하는 데 적절한 메타정보를 넣어 적절히 압축하여 저장할 수 있었고, 이것을 인코딩이라고 한다. 이런 데이터를 다시 유니코드로 표현하는 반대의 과정이 디코딩이라고 한다.
  • UTF8 은 대표적으로 많이 쓰이는 인코딩 방식이다. 다만 마이크로 소프트가 과거 EUC-KR 이라는 인코딩 방식을 채택하여 한국인 입장에서는 같은 유니코드를 해석하는 방법이 여러개인 상황이 펼쳐졌다. 누구나 한번쯤은 euc-kr 로 된 데이터를 utf8 로 읽거나 그 반대로 읽는 경험(=버그)를 해봤을 것이다.

이모지와 utf8mb4 의 등장

  • 앞서 유니코드는 4byte 까지 가변적인 데이터를 가질 수 있었다고 했다. 그러나 MySQL 초창기 전세계 모든 언어가 21bit 안에 표현되는 상황이었고, 3byte로 utf8 을 설계하였다.
  • 지금은 당연한 이모지로 인해 , 문자열을 표현하는 데 3byte 를 넘어 4byte 가 필요하게 되었다. 따라서 2010년 Mysql5.5.3 버전부터 utf8mb4 라는 자료형을 넣었다

맺음

전기전자공학 1학년 C언어 시간에 아스키 표를 배웠던 기억이 아직 선명하다. 이렇게 훗날 아스키를 검색하고 글로 정리할 날이 올줄 알았겠는가. 개발하며 인코딩 버그는 적당히 고칠 수 있었고, 이모지를 지원하려면 utf8mb4 가 필요하다는 것도 어깨너머 알았다. (첫 회사에서 이모지 넣으면 서버에서 거르고 저장했는데 인코딩 이슈가 있어 디비 인코딩 다시 했던걸로 기억한다. ) 찾아보고 이해하기 전에 익숙해졌던 인코딩을 이렇게 다시 펼쳐보는 날도 왔다. 인코딩을 다루다 보니 압축알고리즘의 기본이 급 궁금해졌다.

참고

Buy Me A Coffee