UTF-32

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 역사
3. 특징
4. 사용
- 4.1. 프로그래밍 언어
5. 변형
참조

1. 개요

UTF-32는 유니코드 문자 집합의 각 코드 포인트를 32비트로 표현하는 가변 길이 문자 인코딩 방식이다. ISO/IEC 10646 표준에 정의된 UCS-4의 부분 집합으로, 0부터 10FFFF 범위의 코드 값만을 사용한다. UTF-32는 문자열 내 특정 문자를 빠르게 찾을 수 있다는 장점이 있지만, 결합 문자, 이모지 등으로 인해 코드 포인트와 문자의 수가 일치하지 않을 수 있으며, 다른 인코딩 방식에 비해 데이터 크기가 크다는 단점이 있다. 내부 API에서 단일 코드 포인트나 글리프를 표현하는 데 주로 사용되며, 프로그래밍 언어에서는 C++, 파이썬, Seed7 등에서 지원한다. UTF-32에는 빅 엔디안(UTF-32-BE)과 리틀 엔디안(UTF-32-LE) 두 가지 버전이 존재한다.

더 읽어볼만한 페이지

유니코드 변환 형식 - UTF-8
UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.
유니코드 변환 형식 - UTF-1
UTF-1은 유니코드 초기 버전을 인코딩하기 위해 1992년에 설계된 가변 길이 문자 인코딩 방식으로, ASCII 호환성을 유지하고 ISO 2022 및 MIME과의 호환성을 고려했지만, "모듈로 190" 산술을 사용하는 특징과 현대 유니코드 표준과의 차이점을 가진다.
유니코드에 관한 - UTF-8
UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.
유니코드에 관한 - UTF-1
UTF-1은 유니코드 초기 버전을 인코딩하기 위해 1992년에 설계된 가변 길이 문자 인코딩 방식으로, ASCII 호환성을 유지하고 ISO 2022 및 MIME과의 호환성을 고려했지만, "모듈로 190" 산술을 사용하는 특징과 현대 유니코드 표준과의 차이점을 가진다.
문자 인코딩 - 유니코드
유니코드는 세계의 모든 문자를 하나의 컴퓨터 인코딩 표준으로 통합하기 위해 설계되었으며, 유니코드 컨소시엄에 의해 관리되고 UTF-8, UTF-16, UTF-32 등의 부호화 형식을 제공하지만, 일부 문자 표현 문제, 버전 간 비호환성, 레거시 인코딩과의 호환성 문제 등의 과제를 안고 있다.
문자 인코딩 - UTF-8
UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.

UTF-32

2. 역사

ISO/IEC 10646 표준은 'UCS-4'라고 불리는 32비트 ''인코딩 형식''을 정의하는데, 여기서 유니버설 문자 집합(UCS)의 각 코드 포인트는 0부터 0x7FFFFFFF까지의 31비트 값으로 표현된다.^[2]^[3] 2003년 11월, 유니코드는 UTF-16 인코딩과의 호환성을 위해 U+10FFFF보다 큰 코드 포인트를 사용하지 않도록 제한하면서, UTF-32의 범위를 U+0000 ~ U+10FFFF로 정의하였다.^[2]^[3] ISO/IEC JTC 1/SC 2 워킹 그룹 2의 정책에 따라, 모든 향후 코드 포인트 할당은 유니코드 범위로 제한되므로, UTF-32는 모든 UCS 코드 포인트를 나타낼 수 있게 되었고, UTF-32와 UCS-4는 사실상 동일하게 되었다.^[5]

초기 ISO/IEC 10646 규격은 31비트 부호화 문자 집합인 UCS-4^[17]를 정의했다. 이는 컴퓨터 내부 표현에서 최상위 비트를 이스케이프 등의 목적으로 활용하고, 다른 코드 체계와의 호환성을 고려한 설계였다. GB 18030은 4바이트 코드에서 최상위 비트가 1인 코드를 사용하는 예시이다.

UCS-4는 1,114,112개 (2²⁰ + 2¹⁶)의 코드 위치를 가지며, 16진수로 0x10FFFF까지의 유니코드 코드 공간 전체를 표현하기에 충분하다. UTF-32는 UCS-4의 부분 집합으로 시작되었지만, ISO/IEC JTC 1/SC 2/WG 2의 정책에 따라 모든 미래의 문자 할당이 유니코드 범위로 제한되면서 UTF-32와 UCS-4는 동일해졌다.

