1. 서론
MySQL은 5.5.3 이후에 이 utf8mb4 인코딩을 추가했는데, 이는 대부분의 바이트가 4개이며 4바이트 유니코드와 호환되도록 특별히 사용됩니다. 다행히도 utf8mb4는 utf8의 상위 집합이며, 인코딩을 utf8mb4로 변경하는 것 외에는 다른 변환이 필요하지 않습니다. 물론 공간을 절약하려면 일반적으로 utf8만 사용하는 것만으로도 충분합니다.
2. 내용 설명
위에서 언급했듯이, utf8이 대부분의 중국어 문자를 저장할 수 있는데 왜 utf8mb4를 사용하나요? MySQL이 지원하는 UTF8 인코딩의 최대 문자 길이는 3바이트이며, 4바이트의 넓은 문자를 만나면 예외를 삽입해야 합니다. UTF-8이 인코딩하는 최대 유니코드 문자는 3바이트로, 0xffff로, 이는 유니코드의 기본 다국어 평면(BMP)입니다. 즉, 기본 다중 텍스트 평면에 없는 유니코드 문자는 MySQL의 utf8 문자 집합을 사용해 저장할 수 없습니다. 여기에는 이모지(이모지는 iOS와 안드로이드 폰에서 흔히 볼 수 있는 특수 유니코드 인코딩입니다), 드물게 사용되는 많은 한자, 그리고 새로 추가된 유니코드 문자 등이 포함됩니다.
3. 문제의 근본 원인
원래 UTF-8 형식은 1바이트에서 6바이트까지 사용했고 최대 31자까지 인코딩할 수 있었습니다. 최신 UTF-8 사양은 1에서 4바이트만 사용하며 최대 21비트까지 인코딩할 수 있는데, 이는 17개의 유니코드 평면 전체를 정확히 나타냅니다. utf8은 Mysql에서 UTF-8 문자만 지원하는 문자 집합으로, 최대 3바이트 길이의 UTF-8 문자만 지원하며, 이는 유니코드의 기본 다중 텍스트 평면입니다.
왜 Mysql에서 UTF8은 최대 3바이트의 UTF-8 문자만 지원하나요? 생각해봤는데, 아마도 Mysql이 처음 개발되었을 때 유니코드에는 보조 플레인이 없었기 때문일 겁니다. 당시 유니코드 위원회는 여전히 "65,535자면 전 세계에 충분하다"는 꿈을 꾸고 있었습니다. Mysql의 문자열 길이는 바이트가 아닌 문자를 세고, CHAR 데이터 타입의 경우 문자열이 충분히 길어야 합니다. utf8 문자 집합을 사용할 때, 보존해야 할 길이는 utf8의 가장 긴 문자 길이에 문자열 길이를 곱한 값이므로, 최대 utf8 길이를 3으로 제한하는 것이 자연스럽습니다. 예를 들어, CHAR(100) Mysql은 300바이트를 유지합니다. 이후 버전들이 4바이트 UTF-8 문자를 지원하지 않는 이유에 대해서는, 하나는 하위 호환성 때문이고, 다른 하나는 기본 다국어 평면 외의 문자는 거의 사용되지 않기 때문이라고 생각합니다.
Mysql에서 4바이트 UTF-8 문자를 저장하려면 utf8mb4 문자 집합이 필요하지만, 버전 5.5.3 이후에만 지원됩니다(버전: select version(참조); )。 호환성을 높이려면 항상 utf8mb4를 사용하는 게 좋습니다. CHAR 타입 데이터의 경우 utf8mb4가 더 많은 공간을 차지하며, 공식 Mysql 권장에 따르면 CHAR 대신 VARCHAR를 사용하라고 합니다.
|