HTML 및 javascript_javascript 기술에서 자주 발생하는 코딩 문제

일상적인 프론트엔드 개발 작업에서는 HTML, JavaScript, CSS 등의 언어를 다루는 경우가 많습니다. 실제 언어와 마찬가지로 컴퓨터 언어에도 알파벳, 문법, 어휘, 코딩 방법 등이 있습니다.

여기에서는 프론트엔드 HTML과 JavaScript 일상 업무에서 자주 접하게 되는 코딩 문제에 대해 간략하게 이야기하겠습니다.
컴퓨터에서 우리가 저장하는 정보는 바이너리 코드로 표시됩니다. 화면에 표시되는 영어, 한자 등의 기호와 저장에 사용되는 바이너리 코드 간의 상호 변환이 인코딩입니다.

설명해야 할 두 가지 기본 개념은 문자 집합과 문자 인코딩입니다.

문자 집합, 특정 기호와 특정 숫자 간의 매핑 관계를 표로 나타낸 문자 집합, 즉, 107이 koubei의 'a'이고 21475가 Koubei의 "口"라고 결정합니다. 이 숫자와 문자의 매핑 테이블을 통해 서로 다른 테이블은 서로 다른 매핑 관계를 갖습니다. 숫자의 이진 표현을 특정 문자로 변환할 수 있습니다.
문자 인코딩, 인코딩 방법. 예를 들어, "입"이어야 하는 숫자 21475의 경우 u5k3e3을 사용하여 표현해야 합니까, 아니면 口를 사용하여 표현해야 합니까? 이는 문자 인코딩에 의해 결정됩니다.

미국에서 일반적으로 사용되는 문자인 'koubei.com'과 같은 문자열에 대해 0-127까지의 128개 숫자를 사용하여 전체 이름이 미국 표준 정보 교환 코드인 ASCII라는 문자 집합을 개발했습니다. , (2의 7승, 0×00-0×7f)은 123abc 등 일반적으로 사용되는 128개의 문자를 나타냅니다. 총 7비트가 있으며, 첫 번째 비트는 부호 비트로, 음수를 표현하기 위해 1의 보수를 보완하는 데 사용됩니다. 총 8비트가 바이트를 구성합니다. 그 당시 미국인들은 좀 인색했거든요. 처음부터 바이트를 16비트나 32비트로 설계했다면 세상에 문제가 더 적었을 텐데, 그 당시에는 8비트면 충분하다고 생각했을 겁니다. 128개의 다양한 문자를 표현하세요!

컴퓨터는 미국인이 발명했기 때문에 문제를 해결하고 그들이 사용하는 모든 기호를 인코딩해 사용하는 것이 꽤 재미있습니다. 그런데 컴퓨터가 국제화되기 시작하면서 문제가 생겼습니다. 중국을 예로 들면, 수만 개의 한자가 있습니다.

기존 8비트 1바이트 시스템이 기반이고 16비트 등으로 파괴되거나 변경될 수 없습니다. 그렇지 않으면 변경 사항이 너무 커져서 여러 ASCII 문자를 사용하는 다른 경로만 선택할 수 있습니다. . 또 다른 문자, 즉 MBCS(Multi-Byte Character System, 멀티바이트 문자 시스템)를 나타냅니다.
이 MBCS 개념을 사용하면 더 많은 문자를 표현할 수 있습니다. 예를 들어 2개의 ASCII 문자를 사용하면 이론상으로는 65536개의 문자가 2의 16승이 됩니다. 하지만 이러한 코드는 문자에 어떻게 할당됩니까? 예를 들어 Koubei에서 "口"의 유니코드 인코딩은 21475입니다. 누가 결정했나요? 방금 소개한 문자셋인 문자셋입니다. ascii는 가장 기본적인 문자 세트이며, 이에 더해 gb2312, big5 및 기타 중국어 간체 및 번체에 대한 MBCS 문자 세트와 유사한 문자 세트가 있습니다. 결국 유니코드 컨소시엄이라는 단체에서는 모든 문자를 포함하는 문자 집합(UCS, Universal Character Set)과 해당 인코딩 방식에 대한 표준, 즉 유니코드를 만들기로 결정했습니다. 1991년부터 유니코드 국제 표준의 첫 번째 버전인 ISBN 0-321-18578-1을 발표했으며, 국제표준화기구(ISO)도 이 표준인 ISO/IEC 10646: 범용 문자 집합의 사용자 정의에 참여했습니다. 간단히 말해서, 유니코드는 기본적으로 지구상에 존재하는 모든 기호를 포괄하는 문자 표준으로, 현재 점점 더 광범위하게 사용되고 있습니다. ECMA 표준에서도 자바스크립트 언어의 내부 문자가 유니코드 표준을 사용하도록 규정하고 있습니다. 변수명, 함수명 등은 중국어로 가능합니다!)

