외부 링크
- The Unicode Standard 5.0.0, chapter 3 - formally defines UTF-32 in §3.10, D99-D101
| 유니코드 |
|---|
| 부호화 형식 |
| UCS |
| 양방향 텍스트 |
| BOM |
| 한중일 통합 한자 |
| 유니코드 범위 목록 |
| 유니코드 등가성 |
| 유니코드와 HTML |
| 유니코드와 전자 우편 |
| 유니코드 글꼴 |
UTF-32(32-bit Unicode Transformation Format. 32-비트 유니코드 변환 형식) 또는 UCS-4는 유니코드 코드 포인트를 인코딩하는 데 사용되는 고정 길이 인코딩으로, 코드 포인트당 정확히 32비트(4 바이트)를 사용한다(단, 유니코드 코드 포인트는 232개보다 훨씬 적고 실제로는 21비트만 필요하기 때문에 앞부분의 비트 중 상당수는 0이어야 한다). 반면, 다른 모든 유니코드 변환 형식은 가변 길이 인코딩이다. UTF-32의 각 32비트 값은 하나의 유니코드 코드 포인트를 나타내며, 해당 코드 포인트의 숫자 값과 정확히 일치한다.
UTF-32의 주요 장점은 유니코드 코드 포인트가 직접 색인화된다는 점이다. 코드 포인트 시퀀스에서 N번째 코드 포인트를 찾는 것은 상수 시간(O(1)) 작업이다. 반면, 가변 길이 코드는 문자열 시작 부분부터 N개의 코드 포인트를 세는 데 선형 시간이 필요하다. 이로 인해 UTF-32는 ASCII에서 흔히 수행되었던 방식처럼 정수를 1씩 증가시켜 문자열의 각 위치를 검사하는 코드에서 간단한 대체제로 사용될 수 있다. 초보 프로그래머들은 종종 이 기능이 얼마나 유용한지를 과대평가하곤 한다.
UTF-32의 주요 단점은 항상 0인 11비트를 포함하여 코드 포인트당 4 바이트를 사용하므로 공간 효율성이 떨어진다는 점이다. 기본 다국어 평면(BMP)을 벗어나는 문자는 대부분의 텍스트에서 상대적으로 드물며(일부 대중적인 이모지가 포함된 텍스트는 제외), 일반적으로 크기 추정 시 무시될 수 있다. 이로 인해 UTF-32는 UTF-16의 약 두 배 크기가 된다. ASCII 하위 집합에 속하는 문자가 얼마나 많은지에 따라 UTF-8의 최대 4배 크기가 될 수도 있다.
원래의 ISO/IEC 10646 표준은 UCS-4라고 불리는 32비트 인코딩 형식을 정의했는데, 여기서 Universal Character Set(UCS)의 각 코드 포인트는 0에서 0x7FFFFFFF 사이의 31비트 값으로 표현되었다(부호 비트는 미사용이며 0이었다). 2003년 11월, 유니코드는 UTF-16 인코딩의 제약 사항과 일치시키기 위해 RFC 3629에 의해 U+10FFFF를 초과하는 코드 포인트(및 상위 및 하위 대행자 U+D800부터 U+DFFF까지)를 명시적으로 금지하도록 제한되었다. 이 제한된 하위 집합이 UTF-32를 정의한다. ISO 표준에는 (1998년 유니코드 2.1 기준) 0xE00000에서 0xFFFFFF, 그리고 0x60000000에서 0x7FFFFFFF가 "사용자 정의용으로 예약"되어 있었으나 이후 버전에서 이 영역들은 삭제되었다. ISO/IEC JTC 1/SC 2 워킹 그룹 2의 원칙 및 절차 문서에 따르면 향후 모든 코드 포인트 할당이 유니코드 범위로 제한될 것이므로, UTF-32는 모든 UCS 코드 포인트를 표현할 수 있게 되며 UTF-32와 UCS-4는 동일하다.
코드 포인트당 고정된 바이트 수는 이론적인 장점이 있지만, 현실에서는 각각 문제가 있다.
UTF-32의 주요 용도는 문자열이 아닌 단일 코드 포인트나 자체를 데이터로 다루는 내부 API이다. 예를 들어, 현대적인 텍스트 렌더링에서 마지막 단계는 각각 좌표(x, y), 속성 및 그릴 자체를 식별하는 단일 UTF-32 코드 포인트를 포함하는 구조체 목록을 작성하는 것이 일반적이다. 종종 유니코드가 아닌 정보가 각 워드의 "사용되지 않는" 11비트에 저장되기도 한다.
Windows(wchar_t가 16비트인 곳)에서 UTF-32 문자열의 사용은 거의 전무하다. 유닉스 시스템에서는 wchar_t 타입이 32비트로 정의되어 있기 때문에 드물게 애플리케이션 내부에서 UTF-32 문자열이 사용되기도 한다.
UTF-32는 또한 HTML 문자 인코딩으로 사용이 금지되어 있다.
3.2 버전까지의 파이썬은 UTF-16 대신 UTF-32 문자열을 사용하도록 컴파일될 수 있었다. 3.3 버전부터 유니코드 문자열은 문자열에 BMP 이외의 문자가 하나라도 있으면 UTF-32로 저장되지만, 모든 코드 포인트를 해당 크기로 맞추기 위해 "가장 큰 유니코드 서수(1, 2 또는 4바이트)를 가진 코드 포인트에 따라" 앞부분의 제로 바이트를 최적화하여 제거한다.
줄리아 프로그래밍 언어는 1.0 출시와 함께 내장 UTF-32 지원을 제거하고, "UTF-8 Everywhere Manifesto"에 따라 모든 문자열을 UTF-8로만 유지하도록 언어를 단순화했다(다른 모든 인코딩은 레거시로 간주되어 표준 라이브러리에서 패키지로 이동되었다).
C++11에는 UTF-32를 사용하는 2가지 내장 데이터 타입이 있다. char32_t 데이터 타입은 UTF-32로 1개의 문자를 저장한다. u32string 데이터 타입은 UTF-32로 인코딩된 문자열을 저장한다. UTF-32로 인코딩된 문자 또는 문자열 리터럴은 문자 또는 문자열 리터럴 앞에 U를 붙여 표시한다.
#include <string>
char32_t UTF32_character = U'🔟'; // U'\U0001F51F'로도 작성 가능
std::u32string UTF32_string = U"UTF–32-encoded string"; // `const char32_t*`로 정의됨
C#에는 유니코드 문자를 문자열이 아닌 바이트 시퀀스로 표현하는 UTF32Encoding 클래스가 있다.
기술적으로는 유효하지 않지만, 대행자 쌍(surrogate halves)이 종종 인코딩되어 허용되기도 한다. 이는 UTF-8의 WTF-8 변형이 작동하는 방식과 유사하게, 유효하지 않은 UTF-16(예: Windows 파일 이름)을 UTF-32로 변환할 수 있게 한다. 때로는 CESU-8과 유사하게 BMP 이외의 문자 대신 쌍을 이룬 대행자가 인코딩되기도 한다. 사용되지 않는 32비트 값이 많기 때문에, 비유니코드 값을 사용하여 UTF-8 오류를 인코딩함으로써 유효하지 않은 UTF-8을 보존하는 것도 가능하지만 이에 대한 표준은 없다.
UTF-32에는 빅 엔디언과 리틀 엔디언을 위한 두 가지 버전인 UTF-32-BE와 UTF-32-LE가 있다.
Folks start implying that code points mean something, and that O(1) indexing or slicing at code point boundaries is a useful operation.
Clause 9.4: "Because surrogate code points are not UCS scalar values, UTF-32 code units in the range 0000 D800-0000 DFFF are ill-formed". Clause 4.57: "[UCS codespace] consisting of the integers from 0 to 10 FFFF (hexadecimal)". Clause 4.58: "[UCS scalar value] any UCS code point except high-surrogate and low-surrogate code points".
It [UCS-4] is now treated simply as a synonym for UTF-32, and is considered the canonical form for representation of characters in 10646.
