[unicode] 유니 코드, UTF-8, UTF-16이란 무엇입니까?

왜 유니 코드가 필요한가요?

(그렇지 않은) 초기에는 존재했던 모든 것이 ASCII였습니다. 이 문장에서와 같이 몇 가지 제어 문자, 문장 부호, 숫자 및 문자 만 있으면되었으므로 괜찮습니다. 불행히도, 오늘날의 이상한 세계 상호 통신 및 소셜 미디어 세계는 예견되지 않았으며 영어, العربية, 汉语, עִבְרִית, ελληνικά 및 ភាសាខ្មែរ을 같은 문서에서 보는 것이 너무 이례적이지 않습니다. 브라우저).

그러나 논쟁을 위해 Joe Average는 소프트웨어 개발자라고 말합니다. 그는 영어 만 있으면되고 ASCII 만 사용하기를 원한다고 주장합니다. 사용자 Joe에게는 문제가 될 수 있지만 소프트웨어 개발자 Joe에게는 문제가되지 않습니다 . 세계의 약 절반이 라틴 문자가 아닌 문자를 사용하고 ASCII를 사용하는 것이이 사람들에게는 무시할 수없는 일이며, 게다가 그는 성장하는 경제에 소프트웨어를 폐쇄하고 있습니다.

따라서 모든 언어를 포함하는 문자 세트 가 필요합니다. 따라서 유니 코드가왔다. 모든 문자에 코드 포인트 라는 고유 번호를 할당합니다 . 다른 가능한 세트에 비해 유니 코드의 한 가지 장점은 첫 번째 256 코드 포인트가 ISO-8859-1 과 동일 하므로 ASCII도 있다는 것입니다. 또한, 일반적으로 사용되는 대부분의 문자는 BMP (Basic Multilingual Plane) 라는 영역에서 2 바이트로만 표현할 수 있습니다. 이제이 문자 집합에 액세스하려면 문자 인코딩이 필요하며 질문에 따라 UTF-8과 UTF-16에 집중할 것입니다.

메모리 고려 사항

그렇다면이 인코딩에서 몇 바이트가 어떤 문자에 액세스 할 수 있습니까?

• UTF-8 :
  • 1 바이트 : 표준 ASCII
  • 2 바이트 : 아랍어, 히브리어, 대부분의 유럽 문자 (대부분 그루지야 어 제외 )
  • 3 바이트 : BMP
  • 4 바이트 : 모든 유니 코드 문자
• UTF-16 :
  • 2 바이트 : BMP
  • 4 바이트 : 모든 유니 코드 문자

BMP에 포함되지 않은 문자에는 고대 스크립트, 수학 기호, 음악 기호 및 희귀 한자 / 일본어 / 한국어 (CJK) 문자가 포함됩니다.

주로 ASCII 문자로 작업하는 경우 UTF-8이 확실히 메모리 효율적입니다. 그러나 유럽 이외의 스크립트를 주로 사용하는 경우 UTF-8을 사용하면 UTF-16보다 메모리 효율성이 최대 1.5 배 떨어질 수 있습니다. 큰 웹 페이지 나 긴 단어 문서와 같이 많은 양의 텍스트를 처리 할 경우 성능에 영향을 줄 수 있습니다.

인코딩 기초

^{참고 : UTF-8 및 UTF-16의 인코딩 방식을 알고 있으면 실제 응용 프로그램의 다음 섹션으로 건너 뛰십시오.}

• UTF-8 : 표준 ASCII (0-127) 문자의 경우 UTF-8 코드는 동일합니다. 기존 ASCII 텍스트와의 호환성이 필요한 경우 UTF-8이 이상적입니다. 다른 문자는 2-4 바이트가 필요합니다. 이는 각 바이트에서 일부 비트를 예약하여 멀티 바이트 문자의 일부임을 나타냅니다. 특히, 각 바이트의 첫 번째 비트 1는 ASCII 문자와의 충돌을 피하는 것입니다.
• UTF-16 : 유효한 BMP 문자의 경우 UTF-16 표현은 단순히 코드 포인트입니다. 그러나 BMP가 아닌 문자의 경우 UTF-16은 서로 게이트 쌍을 도입 합니다 . 이 경우 두 개의 2 바이트 부분 조합은 BMP가 아닌 문자에 맵핑됩니다. 이 2 바이트 부분은 BMP 숫자 범위에서 제공되지만 유니 코드 표준에서는 BMP 문자로 유효하지 않은 것으로 보장됩니다. 또한 UTF-16의 기본 단위는 2 바이트이므로 endianness의 영향을 받습니다 . 보상하기 위해, 예약 바이트 순서 마크 는 엔디안을 나타내는 데이터 스트림의 시작 부분에 배치 될 수있다. 따라서 UTF-16 입력을 읽고 엔디안을 지정하지 않은 경우이를 확인해야합니다.

