Unicode 인코딩 비교

이 문서에는 일반적인 참조 목록이 포함되어 있지만 대응하는 충분한 인라인 인용이 없습니다. 좀 더 정밀한 인용문을 도입하여 이 글의 개선에 도움을 주시기 바랍니다.(2019년 7월) (이 템플릿메시지 삭제 방법 및 삭제 시기 확인)

이 문서에서는 Unicode 인코딩을 비교합니다.8비트 클린 환경(전제로 할 수 있음)과 높은 비트가 설정된 바이트 값 사용을 금지하는 환경이라는 두 가지 상황이 고려됩니다.원래 이러한 제한은 7개의 데이터 비트만을 사용하는 링크를 허용하는 것이었지만 일부 표준에서는 유지되므로 일부 표준 준거 소프트웨어는 제한에 준거한 메시지를 생성해야 합니다.Unicode의 표준 압축 방식 및 Unicode의 이진 순서 압축은 단순히 크기를 수량화하기 어렵기 때문에 비교 테이블에서 제외됩니다.

호환성 문제

ASCII 문자만을 포함한 UTF-8 파일은 ASCII 파일과 동일합니다.레거시 프로그램은 일반적으로 UTF-8 인코딩된 파일에 ASC 이외의 파일이 포함되어 있는 경우에도 처리할 수 있습니다.II 문자예를 들어 C printf 함수는 포맷 문자열을 정의하기 위해 ASCII '%' 문자만 찾고 다른 모든 바이트는 변경되지 않으므로 UTF-8 문자열을 인쇄할 수 있습니다.II 문자는 변경되지 않고 출력됩니다.

UTF-16 및 UTF-32는 ASCII 파일과 호환성이 없기 때문에, ASCII 서브셋에 문자만이 포함되어 있는 것을 알고 있는 경우에서도, Unicode 대응 프로그램을 사용해 표시, 인쇄, 조작할 필요가 있습니다.문자열에는 제로 바이트가 다수 포함되어 있기 때문에 복사 ^[a]등의 간단한 조작에서도 일반 늘 종단 문자열 처리에서는 문자열을 조작할 수 없습니다.

따라서 Windows나 Java 등의 대부분의 UTF-16 시스템에서도 UTF-16 텍스트파일은 일반적이지 않습니다.ASCII 나 ISO-8859-1 등의 오래된8비트 인코딩이 사용되고 있습니다.Unicode 지원에는 UTF-8 이 사용됩니다.예를 들어, Mac OS X(10.3 이후) 어플리케이션이 UTF-16으로 디폴트인 국제화된 버전의 메시지를 검색하기 위해 사용하는 "스트링" 파일로, "UTF-8을 사용하여 인코딩된 파일...^[1]이 작동하지 않음을 보증하지 않습니다."가 있습니다.

XML은 디폴트로는 UTF-8로^{[dubious – discuss]} 부호화되어 있으며, 모든 XML 프로세서는 적어도 UTF-8(정의상 US-ASCII 포함)^[2]과 UTF-16을 지원해야 합니다.

효율성.

UTF-8에서는 Unicode 문자를 인코딩하기 위해 8, 16, 24 또는 32비트(1 ~4바이트), UTF-16에서는 문자를 인코딩하기 위해 16비트 또는 32비트가 필요하며 UTF-32에서는 문자를 인코딩하기 위해 항상 32비트가 필요합니다.C0 컨트롤 문자 및 기본 라틴 문자에 사용되며 ASCII 코드 등가 문자에1 대 1로 대응하는 최초의 128 Unicode 코드포인트 U+0000 ~ U+007F는 UTF-8에서는8비트, UTF-16에서는 16비트, UTF-32에서는 32비트를 사용하여 부호화됩니다.

