가변 너비 인코딩
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
가변 너비 인코딩은 다양한 문자를 효율적으로 표현하기 위해 설계된 인코딩 방식으로, 기존 소프트웨어와의 호환성을 유지하면서 문자 표현의 유연성을 제공한다. 가변 너비 인코딩은 단일 문자, 선행 단위, 후행 단위의 세 가지 유형의 단위를 사용하며, 유니코드 표준의 UTF-8, UTF-16 등이 대표적이다. CJK(중국어, 일본어, 한국어)와 같은 큰 문자 집합을 처리하기 위해 멀티바이트 인코딩이 사용되었으며, C 언어는 `char` 형(멀티바이트 문자)과 `wchar_t` 형(와이드 문자)을 사용하여 문자를 처리한다.
더 읽어볼만한 페이지
- 문자 인코딩 - 유니코드
유니코드는 세계의 모든 문자를 하나의 컴퓨터 인코딩 표준으로 통합하기 위해 설계되었으며, 유니코드 컨소시엄에 의해 관리되고 UTF-8, UTF-16, UTF-32 등의 부호화 형식을 제공하지만, 일부 문자 표현 문제, 버전 간 비호환성, 레거시 인코딩과의 호환성 문제 등의 과제를 안고 있다. - 문자 인코딩 - UTF-8
UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.
| 가변 너비 인코딩 | |
|---|---|
| 가변 너비 인코딩 | |
| 다른 이름 | 멀티바이트 문자 인코딩 가변 길이 코드 |
| 정의 | 문자 인코딩 방식 |
| 설명 | 각 문자를 표현하는 데 필요한 비트 수가 달라지는 방식. 일부 문자는 짧은 코드로 표현하고, 다른 문자는 긴 코드로 표현함 |
| 특징 | |
| 호환성 | 고정 너비 인코딩과 비교하여 더 많은 문자를 표현할 수 있음 |
| 효율성 | 자주 사용되는 문자는 짧은 코드로 표현하여 공간 효율성을 높임 |
| 복잡성 | 인코딩 및 디코딩 과정이 더 복잡함 |
| 예시 | |
| 유니코드 | UTF-8, UTF-16 |
| 기타 | 모스 부호 |
| 장점 | |
| 공간 효율성 | 문자 빈도에 따라 코드 길이를 조정하여 저장 공간을 절약 |
| 문자 다양성 | 더 넓은 범위의 문자를 표현 가능 |
| 단점 | |
| 처리 복잡성 | 문자 경계를 식별하고 디코딩하는 데 더 많은 연산이 필요 |
| 오류 전파 | 코드 스트림의 오류가 발생하면 이후 문자 디코딩에 영향을 줄 수 있음 |
| 용도 | |
| 텍스트 저장 | 다양한 문자를 효율적으로 저장 |
| 네트워크 전송 | 대역폭 사용량을 최적화 |
| 관련 기술 | |
| 문자 인코딩 | 문자를 컴퓨터가 이해할 수 있는 형태로 변환하는 과정 |
| 유니코드 | 전 세계의 모든 문자를 표현하기 위한 국제 표준 문자 인코딩 |
| 멀티바이트 문자 | 여러 바이트를 사용하여 하나의 문자를 표현하는 방식 |
2. 일반 구조
가변 너비 인코딩 시스템은 기존 응용 소프트웨어와의 호환성을 위해 일부 문자는 단일 단위 코드를 유지하면서, 다른 문자는 여러 단위 코드를 가질 수 있도록 설계되었다. 가변 너비 인코딩에는 세 가지 종류의 단위가 있다.
- '''단일 문자''': 단일 단위로 구성된 문자.
- '''선행 단위''': 다중 단위 시퀀스의 첫 번째 단위.
- '''후행 단위''': 다중 단위 시퀀스에서 선행 단위 다음에 오는 단위.
입력 및 표시 소프트웨어는 다중 바이트 인코딩 체계의 구조를 알아야 하지만, 다른 소프트웨어는 일반적으로 두 바이트가 두 개의 별도 문자를 나타내는지, 아니면 하나의 문자를 나타내는지를 알 필요가 없다.
예를 들어, "I♥NY" 문자열은 UTF-8로 다음과 같이 인코딩된다(16진수 바이트 값): 49 E2 99 A5 4E 59. 이 시퀀스에서 49, 4E, 59는 단일 문자(각각 ''I, N, Y'')이고, E2는 선행 단위, 99와 A5는 후행 단위이다. 하트 기호(♥)는 선행 단위와 두 개의 후행 단위 조합으로 표시된다.
UTF-8은 세 종류의 단위를 쉽게 식별할 수 있도록 설계되었는데, 이는 세 종류의 단위가 별도의 값 범위를 갖기 때문이다. 이전의 가변 너비 인코딩은 범위가 겹칠 수 있어 오류 발생 가능성이 높았다. 가변 너비 인코딩을 처리하는 텍스트 처리 응용 프로그램은 텍스트를 올바르게 해석하기 위해 모든 결정적 시퀀스의 시작 부분부터 텍스트를 스캔해야 했다. 이러한 인코딩에서는 텍스트 중간에서 문자열을 검색할 때 잘못된 결과를 얻기 쉬웠다. 예를 들어, 16진수 값 DE, DF, E0, E1이 모두 선행 단위 또는 후행 단위가 될 수 있다면, 두 단위 시퀀스 DF E0에 대한 검색은 DE DF E0 E1 시퀀스에서 잘못된 결과를 얻을 수 있다. 또한 하나의 손상되거나 손실된 단위는 다중 단위 시퀀스 전체의 해석을 잘못되게 만들 위험이 있었다.
그러나 UTF-8과 같이 세 가지 유형의 단위가 모두 분리된 가변 너비 인코딩에서는 문자열 검색이 항상 잘못된 결과 없이 작동하며(디코더가 잘 작성된 경우), 하나의 단위가 손상되거나 손실되어도 하나의 문자만 손상된다.
3. CJK 멀티바이트 인코딩
CJK(중국어, 일본어, 한국어)는 큰 문자 집합으로 인해 멀티바이트 인코딩을 처음 사용한 언어들이다. 초기에 인코딩은 7비트로 제한되었다. ISO-2022-JP, ISO-2022-CN, ISO-2022-KR 인코딩은 싱글바이트와 멀티바이트 모드 간 전환을 위해 ISO 2022 이스케이프 시퀀스를 사용하였으며, 총 8,836(94×94)자를 인코딩할 수 있었다. CJK를 위한 ISO 2022 인코딩 방식은 인터넷에서 여전히 사용되고 있다.
유닉스 플랫폼에서 ISO 2022 7비트 인코딩은 8비트 인코딩 방식인 EUC-JP, EUC-CN, EUC-KR로 대체되었다.
PC(MS-DOS 및 마이크로소프트 윈도우) 플랫폼에서는 일본어를 위한 Shift-JIS, 번체 중국어를 위한 Big5와 같은 인코딩 방식이 사용되었다.
4. 유니코드 가변 너비 인코딩
유니코드 표준에는 UTF-8, UTF-16과 같은 가변 너비 인코딩 방식이 있다. (고정 너비 인코딩인 UTF-32도 있다.)
가변 너비 인코딩 시스템의 목표는 기존 응용 소프트웨어에 대한 변경을 최소화하는 것이다. 이를 위해 일부 문자는 다른 문자가 코드에 여러 단위를 가지고 있더라도 기존의 단일 단위 코드를 유지해야 한다. 그 결과 가변 너비 인코딩에는 세 가지 종류의 단위가 있다.
- '''단일 문자''': 단일 단위로 구성
- '''선행 단위''': 다중 단위 시퀀스의 첫 번째로 오는 단위
- '''후행 단위''': 다중 단위 시퀀스 다음에 오는 단위
입력 및 표시 소프트웨어는 다중 바이트 인코딩 체계의 구조를 알아야 하지만, 다른 소프트웨어는 일반적으로 두 바이트가 두 개의 별도 문자를 나타내는지 아니면 하나의 문자를 나타내는지를 알 필요가 없다.
예를 들어, "I♥NY"는 UTF-8에서 16진수 바이트 값으로 `49 E2 99 A5 4E 59`와 같이 인코딩된다. 해당 시퀀스의 6개 단위 중 `49`, `4E` 및 `59`는 단일 문자(각각 ''I, N'' 및 ''Y'')이고, `E2`는 선행 단위이며 `99` 및 `A5`는 후행 단위이다. 하트 기호는 선행 단위와 두 개의 후행 단위의 조합으로 표시된다.
UTF-8은 세 종류의 단위를 쉽게 식별할 수 있도록 설계되었다. 세 종류의 단위는 별도의 값 범위에 속하기 때문이다. 이전의 가변 너비 인코딩은 범위가 겹칠 수 있기 때문에 텍스트 처리 응용 프로그램이 텍스트를 올바르게 해석하기 위해 모든 결정적 시퀀스의 시작 부분부터 텍스트를 스캔해야 했다. 이러한 인코딩에서는 텍스트 중간에서 문자열을 검색할 때 잘못된 결과가 나오기 쉬웠다. 또한 하나의 손상되거나 손실된 단위가 다중 단위 시퀀스 전체 해석을 잘못되게 만들 위험도 있었다. 그러나 UTF-8과 같이 세 가지 유형의 단위가 모두 분리된 가변 너비 인코딩에서는 문자열 검색이 항상 올바르게 작동하며(디코더가 잘 작성된 경우), 하나의 단위가 손상 또는 손실되어도 하나의 문자만 손상된다.
유니코드와 ISO 10646 표준은 원래 고정 너비로 설계되었으며, 유니코드는 16비트, ISO 10646은 32비트였다. ISO 10646은 UTF-1이라는 가변 너비 인코딩을 제공했지만, 값의 중첩이 있는 설계로 인해 벨 연구소의 플랜 9 운영 체제 개발자들은 이를 포기하고 UTF-8로 대체했다. UTF-8에서 싱글톤은 00–7F, 리드 유닛은 C0–FD(현재는 C2–F4), 트레일 유닛은 80–BF의 범위를 가진다.
UTF-16은 원래 유니코드(1.x)의 65,536자 제한에서 벗어나기 위해 고안되었다. UTF-16에서 싱글톤은 0000–D7FF와 E000–FFFF의 범위를 가지며, 리드 유닛은 D800–DBFF이고 트레일 유닛은 DC00–DFFF의 범위를 가진다. 유니코드 용어에서 각각 ''상위 대리자''와 ''하위 대리자''라고 불리는 리드 유닛과 트레일 유닛은 1,048,576개의 보조 문자를 매핑하여 총 1,112,064개의 코드 포인트를 인코딩할 수 있다.
최근 부호화된 문자 집합으로서의 ISO 10646 (유니코드) 및 그 부호화 방식 (UTF-8, UTF-16 등)이 널리 사용되고 있다.
5. 문자 집합과 인코딩 방식
문자 집합(Character Set)은 표현하고자 하는 문자의 집합을 정의하며, 인코딩 방식(Encoding Scheme)은 문자를 컴퓨터에서 표현하기 위한 바이트 표현 방식을 정의한다.
ISO 2022 체계를 기반으로 하는 도형 문자 집합에서, 1문자가 1바이트인 문자 집합을 싱글바이트 문자 집합(single-byte character set)이라고 한다. 반면 1문자가 2바이트 이상으로 표현되는 문자 집합을 멀티바이트 문자 집합(multibyte character set)이라고 한다. 94x94 문자 집합(2바이트), 96x96 문자 집합(2바이트), 94x94x94 문자 집합(3바이트) 등이 있지만, 실제로는 94x94 문자 집합 외에는 드물다.
특히, 1문자가 2바이트인 문자 집합을 2바이트 문자 집합(double-byte character set)이라고 하며, 여기에는 다음이 포함된다.
| 문자 집합 |
|---|
| GB 2312 |
| JIS X 0208 (JIS C 6226) |
| JIS X 0212 |
| JIS X 0213 |
| KS X 1001 (KS C 5601) |
| KPS 9566 |
| CNS 11643 |
2바이트 문자 집합의 문자를 2바이트 문자라고 부르는 경우가 있지만, 1바이트 문자 집합의 문자라도 인코딩 방식에 따라 2바이트로 표현될 수 있다. (예: EUC-JP에서의 JIS X 0201 가타카나) 최근에는 유니코드로 처리하는 경우가 많아, 문자 집합이 아닌 개별 문자를 1바이트/2바이트 문자로 표현하는 것은 혼란을 야기할 수 있다.
인코딩 방식에서 1문자가 항상 1바이트가 되는 방식[2]과 달리, 1문자가 2바이트 이상이 될 수 있는 인코딩 방식을 멀티바이트 문자(열)이라고 한다.
멀티바이트 인코딩은 대부분 ASCII 또는 ISO 646을 기반으로 하며, 16진법으로 80-FF (또는 그 하위 집합)으로 시작하는 바이트 열을 사용하여 다른 문자 집합을 표현한다. 1문자의 바이트 수가 가변적이므로 프로그램에서 다룰 때 주의해야 한다.
'character set'(문자 집합)이라고 부르는 것은 엄밀히 말하면 정확하지 않지만, IBM이나 마이크로소프트에서는 싱글바이트 문자 집합, 더블바이트 문자 집합, 멀티바이트 문자 집합이라는 용어를 사용하기도 한다.
멀티바이트 인코딩 방식에는 다음이 포함된다.
| 인코딩 방식 |
|---|
| Big5 (마이크로소프트 코드 페이지 950) |
| EUC-CN (코드 페이지 936) |
| EUC-JP |
| EUC-KR (코드 페이지 949) |
| ISO-2022-JP |
| Shift_JIS (코드 페이지 932/942) |
| UTF-8 (다중 바이트 인코딩 방식) |
6. C 프로그래밍 언어와 멀티바이트
C 언어 표준에서 `char` 형을 이용하여 문자당 1바이트 이상의 가변 길이 바이트 열로 나타낸 것을 멀티바이트 문자(열)라고 한다. C95 이후 C 언어는 멀티바이트 문자(열) 조작을 위한 다음 함수들을 제공한다.[3]
- `mblen`
- `mbtowc`
- `wctomb`
- `mbstowcs`
- `wcstombs`
마이크로소프트 윈도우에서는 와이드 문자가 2바이트(16비트)로 정의되어 있으며, 인코딩 방식에 UTF-16을 이용한다. 많은 Windows API에는 시스템 로케일 설정에 의존하는 멀티바이트 문자 세트를 이용하는 함수·구조체(심볼 말미에 `A`가 붙어 있다)와, 유니코드 문자 세트를 이용하는 함수·구조체(심볼 말미에 `W`가 붙어 있다)가 모두 준비되어 있다.[3] 그러나 Windows NT 계열에서는 내부 처리에 UTF-16을 사용하고 있기 때문에 멀티바이트 문자 세트용 API를 사용하면 변환을 위한 불필요한 오버헤드가 증가한다. 멀티바이트 문자열 조작이나 와이드 문자열과의 상호 변환을 위한 API 함수는 다음과 같다.
- `MultiByteToWideChar`
- `WideCharToMultiByte`
- `CharNextA`
- `CharPrevA`
심볼 말미에 `A`가 붙은 멀티바이트 문자 세트용 API 함수는 코드 페이지 번호를 명시적으로 지정할 수 없으며, 동작은 시스템 로케일 설정에 의존한다.
참조
[1]
간행물
UTF-9 and UTF-18 Efficient Transformation Formats of Unicode
2005-04-01
[2]
문서
ISO 8859/1、[[Windows]][[コードページ]]1252、[[Macintosh]] Roman など
[3]
웹사이트
Unicode Programming Summary
https://docs.microso[...]
2019-07-15
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com