오늘 우리는 웹사이트와 프로그램에서 형편없는 코드가 어디서 오는지, 어떤 텍스트 인코딩이 존재하는지, 어떤 인코딩을 사용해야 하는지에 대해 이야기하겠습니다. 기본 ASCII뿐만 아니라 확장 버전 CP866, KOI8-R, Windows 1251부터 시작하여 최신 유니코드 컨소시엄 인코딩 UTF 16 및 8로 끝나는 개발 내역을 자세히 살펴보겠습니다 .
어떤 사람들에게는 이 정보가 불필요해 보일 수도 있지만 크롤링 크라코자브르(읽을 수 없는 문자 집합)와 관련하여 내가 얼마나 많은 질문을 받는지 아십니까? 이제 나는 모든 사람에게 이 기사의 텍스트를 참조하고 내 자신의 실수를 찾을 수 있는 기회를 갖게 될 것입니다. 자, 정보를 흡수할 준비를 하고 이야기의 흐름을 따라가도록 노력하세요.
ASCII - 라틴 알파벳의 기본 텍스트 인코딩
텍스트 인코딩의 개발은 IT 산업의 형성과 동시에 이루어졌으며, 이 기간 동안 많은 변화를 겪었습니다. 역사적으로 모든 것은 러시아어 발음이 다소 불협화음인 EBCDIC로 시작하여 라틴 알파벳 문자, 아라비아 숫자 및 문장 부호를 제어 문자로 인코딩할 수 있었습니다. 그러나 여전히 현대 텍스트 인코딩 개발의 출발점은 유명한 ASCII (러시아어로 일반적으로 "질문"으로 발음되는 정보 교환을 위한 미국 표준 코드)로 간주되어야 합니다. 이는 영어권 사용자가 가장 일반적으로 사용하는 라틴 문자, 아라비아 숫자 및 문장 부호 등 처음 128자를 설명합니다. ASCII로 설명된 이러한 128개 문자에는 대괄호, 해시 표시, 별표 등과 같은 일부 서비스 문자도 포함되어 있습니다. 실제로 직접 볼 수 있습니다. 표준이 된 것은 원래 ASCII 버전의 128개 문자이며, 다른 인코딩에서는 확실히 찾을 수 있으며 이 순서로 나타납니다. 그러나 사실 1바이트의 정보를 사용하면 128개가 아니라 최대 256개의 서로 다른 값(2의 8승은 256)을 인코딩할 수 있으므로 Asuka의 기본 버전 이후에는 전체 일련의 확장 ASCII 인코딩이 등장하여 128개의 기본 문자 외에도 국가 인코딩 문자(예: 러시아어)를 사용하여 인코딩할 수도 있습니다. 여기에서는 설명에 사용되는 숫자 체계에 대해 좀 더 이야기해 볼 가치가 있을 것입니다. 첫째, 여러분 모두 알고 있듯이 컴퓨터는 이진법의 숫자, 즉 0과 1(누군가 기관이나 학교에서 배운 경우 "부울 대수학")로만 작동합니다. 1바이트는 8개의 비트로 구성되며 각 비트는 0부터 시작하여 2의 7승까지를 나타냅니다. 이러한 구성에서 0과 1의 가능한 모든 조합이 가능하다는 것을 이해하는 것은 어렵지 않습니다. 256만 가능합니다. 이진수 시스템에서 십진수로 숫자를 변환하는 것은 매우 간단합니다. 두 가지의 거듭제곱과 그 위에 있는 거듭제곱을 더하면 됩니다. 이 예에서 이는 1(2의 0제곱) 더하기 8(2의 3제곱), 더하기 32(2의 5제곱), 더하기 64(6제곱), 더하기 128로 나타납니다. (7승). 합계는 10진수 표기로 233입니다. 보시다시피 모든 것이 매우 간단합니다. 그러나 ASCII 문자가 포함된 표를 자세히 살펴보면 해당 문자가 16진수 인코딩으로 표시되어 있음을 알 수 있습니다. 예를 들어 "별표"는 Aski의 16진수 2A에 해당합니다. 16진수 체계에서는 아라비아 숫자 외에도 A(10을 의미)부터 F(15를 의미)까지의 라틴 문자도 사용된다는 것을 알고 계실 것입니다. 음, 2진수를 16진수로 변환 하려면다음과 같은 간단한 방법을 사용하십시오. 각 정보 바이트는 4비트로 구성된 두 부분으로 나뉩니다. 저것들. 각 1/2바이트에는 16개의 값(2의 4승)만 이진수로 인코딩될 수 있으며 이는 쉽게 16진수로 표시될 수 있습니다. 또한 바이트의 왼쪽 절반에서는 각도를 0부터 다시 계산해야 하며 스크린샷에 표시된 것과는 다릅니다. 결과적으로 E9라는 숫자가 스크린샷에 인코딩되어 있음을 알 수 있습니다. 내 추론 과정과 이 퍼즐에 대한 해결책이 여러분에게 분명해지기를 바랍니다. 자, 이제 실제로 텍스트 인코딩에 대해 계속 이야기해 보겠습니다.
Asuka의 확장 버전 - 의사 그래픽을 사용한 CP866 및 KOI8-R 인코딩
그래서 우리는 모든 최신 인코딩(Windows 1251, 유니코드, UTF 8) 개발의 출발점인 ASCII에 대해 이야기하기 시작했습니다. 처음에는 라틴 알파벳, 아라비아 숫자 등 128자만 포함되어 있었지만 확장 버전에서는 1바이트 정보에 인코딩할 수 있는 256개 값을 모두 사용할 수 있게 되었습니다. 저것들. Aski에 귀하의 언어 문자 기호를 추가하는 것이 가능해졌습니다. 여기서 우리는 텍스트 인코딩이 왜 필요한지 , 그리고 그것이 왜 그렇게 중요한지 다시 한 번 설명할 필요가 있습니다 . 컴퓨터 화면의 문자는 두 가지, 즉 다양한 문자의 벡터 모양(표현) 세트(컴퓨터에 설치된 글꼴이 포함된 파일에 있음)와 해당 문자를 정확하게 끌어낼 수 있는 코드를 기반으로 형성됩니다. 이 벡터 모양 세트(글꼴 파일)에서 올바른 위치에 삽입해야 하는 기호입니다. 벡터 모양은 글꼴 자체가 담당하지만 인코딩은 운영 체제와 여기에 사용된 프로그램이 담당한다는 것은 분명합니다. 저것들. 컴퓨터의 모든 텍스트는 바이트 집합이 되며, 각 바이트는 바로 이 텍스트의 단일 문자를 인코딩합니다. 이 텍스트를 화면에 표시하는 프로그램(텍스트 편집기, 브라우저 등)은 코드를 구문 분석할 때 다음 문자의 인코딩을 읽고 이를 표시하기 위해 연결된 필수 글꼴 파일에서 해당 벡터 형식을 찾습니다. 텍스트 문서. 모든 것이 간단하고 진부합니다. 이는 필요한 문자(예: 국가 알파벳)를 인코딩하려면 두 가지 조건이 충족되어야 함을 의미합니다. 즉, 이 문자의 벡터 형식은 사용된 글꼴이어야 하며 이 문자는 확장 ASCII 인코딩으로 인코딩될 수 있습니다. 1바이트로. 따라서 그러한 옵션이 많이 있습니다. 러시아어 문자를 인코딩하기 위한 확장 Aska에는 여러 종류가 있습니다. 예를 들어 CP866은 원래 러시아 알파벳 문자를 사용할 수 있는 ASCII의 확장 버전이었습니다. 즉, 상단 부분은 바로 위의 스크린샷에 표시된 Aska의 기본 버전(128개의 라틴 문자, 숫자 및 기타 쓰레기)과 완전히 일치하지만 CP866 인코딩이 적용된 테이블의 하단 부분은 다음과 같은 모양을 나타냅니다. 바로 아래의 스크린샷은 또 다른 128자 인코딩을 허용합니다(러시아 문자 및 모든 종류의 의사 그래픽). 오른쪽 열의 숫자는 8로 시작합니다. 0부터 7까지의 숫자는 ASCII의 기본 부분을 나타냅니다(첫 번째 스크린샷 참조). 따라서 CP866의 키릴 문자 "M"은 코드 9C(16진수 시스템에서 9와 해당 행과 숫자 C가 있는 열의 교차점에 위치함)를 가지며 1바이트의 정보로 쓸 수 있습니다. , 그리고 러시아어 문자에 적합한 글꼴이 있는 경우 이 문자는 문제 없이 텍스트에 나타납니다. 이 금액은 어디서 나온 걸까요?CP866의 의사그래픽 ? 요점은 러시아어 텍스트에 대한 이 인코딩이 그래픽 운영 체제가 지금처럼 널리 퍼지지 않았던 얽히고 설킨 시절에 개발되었다는 것입니다. 그리고 Dosa 및 유사한 텍스트 운영 체제에서는 의사 그래픽을 통해 적어도 텍스트 디자인을 다양화할 수 있었기 때문에 CP866과 Asuka 확장 버전 범주의 다른 모든 동료가 풍부합니다. CP866은 IBM에서 배포했지만 이 외에도 러시아어 문자에 대한 여러 인코딩이 개발되었습니다. 예를 들어 KOI8-R은 동일한 유형(확장 ASCII)에 속할 수 있습니다 . 작동 원리는 다음과 동일합니다. 앞서 설명한 CP866의 경우 - 텍스트의 각 문자는 단일 바이트로 인코딩됩니다. 스크린샷은 KOI8-R 테이블의 후반부를 보여줍니다. 전반부는 이 기사의 첫 번째 스크린샷에 표시된 기본 Asuka와 완전히 일치합니다. KOI8-R 인코딩의 특징 중 표의 키릴 문자가 CP866에서처럼 알파벳 순서로 되어 있지 않다는 점을 알 수 있습니다. (모든 확장 인코딩에 포함된 기본 부분의) 첫 번째 스크린샷을 보면 KOI8-R에서 러시아어 문자가 라틴 알파벳의 해당 문자와 동일한 테이블 셀에 위치한다는 것을 알 수 있습니다. 테이블의 첫 번째 부분부터. 이는 1비트(2의 7승 또는 128)만 삭제하여 러시아어에서 라틴 문자로 편리하게 전환하기 위해 수행되었습니다.
Windows 1251 - 최신 버전의 ASCII 및 균열이 나타나는 이유
텍스트 인코딩의 추가 개발은 그래픽 운영 체제가 인기를 얻고 시간이 지남에 따라 의사 그래픽을 사용할 필요성이 사라졌기 때문입니다. 그 결과, 본질적으로 여전히 Asuka의 확장 버전(텍스트의 한 문자는 단 1바이트의 정보로 인코딩됨)이지만 의사 기호를 사용하지 않는 전체 그룹이 나타났습니다. 이는 American Standards Institute에서 개발한 소위 ANSI 인코딩에 속합니다. 일반적으로 키릴 문자라는 이름은 러시아어를 지원하는 버전에도 사용되었습니다. 이에 대한 예는 Windows 1251 입니다 . 이전에 사용된 CP866 및 KOI8-R과는 의사 그래픽 기호의 위치가 러시아어 타이포그래피의 누락된 기호(악센트 표시 제외)와 가까운 슬라브어에서 사용되는 기호에 의해 사용된다는 점에서 유리하게 달랐습니다. 러시아어(우크라이나어, 벨로루시어 등). ): 러시아어의 풍부한 인코딩으로 인해 글꼴 제조업체와 소프트웨어 제조업체는 끊임없이 골치 아픈 일을 겪었고, 사랑하는 독자 여러분, 여러분과 나는 종종 동일한 악명 높은 버그 로 인해 문제를 겪었습니다. 본문에 사용된 버전과 혼동이 있었을 때. 매우 복잡한 변환표를 생성해야 하는 이메일로 메시지를 보내고 받을 때 매우 자주 발생했으며 실제로는 이 문제를 근본적으로 해결할 수 없었으며 종종 사용자는 서신을 위해 라틴 문자 음역을 사용했습니다. CP866, KOI8-R 또는 Windows 1251과 같은 러시아어 인코딩을 사용할 때 악명 높은 횡설수설을 피하십시오. 실제로 러시아어 텍스트 대신 나타나는 균열은 주어진 언어의 인코딩을 잘못 사용한 결과였으며 이는 다음의 인코딩과 일치하지 않습니다. 문자 메시지가 원래 인코딩된 것입니다. Windows 1251 코드 테이블을 사용하여 CP866을 사용하여 인코딩된 문자를 표시하려고 하면 동일한 횡설수설(의미 없는 문자 집합)이 나와서 메시지 텍스트를 완전히 대체한다고 가정해 보겠습니다. 웹 사이트, 포럼 또는 블로그를 만들고 설정할 때 러시아어 문자가 포함된 텍스트가 기본적으로 사이트에서 사용되는 잘못된 인코딩으로 실수로 저장되거나 잘못된 텍스트 편집기에 저장되어 보이지 않는 개그가 추가되는 경우 유사한 상황이 매우 자주 발생합니다. 육안으로 코드를 확인하세요. 결국 많은 사람들은 많은 인코딩과 끊임없이 쓰레기를 쏟아내는 이러한 상황에 지쳤으며 기존의 모든 변형을 대체하고 읽을 수 없는 텍스트의 출현으로 문제를 해결할 새로운 보편적 변형을 만들기 위한 전제 조건이 나타났습니다. . 게다가 중국어 같은 언어는 256자보다 훨씬 더 많은 언어 문자가 있다는 문제도 있었다.
유니코드 - 범용 인코딩 UTF 8, 16 및 32
동남아시아 언어 그룹의 이러한 수천 개의 문자는 ASCII 확장 버전의 문자 인코딩에 할당된 1바이트 정보로는 도저히 설명할 수 없습니다. 그 결과, 범용 텍스트 인코딩의 출현에 관심이 있는 많은 IT 업계 리더(소프트웨어를 생산하는 사람, 하드웨어를 인코딩하는 사람, 글꼴을 만드는 사람)의 협력으로 유니코드(Unicode Consortium)라는 컨소시엄이 만들어졌습니다. Unicode Consortium의 후원으로 출시된 첫 번째 변형은 UTF 32 였습니다 . 인코딩 이름의 숫자는 하나의 문자를 인코딩하는 데 사용되는 비트 수를 의미합니다. 32비트는 새로운 범용 UTF 인코딩에서 단일 문자 하나를 인코딩하는 데 필요한 정보 4바이트와 같습니다. 결과적으로 ASCII 확장 버전과 UTF-32(후자의 경우)로 인코딩된 텍스트가 있는 동일한 파일의 크기(무게)는 4배 더 커집니다. 이것은 좋지 않지만 이제 UTF를 사용하여 2의 30제곱에 해당하는 문자 수(거대한 마진으로 실제로 필요한 값을 포괄하는 수십억 개의 문자 )를 인코딩할 수 있는 기회가 있습니다. 그러나 유럽 그룹의 언어를 사용하는 많은 국가에서는 인코딩에 그렇게 많은 문자를 사용할 필요가 없었지만 UTF-32를 사용할 때 아무 이유없이 텍스트 문서의 무게가 4배 증가했습니다. 그 결과 인터넷 트래픽의 양과 저장되는 데이터의 양이 증가합니다. 이것은 많은 일이며 누구도 그런 낭비를 감당할 수 없습니다. 유니코드 개발의 결과로 UTF-16이 등장했는데 , 이는 매우 성공적이어서 우리가 사용하는 모든 문자의 기본 공간으로 기본적으로 채택되었습니다. 한 문자를 인코딩하는 데 2바이트를 사용합니다. 이것이 어떻게 보이는지 봅시다. Windows 운영 체제에서는 "시작" - "프로그램" - "보조프로그램" - "시스템 도구" - "문자표" 경로를 따라갈 수 있습니다. 결과적으로 시스템에 설치된 모든 글꼴의 벡터 모양이 포함된 표가 열립니다. "고급 옵션"에서 유니코드 문자 세트를 선택하면 각 글꼴에 포함된 전체 문자 범위를 개별적으로 볼 수 있습니다. 그런데 그 중 하나를 클릭하면 4개의 16진수로 구성된 UTF-16 형식의 2바이트 코드를 볼 수 있습니다.16비트를 사용하여 UTF-16으로 인코딩할 수 있는 문자는 몇 개입니까? 65,536(2의 16제곱)이며 이는 유니코드에서 기본 공간으로 채택된 숫자입니다. 또한, 이를 이용하여 약 200만 글자를 인코딩하는 방법도 있지만, 이는 100만 글자의 텍스트라는 확장된 공간에 국한되었다. 그러나 이 성공적인 유니코드 인코딩 버전조차도 영어로만 프로그램을 작성하는 사람들에게는 큰 만족을 주지 못했습니다. 왜냐하면 ASCII 확장 버전에서 UTF-16으로 전환한 후 문서의 무게가 두 배(1바이트당 1바이트) 증가했기 때문입니다. Aski에서는 문자이고 YUTF-16에서는 동일한 문자에 대해 2바이트입니다. 가변 길이 인코딩을 고안하기로 결정한 것은 바로 유니코드 컨소시엄의 모든 사람과 모든 것을 만족시키기 위한 것이었습니다 . UTF-8이라고 불렸습니다. 이름에 8이 있음에도 불구하고 실제로는 가변 길이를 갖습니다. 텍스트의 각 문자는 1~6바이트 길이의 시퀀스로 인코딩될 수 있습니다. 실제로 UTF-8은 1~4바이트 범위만 사용합니다. 왜냐하면 4바이트 이상의 코드는 이론적으로 더 이상 상상조차 불가능하기 때문입니다. 그 안의 모든 라틴 문자는 오래된 ASCII와 마찬가지로 1바이트로 인코딩됩니다. 주목할만한 점은 라틴 알파벳만 인코딩하는 경우 유니코드를 이해하지 못하는 프로그램이라도 YTF-8로 인코딩된 내용을 읽을 수 있다는 것입니다. 즉, Asuka의 기본 부분은 유니코드 컨소시엄의 아이디어로 간단히 이전되었습니다. UTF-8의 키릴 문자는 2바이트로 인코딩되고, 예를 들어 조지아어 문자는 3바이트로 인코딩됩니다. 유니코드 컨소시엄은 UTF 16 및 8을 만든 후 주요 문제를 해결했습니다. 이제 글꼴에 단일 코드 공간이 있습니다 . 이제 제조업체는 강점과 기능에 따라 벡터 형식의 텍스트 문자로만 채울 수 있습니다. 위의 "문자표"를 보면 글꼴마다 지원하는 문자 수가 다르다는 것을 알 수 있습니다. 일부 유니코드가 풍부한 글꼴은 상당히 무거울 수 있습니다. 그러나 이제는 서로 다른 인코딩을 위해 생성되었다는 사실이 아니라 글꼴 제조업체가 단일 코드 공간을 특정 벡터 형식으로 채웠거나 완전히 채우지 않았다는 점에서 다릅니다.
러시아어 문자 대신 미친 단어 - 수정 방법
이제 텍스트 대신 krakozyabrs가 어떻게 나타나는지, 즉 러시아어 텍스트에 대한 올바른 인코딩이 선택되는 방법을 살펴보겠습니다. 실제로 이는 바로 이 텍스트 또는 텍스트 조각을 사용하는 코드를 생성하거나 편집하는 프로그램에서 설정됩니다. 텍스트 파일을 편집하고 생성하기 위해 저는 개인적으로 아주 좋은 Html 및 PHP 편집기인 Notepad++를 사용합니다 . 그러나 수백 가지 다른 프로그래밍 및 마크업 언어의 구문을 강조할 수 있으며 플러그인을 사용하여 확장할 수도 있습니다. 제공된 링크에서 이 훌륭한 프로그램에 대한 자세한 리뷰를 읽어보세요. Notepad++의 상단 메뉴에는 "인코딩" 항목이 있습니다. 여기서 기존 옵션을 사이트에서 기본적으로 사용되는 옵션으로 변환할 수 있습니다. Joomla 1.5 이상의 사이트인 경우 다음과 같습니다. WordPress 블로그의 경우 Krakozyabrov가 BOM 없이 UTF 8 옵션을 선택하는 모습을 피해야 합니다 . BOM 접두사는 무엇입니까? 사실 그들은 YUTF-16 인코딩을 개발할 때 어떤 이유로 문자 코드를 직접 순서(예: 0A15)와 역방향(150A)으로 작성하는 기능을 첨부하기로 결정했습니다. . 그리고 프로그램이 코드를 어떤 순서로 읽어야 하는지 이해하기 위해 BOM (바이트 순서 표시, 즉 서명)이 발명되었으며 이는 문서 맨 처음에 3바이트를 추가하는 방식으로 표현되었습니다. UTF-8 인코딩에서는 유니코드 컨소시엄에 BOM이 제공되지 않았으므로 서명(문서 시작 부분에 있는 악명 높은 추가 3바이트)을 추가하면 일부 프로그램이 코드를 읽을 수 없게 됩니다. 따라서 UTF로 파일을 저장할 때는 항상 BOM 없음(서명 없음) 옵션을 선택해야 합니다. 따라서 krakozyabrs의 크롤링으로부터 사전에 자신을 보호할 수 있습니다 . 주목할만한 점은 Windows의 일부 프로그램(예: 악명 높은 Windows 메모장)이 이를 수행할 수 없다는 것입니다(BOM 없이 UTF-8로 텍스트를 저장할 수 없음). 문서를 UTF-8로 저장하지만 여전히 문서 시작 부분에 서명(추가 3바이트)을 추가합니다. 또한 이러한 바이트는 항상 동일합니다. 코드를 직접 순서대로 읽습니다. 그러나 서버에서는 이 작은 일 때문에 문제가 발생할 수 있습니다. 사기꾼이 나올 것입니다. 그러므로 어떠한 경우에도 일반 Windows 메모장을 사용하지 마십시오 .균열이 나타나는 것을 원하지 않으면 사이트의 문서를 편집하십시오. 나는 이미 언급한 Notepad++ 편집기가 실제로 단점이 없고 장점만으로 구성된 가장 좋고 간단한 옵션이라고 생각합니다. Notepad++에서 인코딩을 선택하면 텍스트를 유니코드 표준과 매우 유사한 UCS-2 인코딩으로 변환하는 옵션이 제공됩니다. 또한 메모장에서는 ANSI로 텍스트를 인코딩하는 것이 가능합니다. 러시아어와 관련하여 이는 위에서 이미 설명한 Windows 1251이 될 것입니다. 이 정보는 어디에서 왔습니까? 이는 Windows 운영 체제의 레지스트리에 등록되어 있습니다. ANSI의 경우 선택할 인코딩, OEM의 경우 선택할 인코딩(러시아어의 경우 CP866)입니다. 컴퓨터에 다른 기본 언어를 설정하면 이러한 인코딩은 동일한 언어에 대한 ANSI 또는 OEM 범주의 유사한 인코딩으로 대체됩니다. 필요한 인코딩으로 Notepad++에 문서를 저장하거나 편집을 위해 사이트에서 문서를 열면 편집기의 오른쪽 하단에서 해당 이름을 볼 수 있습니다. 혼동을 피하기 위해 위에서 설명한 단계 외에도 , 바로 이 인코딩에 대한 사이트 정보의 모든 페이지 헤더에 소스 코드를 작성하여 서버나 로컬 호스트에 혼동이 없도록 하는 것이 유용할 것입니다. 일반적으로 Html을 제외한 모든 하이퍼텍스트 마크업 언어는 텍스트 인코딩을 지정하는 특수 xml 선언을 사용합니다.
<?xml version="1.0" encoding="windows-1251"?>
코드를 구문 분석하기 전에 브라우저는 사용 중인 버전과 해당 언어의 문자 코드를 정확히 어떻게 해석해야 하는지를 알고 있습니다. 하지만 주목할만한 점은 문서를 기본 유니코드로 저장하는 경우 이 xml 선언을 생략할 수 있다는 것입니다(인코딩은 BOM이 없으면 UTF-8로 간주되고 BOM이 있으면 UTF-16으로 간주됩니다). HTML 문서의 경우 Meta 요소는 여는 Head 태그와 닫는 Head 태그 사이에 배치되는 인코딩을 나타내는 데 사용됩니다.
<head>...<meta charset="utf-8">...</head>
이 항목은 Html 4.01의 표준과 상당히 다르지만 Html 5 표준을 완전히 준수하며 현재 사용되는 모든 브라우저에서 올바르게 이해됩니다. 이론적으로 Html 문서의 인코딩을 나타내는 Meta 요소는 문서 헤더에서 가능한 한 높은 위치에 배치되는 것이 좋습니다 . 그러면 텍스트가 기본 ANSI가 아닌 첫 번째 문자(항상 올바르게 읽혀지고 모든 변형) 브라우저에는 이러한 문자의 코드를 해석하는 방법에 대한 정보가 이미 있어야 합니다. 원본 소스 링크: ASCII 텍스트 인코딩(Windows 1251, CP866, KOI8-R) 및 유니코드(UTF 8, 16, 32) - 크래커 문제를 해결하는 방법
표준이 된 것은 원래 ASCII 버전의 128개 문자이며, 다른 인코딩에서는 확실히 찾을 수 있으며 이 순서로 나타납니다. 그러나 사실 1바이트의 정보를 사용하면 128개가 아니라 최대 256개의 서로 다른 값(2의 8승은 256)을 인코딩할 수 있으므로 Asuka의 기본 버전 이후에는 전체 일련의 확장 ASCII 인코딩이 등장하여 128개의 기본 문자 외에도 국가 인코딩 문자(예: 러시아어)를 사용하여 인코딩할 수도 있습니다. 여기에서는 설명에 사용되는 숫자 체계에 대해 좀 더 이야기해 볼 가치가 있을 것입니다. 첫째, 여러분 모두 알고 있듯이 컴퓨터는 이진법의 숫자, 즉 0과 1(누군가 기관이나 학교에서 배운 경우 "부울 대수학")로만 작동합니다. 1바이트는 8개의 비트로 구성되며 각 비트는 0부터 시작하여 2의 7승까지를 나타냅니다. 
이러한 구성에서 0과 1의 가능한 모든 조합이 가능하다는 것을 이해하는 것은 어렵지 않습니다. 256만 가능합니다. 이진수 시스템에서 십진수로 숫자를 변환하는 것은 매우 간단합니다. 두 가지의 거듭제곱과 그 위에 있는 거듭제곱을 더하면 됩니다. 이 예에서 이는 1(2의 0제곱) 더하기 8(2의 3제곱), 더하기 32(2의 5제곱), 더하기 64(6제곱), 더하기 128로 나타납니다. (7승). 합계는 10진수 표기로 233입니다. 보시다시피 모든 것이 매우 간단합니다. 그러나 ASCII 문자가 포함된 표를 자세히 살펴보면 해당 문자가 16진수 인코딩으로 표시되어 있음을 알 수 있습니다. 예를 들어 "별표"는 Aski의 16진수 2A에 해당합니다. 16진수 체계에서는 아라비아 숫자 외에도 A(10을 의미)부터 F(15를 의미)까지의 라틴 문자도 사용된다는 것을 알고 계실 것입니다. 음, 2진수를 16진수로 변환 하려면다음과 같은 간단한 방법을 사용하십시오. 각 정보 바이트는 4비트로 구성된 두 부분으로 나뉩니다. 저것들. 각 1/2바이트에는 16개의 값(2의 4승)만 이진수로 인코딩될 수 있으며 이는 쉽게 16진수로 표시될 수 있습니다. 또한 바이트의 왼쪽 절반에서는 각도를 0부터 다시 계산해야 하며 스크린샷에 표시된 것과는 다릅니다. 결과적으로 E9라는 숫자가 스크린샷에 인코딩되어 있음을 알 수 있습니다. 내 추론 과정과 이 퍼즐에 대한 해결책이 여러분에게 분명해지기를 바랍니다. 자, 이제 실제로 텍스트 인코딩에 대해 계속 이야기해 보겠습니다.
오른쪽 열의 숫자는 8로 시작합니다. 0부터 7까지의 숫자는 ASCII의 기본 부분을 나타냅니다(첫 번째 스크린샷 참조). 따라서 CP866의 키릴 문자 "M"은 코드 9C(16진수 시스템에서 9와 해당 행과 숫자 C가 있는 열의 교차점에 위치함)를 가지며 1바이트의 정보로 쓸 수 있습니다. , 그리고 러시아어 문자에 적합한 글꼴이 있는 경우 이 문자는 문제 없이 텍스트에 나타납니다. 이 금액은 어디서 나온 걸까요?CP866의 의사그래픽 ? 요점은 러시아어 텍스트에 대한 이 인코딩이 그래픽 운영 체제가 지금처럼 널리 퍼지지 않았던 얽히고 설킨 시절에 개발되었다는 것입니다. 그리고 Dosa 및 유사한 텍스트 운영 체제에서는 의사 그래픽을 통해 적어도 텍스트 디자인을 다양화할 수 있었기 때문에 CP866과 Asuka 확장 버전 범주의 다른 모든 동료가 풍부합니다. CP866은 IBM에서 배포했지만 이 외에도 러시아어 문자에 대한 여러 인코딩이 개발되었습니다. 예를 들어 KOI8-R은 동일한 유형(확장 ASCII)에 속할 수 있습니다 . 
작동 원리는 다음과 동일합니다. 앞서 설명한 CP866의 경우 - 텍스트의 각 문자는 단일 바이트로 인코딩됩니다. 스크린샷은 KOI8-R 테이블의 후반부를 보여줍니다. 전반부는 이 기사의 첫 번째 스크린샷에 표시된 기본 Asuka와 완전히 일치합니다. KOI8-R 인코딩의 특징 중 표의 키릴 문자가 CP866에서처럼 알파벳 순서로 되어 있지 않다는 점을 알 수 있습니다. (모든 확장 인코딩에 포함된 기본 부분의) 첫 번째 스크린샷을 보면 KOI8-R에서 러시아어 문자가 라틴 알파벳의 해당 문자와 동일한 테이블 셀에 위치한다는 것을 알 수 있습니다. 테이블의 첫 번째 부분부터. 이는 1비트(2의 7승 또는 128)만 삭제하여 러시아어에서 라틴 문자로 편리하게 전환하기 위해 수행되었습니다.
러시아어의 풍부한 인코딩으로 인해 글꼴 제조업체와 소프트웨어 제조업체는 끊임없이 골치 아픈 일을 겪었고, 사랑하는 독자 여러분, 여러분과 나는 종종 동일한 악명 높은 버그 로 인해 문제를 겪었습니다. 본문에 사용된 버전과 혼동이 있었을 때. 매우 복잡한 변환표를 생성해야 하는 이메일로 메시지를 보내고 받을 때 매우 자주 발생했으며 실제로는 이 문제를 근본적으로 해결할 수 없었으며 종종 사용자는 서신을 위해 라틴 문자 음역을 사용했습니다. CP866, KOI8-R 또는 Windows 1251과 같은 러시아어 인코딩을 사용할 때 악명 높은 횡설수설을 피하십시오. 실제로 러시아어 텍스트 대신 나타나는 균열은 주어진 언어의 인코딩을 잘못 사용한 결과였으며 이는 다음의 인코딩과 일치하지 않습니다. 문자 메시지가 원래 인코딩된 것입니다. Windows 1251 코드 테이블을 사용하여 CP866을 사용하여 인코딩된 문자를 표시하려고 하면 동일한 횡설수설(의미 없는 문자 집합)이 나와서 메시지 텍스트를 완전히 대체한다고 가정해 보겠습니다. 
웹 사이트, 포럼 또는 블로그를 만들고 설정할 때 러시아어 문자가 포함된 텍스트가 기본적으로 사이트에서 사용되는 잘못된 인코딩으로 실수로 저장되거나 잘못된 텍스트 편집기에 저장되어 보이지 않는 개그가 추가되는 경우 유사한 상황이 매우 자주 발생합니다. 육안으로 코드를 확인하세요. 결국 많은 사람들은 많은 인코딩과 끊임없이 쓰레기를 쏟아내는 이러한 상황에 지쳤으며 기존의 모든 변형을 대체하고 읽을 수 없는 텍스트의 출현으로 문제를 해결할 새로운 보편적 변형을 만들기 위한 전제 조건이 나타났습니다. . 게다가 중국어 같은 언어는 256자보다 훨씬 더 많은 언어 문자가 있다는 문제도 있었다.
16비트를 사용하여 UTF-16으로 인코딩할 수 있는 문자는 몇 개입니까? 65,536(2의 16제곱)이며 이는 유니코드에서 기본 공간으로 채택된 숫자입니다. 또한, 이를 이용하여 약 200만 글자를 인코딩하는 방법도 있지만, 이는 100만 글자의 텍스트라는 확장된 공간에 국한되었다. 그러나 이 성공적인 유니코드 인코딩 버전조차도 영어로만 프로그램을 작성하는 사람들에게는 큰 만족을 주지 못했습니다. 왜냐하면 ASCII 확장 버전에서 UTF-16으로 전환한 후 문서의 무게가 두 배(1바이트당 1바이트) 증가했기 때문입니다. Aski에서는 문자이고 YUTF-16에서는 동일한 문자에 대해 2바이트입니다. 가변 길이 인코딩을 고안하기로 결정한 것은 바로 유니코드 컨소시엄의 모든 사람과 모든 것을 만족시키기 위한 것이었습니다 . UTF-8이라고 불렸습니다. 이름에 8이 있음에도 불구하고 실제로는 가변 길이를 갖습니다. 텍스트의 각 문자는 1~6바이트 길이의 시퀀스로 인코딩될 수 있습니다. 실제로 UTF-8은 1~4바이트 범위만 사용합니다. 왜냐하면 4바이트 이상의 코드는 이론적으로 더 이상 상상조차 불가능하기 때문입니다. 그 안의 모든 라틴 문자는 오래된 ASCII와 마찬가지로 1바이트로 인코딩됩니다. 주목할만한 점은 라틴 알파벳만 인코딩하는 경우 유니코드를 이해하지 못하는 프로그램이라도 YTF-8로 인코딩된 내용을 읽을 수 있다는 것입니다. 즉, Asuka의 기본 부분은 유니코드 컨소시엄의 아이디어로 간단히 이전되었습니다. UTF-8의 키릴 문자는 2바이트로 인코딩되고, 예를 들어 조지아어 문자는 3바이트로 인코딩됩니다. 유니코드 컨소시엄은 UTF 16 및 8을 만든 후 주요 문제를 해결했습니다. 이제 글꼴에 단일 코드 공간이 있습니다 . 이제 제조업체는 강점과 기능에 따라 벡터 형식의 텍스트 문자로만 채울 수 있습니다. 위의 "문자표"를 보면 글꼴마다 지원하는 문자 수가 다르다는 것을 알 수 있습니다. 일부 유니코드가 풍부한 글꼴은 상당히 무거울 수 있습니다. 그러나 이제는 서로 다른 인코딩을 위해 생성되었다는 사실이 아니라 글꼴 제조업체가 단일 코드 공간을 특정 벡터 형식으로 채웠거나 완전히 채우지 않았다는 점에서 다릅니다.
Joomla 1.5 이상의 사이트인 경우 다음과 같습니다. WordPress 블로그의 경우 Krakozyabrov가 BOM 없이 UTF 8 옵션을 선택하는 모습을 피해야 합니다 . BOM 접두사는 무엇입니까? 사실 그들은 YUTF-16 인코딩을 개발할 때 어떤 이유로 문자 코드를 직접 순서(예: 0A15)와 역방향(150A)으로 작성하는 기능을 첨부하기로 결정했습니다. . 그리고 프로그램이 코드를 어떤 순서로 읽어야 하는지 이해하기 위해 BOM (바이트 순서 표시, 즉 서명)이 발명되었으며 이는 문서 맨 처음에 3바이트를 추가하는 방식으로 표현되었습니다. UTF-8 인코딩에서는 유니코드 컨소시엄에 BOM이 제공되지 않았으므로 서명(문서 시작 부분에 있는 악명 높은 추가 3바이트)을 추가하면 일부 프로그램이 코드를 읽을 수 없게 됩니다. 따라서 UTF로 파일을 저장할 때는 항상 BOM 없음(서명 없음) 옵션을 선택해야 합니다. 따라서 krakozyabrs의 크롤링으로부터 사전에 자신을 보호할 수 있습니다 . 주목할만한 점은 Windows의 일부 프로그램(예: 악명 높은 Windows 메모장)이 이를 수행할 수 없다는 것입니다(BOM 없이 UTF-8로 텍스트를 저장할 수 없음). 문서를 UTF-8로 저장하지만 여전히 문서 시작 부분에 서명(추가 3바이트)을 추가합니다. 또한 이러한 바이트는 항상 동일합니다. 코드를 직접 순서대로 읽습니다. 그러나 서버에서는 이 작은 일 때문에 문제가 발생할 수 있습니다. 사기꾼이 나올 것입니다. 그러므로 어떠한 경우에도 일반 Windows 메모장을 사용하지 마십시오 .균열이 나타나는 것을 원하지 않으면 사이트의 문서를 편집하십시오. 나는 이미 언급한 Notepad++ 편집기가 실제로 단점이 없고 장점만으로 구성된 가장 좋고 간단한 옵션이라고 생각합니다. Notepad++에서 인코딩을 선택하면 텍스트를 유니코드 표준과 매우 유사한 UCS-2 인코딩으로 변환하는 옵션이 제공됩니다. 또한 메모장에서는 ANSI로 텍스트를 인코딩하는 것이 가능합니다. 러시아어와 관련하여 이는 위에서 이미 설명한 Windows 1251이 될 것입니다. 이 정보는 어디에서 왔습니까? 이는 Windows 운영 체제의 레지스트리에 등록되어 있습니다. ANSI의 경우 선택할 인코딩, OEM의 경우 선택할 인코딩(러시아어의 경우 CP866)입니다. 컴퓨터에 다른 기본 언어를 설정하면 이러한 인코딩은 동일한 언어에 대한 ANSI 또는 OEM 범주의 유사한 인코딩으로 대체됩니다. 필요한 인코딩으로 Notepad++에 문서를 저장하거나 편집을 위해 사이트에서 문서를 열면 편집기의 오른쪽 하단에서 해당 이름을 볼 수 있습니다. 
혼동을 피하기 위해 위에서 설명한 단계 외에도 , 바로 이 인코딩에 대한 사이트 정보의 모든 페이지 헤더에 소스 코드를 작성하여 서버나 로컬 호스트에 혼동이 없도록 하는 것이 유용할 것입니다. 일반적으로 Html을 제외한 모든 하이퍼텍스트 마크업 언어는 텍스트 인코딩을 지정하는 특수 xml 선언을 사용합니다.
GO TO FULL VERSION