오늘의 글은 문자 인코딩에 대해서 작성해보려 한다. 문자 인코딩에서 대표적으로 사용하는 utf8, utf8mb4 에 대해서 글을 작성하겠다.
character set
-
텍스트 데이터를 저장하는 방식
-
데이터베이스(스키마), 테이블, 컬럼 레벨로 정의 가능
-
종류
- utf8: UTF-8 인코딩으로 1~4Byte로 저장되며, 거의 모든 언어를 지원합니다
- latin1: ISO-8859-1 인코딩으로 1Byte로 저장되며, 서유럽 언어를 지원합니다
- ascii: 7비트 ASCII 인코딩으로 1Byte로 저장되며, 영어 문자만 지원합니다
기본으로 DB 를 세팅하게 되면 latin1으로 인코딩이 잡힌다.
- ascii 가 지원하는 영어에서 조금 더 확장되어 서유럽권 까지 지원
보통 처음 MySQL 을 사용하다보면 제일 먼저 흔하게 하는 것이 한글이 안되서 검색을 많이 하게 된다. 그때 utf8 을 처음 접하게 되는데
- utf8 은 가변적인 저장 방식이기에, 1~4Byte로 저장되고 대신 거의 모든 언어를 지원
개발을 할 때 ID 와 같이 중요한 영역은 공백이나 한자 또는 읽지 못하는 값이 있으면 안되기 때문에 ascii 로 제한하는게 관리하기 편하다.
UTF-8 vs UTF-8mb4
-
유니코드 문자를 인코딩하기 위한 방법
-
UTF-8
- 가변 길이의 문자 인코딩 방식으로, 대부분의 문자를 1Byte로, 복잡한 문자는 2~4Byte로 인코딩
- 하지만 MySQL의 UTF-8은 3Byte 까지만 지원하여 일부 문자를 저장하지 못함
- 4Byte 넘어가는 이모지 같은 경우는 저장, 조회 못함
-
UTF-8mb4
- MySQL에서 제공하는 확장된 UTF-8 인코딩으로, 유니코드의 4바이트 문자까지 지원
- 이모지나 동아시아 문자와 같은 모든 유니코드 문자를 완벽하게 지원
Collation
-
텍스트 데이터를 비교하고 정렬하는 방식
-
종류
- utf8_general_ci: 대소문자를 구분하지 않는 일반적인 UTF-8 정렬
- utf8_bin: 대소문자를 구분하는 이진 비교
- utf8_unicode_ci: 유니코드 표준을 따르는 대소문자 구분 없는 비교
막상 저장되어 들어가 있는걸 보면 테이블에 a, A 모두 들어가 있지만 내가 A를 조회하고 싶어서 해봐도 대 소문자 구별이 안되면 a, A 둘다 나오게 된다.
개발을 할 때는 utf8_bin 을 그래서 하는 것을 권장
Character set vs Collation
- Character Set
- 문자들이 어떻게 “저장”되는지
- Collation
- 문자들이 어떻게 “비교 / 정렬”되는지
