UTF-8, UTF-16 및 UTF-32의 차이점은 무엇입니까?

나는 그들이 모두 유니 코드를 저장하고 각각 다른 바이트 수를 사용하여 문자를 나타냅니다. 다른 것을 선택하면 이점이 있습니까?

UTF-8은 ASCII 블록과 같은 8 비트로 인코딩하기 때문에 ASCII 문자가 텍스트 블록에서 대부분의 문자를 나타내는 경우 이점이 있습니다. ASCII 문자 만 포함하는 UTF-8 파일은 ASCII 파일과 동일한 인코딩을 갖는 것이 유리합니다.

UTF-16은 주로 문자 당 2 바이트를 사용하므로 ASCII가 우세하지 않은 경우에 더 좋습니다. UTF-8은 대부분의 문자에 대해 UTF-16이 2 바이트에 불과한 상위 문자에 3 바이트 이상을 사용하기 시작합니다.

UTF-32는 가능한 모든 문자를 4 바이트로 처리합니다. 이것은 꽤 부풀어 오른다. 나는 그것을 사용하는 것의 이점을 생각할 수 없다.

한마디로 :

• UTF-8 : 가변 폭 인코딩, 하위 버전과 ASCII 호환. ASCII 문자 (U + 0000 ~ U + 007F)는 1 바이트, 코드 포인트 U + 0080 ~ U + 07FF는 2 바이트, 코드 포인트 U + 0800 ~ U + FFFF는 3 바이트, 코드 포인트 U + 10000 ~ U + 10FFFF 4 바이트를 사용하십시오. 영어 텍스트에는 좋지만 아시아 텍스트에는 좋지 않습니다.
• UTF-16 : 가변 폭 인코딩. 코드 포인트 U + 0000 ~ U + FFFF는 2 바이트, 코드 포인트 U + 10000 ~ U + 10FFFF는 4 바이트를 사용합니다. 영어 텍스트에는 좋지 않으며 아시아 텍스트에는 좋습니다.
• UTF-32 : 고정 폭 인코딩. 모든 코드 포인트는 4 바이트를 사용합니다. 거대한 메모리 호그이지만 빠르게 작동합니다. 드물게 사용되는.

길게 : Wikipedia : UTF-8 , UTF-16 및 UTF-32를 참조하십시오 .

• UTF-8은 1-4 바이트의 변수 입니다.

• UTF-16은 변수 2 또는 4 바이트입니다.

• UTF-32는 4 바이트 로 고정되어 있습니다.

참고 : UTF-8은 최신 규칙에 따라 1-6 바이트를 사용할 수 있습니다. https://lists.gnu.org/archive/html/help-flex/2005-01/msg00030.html

유니 코드는 하나의 거대한 문자 집합을 정의하여 하나의 고유 한 정수 값을 모든 그래픽 심볼에 할당합니다 (대부분 단순화 된 것이지만 실제로는 아니지만이 질문의 목적을 위해 충분히 가깝습니다). UTF-8 / 16 / 32는 이것을 인코딩하는 다른 방법입니다.

간단히 말해 UTF-32는 각 문자에 대해 32 비트 값을 사용합니다. 따라서 모든 문자에 고정 너비 코드를 사용할 수 있습니다.

UTF-16은 기본적으로 16 비트를 사용하지만 65k 가능한 문자 만 제공합니다. 따라서 일부 문자는 16 비트 값 쌍을 사용합니다.

UTF-8은 기본적으로 8 비트 값을 사용합니다. 즉, 127 개의 첫 번째 값은 고정 너비 1 바이트 문자입니다 (가장 큰 비트는 이것이 멀티 바이트 시퀀스의 시작임을 나타내는 데 사용됩니다. 실제 문자 값에 대한 비트). 다른 모든 문자는 최대 4 바이트의 시퀀스로 인코딩됩니다 (메모리가 제공되는 경우).

그리고 그것은 우리를 이점으로 이끌어줍니다. 모든 ASCII 문자는 UTF-8과 직접 호환되므로 레거시 앱을 업그레이드하는 경우 UTF-8이 일반적이고 명백한 선택입니다. 거의 모든 경우에 가장 적은 메모리를 사용합니다. 반면에 문자의 너비에 대해서는 보장 할 수 없습니다. 1, 2, 3 또는 4 자 너비 일 수 있으므로 문자열 조작이 어렵습니다.

UTF-32은 메모리를 가장 많이 (각 문자 폭 고정 된 4 바이트)를 사용하지만, 다른 한편으로는, 당신은, 반대 알고 문자열 조작이 훨씬 간단하게, 그래서 모든 문자가이 정확한 길이를 가지고있다. 문자열의 길이를 바이트 단위로 간단히 문자열의 문자 수를 계산할 수 있습니다. UTF-8로는 그렇게 할 수 없습니다.