3. 특징

UTF-32는 코드 포인트마다 고정된 바이트 수를 사용하므로 문자열에서 N번째 문자를 찾는 연산(O(1))을 빠르게 수행할 수 있다는 장점이 있다. 하지만 UTF-8이나 UTF-16과 같은 가변 너비 인코딩에서도 잘림(truncation) 처리가 효율적으로 가능하며,^[6] 결합 문자, 이모지, 합자 등의 영향으로 사용자가 인식하는 "문자"와 코드 포인트의 개수가 항상 일치하지는 않아 고정 너비의 장점이 제한적일 수 있다.^[7]

또한, "고정 너비" 글꼴도 가변 너비를 가질 수 있다. 예를 들어 CJK 표의 문자는 종종 두 배 너비로 표현되기 때문에,^[6] 코드 포인트 수가 문자열의 "너비"와 항상 일치하지는 않는다.

일반적으로 시스템이 문자를 처리할 때는 필요한 코드 위치에 접근하여 글리프 모양이나 문자의 의미 등 문자 정보를 얻는다. UTF-32는 한 번의 접근으로 정보를 얻을 수 있지만, 가변 길이 형식은 여러 번 접근해야 한다. 따라서 메모리에 배치할 경우에는 UTF-32가 사용될 수 있다.

최근 데이터베이스에서는 코드 위치 수로 영역을 확보하는 형식을 사용할 수 있다. UTF-32는 바이트 수가 고정되어 있어 물리적 크기를 디스크에 확보하는 것이 가능하다.

데이터 크기 측면에서는 다른 문자 인코딩 방식보다 크기가 크다. 문자열 표시 폭 계산도 결합 문자나 CJKV 한자 등으로 인해 간단하지 않다. 이러한 이유로 데이터 교환에는 UTF-32 대신 UTF-8이나 UTF-16이 주로 사용된다.

텍스트 형식으로 다룰 때 UTF-32는 바이트 순서 마크(BOM)를 사용하여 엔디안을 구별한다. 리틀 엔디안(UTF-32-LE)은 `FF FE 00 00`, 빅 엔디안(UTF-32-BE)은 `00 00 FE FF`로 시작한다.

C 언어(C11)나 C++(C++11) 등 프로그래밍 언어에서는 문자열 리터럴 앞에 대문자 U를 붙여 UTF-32로 처리하도록 지정할 수 있다.

4. 사용

UTF-32는 주로 내부 API에서 문자열이 아닌 단일 코드 포인트 또는 글리프를 처리하는 데 사용된다. 예를 들어, 현대 텍스트 렌더링에서 마지막 단계는 좌표 (x, y), 속성 및 그릴 글리프를 식별하는 단일 UTF-32 코드 포인트를 포함하는 구조 목록을 만드는 경우가 일반적이다.

윈도우에서는 wchar_t가 16비트이므로 UTF-32 문자열 사용이 거의 없지만, 유닉스 시스템에서는 wchar_t가 32비트이므로 응용 프로그램 내부에서 UTF-32 문자열이 가끔 사용된다. UTF-32는 HTML 문자 인코딩으로 사용이 금지되어 있다.

데이터베이스에서는 코드 포인트 수로 영역을 확보할 수 있는 형식을 사용할 수 있는데, UTF-32는 바이트 수가 고정되어 있어 물리적 크기를 디스크에 확보하는 것이 가능하다. 데이터 크기 측면에서 다른 문자 인코딩 방식에 비해 크기가 커서 데이터 교환에는 UTF-8이나 UTF-16이 일반적으로 사용된다.

특정 문자의 유니코드 코드 포인트를 텍스트로 표현할 때, U+10001과 같이 UTF-32로 처리했을 경우의 16진수 표기가 사용되는 경우가 많다. 텍스트 형식으로 다룰 때, UTF-32는 처음에 바이트 순서 마크 (BOM)를 붙인다. 처음 4바이트의 배열이 `FF FE 00 00`이면 리틀 엔디안이 되고, `00 00 FE FF`이면 빅 엔디안이 된다.