다음 1,920자(U+0080 ~ U+07FF)는 UTF-16, UTF-8로 인코딩하려면 16비트가 필요합니다.U+0800에서 U+FFFF의 경우, 즉 Basic Multilingualling Plane(BMP, Plane 0, U+0000에서 U+FFFF)의 나머지 문자는 UTF-8에서 24비트를 인코딩해야 합니다.보조 플레인(플레인1 ~ 16)의 문자를 나타내는 코드 포인트 U+010000 ~ U+10FFF는 UTF-8, UTF-16 및 UTF-32의 32비트를 필요로 합니다.

UTF-EBCDIC의 모든 인쇄 가능한 문자는 적어도 UTF-8과 같은 수의 바이트를 사용하며, C1 제어 코드를 단일 바이트로 부호화하도록 결정되었기 때문에 대부분 더 많은 바이트를 사용합니다.7비트 환경의 경우 UTF-7은 다른 Unicode 인코딩과 따옴표로 묶은 인쇄 가능 또는 base64를 조합하는 것보다 공간 효율이 높습니다(아래의 "7비트 환경" 참조).

스토리지 사용률

각 포맷은 스토리지 효율성(및 전송 시간) 및 처리 효율과 관련하여 고유한 장점과 단점을 가지고 있습니다.스토리지 효율성은 Unicode 코드 공간 내에서 특정 텍스트의 문자가 주로 사용되는 위치에 따라 달라집니다.Unicode 코드 공간 블록은 문자 집합(알파벳/스크립트)별로 구성되므로 주어진 텍스트의 스토리지 효율은 해당 텍스트에 사용되는 알파벳/스크립트에 따라 효과적으로 좌우됩니다.예를 들어 UTF-8은 U+0000과 U+007F 사이의 128개의 코드 포인트에 대해 UTF-16보다 문자당1바이트(8비트와 16비트)가 적게 필요하지만 U+0800과 U+FFFF 사이의 63,488개의 코드 포인트에 대해서는 문자당1바이트(24비트와 16비트)가 더 필요합니다.따라서 U+0000 ~U+007F 의 범위가 U+0800 ~U+FFF 의 범위보다 많은 문자가 있는 경우는 UTF-8 이 효율적이며 적은 경우는 UTF-16 이 효율적입니다.카운트가 같은 경우는, 같은 사이즈입니다.놀라운 결과는 UTF-8에서는 공백, 숫자, 구두점, 줄 바꿈, HTML 마크업, ^{[citation needed]}라틴 문자로 작성된 삽입 단어와 머리글자어가 광범위하게 사용되기 때문에 UTF-8에서는 여전히 높은 범위의 문자만 사용하는 실제 문서가 더 짧다는 것입니다.

처리시간

처리 시간에 관한 한, UTF-8이나 UTF-16과 같은 가변 길이 인코딩을 사용하는 텍스트는 코드 단위의 시퀀스를 사용하는 것이 아니라 개별 코드 단위를 찾을 필요가 있는 경우 처리하기가 더 어렵습니다.일련의 코드 유닛의 검색은 분할에 개의치 않기 때문에, 검색은 문자의 가변 사이즈 여부에 영향을 받지 않습니다(UTF-8과 UTF-16의 양쪽 모두와 같이, 부호화가 자기 동기화할 필요가 있습니다).일반적인 오해는 "n번째 문자를 찾아야 한다"는 것과 고정 길이의 인코딩이 필요하다는 것입니다.그러나 실제로는 숫자n은 n-1 문자를 조사하는 것만으로 도출되므로 시퀀셜접속이 필요합니다.^{[citation needed]}UTF-16BE 및 UTF-32BE는 빅엔디안, UTF-16LE 및 UTF-32LE는 리틀엔디안입니다엔디안 순서가 다른 머신에 1개의 엔디안 순서로 문자 시퀀스를 로드하는 경우 데이터가 바이트 단위로 처리되지 않는 한 문자를 효율적으로 처리하기 전에 변환해야 합니다(UTF-8에 필요한 경우).따라서, 당면한 문제는 계산상의 어려움보다는 프로토콜과 통신에 더 관련이 있다.

처리 문제