UTF-16은 타협입니다. 대부분의 문자를 고정 너비 16 비트 값에 맞출 수 있습니다 . 중국어 기호, 음표 또는 기타 문자가없는 한 각 문자의 너비가 16 비트라고 가정 할 수 있습니다. UTF-32보다 적은 메모리를 사용합니다. 그러나 그것은 어떤면에서 "두 세계 중 최악"입니다. 거의 항상 UTF-8보다 많은 메모리를 사용하며 UTF-8 (가변 길이 문자)을 괴롭히는 문제를 피하지는 않습니다.

마지막으로, 플랫폼이 지원하는 것과 함께 진행하는 것이 종종 도움이됩니다. Windows는 내부적으로 UTF-16을 사용하므로 Windows에서는 이것이 명백한 선택입니다.

리눅스는 조금씩 다르지만 일반적으로 유니 코드와 호환되는 모든 것에 UTF-8을 사용합니다.

짧은 대답 : 세 가지 인코딩 모두 동일한 문자 세트를 인코딩 할 수 있지만 각 문자를 다른 바이트 시퀀스로 나타냅니다.

유니 코드 는 표준이며 UTF-x 에 관한 것이며 실제적인 목적을위한 기술적 구현으로 생각할 수 있습니다.

• UTF-8- " 크기 최적화 됨 ": 라틴 문자 기반 데이터 (또는 ASCII)에 가장 적합하며 문자 당 1 바이트 만 필요하지만 크기는 기호에 따라 커집니다 (최악의 경우 문자 당 최대 6 바이트까지 증가 할 수 있음)
• UTF-16- " balance ": 문자 당 최소 2 바이트를 사용하므로 문자 처리를 쉽게하기 위해 크기가 고정 된 기존 주류 언어 세트에 충분합니다 (그러나 크기는 여전히 가변적이며 문자 당 최대 4 바이트까지 증가 할 수 있음) )
• UTF-32- " performance ": 고정 크기 문자 (4 바이트)의 결과로 간단한 알고리즘을 사용할 수 있지만 메모리 단점이 있습니다.

나는 내 blogpost에 간단한 설명을하려고했습니다 .

UTF-32

모든 문자 를 인코딩하려면 32 비트 (4 바이트)가 필요 합니다. 예를 들어,이 체계를 사용하여 "A"문자 코드 포인트를 나타내려면 32 비트 이진수로 65를 작성해야합니다.

00000000 00000000 00000000 01000001 (Big Endian)

자세히 살펴보면 ASCII 체계를 사용할 때 가장 오른쪽에있는 7 비트가 실제로 동일한 비트임을 알 수 있습니다. 그러나 UTF-32는 고정 너비 방식 이므로 세 개의 추가 바이트를 첨부해야합니다. "A"문자 만 포함하는 두 개의 파일이있는 경우 하나는 ASCII로 인코딩되고 다른 하나는 UTF-32로 인코딩되며 크기는 1 바이트 및 4 바이트입니다.

UTF-16

많은 사람들은 UTF-32가 고정 폭 32 비트를 사용하여 코드 포인트를 나타내므로 UTF-16은 고정 폭 16 비트라고 생각합니다. 잘못된!

UTF-16에서 코드 포인트는 16 비트 또는 32 비트로 표시 될 수 있습니다. 따라서이 체계는 가변 길이 인코딩 시스템입니다. UTF-32에 비해 장점은 무엇입니까? 적어도 ASCII의 경우 파일 크기는 원본의 4 배가 아니지만 (아직 두 번) ASCII와 호환되지 않습니다.

7 비트는 "A"문자를 표현하기에 충분하므로 UTF-32와 같이 4 대신 4 바이트를 사용할 수 있습니다. 다음과 같이 보일 것입니다 :

00000000 01000001

UTF-8

UTF-8에서 코드 포인트는 32, 16, 24 또는 8 비트를 사용하여 표현 될 수 있으며 UTF-16 시스템으로서 가변 길이 인코딩 시스템이기도합니다.

마지막으로 ASCII 인코딩 시스템을 사용하여 "A"를 나타내는 것과 같은 방식으로 "A"를 나타낼 수 있습니다.

01001101

UTF-16이 실제로 UTF-8보다 나은 작은 예 :

중국어 문자 "語"를 고려하십시오. UTF-8 인코딩은 다음과 같습니다.

11101000 10101010 10011110

UTF-16 인코딩은 더 짧은 반면 :

