12.9.8 Converting Between 3-Byte and 4-Byte Unicode Character Sets

12.9.8 3바이트와 4바이트 Unicode Character Set 간 변환

이 절에서는 utf8mb3와 utf8mb4 문자 집합 간에 문자 데이터를 변환할 때 직면할 수 있는 이슈를 설명합니다.

참고

이 설명은 주로 utf8mb3와 utf8mb4 간의 변환에 초점을 맞추지만, ucs2 문자 집합과 utf16 또는 utf32 같은 문자 집합 간의 변환에도 유사한 원칙이 적용됩니다.

utf8mb3와 utf8mb4 문자 집합은 다음과 같이 다릅니다:

• utf8mb3는 Basic Multilingual Plane (BMP)의 문자만 지원합니다. utf8mb4는 여기에 더해 BMP 밖에 있는 보충 문자도 지원합니다.

• utf8mb3는 문자당 최대 3바이트를 사용합니다. utf8mb4는 문자당 최대 4바이트를 사용합니다.

참고

이 설명에서는 3바이트와 4바이트 UTF-8 문자 집합 데이터를 명시적으로 지칭하기 위해 utf8mb3와 utf8mb4 문자 집합 이름을 사용합니다.

utf8mb3에서 utf8mb4로 변환하는 한 가지 장점은 애플리케이션에서 보충 문자를 사용할 수 있게 된다는 점입니다. 한 가지 트레이드오프는 데이터 저장 공간 요구량이 증가할 수 있다는 점입니다.

테이블 내용 관점에서 보면, utf8mb3에서 utf8mb4로의 변환은 문제가 되지 않습니다:

• BMP 문자의 경우, utf8mb4와 utf8mb3는 동일한 저장 특성을 가집니다: 동일한 코드 값, 동일한 인코딩, 동일한 길이.

• 보충 문자의 경우, utf8mb4는 이를 저장하는 데 4바이트가 필요하지만, utf8mb3는 해당 문자를 전혀 저장할 수 없습니다. utf8mb3 컬럼을 utf8mb4로 변환할 때 보충 문자를 변환하는 것에 대해 걱정할 필요가 없습니다. 존재하지 않기 때문입니다.

테이블 구조 관점에서는 다음과 같은 주요 잠재적 비호환성이 있습니다:

• 가변 길이 문자 데이터 타입 (VARCHAR 및 TEXT 타입)의 경우, 문자 단위로 허용되는 최대 길이는 utf8mb3 컬럼보다 utf8mb4 컬럼에서 더 작습니다.

• 모든 문자 데이터 타입 (CHAR, VARCHAR, TEXT 타입)에 대해, 인덱싱할 수 있는 최대 문자 수는 utf8mb3 컬럼보다 utf8mb4 컬럼에서 더 작습니다.

따라서 테이블을 utf8mb3에서 utf8mb4로 변환하려면 일부 컬럼 또는 인덱스 정의를 변경해야 할 수도 있습니다.

테이블은 ALTER TABLE을 사용하여 utf8mb3에서 utf8mb4로 변환할 수 있습니다. 예를 들어, 테이블 정의가 다음과 같다고 가정합니다:

1CREATE TABLE t1 (
2  col1 CHAR(10) CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci NOT NULL,
3  col2 CHAR(10) CHARACTER SET utf8mb3 COLLATE utf8mb3_bin NOT NULL
4) CHARACTER SET utf8mb3;

다음 스테이트먼트는 t1을 utf8mb4를 사용하도록 변환합니다:

1ALTER TABLE t1
2  DEFAULT CHARACTER SET utf8mb4,
3  MODIFY col1 CHAR(10)
4    CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
5  MODIFY col2 CHAR(10)
6    CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL;

utf8mb3에서 utf8mb4로 변환할 때의 함정은 컬럼 또는 인덱스 키의 최대 길이가 바이트 단위로는 변하지 않는다는 점입니다. 따라서 문자 최대 길이가 3바이트 대신 4바이트이므로 문자 단위 최대 길이는 더 작아집니다. CHAR, VARCHAR, TEXT 데이터 타입에 대해, MySQL 테이블을 변환할 때 다음 이슈에 유의하십시오:

• 모든 utf8mb3 컬럼 정의를 확인하여 스토리지 엔진의 최대 길이를 초과하지 않는지 확인합니다.

• 모든 utf8mb3 컬럼에 대한 인덱스를 확인하여 스토리지 엔진의 최대 길이를 초과하지 않는지 확인합니다. 때로는 스토리지 엔진의 개선으로 인해 최대값이 변경될 수 있습니다.

앞의 조건이 적용되는 경우, 정의된 컬럼 또는 인덱스 길이를 줄이거나, utf8mb4 대신 계속 utf8mb3를 사용해야 합니다.