처리를 위해 포맷은 검색, 잘라내기 쉬워야 하며 일반적으로 안전하게 처리해야 합니다.모든 일반 Unicode 인코딩은 일정한 크기의 코드 단위를 사용합니다.부호화할 형식과 코드 포인트에 따라 이러한 코드 유닛 중 하나 이상이 Unicode 코드 포인트를 나타냅니다.쉽게 검색 및 잘라내려면 시퀀스가 더 긴 시퀀스 내에서 또는 다른 두 시퀀스의 경계를 넘어서는 안 됩니다.UTF-8, UTF-16, UTF-32 및 UTF-EBCDIC에는 이러한 중요한 속성이 있지만 UTF-7 및 GB 18030에는 없습니다.

고정 사이즈의 문자는 도움이 됩니다만, UTF-32 와 같이 코드 포인트 마다 고정 바이트 카운트가 있는 경우에서도, 문자가 조합되어 표시 문자 마다 고정 바이트 카운트는 없습니다.이러한 비호환성 및 다른 부호화 방식 간의 기이한 점을 고려할 때 인터페이스 전체에 걸쳐 동일하거나 호환되는 프로토콜로 유니코드 데이터를 처리하는 것(예를 들어 API/라이브러리 사용, 클라이언트/서버 모델에서의 유니코드 문자 처리 등)은 일반적으로 잠재적인 소스를 제거하면서 파이프라인 전체를 단순화할 수 있습니다.동시에 버그를 검출합니다.

UTF-16은 Unicode가 16비트 고정폭(UCS-2)이었던 시점까지 거슬러 올라가기 때문에 널리 사용되고 있습니다.단, UTF-16을 사용하면 Basic Multilinguage Plane 이외의 문자는 특수한 케이스가 되어 취급에 관한 과시의 위험이 높아집니다.즉, 대리 쌍을 잘못 다루는 프로그램도 시퀀스의 결합에 문제가 있을 수 있으므로 UTF-32를 사용하는 것은 멀티 코드 단위 문자의 처리 불량이라는 보다 일반적인 문제를 해결할 수 없을 것 같습니다.

저장된 데이터가 UTF-8(파일 내용이나 이름 등)에 있는 경우 UTF-16 또는 UTF-32를 API로 사용하는 시스템을 작성하는 것은 매우 어렵습니다.이는 UTF-8에서 사용되는 바이트 배열에 비활성 시퀀스가 물리적으로 포함되어 있을 수 있다는 점을 간과하는 경우가 많기 때문입니다.예를 들어 UTF-16 API를 사용하여 비활성 UTF-8 파일 이름을 수정할 수 없습니다.이는 UTF-16 문자열이 비활성 파일 이름으로 변환되지 않기 때문입니다.그 반대는 아닙니다.유효하지 않은 UTF-16을 일의의 UTF-8 문자열(기술적으로는 무효지만)로 변환하는 것은 간단하기 때문에 UTF-8 API는 UTF-8과 UTF-16의 양쪽 파일과 이름을 제어할 수 있기 때문에 이러한 혼합 환경에서는 UTF-8이 우선됩니다.UTF-16 시스템에서 사용되는 유감스럽지만 훨씬 일반적인 회피책은 UTF-8을 CP-1252 등의 다른 인코딩으로 해석하여 ASCII 이외의 데이터에 대해 mojibake를 무시하는 것입니다.

통신 및 저장용

UTF-16 및 UTF-32에는 엔디안니스 정의가 없기 때문에 바이트 지향 네트워크를 통해 수신하거나 바이트 지향 스토리지에서 읽을 때 바이트 순서를 선택해야 합니다.이는 텍스트 시작 부분에서 바이트 순서 마크를 사용하거나 빅 엔디안(RFC 2781)을 가정함으로써 달성할 수 있습니다.UTF-8, UTF-16BE, UTF-32BE, UTF-16LE 및 UTF-32LE는 단일 바이트 순서로 표준화되어 있어 이 문제는 발생하지 않습니다.

