지난 달, 나는 유니 코드 문자 세트와 JavaScript 언어의 지원을 자세히 설명하는 공유를 만들었습니다. 다음은 이번에 공유 된 연설입니다.
1. 유니 코드 란 무엇입니까?
유니 코드는 매우 간단한 아이디어에서 비롯되었습니다. 컬렉션에 세계의 모든 문자를 포함시키는 것입니다. 컴퓨터 가이 문자 세트를 지원하는 한 모든 문자를 표시 할 수 있으며 다시는 코드가 없습니다.
0에서 시작하여 "코드 포인트"라고하는 각 기호에 대해 숫자를 지정합니다. 예를 들어, 코드 포인트 0의 기호는 NULL입니다 (모든 이진 비트가 0임을 나타냅니다).
다음과 같이 코드를 복사하십시오. u+0000 = null
위의 공식에서, u+는 바로 다음 16 진수가 유니 코드의 코드 지점임을 의미합니다.
현재 Unicode의 최신 버전은 버전 7.0이며 총 109,449 개의 기호가 있으며 그 중 74,500 명이 중국어, 일본 및 한국 문자에 포함되어 있습니다. 세계의 기존 상징의 3 분의 2 이상이 동아시아 캐릭터에서 나온 것으로 거의 믿어 질 수 있습니다. 예를 들어, 중국어 "좋은"코드 포인트는 16 진수 597d입니다.
다음과 같이 코드를 복사하십시오. u+597d = ok
기호가 너무 많으면 유니 코드는 한 번에 정의되지 않고 파티션 정의입니다. 각 지역은 비행기라고 불리는 65,536 (216) 문자를 저장할 수 있습니다. 현재 총 17 (25) 평면이 있으며, 이는 전체 유니 코드 문자 세트의 크기가 이제 221임을 의미합니다.
처음 65536 문자 비트를 기본 평면 (약어 BMP)이라고하며 코드 포인트는 0에서 216-1입니다. 16 진수로 작성된 것은 U+0000에서 U+FFFF까지입니다. 유니 코드가 정의하고 게시하는 첫 번째 평면 인이 평면에 가장 일반적인 문자가 모두 배치됩니다.
나머지 문자는 보조 평면 (약어 SMP)에 배치되며 코드 포인트는 U+010000에서 U+10FFFF까지 다양합니다.
2. UTF-32 및 UTF-8
유니 코드는 각 문자의 코드 포인트 만 지정합니다. 인코딩 방법을 포함하는이 코드 포인트를 나타내는 데 사용되는 바이트 순서의 종류.
가장 직관적 인 인코딩 방법은 각 코드 포인트가 4 바이트로 표시되고 바이트 컨텐츠는 코드 포인트에 하나씩 해당한다는 것입니다. 이 인코딩 방법을 UTF-32라고합니다. 예를 들어, 코드 포인트 0은 4 바이트의 0으로 표시되고 코드 포인트 597D는 앞쪽에 2 바이트가 추가됩니다.
코드를 다음과 같이 복사하십시오. u+0000 = 0x0000 0000u+597d = 0x0000 597d
UTF-32의 장점은 전환 규칙이 간단하고 직관적이며 검색 효율이 높다는 것입니다. 단점은 공간이 낭비되며 동일한 내용의 영어 텍스트는 ASCII 인코딩보다 4 배 더 크다는 것입니다. 이 단점은 치명적이며 실제로이 인코딩 방법을 사용하지 않습니다. HTML 5 표준은 웹 페이지가 UTF-32로 인코딩되어서는 안된다고 명시 적으로 규정합니다.
사람들이 실제로 필요한 것은 우주 절약 코딩 방법으로 UTF-8의 탄생으로 이어졌습니다. UTF-8은 가변 길이 인코딩 방법이며, 문자 길이는 1 바이트 ~ 4 바이트입니다. 일반적으로 사용되는 문자가 많을수록 바이트가 짧습니다. 처음 128자는 1 바이트로 표시되며 ASCII 코드와 정확히 동일합니다.
번호 범위 바이트 0x0000 -0x007f10x0080-0x07ff20x0800-0xfff30x010000-0x10ffff4
UTF-8의 우주 절약 기능으로 인해 인터넷에서 가장 일반적인 웹 인코딩이되었습니다. 그러나 오늘날의 주제와는 거의 관련이 없으므로 들어 가지 않을 것입니다. 특정 트랜스 코딩 방법은 "문자 인코딩 노트"를 참조하십시오.
III. UTF-16 소개
UTF-16 인코딩은 UTF-32와 UTF-8 사이이며 고정 길이와 가변 길이의 두 인코딩 방법의 특성을 결합합니다.
인코딩 규칙은 간단합니다. 기본 평면의 문자는 2 바이트를 차지하고 보조 평면의 문자는 4 바이트를 차지합니다. 즉, UTF-16의 인코딩 길이는 2 바이트 (U+0000 ~ U+FFFF) 또는 4 바이트 (U+010000 ~ U+10FFFF)입니다.
따라서 질문이 있습니다. 두 바이트를 만나면 어떻게 문자 자체라는 것을 어떻게 알 수 있습니까? 아니면 다른 두 바이트와 해석해야합니까?
매우 영리하고 의도적인지 모르겠습니다. 기본 평면에서 U+D800에서 U+DFFF까지의 빈 세그먼트, 즉 이러한 코드 포인트는 문자에 해당하지 않습니다. 따라서이 빈 세그먼트는 보조 평면의 문자를 매핑하는 데 사용될 수 있습니다.
구체적으로, 보조 평면에는 220 개의 문자 비트가 있으며, 이는 이들 문자에 최소 20 개의 이진 비트가 필요하다는 것을 의미합니다. UTF-16은이 20 비트를 반으로 나눕니다. 처음 10 비트는 U+D800에서 U+DBFF (공간 크기 210)로 맵핑되며, 이는 높은 비트 (H)라고하며, 마지막 10 비트는 U+DC00에서 U+DFFF (공간 크기 210)로 매핑되며, 이는 낮은 비트 (L)라고합니다. 이는 보조 평면의 캐릭터가 문자 표현의 두 기본 평면으로 나뉘어져 있음을 의미합니다.
따라서 두 바이트를 만나고 코드 포인트가 u+d800과 u+dbff 사이에 있음을 알게되면 두 바이트에 따른 코드 포인트가 u+dc00과 u+dfff 사이에 있어야한다고 결론을 내릴 수 있습니다. 이 4 바이트는 함께 해석해야합니다.
IV. UTF-16 트랜스 코딩 공식
유니 코드 코드를 UTF-16으로 변환 할 때, 먼저 이것이 기본 플랫 문자인지 보조 플랫 문자인지를 구별하십시오. 전자 인 경우 코드 포인트를 해당 16 진 양식으로 직접 변환하고 길이는 두 바이트의 길이입니다.
다음과 같이 코드를 복사하십시오. u+597d = 0x597d
보조 플랫 문자 인 경우 유니 코드 버전 3.0은 트랜스 코딩 공식을 제공합니다.
코드 코드를 다음과 같이 복사하십시오.
캐릭터를 예를 들어, 코드 포인트 U+1D306을 가진 보조 평면 문자입니다. UTF-16으로 변환하는 계산 프로세스는 다음과 같습니다.
코드 코드를 다음과 같이 복사하십시오.
따라서 문자의 UTF-16 인코딩은 0xD834 DF06이며 길이는 4 바이트입니다.
5. JavaScript에서 어떤 인코딩이 사용됩니까?
JavaScript 언어는 유니 코드 문자 세트를 사용하지만 하나의 인코딩 방법 만 지원합니다.
이 인코딩은 UTF-16 또는 UTF-8, 또는 UTF-32가 아닙니다. JavaScript는 위의 인코딩 방법을 사용하지 않습니다.
JavaScript는 UCS-2를 사용합니다!
VI. UCS-2 인코딩
UCS-2가 갑자기 나타난 이유는 무엇입니까? 이것은 약간의 역사가 필요합니다.
인터넷이 아직 나타나지 않은 시대에는 통일 된 캐릭터 세트를 만들고 싶어하는 두 팀이있었습니다. 하나는 1989 년에 설립 된 유니 코드 팀이고, 다른 하나는 1988 년에 설립 된 초기 UCS 팀입니다. 그들이 서로의 존재를 발견했을 때, 그들은 신속하게 계약에 도달했습니다. 세계에서 두 개의 통합 캐릭터 세트가 필요하지 않습니다.
1991 년 10 월, 두 팀은 캐릭터 세트를 병합하기로 결정했습니다. 다시 말해, 유니 코드 인 지금부터 하나의 문자 세트 만 릴리스되며 이전에 릴리스 된 문자 세트가 수정되며 UC의 코드 포인트는 유니 코드와 정확히 동일합니다.
당시 실제 상황은 UCS 개발 진행이 유니 코드보다 빠르다는 것입니다. 1990 년 초, 첫 번째 인코딩 방법 UCS-2가 코드 포인트가있는 문자를 나타 내기 위해 2 바이트를 사용하여 발표되었습니다. (당시 기본 평면이었던 평면은 단 하나 였으므로 2 바이트가 충분했습니다.) UTF-16 인코딩은 1996 년 7 월까지 발표되지 않았으며 UCS-2의 슈퍼 세트, 즉 UCS-2에 의해 인코딩되었으며, 보조 평면 문자는 4 바이테 대표 방법을 정의했습니다.
간단히 말해서,이 둘 사이의 관계는 UTF-16이 UCS-2를 대체하거나 UCS-2가 UTF-16에 통합된다는 것입니다. 따라서 이제 UCS-2는 UTF-16 만 있습니다.
7. JavaScript의 출생 배경
그렇다면 왜 JavaScript가 더 고급 UTF-16을 선택하지 않고 이미 쓸모없는 UCS-2를 사용합니까?
대답은 매우 간단합니다. 원하지 않는 것이 아니라 할 수 없다는 것입니다. JavaScript 언어가 나타 났을 때 UTF-16 인코딩이 없었습니다.
1995 년 5 월, Brendan Eich는 10 일 만에 JavaScript 언어를 설계했습니다. 10 월에는 첫 번째 설명 엔진이 출시되었습니다. 다음 해 11 월, Netscape는 공식적으로 언어 표준을 ECMA에 제출했습니다 (전체 프로세스에 대한 자세한 내용은 "JavaScript의 탄생"참조). UTF-16의 출시 날짜 (1996 년 7 월)를 비교하면 Netscape가 그 당시 다른 선택이 없다는 것을 이해할 것입니다. UCS-2 인코딩 방법 만 사용할 수있었습니다!
8. JavaScript 문자 함수의 한계
JavaScript는 UCS-2 인코딩 만 처리 할 수 있으므로 모든 문자는이 언어의 2 바이트입니다. 4 바이트 인 경우 2 개의 이중 바이트로 취급됩니다. JavaScript의 문자 기능은 이에 의해 영향을받으며 올바른 결과를 반환 할 수 없습니다.
문자를 예로 들면 UTF-16 인코딩은 4 바이트 0xD834 DF06입니다. 문제는 4 바이트 인코딩이 UCS-2에 속하지 않으며 JavaScript는이를 인식하지 못하며이를 두 개의 개별 문자 U+D834 및 U+DF06으로 간주한다는 것입니다. 앞에서 언급 했듯이이 두 코드 포인트는 비어 있으므로 JavaScript는 두 개의 빈 문자로 구성된 문자열로 간주됩니다!
위의 코드는 JavaScript가 문자의 길이가 2라고 생각하고, 얻은 첫 번째 문자는 널 문자이며, 얻은 첫 번째 문자의 코드 포인트는 0xDB34임을 나타냅니다. 이 결과는 정확하지 않습니다!
이 문제를 해결하려면 코드 포인트를 판단한 다음 수동으로 조정해야합니다. 다음은 문자열을 작성하는 올바른 방법입니다.
다음과 같이 코드 코드를 복사하십시오. } else {output.push (문자); }}
위의 코드는 문자열을 가로 지르면 코드 포인트를 판단해야 함을 보여줍니다. 0xD800과 0xDBFF 사이의 간격에 속하는 한 다음 2 바이트와 함께 읽어야합니다.
모든 JavaScript 문자 조작 기능에도 비슷한 문제가 있습니다.
String.prototype.replace () string.prototype.substring () string.prototype.slice () ...
위의 모든 기능은 2 바이트 코드 포인트에만 유효합니다. 4 바이트 코드 포인트를 올바르게 처리하려면 자신의 버전을 하나씩 배포하고 현재 문자의 코드 포인트 범위를 판단해야합니다.
9. ECMAScript 6
JavaScript의 다음 버전 인 ECMAScript 6 (ES6의 짧은 ES6)은 기본적 으로이 문제를 해결하여 유니 코드 지원을 크게 향상 시켰습니다.
(1) 문자를 올바르게 식별합니다
ES6은 4 바이트 코드 포인트를 자동으로 인식 할 수 있습니다. 따라서 줄을 가로 지르는 것이 훨씬 쉽습니다.
다음과 같이 코드를 복사하십시오. for (string of string) {// ...}
그러나 호환성을 유지하기 위해서는 길이 속성이 여전히 원래 동작입니다. 문자열의 올바른 길이를 얻으려면 다음 방법을 사용할 수 있습니다.
다음과 같이 코드를 복사하십시오. array.from (String) .length
(2) 코드 포인트 표현
JavaScript를 사용하면 "Slash + U + Code Points"로 작성된 코드 포인트로 유니 코드 문자를 직접 표시 할 수 있습니다.
다음과 같이 코드를 복사하십시오. 'OK'=== '/u597d'// true
그러나이 표기법은 4 바이트 코드 포인트에 대해 유효하지 않습니다. ES6 은이 문제를 해결하고 코드 포인트가 곱슬 괄호 안에 배치되는 한 올바르게 식별 할 수 있습니다.
(3) 문자열 처리 기능
ES6은 4 바이트 코드 포인트를 구체적으로 다루는 몇 가지 새로운 기능을 추가했습니다.
string.fromCodePoint () : 유니 코드 코드 포인트 string.prototype.codepointat ()에서 해당 문자를 반환합니다.
(4) 정규 표현
ES6은 4 바이트 코드 포인트를 일반 표현식에 추가 할 수있는 U 수정자를 제공합니다.
(5) 유니 코드 정규화
일부 문자에는 글자 외에 추가 기호가 있습니다. 예를 들어, 중국 Pinyin에서 문자의 톤은 추가 기호입니다. 톤 기호는 많은 유럽 언어에 매우 중요합니다.
유니 코드는 두 가지 표현 방법을 제공합니다. 하나는 추가 기호를 가진 단일 문자입니다. 즉, 코드 포인트는 ǒ의 코드 포인트와 같은 문자를 나타냅니다. 다른 하나는 추가 기호를 코드 포인트로 사용하여 주 문자와 함께 표시하는 것입니다. 즉, 두 코드 포인트는 O (u+004f)+ˇ (u+030c)로 쓸 수있는 문자를 나타냅니다.
코드 사본은 다음과 같습니다.
// 메소드 1
'/u01d1'
// 'ǒ'
// 방법 2
'/u004f/u030c'
// 'ǒ'
이 두 가지 표현 방법은 비전과 의미론에서 정확히 동일하며 동등한 상황으로 취급되어야합니다. 그러나 JavaScript는 말할 수 없습니다.
코드 사본은 다음과 같습니다.
'/u01d1'=== '/u004f/u030c'
//거짓
ES6은 "유니 코드 정규화"를 허용하여 두 가지 메소드를 동일한 순서로 변환 할 수있는 정규화 방법을 제공합니다.
다음과 같이 코드를 복사하십시오.
ES6에 대한 자세한 내용은 "ECMAScript 6의 엔터테인먼트"를 참조하십시오.
==================================