4. 1. 프로그래밍 언어

파이썬 3.2 버전까지는 UTF-16 대신 UTF-32를 사용하도록 컴파일할 수 있었다. 3.3 버전부터는 문자열에 하나 이상의 BMP 문자가 포함된 경우 유니코드 문자열이 UTF-32로 저장되지만, 모든 코드 포인트가 해당 크기가 되도록 "가장 큰 유니코드 서수(1, 2, 또는 4 바이트)에 따라" 선행 0 바이트를 최적화한다.^[10]

Seed7^[11] 및 Lasso 프로그래밍 언어는 직접 인덱싱이 중요하다고 믿고 모든 문자열을 UTF-32로 인코딩한다. 반면 줄리아 프로그래밍 언어는 1.0 릴리스와 함께 내장 UTF-32 지원을 중단하여 "UTF-8 Everywhere 선언"에 따라 UTF-8 문자열만 갖도록 언어를 단순화했다.^[12]^[13]

C++11에는 UTF-32를 사용하는 두 개의 내장 데이터 형식이 있다. `char32_t` 데이터 형식은 UTF-32로 한 개의 문자를 저장한다. `u32string` 데이터 형식은 UTF-32로 인코딩된 문자열을 저장한다. UTF-32로 인코딩된 문자 또는 문자열 리터럴은 문자 또는 문자열 리터럴 앞에 `U`로 표시된다.^[14]^[15]

C#는 유니코드 문자를 문자열이 아닌 바이트로 나타내는 `UTF32Encoding` 클래스를 가지고 있다.^[16]

5. 변형

기술적으로는 유효하지 않지만, 서러게이트 하프(surrogate halves)는 종종 인코딩되어 허용된다. 이는 WTF-8 변형 UTF-8이 작동하는 방식과 유사하게 잘못된 UTF-16(예: Windows 파일 이름)을 UTF-32로 변환할 수 있게 해준다. 때로는 CESU-8과 유사하게 비(非) BMP 문자가 아닌 페어링된 서러게이트가 인코딩된다. 사용되지 않는 32비트 값이 많기 때문에, 비(非) 유니코드 값을 사용하여 UTF-8 오류를 인코딩하여 잘못된 UTF-8을 보존하는 것도 가능하지만, 이에 대한 표준은 없다.

참조

_[1] 웹사이트 FAQ - UTF-8, UTF-16, UTF-32 & BOM http://unicode.org/f[...] 2022-09-04
_[2] 웹사이트 Publicly Available Standards - ISO/IEC 10646:2020 https://standards.is[...] 2021-10-12
_[3] 웹사이트 Mapping codepoints to Unicode encoding forms https://scripts.sil.[...] 2022-10-03
_[4] 웹사이트 Annex B - The Universal Character Set (UCS) http://std.dkuug.dk/[...] 2022-10-03
_[5] 서적 The Unicode Standard, version 6.0 Unicode Consortium 2011-02
_[6] 웹사이트 Let's Stop Ascribing Meaning to Code Points https://manishearth.[...] 2020-06-14
_[7] 웹사이트 👨‍🦲 Man: Bald Emoji https://emojipedia.o[...] 2021-10-12
_[8] 웹사이트 HTML Standard https://html.spec.wh[...] 2024-11-11
_[9] 웹사이트 Choisir et appliquer un encodage de caractères https://www.w3.org/I[...] 2024-11-11
_[10] 웹사이트 PEP 393 -- Flexible String Representation https://legacy.pytho[...] Python 2014-10-26
_[11] 웹사이트 The usage of UTF-32 has several advantages http://seed7.sourcef[...]
_[12] 웹사이트 JuliaStrings/LegacyStrings.jl: Legacy Unicode string types https://github.com/J[...] JuliaStrings 2019-10-15
_[13] 웹사이트 UTF-8 Everywhere Manifesto http://utf8everywher[...]
_[14] 웹사이트 u32string https://cplusplus.co[...] 2024-11-12
_[15] 웹사이트 String literal - cppreference.com https://en.cpprefere[...] 2024-11-14
_[16] 웹사이트 UTF32Encoding Class (System.Text) https://learn.micros[...] 2024-11-27
_[17] 문서 UTF（符号化形式/符号化スキーム）ではなくUCSであることに注意

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com