바이트 스트림이 파손될 경우 일부 인코딩은 다른 인코딩보다 더 잘 복구됩니다.UTF-8 및 UTF-EBCDIC은 다음 코드 포인트 시작 시 바이트가 파손되거나 없어진 후 항상 재동기화할 수 있기 때문에 이 점에서 가장 적합합니다.GB 18030은 다음 ASCII 번호가 아닌 번호까지 복구할 수 없습니다.UTF-16은 변경된 바이트를 처리할 수 있지만 홀수 수의 누락 바이트는 처리할 수 없습니다.이 경우 다음 텍스트가 모두 깨집니다(단, 일반적이지 않거나 할당되지 않은 ^[b]문자가 생성됩니다).비트가 손실될 수 있는 경우 모든 비트가 다음 텍스트를 가글링합니다.단, UTF-8은 잘못된 바이트 경계로 인해 몇 바이트보다 긴 거의 모든 텍스트에서 비활성 UTF-8이 생성되기 때문에 재동기화할 수 있습니다.

상세하게

다음 표에 다양한 Unicode 범위의 코드 포인트당 바이트 수를 나타냅니다.필요한 추가 코멘트가 표에 포함되어 있습니다.이 그림에서는 텍스트 블록의 시작과 끝의 오버헤드는 무시할 수 있다고 가정합니다.

N.B. 아래 표에는 사용자가 볼 수 있는 "문자"(또는 "그래펨 클러스터")가 아닌 코드 포인트당 바이트 수가 나열되어 있습니다.단일 그래핀 클러스터를 기술하려면 여러 코드 포인트가 필요하므로 UTF-32에서도 문자열을 분할하거나 연결할 때 주의해야 합니다.

8비트 환경

코드 범위(16진수)	UTF-8	UTF-16	UTF-32	UTF-EBCDIC	GB 18030
000000 – 00007f	1	2	4	1	1
000080 – 00009f	2				에서 상속된 캐릭터의 경우 2 GB 2312/GBK (대부분 등) 한자) 4: 그 외 모든 것.
0000A0 – 0003FF				2
000400 – 0007FF				3
000800 – 003fortississimo.	3
004000 – 00FFF				4
010000 – 03FFFF	4	4			4
040000 – 10FFF				5

7비트 환경

이 표는 모든 특수한 경우를 대상으로 하는 것은 아니므로 추정과 비교만을 위해 사용해야 합니다.부호화의 텍스트 크기를 정확하게 판별하려면 실제 사양을 참조하십시오.

코드 범위(16진수)	UTF-7	UTF-8 인용 인쇄 가능	UTF-8 base64	UTF-16 q.-p.	UTF-16 base64	GB 18030 Q.-p.	GB 18030 base64
ASCII 그래픽 문자 (U+003D "=" 제외)	"직접 문자"(일부 코드 포인트의 인코더 설정에 따라 다름), U+002B "+", 000080 – 00FFF와 동일함	1	1+1/3	4	2+2×3	1	1+1/3
00003D(등호)		3		6		3
ASCII 제어 문자: 000000 – 00001f 및 00007F		직접성에 따라 1 또는 3				직접성에 따라 1 또는 3
000080 – 0007FF	단일 바이트 문자 실행 내에서 분리된 대소문자의 경우 5입니다.의 경우 1문자당 2+2µ3 + 패딩으로 정수의 바이트 +2 + 실행 시작 및 완료	6	2+2×3	바이트 값을 이스케이프할 필요가 있는지 여부에 따라 2 ~6		GB2312/GBK에서 상속받은 문자의 경우 4~6(예: 대부분의 한자) 기타 모든 것에 대해 8을 클릭합니다.	GB2312/GBK에서 상속된 문자의 경우 2+2⁄3(예: 대부분의 한자) 기타 모든 것에 대해 5+1÷3을 사용합니다.
000800 – 00FFFF		9	4
010000 – 10FFF	격리된 경우 8개, 문자당 5+1µ3 + 정수에 대한 패딩 + 실행 시 2개	12	5+1/3	대용 바이트의 낮은 바이트를 이스케이프할 필요가 있는지 여부에 따라 8 ~12 。	5+1/3	8	5+1/3

