UTF-16의 요점은 무엇입니까?

UTF-16의 요점은 무엇입니까?

---

UTF-16 인코딩의 요점을 이해하지 못했습니다. 문자열을 임의 액세스로 처리 할 수 ​​있어야하는 경우 (즉, 코드 포인트가 코드 단위와 동일 함) UTF-16이 여전히 가변 길이이기 때문에 UTF-32가 필요합니다. 이것이 필요하지 않다면 UTF-16은 UTF-8에 비해 엄청난 공간 낭비처럼 보입니다. UTF-8 및 UTF-32에 비해 UTF-16의 장점은 무엇이며 Windows 및 Java에서 기본 인코딩으로 사용하는 이유는 무엇입니까?

---

Windows NT가 설계되었을 때 UTF-16은 존재하지 않았습니다 (NT 3.51은 1993 년에 탄생 한 반면 UTF-16은 1996 년에 Unicode 2.0 표준으로 탄생했습니다.) 대신 UCS-2가 있었는데, 그 당시에는 유니 코드에서 사용 가능한 모든 문자를 보유하기에 충분했기 때문에 1 코드 포인트 = 1 코드 단위 동등성이 실제로 사실이었습니다. 문자열에 가변 길이 논리가 필요하지 않았습니다.

나중에 전체 유니 코드 문자 집합을 지원하기 위해 UTF-16으로 이동했습니다. 그러나 UTF-8 또는 UTF-32로 이동할 수 없습니다. API 인터페이스에서 바이너리 호환성이 깨 졌기 때문입니다.

Java에 관해서는 잘 모르겠습니다. 1995 년에 출시 된 이후로 나는 UTF-16이 (아직 표준화되지 않았더라도) 이미 공중에 있다고 생각하지만, NT 기반 운영 체제와의 호환성이 그들의 선택에 어떤 역할을했을 수도 있다고 생각합니다. Windows API에 대한 모든 호출에 대한 UTF-8 <-> UTF-16 변환으로 인해 약간의 속도가 저하 될 수 있습니다.

---

편집하다

Wikipedia는 Java에서도 동일한 방식으로 진행되었다고 설명합니다. 원래 UCS-2를 지원했지만 J2SE 5.0에서는 UTF-16으로 이동했습니다.

따라서 일반적으로 일부 API / 프레임 워크에서 UTF-16이 사용되는 것은 UCS-2로 시작했기 때문입니다 (문자열 관리 알고리즘의 복잡성을 피하기 위해). 그러나 외부의 코드 포인트를 지원하기 위해 UTF-16으로 이동했기 때문입니다. BMP, 여전히 동일한 코드 단위 크기를 유지합니다.

---

UTF-8보다 UTF-16의 장점을 나타내는 응답은 이전 버전과의 호환성 응답을 제외하고는 의미가 없습니다.

글쎄, 내 의견에는 두 가지주의 사항이 있습니다.

Erik은 "UTF-16은 단일 단위로 전체 BMP를 다룹니다. 따라서 BMP 외부의 희귀 문자가 필요하지 않으면 UTF-16은 사실상 문자 당 2 바이트입니다."

경고 1)

응용 프로그램에 BMP 외부의 문자가 필요하지 않으며 함께 사용하기 위해 작성한 라이브러리 코드가 BMP 외부의 문자가 필요한 응용 프로그램과 함께 사용되지 않는다고 확신 할 수있는 경우 다음을 사용할 수 있습니다. UTF-16이며 모든 문자의 길이가 정확히 2 바이트라는 암시 적 가정을 만드는 코드를 작성합니다.

그것은 매우 위험 해 보입니다 (실제로는 어리석은).

코드에서 모든 UTF-16 문자 길이가 2 바이트라고 가정하고 프로그램이 BMP 외부에 단일 문자가있는 응용 프로그램 또는 라이브러리와 상호 작용하면 코드가 손상됩니다. UTF-16을 검사하거나 조작하는 코드는 2 바이트 이상이 필요한 UTF-16 문자의 경우를 처리하도록 작성되어야합니다. 따라서 나는이 경고를 "거절"합니다.

UTF-16은 UTF-8보다 코딩하기가 더 간단하지 않습니다 (두 코드 모두 가변 길이 문자를 처리해야 함).

경고 2)

UTF-16은 적절하게 작성된다면 어떤 상황에서는 계산적으로 더 효율적일 수 있습니다.

다음과 같이 : 특정 긴 문자열이 거의 수정되지 않지만 종종 검사된다고 가정합니다 (또는 한 번 빌드 된 후에 수정 하지 않는 것이 좋습니다. 즉, 수정할 수 없는 문자열을 만드는 문자열 작성기). 문자열에 "고정 길이"문자 만 포함되어 있는지 여부를 나타내는 플래그가 각 문자열에 대해 설정 될 수 있습니다 (즉, 길이가 정확히 2 바이트가 아닌 문자는 포함하지 않음). 플래그가 참인 문자열은 고정 길이 (2 바이트) 문자를 가정하는 최적화 된 코드로 검사 할 수 있습니다.

공간 효율성은 어떻습니까?

UTF-16은 UTF-8보다 인코딩하는 데 더 적은 바이트가 필요한 A) 문자에 대해 분명히 더 효율적입니다.

UTF-8은 UTF-8이 UTF-16보다 인코딩하는 데 더 적은 바이트를 필요로하는 B) 문자에 대해 분명히 더 효율적입니다.

매우 "특화된"텍스트를 제외하고는 count (B)가 count (A)를 훨씬 초과 할 가능성이 높습니다.

---

UTF-16은 단일 단위로 전체 BMP 를 다룹니다. 따라서 BMP 외부의 희귀 문자가 필요하지 않는 한 UTF-16은 사실상 문자 당 2 바이트입니다. UTF-32는 더 많은 공간을 차지하고 UTF-8에는 가변 길이 지원이 필요합니다.

---

UTF16은 일반적으로 멀티 바이트 문자 집합에 대한 직접 매핑, 즉 원래 0-0xFFFF 할당 문자에 대한 직접 매핑으로 사용됩니다.

이것은 당신에게 두 세계의 장점을 제공합니다. 당신은 고정 된 문자 크기를 가지고 있지만 누구나 사용할 가능성이있는 모든 문자를 인쇄 할 수 있습니다 (정통 Klingon 종교 스크립트는 제외).

---

UTF-16을 사용하면 모든 기본 다국어 평면 (BMP)을 단일 코드 단위로 나타낼 수 있습니다. U + FFFF를 넘어서는 유니 코드 코드 포인트는 서로 게이트 쌍으로 표시됩니다.

흥미로운 점은 Java 및 Windows (및 UTF-16을 사용하는 기타 시스템)가 모두 유니 코드 코드 포인트 수준이 아닌 코드 단위 수준에서 작동한다는 것입니다. 따라서 단일 문자 U + 1D122 (MUSICAL SYMBOL F CLEF)로 구성된 문자열은 Java에서 "\ ud824 \ udd22"및 "\ud824\udd22".length() == 2(아님 1) 으로 인코딩됩니다 . 그래서 일종의 해킹이지만 캐릭터가 가변 길이가 아니라는 것이 밝혀졌습니다.

UTF-8에 비해 UTF-16의 장점은 동일한 해킹이 UTF-8과 함께 사용되면 너무 많이 포기한다는 것입니다.

참고 URL : https://stackoverflow.com/questions/5292150/whats-the-point-of-utf-16