구조적 변경이 필요할 수 있는 예는 다음과 같습니다:

• TINYTEXT 컬럼은 최대 255바이트를 저장할 수 있으므로, 최대 85개의 3바이트 문자 또는 63개의 4바이트 문자를 저장할 수 있습니다. utf8mb3를 사용하지만 63자 이상을 포함할 수 있어야 하는 TINYTEXT 컬럼이 있다고 가정합니다. 데이터 타입을 더 긴 타입(예: TEXT)으로 변경하지 않으면 이를 utf8mb4로 변환할 수 없습니다.

마찬가지로, 매우 긴 VARCHAR 컬럼을 utf8mb3에서 utf8mb4로 변환하려면 더 긴 TEXT 타입 중 하나로 변경해야 할 수도 있습니다.

• InnoDB는 COMPACT 또는 REDUNDANT 로우 포맷을 사용하는 테이블에 대해 최대 인덱스 길이가 767바이트입니다. 따라서 utf8mb3 또는 utf8mb4 컬럼의 경우, 각각 최대 255 또는 191 문자를 인덱싱할 수 있습니다. 현재 191자보다 긴 인덱스를 가진 utf8mb3 컬럼이 있는 경우, 더 적은 수의 문자를 인덱싱해야 합니다.

COMPACT 또는 REDUNDANT 로우 포맷을 사용하는 InnoDB 테이블에서는 다음과 같은 컬럼 및 인덱스 정의가 허용됩니다:

1col1 VARCHAR(500) CHARACTER SET utf8mb3, INDEX (col1(255))

utf8mb4를 사용하려면 인덱스는 더 작아야 합니다:

1col1 VARCHAR(500) CHARACTER SET utf8mb4, INDEX (col1(191))

참고

COMPRESSED 또는 DYNAMIC 로우 포맷을 사용하는 InnoDB 테이블의 경우, 767바이트보다 긴 index key prefixes(최대 3072바이트까지)가 허용됩니다. 이러한 로우 포맷으로 생성된 테이블에서는 utf8mb3 또는 utf8mb4 컬럼에 대해 각각 최대 1024 또는 768 문자를 인덱싱할 수 있습니다. 관련 정보는 Section 17.21, “InnoDB Limits” 및 DYNAMIC Row Format을 참조하십시오.

앞에서 설명한 유형의 변경은 매우 긴 컬럼 또는 인덱스가 있을 때만 요구되는 경우가 대부분입니다. 그렇지 않으면 앞에서 설명한 대로 ALTER TABLE을 사용하여 utf8mb3에서 utf8mb4로 문제 없이 테이블을 변환할 수 있어야 합니다.

다른 잠재적 비호환성을 요약하면 다음과 같습니다:

• SET NAMES 'utf8mb4'는 커넥션 문자 집합에 4바이트 문자 집합을 사용하게 합니다. 서버에서 4바이트 문자가 전송되지 않는 한 문제는 없어야 합니다. 그렇지 않으면 문자당 최대 3바이트를 받을 것으로 예상하는 애플리케이션에서 문제가 발생할 수 있습니다. 반대로, 4바이트 문자를 전송할 것으로 예상하는 애플리케이션은 서버가 이를 이해하는지 확인해야 합니다.

• 복제의 경우, 소스에서 보충 문자를 지원하는 문자 집합을 사용하려면 모든 레플리카도 이를 이해해야 합니다.

또한, 일반적인 원칙으로 소스와 레플리카의 테이블 정의가 다르면 예상치 못한 결과를 초래할 수 있다는 점을 명심해야 합니다. 예를 들어 최대 인덱스 키 길이의 차이로 인해 소스에서 utf8mb3를, 레플리카에서 utf8mb4를 사용하는 것은 위험할 수 있습니다.

utf8mb4, utf16, utf16le, utf32로 변환한 뒤 다시 utf8mb3 또는 ucs2로 변환하기로 결정한 경우(예를 들어, 더 오래된 버전의 MySQL로 다운그레이드하기 위해), 다음 사항이 적용됩니다:

• utf8mb3와 ucs2 데이터는 문제를 일으키지 않아야 합니다.

• 변환하려는 문자 집합을 참조하는 정의를 인식할 수 있을 만큼 서버가 충분히 최신이어야 합니다.

• utf8mb4 문자 집합을 참조하는 오브젝트 정의의 경우, 다운그레이드하기 전에 mysqldump로 덤프를 뜬 후, 덤프 파일에서 utf8mb4를 utf8로 변경하고, 데이터에 4바이트 문자가 없다는 전제하에 이 파일을 더 오래된 서버에 다시 로드할 수 있습니다. 이 오래된 서버는 덤프 파일의 오브젝트 정의에서 utf8을 보고 (3바이트) utf8 문자 집합을 사용하는 새 오브젝트를 생성합니다.