endianness는 사이즈에 영향을 주지 않습니다(UTF-16BE 및 UTF-32BE는 각각 UTF-16LE 및 UTF-32LE와 같은 사이즈입니다).quoted-printable에서 UTF-32를 사용하는 것은 매우 비현실적이지만, 실장했을 경우, 코드 포인트 마다 8 ~12 바이트(평균 약 10 바이트)가 됩니다.즉, BMP 의 경우, 각 코드 포인트는, quoted-printable/UTF-32 5+1 바이트의 같은 코드보다 정확하게 6 바이트를 차지합니다.Base64/UTF-32는 임의의 포인트로 취득합니다.

따옴표 인쇄 가능 또는 UTF-7 아래의 ASCII 제어 문자는 직접 또는 부호화(에스케이프)할 수 있습니다.지정된 제어 문자를 이스케이프해야 하는 필요성은 여러 상황에 따라 다르지만 텍스트 데이터의 줄바꿈은 일반적으로 직접 코딩됩니다.

압축 방식

BOCU-1과 SCSU는 Unicode 데이터를 압축하는 두 가지 방법입니다.이러한 인코딩은 텍스트의 사용 빈도에 따라 달라집니다.대부분의 텍스트 실행은 동일한 스크립트를 사용합니다(예: 라틴어, 키릴어, 그리스어 등).이러한 일반적인 사용으로 많은 텍스트 실행이 코드 포인트당 약 1바이트로 압축될 수 있습니다.이러한 스테이트풀한 인코딩을 사용하면 문자열의 임의의 위치에서 텍스트에 랜덤하게 액세스하기 어려워집니다.

이러한 두 가지 압축 방식은 zip 또는 bzip2와 같은 다른 압축 방식만큼 효율적이지 않습니다.이러한 범용 압축 방식에서는 장시간 실행되는 바이트를 몇 바이트로 압축할 수 있습니다.SCSU 및 BOCU-1 압축 방식은 UTF-8, UTF-16 또는 UTF-32로 인코딩된 텍스트의 이론적인 25%를 넘지 않습니다.다른 범용 압축 방식은 원래 텍스트 크기의 10%까지 쉽게 압축할 수 있습니다.범용 스킴에서는, 보다 복잡한 알고리즘과 보다 긴 텍스트의 청크가 필요합니다.

Unicode Technical Note #14에는 압축 방식에 대한 자세한 비교가 포함되어 있습니다.

이력: UTF-5 및 UTF-6

도메인 네임(IDN)의 국제화를 위한 UTF-5 및 UTF-6의 제안이 있습니다.UTF-5 프로포절에서는 Base 32 인코딩을 사용했습니다.Punycode는 (특히) Base 36 인코딩입니다.5비트 코드 단위의 UTF-5는 2 = ^[3]32라는 공식으로⁵ 설명됩니다.UTF-6 프로포절에서는 UTF-5에 실행 길이 부호화가 추가되었습니다.여기서 6은 단순히 UTF-5+^[4]1을 나타냅니다.이후 IETF IDN WG는 이 목적을 ^[5]위해 보다 효율적인 Punycode를 채택했습니다.

진지하게 쫓기지 않다

UTF-1은 진지하게 받아들여지지 않았다.UTF-8이 훨씬 더 자주 사용됩니다.

UTF-9 및 UTF-18 인코딩은 만우절 RFC 농담 사양입니다.다만, UTF-9는 기능하는 Unicode 변환 형식이며, UTF-18은 Unicode 12 이하의 모든 비개인용 코드 포인트에 기능하는 Nonet 인코딩입니다.단, 보충적인 용도에는 해당되지 않습니다.

메모들

레퍼런스