10001010 10011110

표현과 해석 방법을 이해하려면 원래 게시물을 방문하십시오.

UTF-8

• 바이트 순서의 개념이 없다
• 문자 당 1-4 바이트 사용
• ASCII는 인코딩의 호환 가능한 하위 집합입니다
• 완전히 자체 동기화하는 것, 예를 들어 스트림의 어느 곳에서나 삭제 된 바이트는 최대 하나의 문자 만 손상됨
• 거의 모든 유럽 언어가 문자 당 2 바이트 이하로 인코딩됩니다.

UTF-16

• 알려진 바이트 순서로 구문 분석되거나 바이트 순서 표시 (BOM)를 읽어야합니다.
• 문자 당 2 또는 4 바이트를 사용합니다.

UTF-32

• 모든 문자는 4 바이트입니다
• 알려진 바이트 순서로 구문 분석되거나 바이트 순서 표시 (BOM)를 읽어야합니다.

UTF-8은 대부분의 문자가 CJK (중국어, 일본어 및 한국어) 문자 공간이 아닌 경우 가장 공간 효율적입니다.

UTF-32는 바이트 배열로의 문자 오프셋을 통한 임의 액세스에 가장 적합합니다.

MySQL에서 UTF-8과 UTF-16 사이의 데이터베이스 성능을 비교하기 위해 몇 가지 테스트를 수행했습니다.

업데이트 속도

UTF-8

UTF-16

삽입 속도

속도 삭제

UTF-32에서 모든 문자는 32 비트로 코딩됩니다. 장점은 문자열의 길이를 쉽게 계산할 수 있다는 것입니다. 단점은 각 ASCII 문자에 대해 추가 3 바이트를 낭비한다는 것입니다.

UTF-8 문자의 길이는 가변적이며 ASCII 문자는 1 바이트 (8 비트)로 코딩되고 대부분의 서양 특수 문자는 2 바이트 또는 3 바이트 (예 : €는 3 바이트)로 코딩되며보다 이국적인 문자는 차지할 수 있습니다 4 바이트까지 분명한 단점은 우선 순위가 문자열의 길이를 계산할 수 없다는 것입니다. 그러나 UTF-32에 비해 라틴 (영어) 알파벳 텍스트를 코딩하는 데 훨씬 적은 바이트가 필요합니다.

UTF-16도 가변 길이입니다. 문자는 2 바이트 또는 4 바이트로 코딩됩니다. 나는 정말로 요점을 보지 못한다. 가변 길이라는 단점이 있지만 UTF-8만큼 많은 공간을 절약 할 수는 없다는 이점이 있습니다.

이 세 가지 중에서 분명히 UTF-8이 가장 널리 퍼져 있습니다.

개발 환경에 따라 문자열 데이터 유형이 내부에서 어떤 인코딩을 사용할지 선택하지 못할 수도 있습니다.

그러나 데이터를 저장하고 교환하려면 항상 UTF-8을 사용하십시오. 대부분 ASCII 데이터가있는 경우 전송하는 데 가장 적은 양의 데이터를 제공하면서도 모든 것을 인코딩 할 수 있습니다. 최소한의 I / O를 최적화하는 것이 최신 기계를 사용하는 방법입니다.

언급 한 바와 같이, 차이는 주로 기본 변수의 크기이며, 각 경우 더 많은 문자를 표현할 수 있도록 커집니다.

그러나 글꼴, 인코딩 및 사물은 사악하게 복잡하므로 (필요하지 않습니까?)보다 자세하게 채우려면 큰 링크가 필요합니다.

http://www.cs.tut.fi/~jkorpela/chars.html#ascii

모든 것을 이해하지는 않겠지 만 나중에 문제가 발생하지 않으려면 최대한 빨리 배우는 것이 좋습니다.

폴

간단히 말해서 UTF-16 또는 UTF-32를 사용하는 유일한 이유는 영어가 아닌 스크립트와 고대 스크립트를 각각 지원하는 것입니다.

웹 / 프로그래밍 목적에 더 효율적일 때 누군가가 비 UTF-8 인코딩을 선택한 이유가 궁금합니다.

일반적인 오해-접미사 숫자는 해당 기능을 나타내는 것이 아닙니다. UTF-8이 ASCII를 단일 바이트로 처리 할 수 ​​있다는 점에서 모두 완전한 유니 코드를 지원하므로 CPU와 인터넷을 통해 더 효율적이고 덜 손상됩니다.

좋은 읽을 거리 : http://www.personal.psu.edu/ejp10/blogs/gotunicode/2007/10/which_utf_do_i_use.html 및 http://utf8everywhere.org