UTF-32

UTF-32

UTF-32(32비트 유니코드 변환 포맷)는 유니코드 코드 포인트를 인코딩하는 데 사용되는 고정 길이 인코딩으로, 코드 포인트당 정확히 32비트(4바이트)를 사용한다(단, 유니코드 코드 포인트가 2개보다32 훨씬 적기 때문에 선행 비트 수가 0이어야 하며, 실제로는 21비트만 필요하다).[1]UTF-32는 가변 길이 인코딩인 다른 모든 유니코드 변환 형식과는 대조적으로 고정 길이 인코딩이다.UTF-32의 각 32비트 값은 하나의 유니코드 코드 포인트를 나타내며 해당 코드 포인트의 숫자 값과 정확히 동일하다.

UTF-32의 주요 장점은 유니코드 코드 포인트가 직접 인덱싱된다는 점이다.코드 포인트의 순서에서 N번째 코드 포인트를 찾는 것은 일정한 시간 작업이다.이와는 대조적으로 가변 길이 코드는 문자열 시작부터 N개의 코드 포인트를 세는 데 선형 시간이 필요하다.따라서 UTF-32는 일반적으로 ASCII에 대해 그랬던 것처럼 1씩 증가되는 정수를 사용하여 문자열의 각 위치를 검사하는 코드에서의 간단한 대체가 된다.오래된 코드를 변환하는 것 외에, 이러한 지속적인 시간 접근은 초보 프로그래머들이 추측할 수 있는 것보다 훨씬 덜 유리하다.

UTF-32의 주요 단점은 항상 0인 11비트를 포함하여 코드 포인트당 4바이트를 사용하는 등 공간 효율성이 떨어진다는 점이다.BMP를 초과하는 문자는 대부분의 텍스트(예: 일부 인기 있는 이모티콘이 있는 텍스트 제외)에서 상대적으로 드물며 일반적으로 추정치 크기에서 무시할 수 있다.이로써 UTF-32는 UTF-16 크기의 두 배 가까이 된다.ASCII 하위 집합에 있는 문자 수에 따라 UTF-8 크기의 최대 4배까지 될 수 있다.

역사

