UTF-8, UTF-16 및 UTF-32는 저장할 수 있는 문자 수가 다릅니까?
https://stackoverflow.com/questions/130438
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
좋아요.나는 이것이 전형적인 것처럼 보인다는 것을 안다. "그는 왜 그냥 구글에서 검색하거나 웹사이트로 가지 않았나요? www.unicode.org 그리고 찾아봐?" 질문이지만 이렇게 간단한 질문에 대해서는 두 소스를 모두 확인한 후에도 여전히 대답을 찾을 수 없습니다.
이 세 가지 인코딩 시스템이 모두 모든 유니코드 문자를 지원한다고 확신하지만 프레젠테이션에서 주장하기 전에 이를 확인해야 합니다.
보너스 질문:이러한 인코딩은 지원하기 위해 확장할 수 있는 문자 수가 다른가요?
해결책
아니요, 단순히 인코딩 방법이 다릅니다. 그들은 모두 동일한 문자 세트를 인코딩하는 것을 지원합니다.
UTF-8은 인코딩하는 문자에 따라 문자 당 1 ~ 4 바이트를 사용합니다. ASCII 범위 내의 캐릭터는 하나의 바이트 만 사용하는 반면 매우 특이한 캐릭터는 4를 가져갑니다.
UTF-32는 문자가 어떤 문자인지에 관계없이 문자 당 4 바이트를 사용하므로 동일한 문자열을 인코딩하기 위해 UTF-8보다 더 많은 공간을 사용합니다. 유일한 장점은 바이트 만 계산하여 UTF-32 문자열의 문자 수를 계산할 수 있다는 것입니다.
UTF-16은 대부분의 charactes에 대해 2 바이트, 특이한 것들에 대해 4 바이트를 사용합니다.
http://en.wikipedia.org/wiki/comparison_of_unicode_encodings
다른 팁
한 인코딩에는 저장할 수 있지만 다른 인코딩에는 저장할 수 없는 유니코드 문자가 없습니다.이는 유효한 유니코드 문자가 UTF-16(세 가지 인코딩 중 용량이 가장 작음)으로 저장될 수 있는 문자로 제한되었기 때문입니다.즉, UTF-8 및 UTF-32 ~할 수 있었다 UTF-16보다 더 넓은 범위의 문자를 나타내는 데 사용되지만 그렇지 않다.자세한 내용은 계속 읽어보세요.
UTF-8
UTF-8은 가변 길이 코드입니다.일부 문자에는 1바이트가 필요하고 일부 문자에는 2바이트, 일부 문자에는 3바이트, 일부 4바이트가 필요합니다.각 문자의 바이트는 연속적인 바이트 스트림으로 차례로 기록됩니다.
일부 UTF-8 문자의 길이는 4바이트일 수 있지만 UTF-8 2^32자를 인코딩할 수 없습니다..가깝지도 않아요.나는 그 이유를 설명하려고 노력할 것입니다.
UTF-8 스트림을 읽는 소프트웨어는 단지 일련의 바이트를 얻습니다. 다음 4바이트가 단일 4바이트 문자인지, 2개의 2바이트 문자인지, 4개의 1바이트 문자(또는 4바이트)인지 결정하는 방법은 무엇입니까? 다른 조합)?기본적으로 이는 특정 1바이트 시퀀스가 유효한 문자가 아니고 특정 2바이트 시퀀스가 유효한 문자가 아니라고 결정하는 방식으로 수행됩니다.이러한 유효하지 않은 시퀀스가 나타나면 해당 시퀀스가 더 길게 순서.
당신은 이것에 대한 다소 다른 예를 보았습니다. 나는 확신합니다.탈출이라고 합니다.많은 프로그래밍 언어에서는 다음과 같이 결정됩니다. \ 문자열의 소스 코드에 있는 문자는 문자열의 "컴파일된" 형식에 있는 유효한 문자로 변환되지 않습니다.소스에서 \가 발견되면 다음과 같이 더 긴 시퀀스의 일부로 간주됩니다. \n 또는 \xFF.참고하세요 \x 잘못된 2문자 시퀀스입니다. \xF 은(는) 잘못된 3자 시퀀스이지만 \xFF 유효한 4자 시퀀스입니다.
기본적으로 문자 수가 많은 것과 문자 수가 짧은 것 사이에는 절충점이 있습니다.2^32자를 원할 경우 길이는 평균 4바이트여야 합니다.모든 문자를 2바이트 이하로 만들고 싶다면 2^16자를 초과할 수 없습니다.UTF-8은 합리적인 절충안을 제공합니다.모두 아스키 문자(ASCII 0 ~ 127)에는 1바이트 표현이 제공되므로 호환성이 좋지만 더 많은 문자가 허용됩니다.
위에 표시된 이스케이프 시퀀스 종류를 포함하여 대부분의 가변 길이 인코딩과 마찬가지로 UTF-8은 즉각적인 코드.즉, 디코더는 바이트 단위로 읽고 문자의 마지막 바이트에 도달하자마자 문자가 무엇인지 알게 됩니다. 그렇지 않다 긴 문자의 시작 부분).
예를 들어 문자 'A'는 바이트 65를 사용하여 표현되며 첫 번째 바이트가 65인 2/3/4바이트 문자는 없습니다.그렇지 않으면 디코더는 'A' 뒤에 다른 문자가 오는 것을 제외하고 해당 문자를 구분할 수 없습니다.
그러나 UTF-8은 훨씬 더 제한됩니다.더 짧은 문자의 인코딩이 나타나지 않도록 보장합니다. 어딘가에 더 긴 문자의 인코딩 내에서.예를 들어, 4바이트 문자의 바이트는 모두 65가 될 수 없습니다.
UTF-8에는 128개의 서로 다른 1바이트 문자(바이트 값은 0-127)가 있으므로 모든 2, 3 및 4바이트 문자는 128-256 범위의 바이트로만 구성되어야 합니다.그것은 큰 제한입니다.그러나 바이트 지향 문자열 함수를 거의 또는 전혀 수정하지 않고도 작동할 수 있습니다.예를 들어, C strstr() 입력이 유효한 UTF-8 문자열인 경우 함수는 항상 예상대로 작동합니다.
UTF-16
UTF-16은 가변 길이 코드이기도 합니다.해당 문자는 2바이트 또는 4바이트를 소비합니다.0xD800-0xDFFF 범위의 2바이트 값은 4바이트 문자를 구성하기 위해 예약되어 있으며, 모든 4바이트 문자는 0xD800-0xDBFF 범위의 2바이트와 0xDC00-0xDFFF 범위의 2바이트로 구성됩니다.이러한 이유로 유니코드는 U+D800-U+DFFF 범위의 문자를 할당하지 않습니다.
UTF-32
UTF-32는 각 문자의 길이가 4바이트인 고정 길이 코드입니다.이를 통해 2^32개의 서로 다른 문자 인코딩이 허용되지만 이 구성표에서는 0에서 0x10FFFF 사이의 값만 허용됩니다.
용량 비교:
- UTF-8: 2,097,152(실제로는 2,166,912이지만 디자인 세부 사항으로 인해 일부는 동일한 것으로 매핑됨)
- UTF-16: 1,112,064
- UTF-32: 4,294,967,296(단, 처음 1,114,112로 제한됨)
따라서 가장 제한된 것은 UTF-16입니다!공식적인 유니코드 정의에서는 유니코드 문자를 UTF-16으로 인코딩할 수 있는 문자로 제한했습니다(예:범위 U+0000 ~ U+10FFFF(U+D800 ~ U+DFFF 제외).UTF-8 및 UTF-32는 이러한 문자를 모두 지원합니다.
UTF-8 시스템은 실제로 "인위적으로" 4바이트로 제한됩니다.앞서 설명한 제한 사항을 위반하지 않고 8바이트까지 확장할 수 있으며, 이렇게 하면 2^42의 용량이 생성됩니다.원래 UTF-8 사양은 실제로 최대 6바이트를 허용하여 2^31의 용량을 제공합니다.하지만 RFC 3629 UTF-16이 수행하는 모든 작업을 처리하는 데 필요한 양이므로 4바이트로 제한했습니다.
다른(주로 역사적인) 유니코드 인코딩 체계, 특히 UCS-2(U+0000을 U+FFFF로만 인코딩할 수 있음)가 있습니다.
UTF-8, UTF-16 및 UTF-32는 모두 유니 코드 코드 포인트의 전체 세트를 지원합니다. 하나가 지원하는 문자는 없지만 다른 사람은 없습니다.
보너스 질문은 "이러한 인코딩은 지원하기 위해 확장 할 수있는 문자 수에서 다릅니 까?" 예 그리고 아니오. UTF-8 및 UTF-16이 인코딩되는 방식은 2^32 미만으로 지원할 수있는 총 코드 포인트 수를 제한합니다. 그러나 유니 코드 컨소시엄은 UTF-8 또는 UTF-16에서 표현할 수없는 UTF-32에 코드 포인트를 추가하지 않습니다. 그렇게하면 인코딩 표준의 정신을 위반하고 UTF-32에서 UTF-8 (또는 UTF-16)으로 일대일 매핑을 보장하는 것을 불가능하게 만듭니다.
나는 개인적으로 항상 확인합니다 Joel의 게시물 의심 할 때 유니 코드, 인코딩 및 문자 세트에 대해.
모든 UTF-8/16/32 인코딩은 모든 유니 코드 문자를 매핑 할 수 있습니다. 보다 위키 백과의 유니 코드 인코딩 비교.
이 IBM 기사 UTF-8에서 XML 문서를 인코딩하십시오 매우 도움이되며 선택의 여지가 있는지 확인하면 UTF-8을 선택하는 것이 좋습니다. 주로 이유는 넓은 공구 지원이며 UTF-8은 대개 유니 코드를 알지 못하는 시스템을 통과하십시오.
섹션에서 사양의 말 에서 IBM 기사:
W3C와 IETF는 최근 UTF-8을 먼저, 마지막으로, 때로는 선택하는 것에 대해 더욱 단호하게되었습니다. 월드 와이드 웹 1.0의 W3C 문자 모델 : 기본 사항은 "고유 한 문자 인코딩이 필요할 때 문자 인코딩은 UTF-8, UTF-16 또는 UTF-32 여야합니다. US-ASCII는 UTF-와 호환됩니다. 8 (US-ASCII 문자열은 UTF-8 문자열, [RFC 3629] 참조)이므로 UTF-8이 US-ASCII와의 호환성이 필요하다면 적절합니다. " 실제로, US-ASCII와의 호환성은 매우 유용하여 거의 요구 사항입니다. W3C는 "API, UTF-16 또는 UTF-32와 같은 다른 상황에서는 더 적절할 수 있습니다.이 중 하나를 선택하는 가능한 이유는 내부 처리 효율성과 다른 프로세스와의 상호 운용성을 포함합니다."
모든 사람이 말했듯이 UTF-8, UTF-16 및 UTF-32는 모든 유니 코드 코드 포인트를 모두 인코딩 할 수 있습니다. 그러나 UCS-2 (때로는 실수로 UCS-16이라고도 함) 변형은 할 수 없습니다., 그리고 이것은 당신이 Windows XP/Vista에서 찾은 것입니다..
보다 위키 백과 자세한 내용은.
편집하다: 나는 Windows에 대해 틀 렸습니다. NT는 UCS-2를 지원하는 유일한 사람이었습니다. 그러나 많은 Windows 응용 프로그램은 UCS-2에서 코드 지점 당 단일 단어를 가정하므로 버그를 찾을 수 있습니다. 보다 또 다른 Wikipedia 기사. (감사합니다 Jasontrue)