중국 개발자의 경우 gbk, gb2312 및 utf-8 간의 변환과 같은 더 많은 문제에 직면할 수 있습니다. 엄밀히 말하면 이 문장은 그다지 정확하지 않습니다. gbk와 gb2312는 문자 집합(charset)이고, utf-8은 유니코드 표준의 UCS 문자 집합의 인코딩 방법입니다. 문자가 사용됩니다. 컬렉션의 웹 페이지는 주로 UTF-8로 인코딩되므로 사람들이 병치하는 경우가 종종 있는데 이는 실제로 부정확합니다.

유니코드에서는 적어도 인류 문명이 외계인을 만나기 전까지는 이것이 마스터 키이므로 모두가 사용해야 합니다. 현재 가장 널리 사용되는 유니코드 인코딩 방법은 UTF-8(8비트 UCS/유니코드 변환 형식)이며, 여기에는 몇 가지 특히 좋은 기능이 있습니다.

전 세계적으로 보편적으로 사용되는 인코딩된 UCS 문자 집합
ASCII와 호환되는 가변 길이 문자 인코딩 방법입니다
두 번째 점은 추가 저장 공간을 추가하지 않고도 이전에 순수 ASCII 인코딩을 사용했던 시스템을 호환 가능하게 한다는 점입니다. 각 문자는 2바이트로 구성되며, ASCII 문자가 차지하는 저장 공간은 두 배가 됩니다.

UTF-8을 명확하게 설명하려면 테이블을 소개하는 것이 더 편리합니다.

U-00000000 – U-0000007F: 0xxxxxxx
U-00000080 – U-000007FF: 110xxxxx 10xxxxxx
U-00000800 – U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 – U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 – U-03FFFFFF: 1 11110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U- 04000000 – U-7FFFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

이 테이블을 이해하려면 처음 두 줄만 보면 됩니다

U-00000000 – U-0000007F:
0xxxxxxx 첫 번째 줄은 다음과 같습니다. 즉, utf- 8로 인코딩된 바이트의 바이너리 코드는 0xxxxxx이며, 이는 0으로 시작합니다. 즉, 10진수로는 0-127 사이입니다. 그러면 문자를 나타내는 단일 바이트이며 ASCII 코드와 완전히 동일한 의미를 갖습니다. 다른 모든 utf8 인코딩 바이너리 값은 1, 1xxxxxxx로 시작하고 127보다 크며 기호를 표시하려면 최소 2바이트가 필요합니다. 따라서 바이트의 첫 번째 비트는 문자가 ASCII 코드인지 여부를 나타내는 스위치입니다. 이것은 방금 언급한 호환성입니다. 영어 정의에 따르면 utf8 인코딩의 두 가지 속성이 있습니다.

UCS 문자 U 0000 ~ U 007F(ASCII)는 단순히 바이트 0×00 ~ 0× 7F( ASCII 호환성) 이는 7비트 ASCII 문자만 포함하는 파일과 문자열이 ASCII와 UTF-8 모두에서 동일한 인코딩을 갖는다는 것을 의미합니다.
모든 UCS 문자 >U 007F는 각각 여러 바이트의 시퀀스로 인코딩됩니다. 그 중 가장 중요한 비트가 설정되어 있습니다. 따라서 ASCII 바이트(0×00-0×7F)는 다른 문자의 일부로 나타날 수 없습니다.

그 다음 두 번째 줄을 살펴보겠습니다.

U-00000080 – U-000007FF: 110xxxxx 10xxxxxx
첫 번째 바이트를 먼저 보세요: 110xxxxx, 그 의미는 내가 ASCII 코드가 아니라는 것입니다(첫 번째 비트가 0이 아니기 때문에). 나는 첫 번째 바이트입니다. 멀티바이트 문자(두 번째 비트는 1) 중 내가 참여하고 있는 문자는 2바이트(세 번째 비트는 0)로 구성되며, 네 번째 비트부터 문자 정보가 저장되는 곳이다.
두 번째 바이트를 보세요: 10xxxxxx, 그 의미는 다음과 같습니다. 나는 ASCII 코드가 아닙니다(첫 번째 비트가 0이 아니기 때문입니다). 나는 다중 바이트 문자의 첫 번째 바이트가 아닙니다(두 번째 비트는 0입니다). ), 세 번째 비트부터 문자 정보가 저장되는 위치이다.