원래의 ISO 10646 표준은 UCS-4라는 32비트 인코딩 양식을 정의하는데, UCS-4(Universal 문자 집합(UCS)의 각 코드 포인트가 0 ~ 0x7FFFFFFF(부호 비트는 사용되지 않고 0)의 31비트 값으로 표현된다.2003년 11월, 유니코드는 U+10FFF보다 큰 코드 포인트(그리고 U+DFFF를 통한 높고 낮은 대리 U+D800도 명시적으로 금지)라는 UTF-16 인코딩의 제약조건과 일치하도록 RFC 3629에 의해 제한되었다.이 제한된 하위 집합은 UTF-32를 정의한다.[2][1]ISO 표준은 (유니코드 2.1의 1998년 기준) 0xE00000 ~ 0xFFFFF, 0x6000000 ~ 0x7FFFFFFF를[3] "사용으로 보존"하였지만, 이러한 영역은 이후 버전에서 제거되었다.ISO/IEC JTC 1/SC 2 워킹그룹 2의 원칙과 절차 문서에는 향후 코드 포인트의 모든 할당이 유니코드 범위에 제약을 받는다고 명시되어 있기 때문에 UTF-32는 모든 UCS 코드 포인트를 나타낼 수 있고 UTF-32와 UCS-4는 동일하다.

분석

코드 포인트당 정해진 바이트 수가 편리해 보이지만, 보이는 것만큼 유용하지는 않다.UTF-8과 UTF-16에 비해 잘라내기는 쉬워지지만 크게는 그렇지 않다(둘 다 최대 2~4개의 코드 단위를 보면 잘라낼 지점을 거꾸로 검색할 수 있다).

이 위치와 문자열의 한쪽 끝 사이의 모든 코드 포인트를 검사하여 먼저 N을 계산할 필요 없이 N번째 코드 포인트를 찾으려는 코드는 극히 드물다[citation needed].예를 들어, 모든 LALR 구문 분석기(예: XML)는 N번째 코드 포인트로 작업을 수행하기 전에 이전의 모든 코드 포인트를 검토해야 한다.[4]각 문자에 대해 1씩 증가되는 정수 색인은 정수 오프셋으로 대체하여 코드 단위로 측정하고 각 문자를 검사할 때 코드 단위 수로 증가시킬 수 있다.이것은 UTF-32의 어떤 속도 장점도 제거한다.

UTF-32는 "고정 너비" 글꼴이 있더라도 문자 위치당 코드 포인트(결합 문자)가 두 개 이상일 수 있고 코드 포인트당 문자 위치("CJK 문자판의 경우 그라페임 클러스터")가 두 개 이상일 수 있으므로 문자열의 표시 너비를 계산하기가 더 쉽지는 않다.좌우 언어와 사전 컴파일된 문자로 자신을 제한하는 편집자는 고정 크기 코드 단위를 활용할 수 있지만, 그러한 편집자는 비 BMP 문자를 지원할 가능성이 낮기 때문에 UTF-16과 동등하게 잘 작동할 수 있다.[citation needed]

사용자가 "문자"라고 생각하는 것은 문자나 그래핀 클러스터가 결합되어 있기 때문에 코드 포인트의 수가 일정하지 않다.현대 사용자들이 더 많이 접하는 이모지 ZWJ 시퀀스와[5] 이모지 수식어가 있어, 일부 이모지들은 하나의 코드 포인트보다 길다, 예를 들면 "👨🦲맨: Bald",[6] "👩🦰🦰 Woman: Red Hair"[7]와 같이.

사용하다

UTF-32의 주요 용도는 데이터가 문자열이 아닌 단일 코드 포인트 또는 글리프인 내부 API에 있다.예를 들어, 현대의 텍스트 렌더링에서 마지막 단계는 좌표(x,y), 속성 및 그릴 글리프를 식별하는 단일 UTF-32 코드 포인트를 포함하는 구조 목록을 작성하는 것이 일반적이다.종종 Unicode 정보가 아닌 정보는 각 단어의 "사용되지 않은" 11비트에 저장된다.[citation needed]

윈도우즈에서 UTF-32 문자열 사용(여기서) wchar_t는 16비트)는 거의 존재하지 않는다.Unix 시스템에서는 wchar_t 유형이 32비트로 정의되기 때문에 UTF-32 문자열이 애플리케이션에서 내부적으로 사용되기도 하지만 거의 사용되지 않는다.Python 버전은 UTF-16 대신 3.2까지 컴파일할 수 있다; 버전 3.3부터 모든 유니코드 문자열은 UTF-32에 저장되지만, 모든 코드 포인트를 그 크기로 만들기 위해 "가장 큰 유니코드 서수형(1, 2 또는 4바이트)을 가진 [코드 포인트]에 따라" 최적화되는 선행 0바이트로 구성된다.[8]반면 줄리아는 프로그래밍 언어가 기본 제공 UTF-32 지원에서 1.0출시로 이동했다 Seed7[9]과 Lasso[표창 필요한]프로그래밍 언어, 신앙을 직접 분할 법 중요하다에서,( 다른 모든 인코딩 유산, 이사에 오직 UTF-8문자열을 가지는 것은 언어를 단순화 UTF-32과 모든 문자열을 인코딩합니다.표준에서라이브러리[10]: "UTF-8 Everywhere Manifesto"[11] 후속.

변형

기술적으로는 무효가 되었지만, 대리모 반쪽은 종종 암호화되어 허용된다.이를 통해 UTF-8의 WTF-8 변종이 작동하는 방식과 유사하게 유효하지 않은 UTF-16(Windows 파일 이름 등)을 UTF-32로 변환할 수 있다.때로는 CESU-8과 유사하게 비 BMP 문자 대신 짝을 이룬 대용물을 인코딩하기도 한다.미사용 32비트 값이 많기 때문에, 이에 대한 표준은 없지만, UTF-8 오류를 인코딩하기 위해 비 유니코드 값을 사용하여 무효 UTF-8을 보존하는 것도 가능하다.

참고 항목

참조

  1. ^ a b 유니코드 인코딩 양식에 코드 포인트 매핑, § 1: UTF-32
  2. ^ "ISO/IEC 10646:2020". standards.iso.org. Retrieved 2021-10-12. 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".
  3. ^ 범용 문자 집합(UCS)
  4. ^ "Web Application Development".
  5. ^ "↔️ Emoji ZWJ (Zero Width Joiner) Sequences". emojipedia.org. Retrieved 2021-10-12.
  6. ^ "👨🦲 Man: Bald Emoji". Emojipedia. Retrieved 2021-10-12.
  7. ^ "👩🦰 Woman: Red Hair Emoji". Emojipedia. Retrieved 2021-10-12.
  8. ^ Löwis, Martin. "PEP 393 -- Flexible String Representation". python.org. Python. Retrieved 26 October 2014.
  9. ^ "The usage of UTF-32 has several advantages".
  10. ^ JuliaStrings/LegacyStrings.jl: Legacy Unicode string types, JuliaStrings, 2019-05-17, retrieved 2019-10-15
  11. ^ "UTF-8 Everywhere Manifesto".

외부 링크