[RDB/MySQL] 이모지를 사용하는 DB Charset 설정

이모지를 사용하는 서비스에서는 일반적인 UTF-8 Charset 으로는 불가능하다. 

이유는 이모지가 3Byte 가 아닌 4Byte 이기에 이모지를 어플리케이션을 통해 DB에 저장 시 ??? 로 들어가는 경우를 볼 수 있다,

 

그렇다면 이 문제를 해결하기 위한 방법은 무엇일까?

 

4byte의 문자를 저장할 수 있는 DB charset 과 설정법을 알아보자

 

MySQL 에서 2010년 3월 24일 utf8mb4 라는 Charset 을 추가지원했다.

 

(관련 : https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-3.html )

utf8mb4가 추가되었습니다. utf8과 비슷하지만 확장된 문자를 지원하기 위해서 4바이트까지 저장할 수 있습니다.

자 위에서 설명된 내용 중 현재 우리에게 가장 중요시되는 부분은 4Byte 문자를 지원한다는 것이다.

Emoji 가 바로 그 4Byte에 해당하고 우리가 ??? 를 고칠 수 있게 되기 때문이다.

 

그러면 이제 어떤 charset 을 써야할지 알게 되었으니 어떤 collation을 쓸지 고민해보자

아래에서 설명하는 각 collation에는 특징이 있고 나열해보도록 하겠다.

utf8mb4_bin 

말 그대로 바이너리 저장 값을 그대로 정렬하는 문자열 집합이다.

utf8mb4_general_ci

텍스트를 정렬할 때, a 다음에 b 가 나오는 일반적인 우리가 흔히 하는 정렬방식이며, 그런 만큼 일반적으로 널리 사용된다.

바이너리를 한 번 가공한 것.

utf8mb4_unicode_ci

general_ci 보다 조금 더 문자열 중심의 정렬을 한다.

한국어, 영어, 중국어, 일본어를 사용하는 환경이라면 general_ci 와 다소 차이가 없겠지만 국제 서비스 (독일, 러시아 등등..)를 하는 서비스라고 한다면 unicode_ci 를 사용하여야 할 것이다.

 

그럼 저 둘의 차이는 뭘까??

general_ci 와 unicode_ci 는 겪어보기로는 정렬방법과 속도의 차이가 있었다.

먼저는 general_ci 와 unicode_ci 에서 지원하는 legacy Collation 의 차이가 있다. 이것이 의미하는 건 

utf8mb4_general_ci 가 속도 면에서는 우위를 보인다.

하지만 utf8mb4_general_ci 은 우리가 흔히 '알파벳 순서'라고 부르는 방식으로 문자를 정렬하지는 않는다.

 

예를 들어, 유니 코드 데이터 정렬은 "ss"와 동일한 "ß" 그리고 "OE"와 동일한 "Œ"

이러한 문자를 사용하는 사람들이 일반적으로 원하는대로 정렬하는 반면, utf8mb4_general_ci는 이러한 문자를 단일 문자로 정렬합니다 (예 : 각각 "s"및 "e")

결론

그래서 말하고 싶은건 뭐냐!?
이전엔 속도를 우위로 가져가고 싶었다면 utf8mb4_general_ci 를 사용했겠지만, 현재 CPU 는 발전했고, 개발자들은 성능비용 문제보다 국제화를 더욱 심각하게 다루고 있기에, 우리는 utf8mb4_unicode_ci 를 사용하는게 현재로선 더 좋지 않을까 싶은 개인적인 생각이든다.

 

참고

[MySQL/MariaDB] utf8mb4 언어셋 소개 및 표현범위.

[MySQL/MariaDB] utf8mb4 언어셋 소개 및 표현범위.

stormcrow.dev/ko/questions/766809