이 예를 통해 UTF-8 인코딩 방법에서 긴 연속 이진 바이트 코드에서 기호는 2~6바이트로 표시될 수 있으므로 A 바이트를 사용하는 것과 비교할 때 기호의 ASCII 코드 두 가지 추가 정보를 저장할 공간이 필요합니다. 첫째, 기호의 시작 위치, 즉 생물학적 용어로 단백질 번역 중 시작 코돈 AUG입니다. 이 기호에 사용되는 바이트(사실 각 기호에 시작 문자가 있는 경우 이 길이를 제공할 필요는 없지만 일부 바이트가 손실될 때 길이 정보를 제공하면 내결함성이 향상됩니다.) 해결 방법은 다음과 같습니다. 바이트의 두 번째 비트가 1인지 여부를 사용하여 해당 바이트가 문자의 시작 바이트인지 여부를 나타냅니다(바이트의 첫 번째 비트가 방금 사용되었기 때문에 0은 ASCII 코드를 의미하고 1은 비ASCII를 의미함). 즉, 멀티바이트 기호의 첫 번째 바이트는 192에서 255 사이의 이진수인 11xxxxxx여야 합니다. 다음으로 세 번째 비트부터 길이 정보가 제공됩니다. 세 번째 비트는 0입니다. 즉, 세 번째 비트부터 시작하여 1이 추가될 때마다 해당 문자가 차지하는 바이트 수가 1씩 증가합니다. . UTF-8은 최대 6바이트의 문자를 정의합니다. 이는 110xxxxx와 같은 2바이트 시작 문자보다 4개의 1이 더 필요하므로 이 시작 문자는 위 표에 표시된 대로 1111110x입니다.
영어의 표준 정의를 다시 보면 동일한 의미를 나타냅니다.

ASCII가 아닌 문자를 나타내는 멀티바이트 시퀀스의 첫 번째 바이트는 항상 0xC0에서 0xFD 범위에 있으며 이는 어떻게 이 문자에 대해 많은 바이트가 뒤따릅니다. 멀티바이트 시퀀스의 모든 추가 바이트는 0×80에서 0xBF 범위에 있습니다. 이를 통해 쉽게 재동기화할 수 있으며 인코딩이 상태 비저장되고 누락된 바이트에 대해 견고해집니다. 즉, charset 문자 집합의 실제 디지털 정보)는 바이너리 형식으로 위 테이블의 'x'에 순서대로 직접 배치됩니다. 우리 중국 프로그래머들이 가장 많이 접하는 한자를 살펴보겠습니다. 인코딩 범위는 U-00000800 – U-0000FFFF 사이입니다. 위의 표에서 이 범위에 대한 UTF-8 인코딩은 3바이트로 표시된다는 것을 알 수 있습니다. (이것이 utf-8로 인코딩된 한자가 문자당 2바이트를 차지하는 EUC-CN으로 인코딩된 gb2312 문자 세트 한자보다 더 많은 저장 공간을 사용하는 이유입니다.) 또는 입소문의 "口"라는 단어를 사용합니다. 예를 들어 숫자 of Mouth in Unicode는 다음과 같습니다.
口: 21475 == 0×53e3 == Binary 101001111100011

javascript에서 이 코드를 실행합니다(firebug 콘솔을 사용하거나 HTML을 편집하고 사이에 다음 코드를 삽입합니다). 한 쌍의 스크립트 태그):

alert('u53e3′); // '구'를 얻습니다.
alert(escape('구')) // '%u53E3'을 얻습니다
alert (String.fromCharCode('21475′)); // '구'를 얻습니다
alert('구'.charCodeAt(0)) // '21475'를 얻습니다
경고 (encodeURI('구')) ; //get '口'

보시다시피 문자열 리터럴은 u 16진수 유니코드 코드 형식으로 '口' 문자를 가져올 수 있으며 fromCharCode 메서드는 10을 허용합니다. '口' 문자를 얻습니다.

두 번째 경고는 비표준 유니코드 인코딩이며 URI의 Percent 인코딩의 일부인 '%u7545'를 받았습니다. 그러나 이 사용 방법은 W3C에서 공식적으로 거부되었으며 RFC 표준, ECMA에는 포함되지 않습니다. -262 표준에서는 이러한 탈출 동작을 규정하고 있으며 일시적인 것으로 추정됩니다.
더 흥미로운 것은 5번째 알림에서 얻은 '입'입니다. 어떻게 얻었나요?

URI에서 흔히 사용되는 Percent 인코딩으로 RFC 3986 표준에 명시되어 있습니다.