알 수 있듯이 UTF-8과 UTF-16은 서로 거의 호환되지 않습니다. 따라서 I / O를 수행하는 경우 사용중인 인코딩을 알고 있어야합니다! 이러한 인코딩에 대한 자세한 내용은 UTF FAQ 를 참조하십시오 .

실제 프로그래밍 고려 사항

문자 및 문자열 데이터 유형 : 프로그래밍 언어로 어떻게 인코딩됩니까? 원시 바이트 인 경우 비 ASCII 문자를 출력하려고 시도하는 순간 몇 가지 문제가 발생할 수 있습니다. 또한 문자 유형이 UTF를 기반으로하더라도 문자열이 올바른 UTF임을 의미하지는 않습니다. 잘못된 바이트 시퀀스를 허용 할 수 있습니다. 일반적으로 C, C ++ 및 Java 용 ICU 와 같은 UTF를 지원하는 라이브러리를 사용해야합니다 . 어쨌든 기본 인코딩 이외의 것을 입력 / 출력하려면 먼저 변환해야합니다.

권장 / 기본 / 주요 인코딩 : 사용할 UTF를 선택하면 일반적으로 작업중인 환경에 권장되는 표준을 따르는 것이 가장 좋습니다. 예를 들어 UTF-8은 웹에서 지배적이며 HTML5부터는 왔다 권장 인코딩 . 반대로 .NET 및 Java 환경은 모두 UTF-16 문자 유형으로 구성됩니다. 혼란스럽고 (잘못), 종종 “유니 코드 인코딩”이 언급되는데, 이것은 일반적으로 주어진 환경에서 지배적 인 UTF 인코딩을 말합니다.

라이브러리 지원 : 사용중인 라이브러리는 일종의 인코딩을 지원합니다. 어느 것? 그들은 코너 케이스를 지원합니까? 필요성은 발명의 어머니이기 때문에 UTF-8 라이브러리는 일반적으로 1, 2 및 3 바이트 문자가 자주 발생할 수 있으므로 4 바이트 문자를 올바르게 지원합니다. 그러나 모든 의도 된 UTF-16 라이브러리는 대리 쌍이 거의 발생하지 않기 때문에 대리 쌍을 올바르게 지원하지는 않습니다.

계산 문자 : 유니 코드 에는 결합 문자 가 있습니다 . 예를 들어, 코드 포인트 U + 006E (n) 및 U + 0303 (결합 물결표)은 n ~을 형성하지만 코드 포인트 U + 00F1은 ñ를 형성합니다. 그것들은 동일하게 보이지만, 간단한 카운팅 알고리즘은 첫 번째 예에서는 2를, 후자는 1을 반환합니다. 반드시 잘못된 것은 아니지만 원하는 결과가 아닐 수도 있습니다.

평등 비교 : A, А 및 A는 동일하게 보이지만 각각 라틴어, 키릴 어 및 그리스어입니다. C와 Ⅽ와 같은 경우가 있습니다. 하나는 문자이고 다른 하나는 로마 숫자입니다. 또한 고려할 결합 문자도 있습니다. 자세한 내용 은 유니 코드에서 문자 복제를 참조하십시오 .

대리 쌍 : 이것들은 종종 SO에서 충분히 나오므로 몇 가지 예제 링크를 제공합니다.

• 문자열 길이 얻기
• 서로 게이트 쌍 제거
• 회문 검사

다른 사람? :

답변

30 42 (hex) - > UTF8 encoding - > E3 81 82 (hex), which is above result in binary.

30 42 (hex) - > UTF16 encoding - > 30 42 (hex), which is above result in binary.