Ascii 라틴 알파벳. ASCII 인코딩(정보 교환을 위한 미국 표준 코드) - 라틴 알파벳의 기본 텍스트 인코딩

아시다시피 컴퓨터는 정보를 이진 형식으로 저장하며 이를 1과 0의 시퀀스로 표시합니다. 정보를 인간의 인식에 편리한 형태로 변환하기 위해 표시될 때 각각의 고유한 숫자 시퀀스는 해당 기호로 대체됩니다.

인쇄된 제어 문자와 이진 코드를 연관시키는 시스템 중 하나는 다음과 같습니다.

현재의 컴퓨터 기술 개발 수준에서는 사용자가 각 특정 문자의 코드를 알 필요가 없습니다. 그러나 코딩이 수행되는 방법에 대한 일반적인 이해는 매우 유용하며 일부 전문가 범주에는 필요합니다.

ASCII 생성

인코딩은 원래 1963년에 개발되었으며 이후 25년에 걸쳐 두 번 업데이트되었습니다.

원래 버전에서는 ASCII 문자 테이블에 128자가 포함되어 있었지만 나중에 확장 버전이 등장하여 처음 128자가 저장되고 이전에 누락된 문자가 8번째 비트가 포함된 코드에 할당되었습니다.

수년 동안 이 인코딩은 세계에서 가장 인기가 있었습니다. 2006년에는 Latin 1252가 선두 자리를 차지했고, 2007년 말부터 현재까지 유니코드가 선두 자리를 굳건히 지키고 있습니다.

ASCII의 컴퓨터 표현

각 ASCII 문자에는 0 또는 1을 나타내는 8개의 문자로 구성된 고유한 코드가 있습니다. 이 표현의 최소 숫자는 0(이진 시스템에서는 8개의 0)이며, 이는 테이블의 첫 번째 요소 코드입니다.

표의 두 코드는 표준 US-ASCII와 국가별 변형 간 전환을 위해 예약되었습니다.

ASCII에 128자가 아닌 256자가 포함되기 시작한 이후 인코딩 변형이 널리 보급되었습니다. 이 변형에서는 테이블의 원래 버전이 8번째 비트가 0인 처음 128개 코드에 저장되었습니다. 국가 문자는 표의 위쪽 절반(위치 128-255)에 저장되었습니다.

사용자는 ASCII 문자 코드를 직접 알 필요가 없습니다. 소프트웨어 개발자는 일반적으로 필요한 경우 이진 시스템을 사용하여 코드를 계산하기 위해 테이블의 요소 번호만 알면 됩니다.

러시아어

70년대 초 스칸디나비아 언어, 중국어, 한국어, 그리스어 등의 인코딩이 개발된 후 소련은 자체 버전을 만들기 시작했습니다. 곧 KOI8이라는 8비트 인코딩 버전이 개발되어 처음 128개의 ASCII 문자 코드를 보존하고 국가 알파벳 문자와 추가 문자에 동일한 수의 위치를 ​​할당했습니다.

유니코드가 도입되기 전에는 KOI8이 러시아 인터넷 부문을 지배했습니다. 러시아어와 우크라이나어 알파벳 모두에 대한 인코딩 옵션이 있었습니다.

ASCII 문제

확장된 테이블에서도 요소 개수가 256개를 넘지 않았기 때문에 하나의 인코딩에서 여러 다른 스크립트를 수용할 가능성이 없었습니다. 90년대에는 러시아어 ASCII 문자로 입력된 텍스트가 잘못 표시되는 "crocozyabr" 문제가 Runet에 나타났습니다.

문제는 서로 다른 ASCII 코드가 서로 일치하지 않는다는 것입니다. 다양한 문자가 위치 128-255에 위치할 수 있으며 키릴 문자 인코딩을 다른 문자로 변경할 때 텍스트의 모든 문자는 다른 인코딩 버전에서 동일한 숫자를 갖는 다른 문자로 대체되었습니다.

현재 상태

유니코드의 출현과 함께 ASCII의 인기는 급격히 떨어지기 시작했습니다.

그 이유는 새로운 인코딩을 통해 거의 모든 언어의 문자를 수용할 수 있게 되었기 때문입니다. 이 경우 처음 128개의 ASCII 문자는 유니코드의 동일한 문자에 해당합니다.

2000년에는 ASCII가 인터넷에서 가장 널리 사용되는 인코딩이었으며 Google에서 색인한 웹페이지의 60%에 사용되었습니다. 2012년까지 이러한 페이지의 점유율은 17%로 떨어졌고 유니코드(UTF-8)가 가장 널리 사용되는 인코딩을 대신했습니다.

따라서 ASCII는 정보 기술 역사에서 중요한 부분을 차지하지만 미래에 ASCII를 사용하는 것은 어려울 것 같습니다.

[8비트 인코딩: ASCII, KOI-8R 및 CP1251] 미국에서 만들어진 최초의 인코딩 테이블은 바이트의 8번째 비트를 사용하지 않았습니다. 텍스트는 일련의 바이트로 표시되었지만 8번째 비트는 고려되지 않았습니다(공식 목적으로 사용됨).

테이블은 일반적으로 허용되는 표준이되었습니다. 아스키(정보 교환을 위한 미국 표준 코드). ASCII 테이블의 처음 32자(00~1F)는 인쇄할 수 없는 문자로 사용되었습니다. 인쇄 장치 등을 제어하도록 설계되었습니다. 나머지(20층부터 7층까지)는 일반(인쇄 가능한) 문자입니다.

표 1 - ASCII 인코딩

쉽게 알 수 있듯이 이 인코딩에는 라틴 문자와 영어에서 사용되는 문자만 포함되어 있습니다. 산술 및 기타 서비스 기호도 있습니다. 그러나 독일어나 프랑스어에는 러시아어 문자도 없고 특별한 라틴어 문자도 없습니다. 이는 설명하기 쉽습니다. 인코딩은 미국 표준으로 특별히 개발되었습니다. 컴퓨터가 전 세계적으로 사용되기 시작하면서 다른 문자도 인코딩해야 했습니다.

이를 달성하기 위해 각 바이트에서 8번째 비트를 사용하기로 결정했습니다. 이로 인해 문자를 인코딩하는 데 사용할 수 있는 값이 128개 더 추가되었습니다(80에서 FF까지). 8비트 테이블 중 첫 번째는 "확장 ASCII"( 확장 ASCII) - 서유럽의 일부 언어에서 사용되는 다양한 라틴 문자 변형이 포함되었습니다. 또한 의사그래픽을 포함한 다른 추가 기호도 포함되어 있습니다.

의사 문자를 사용하면 화면에 텍스트 문자만 표시하여 그래픽과 유사한 느낌을 제공할 수 있습니다. 예를 들어, 파일 관리 프로그램인 FAR Manager는 의사 그래픽을 사용하여 작동합니다.

확장 ASCII 테이블에는 러시아어 문자가 없습니다. 러시아(이전 소련)와 기타 국가에서는 8비트 텍스트 파일에서 특정 "국가" 문자(폴란드어 및 체코어의 라틴 문자, 키릴 문자(러시아 문자 포함) 및 기타 알파벳)를 표현할 수 있는 자체 인코딩을 만들었습니다.

널리 보급된 모든 인코딩에서 처음 127자(즉, 8번째 비트가 0인 바이트 값)는 ASCII와 동일합니다. 따라서 ASCII 파일은 이러한 인코딩 중 하나로 작동합니다. 영어의 문자도 같은 방식으로 표시됩니다.

조직 ISO(국제표준화기구) 표준군 채택 ISO 8859. 다양한 언어 그룹에 대한 8비트 인코딩을 정의합니다. 따라서 ISO 8859-1은 미국과 서유럽을 위한 확장 ASCII 테이블입니다. 그리고 ISO 8859-5는 키릴 문자(러시아어 포함)에 대한 표입니다.

그러나 역사적인 이유로 ISO 8859-5 인코딩은 뿌리를 내리지 못했습니다. 실제로 러시아어에는 다음 인코딩이 사용됩니다.

코드 페이지 866( CP866), 일명 "DOS", 일명 "대체 GOST 인코딩". 90년대 중반까지 널리 사용되었습니다. 이제는 제한적으로 사용됩니다. 실제로 인터넷에 텍스트를 배포하는 데 사용되지 않습니다.
- KOI-8. 70~80년대에 개발되었습니다. 이는 러시아 인터넷에서 이메일 메시지를 전송하는 데 일반적으로 허용되는 표준입니다. 또한 Linux를 포함한 Unix 제품군의 운영 체제에서도 널리 사용됩니다. 러시아어용으로 설계된 KOI-8 버전은 다음과 같습니다. KOI-8R; 다른 키릴어용 버전도 있습니다(예: KOI8-U는 우크라이나어용 버전입니다).
- 코드 페이지 1251, CP1251,Windows-1251. Windows에서 러시아어를 지원하기 위해 Microsoft에서 개발했습니다.

CP866의 가장 큰 장점은 확장 ASCII와 동일한 위치에 의사 그래픽 문자가 보존된다는 것입니다. 따라서 유명한 Norton Commander와 같은 외국 텍스트 프로그램은 변경 없이 작동할 수 있습니다. CP866은 이제 FAR ​​Manager를 포함하여 텍스트 창 또는 전체 화면 텍스트 모드에서 실행되는 Windows 프로그램에 사용됩니다.

CP866의 텍스트는 최근 몇 년 동안 매우 드물었습니다(그러나 Windows에서 러시아어 파일 이름을 인코딩하는 데 사용됩니다). 따라서 KOI-8R과 CP1251이라는 두 가지 다른 인코딩에 대해 자세히 설명하겠습니다.

보시다시피 CP1251 인코딩 테이블에서 러시아어 문자는 알파벳 순서로 배열됩니다 (단 문자 E는 제외). 이러한 배열은 컴퓨터 프로그램이 알파벳순으로 정렬하는 것을 매우 쉽게 만듭니다.

그러나 KOI-8R에서는 러시아어 문자의 순서가 무작위로 보입니다. 그러나 실제로는 그렇지 않습니다.

많은 오래된 프로그램에서는 텍스트를 처리하거나 전송할 때 8번째 비트가 손실되었습니다. (이제 이러한 프로그램은 사실상 "멸종"되었지만 80년대 후반부터 90년대 초반까지 널리 퍼졌습니다.) 8비트 값에서 7비트 값을 얻으려면 최상위 숫자에서 8을 빼면 됩니다. 예를 들어 E1은 61이 됩니다.

이제 KOI-8R을 ASCII 테이블(표 1)과 비교해 보십시오. 러시아어 문자가 라틴어 문자와 명확하게 일치하는 것을 볼 수 있습니다. 8번째 비트가 사라지면 러시아 소문자는 라틴 대문자로 바뀌고, 러시아 대문자는 라틴 소문자로 바뀐다. 따라서 KOI-8의 E1은 러시아어 "A"이고 ASCII의 61은 라틴어 "a"입니다.

따라서 KOI-8을 사용하면 8번째 비트가 손실된 경우 러시아어 텍스트의 가독성을 유지할 수 있습니다. “안녕하세요 여러분”은 “pRIWET WSEM”이 됩니다.

최근에는 인코딩 테이블의 문자 알파벳 순서와 8번째 비트가 손실된 가독성 모두 결정적인 중요성을 잃었습니다. 현대 컴퓨터의 8번째 비트는 전송이나 처리 중에 손실되지 않습니다. 그리고 단순히 코드를 비교하는 것이 아니라 인코딩을 고려하여 알파벳순 정렬이 수행됩니다. (그런데 CP1251 코드는 완전히 알파벳순으로 정렬되어 있지 않습니다. 문자 E가 그 자리에 없습니다.)

두 가지 일반적인 인코딩이 있기 때문에 인터넷 작업(메일, 웹 사이트 검색)을 할 때 러시아어 텍스트 대신 의미 없는 문자 집합을 볼 수 있는 경우가 있습니다. 예를 들어, “나는 SBYUFEMHEL입니다.” 이것은 단지 "존경하는 마음으로"라는 단어일 뿐입니다. 그러나 CP1251 인코딩으로 인코딩되었으며 컴퓨터는 KOI-8 테이블을 사용하여 텍스트를 디코딩했습니다. 반대로 동일한 단어가 KOI-8로 인코딩되고 컴퓨터가 CP1251 테이블에 따라 텍스트를 디코딩한 경우 결과는 "U KHBTSEOYEN"이 됩니다.

때때로 컴퓨터가 러시아어용이 아닌 표를 사용하여 러시아어 문자를 해독하는 경우가 있습니다. 그런 다음 러시아어 문자 대신 의미 없는 기호 집합이 나타납니다(예: 동유럽 언어의 라틴 문자). 그들은 종종 "crocozybras"라고 불립니다.

대부분의 경우 최신 프로그램은 인터넷 문서(이메일 및 웹 페이지)의 인코딩을 독립적으로 결정하는 데 대처합니다. 그러나 때때로 그들은 "실패"하고 러시아 문자 또는 "krokozyabry"의 이상한 순서를 볼 수 있습니다. 일반적으로 이러한 상황에서 실제 텍스트를 화면에 표시하려면 프로그램 메뉴에서 수동으로 인코딩을 선택하면 충분합니다.

이 기사에는 http://open-office.edusite.ru/TextProcessor/p5aa1.html 페이지의 정보가 사용되었습니다.

사이트에서 가져온 자료:

컴퓨터는 이 데이터를 보다 편리하게 전송, 저장 또는 자동 처리할 수 있는 형식으로 변환하는 프로세스를 이해합니다. 이를 위해 다양한 테이블이 사용됩니다. ASCII는 영어 텍스트 작업을 위해 미국에서 개발된 최초의 시스템으로, 이후 전 세계적으로 널리 보급되었습니다. 아래 기사에서는 설명, 기능, 속성 및 추가 사용에 대해 다룹니다.

컴퓨터에 정보 표시 및 저장

컴퓨터 모니터 또는 하나 이상의 모바일 디지털 장치의 기호는 다양한 문자의 벡터 형태 세트와 올바른 위치에 삽입해야 하는 기호를 찾을 수 있는 코드를 기반으로 형성됩니다. 이는 일련의 비트를 나타냅니다. 따라서 각 문자는 특정한 고유한 순서로 나타나는 0과 1의 집합에 고유하게 대응해야 합니다.

모든 것이 어떻게 시작되었는지

역사적으로 최초의 컴퓨터는 영어였습니다. 그 안에 기호정보를 부호화하기 위해서는 7비트의 메모리만 사용해도 충분했고, 이를 위해 8비트로 구성된 1바이트가 할당됐다. 이 경우 컴퓨터가 인식하는 문자 수는 128개였습니다. 이 문자에는 구두점을 포함한 영어 알파벳, 숫자 및 일부 특수 문자가 포함되었습니다. 1963년에 개발된 해당 테이블(코드 페이지)이 포함된 영어 7비트 인코딩을 정보 교환을 위한 미국 표준 코드라고 합니다. 일반적으로 "ASCII 인코딩"이라는 약어는 이를 나타내는 데 사용되었으며 여전히 사용됩니다.

다국어로의 전환

시간이 지나면서 컴퓨터는 비영어권 국가에서도 널리 사용되었습니다. 이러한 점에서 자국어 사용을 허용하는 인코딩이 필요했습니다. 바퀴를 재발명하지 않고 ASCII를 기본으로 사용하기로 결정했습니다. 새 버전의 인코딩 테이블은 크게 확장되었습니다. 8번째 비트를 사용하면 256자를 컴퓨터 언어로 번역하는 것이 가능해졌습니다.

설명

ASCII 인코딩에는 두 부분으로 나누어진 테이블이 있습니다. 전반부만 일반적으로 인정되는 국제 표준으로 간주됩니다. 여기에는 다음이 포함됩니다.

• 일련 번호가 0부터 31까지이고 00000000부터 00011111까지의 순서로 인코딩된 문자입니다. 이는 화면이나 프린터에 텍스트를 표시하고 사운드 신호를 울리는 과정을 제어하는 ​​제어 문자용으로 예약되어 있습니다.
• 32부터 127까지의 테이블에서 NN이 있는 문자는 00100000부터 01111111까지의 시퀀스로 인코딩되어 테이블의 표준 부분을 형성합니다. 여기에는 공백(N 32), 라틴 알파벳 문자(소문자 및 대문자), 0에서 9까지의 10자리 숫자, 구두점, 다양한 스타일의 괄호 및 기타 기호가 포함됩니다.
• 일련 번호가 128부터 255까지이고 10000000부터 11111111까지의 시퀀스로 인코딩된 문자입니다. 여기에는 라틴어 이외의 국가 알파벳 문자가 포함됩니다. 러시아어 문자를 컴퓨터 형식으로 변환하는 데 사용되는 것은 ASCII 테이블의 대체 부분입니다.

일부 속성

ASCII 인코딩의 특징은 "A" - "Z" 문자의 소문자와 대문자 사이의 차이가 단 1비트에 불과하다는 점입니다. 이러한 상황에서는 레지스터 변환은 물론 해당 값이 지정된 값 범위에 속하는지 확인하는 작업도 크게 단순화됩니다. 또한 ASCII 인코딩 시스템의 모든 문자는 알파벳의 자체 시퀀스 번호로 표시되며 이진수 시스템에서 5자리로 작성되며 앞에 소문자의 경우 011 2, 대문자의 경우 010 2가 옵니다.

ASCII 인코딩의 특징 중 하나는 "0" - "9"의 10자리 숫자를 표현하는 것입니다. 두 번째 숫자 체계에서는 00112로 시작하고 2개의 숫자 값으로 끝납니다. 따라서 0101 2는 십진수 5와 동일하므로 문자 "5"는 0011 01012로 기록됩니다. 위의 내용을 바탕으로 각 니블에 비트 시퀀스 00112를 추가하면 BCD 숫자를 ASCII 문자열로 쉽게 변환할 수 있습니다. 왼쪽.

"유니코드"

아시다시피 동남아시아 그룹의 언어로 텍스트를 표시하려면 수천 개의 문자가 필요합니다. 그러한 숫자는 어떤 식으로든 1바이트 정보로 설명할 수 없으므로 확장 버전의 ASCII라도 더 이상 다른 국가에서 증가하는 사용자 요구를 충족할 수 없습니다.

따라서 유니코드 컨소시엄에서 글로벌 IT 산업의 많은 리더들과 협력하여 개발을 수행한 범용 텍스트 인코딩을 만들어야 할 필요성이 생겼습니다. 전문가들은 UTF 32 시스템을 만들었습니다. 이 시스템에서는 1개의 문자를 인코딩하는 데 32비트가 할당되어 4바이트의 정보를 구성합니다. 가장 큰 단점은 필요한 메모리 양이 무려 4배나 급증해 많은 문제가 발생했다는 점이었습니다.

동시에 인도 유럽어 그룹에 속하는 공식 언어를 사용하는 대부분의 국가에서는 2 32에 해당하는 문자 수가 너무 많습니다.

유니코드 컨소시엄 전문가들의 추가 작업 결과, UTF-16 인코딩이 등장했습니다. 필요한 메모리 양과 인코딩된 문자 수 측면에서 모두에게 적합한 기호 정보를 변환하는 옵션이 되었습니다. 이것이 UTF-16이 기본적으로 채택된 이유이며 한 문자에 2바이트를 예약해야 합니다.

이 상당히 발전되고 성공적인 유니코드 버전에도 몇 가지 단점이 있었으며, ASCII 확장 버전에서 UTF-16으로 전환한 후 문서의 무게가 두 배로 늘어났습니다.

이에 UTF-8 가변길이 인코딩을 사용하기로 결정하였다. 이 경우 소스 텍스트의 각 문자는 1~6바이트 길이의 시퀀스로 인코딩됩니다.

정보교환을 위한 미국표준코드에 문의하세요.

UTF-8 가변 길이의 모든 라틴 문자는 ASCII 인코딩 시스템과 마찬가지로 1바이트로 인코딩됩니다.

YTF-8의 특별한 특징은 다른 문자를 사용하지 않는 라틴어 텍스트의 경우 유니코드를 이해하지 못하는 프로그램이라도 여전히 읽을 수 있다는 것입니다. 즉, 기본 ASCII 텍스트 인코딩은 단순히 새로운 가변 길이 UTF의 일부가 됩니다. YTF-8의 키릴 문자는 2바이트를 차지하며, 예를 들어 조지아어 문자는 3바이트를 차지합니다. UTF-16 및 8을 생성함으로써 글꼴에 단일 코드 공간을 생성하는 주요 문제가 해결되었습니다. 그 이후로 글꼴 제조업체는 필요에 따라 벡터 형식의 텍스트 문자로만 테이블을 채울 수 있습니다.

운영 체제마다 선호하는 인코딩이 다릅니다. 다른 인코딩으로 입력된 텍스트를 읽고 편집하려면 러시아어 텍스트 변환 프로그램이 사용됩니다. 일부 텍스트 편집기에는 내장형 트랜스코더가 포함되어 있어 인코딩에 관계없이 텍스트를 읽을 수 있습니다.

이제 ASCII 인코딩에 몇 개의 문자가 포함되어 있는지, 그리고 그것이 개발된 방법과 이유를 알게 되었습니다. 물론 오늘날 유니코드 표준은 세계에서 가장 널리 퍼져 있습니다. 그러나 ASCII 기반이라는 점을 잊어서는 안 되며, IT 분야에 대한 개발자의 기여는 높이 평가되어야 합니다.

안녕하세요, 블로그 사이트 독자 여러분. 오늘 우리는 웹사이트와 프로그램에서 krakozyabrs가 어디에서 왔는지, 어떤 텍스트 인코딩이 존재하는지, 어떤 인코딩을 사용해야 하는지에 대해 이야기하겠습니다. 기본 ASCII뿐만 아니라 확장 버전 CP866, KOI8-R, Windows 1251부터 시작하여 최신 유니코드 컨소시엄 인코딩 UTF 16 및 8로 끝나는 개발 내역을 자세히 살펴보겠습니다.

어떤 사람들에게는 이 정보가 불필요해 보일 수도 있지만 크롤링 크라코자브르(읽을 수 없는 문자 집합)와 관련하여 내가 얼마나 많은 질문을 받는지 아십니까? 이제 나는 모든 사람에게 이 기사의 텍스트를 참조하고 내 자신의 실수를 찾을 수 있는 기회를 갖게 될 것입니다. 자, 정보를 흡수할 준비를 하고 이야기의 흐름을 따라가도록 노력하세요.

ASCII - 라틴 알파벳의 기본 텍스트 인코딩

텍스트 인코딩의 개발은 IT 산업의 형성과 동시에 이루어졌으며, 이 기간 동안 많은 변화를 겪었습니다. 역사적으로 모든 것은 러시아어 발음이 다소 불협화음인 EBCDIC로 시작하여 라틴 알파벳 문자, 아라비아 숫자 및 문장 부호를 제어 문자로 인코딩할 수 있었습니다.

그러나 여전히 현대 텍스트 인코딩 개발의 출발점은 유명한 것으로 간주되어야 합니다. 아스키(미국 정보 교환 표준 코드, 러시아어에서는 일반적으로 "aski"로 발음됩니다.) 이는 영어권 사용자가 가장 일반적으로 사용하는 라틴 문자, 아라비아 숫자 및 문장 부호 등 처음 128자를 설명합니다.

ASCII로 설명된 이러한 128개 문자에는 대괄호, 해시 표시, 별표 등과 같은 일부 서비스 문자도 포함되어 있습니다. 실제로 직접 볼 수 있습니다.

표준이 된 것은 원래 ASCII 버전의 128개 문자이며, 다른 인코딩에서는 확실히 찾을 수 있으며 이 순서로 나타납니다.

그러나 사실 1바이트의 정보로 128개가 아니라 최대 256개의 서로 다른 값(2의 8승은 256)을 인코딩할 수 있으므로 Asuka의 기본 버전 이후에는 전체 시리즈가 확장된 ASCII 인코딩, 128개의 기본 문자 외에도 국가 인코딩 기호(예: 러시아어)를 인코딩하는 것도 가능했습니다.

여기에서는 설명에 사용되는 숫자 체계에 대해 좀 더 이야기해 볼 가치가 있을 것입니다. 첫째, 여러분 모두 알고 있듯이 컴퓨터는 이진법의 숫자, 즉 0과 1(누군가 기관이나 학교에서 배운 경우 "부울 대수학")로만 작동합니다. , 각각은 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가 있는 해당 행과 16진수 체계에서 숫자 C가 있는 열의 교차점에 위치함)를 가지며, 이는 1바이트의 정보로 쓸 수 있습니다. 러시아어 문자에 적합한 글꼴이 있으면 문제 없이 이 문자가 텍스트에 나타납니다.

이 금액은 어디서 나온 걸까요? CP866의 의사그래픽? 요점은 러시아어 텍스트에 대한 이 인코딩이 그래픽 운영 체제가 지금만큼 널리 퍼지지 않았던 얽히고 설킨 시절에 개발되었다는 것입니다. 그리고 Dosa 및 유사한 텍스트 운영 체제에서는 의사 그래픽을 통해 적어도 텍스트 디자인을 다양화할 수 있었기 때문에 CP866과 확장 버전 Asuka 범주의 다른 모든 동료가 풍부합니다.

CP866은 IBM에서 배포했지만 이 외에도 러시아어 문자에 대한 여러 인코딩이 개발되었습니다. 예를 들어 동일한 유형(확장 ASCII)이 속성화될 수 있습니다. KOI8-R:

작동 원리는 앞서 설명한 CP866의 작동 원리와 동일합니다. 즉, 텍스트의 각 문자는 1바이트로 인코딩됩니다. 스크린샷은 KOI8-R 테이블의 후반부를 보여줍니다. 전반부는 이 기사의 첫 번째 스크린샷에 표시된 기본 Asuka와 완전히 일치합니다.

KOI8-R 인코딩의 기능 중 예를 들어 CP866에서와 같이 테이블의 러시아어 문자가 알파벳 순서가 아니라는 점을 알 수 있습니다.

(모든 확장 인코딩에 포함된 기본 부분의) 첫 번째 스크린샷을 보면 KOI8-R에서 러시아어 문자가 라틴 알파벳의 해당 문자와 ​​동일한 테이블 셀에 있음을 알 수 있습니다. 테이블의 첫 번째 부분부터. 이는 1비트(2의 7승 또는 128)만 삭제하여 러시아어에서 라틴 문자로 편리하게 전환하기 위해 수행되었습니다.

Windows 1251 - 최신 버전의 ASCII 및 균열이 나타나는 이유

텍스트 인코딩의 추가 개발은 그래픽 운영 체제가 인기를 얻고 시간이 지남에 따라 의사 그래픽을 사용할 필요성이 사라졌기 때문입니다. 결과적으로, 본질적으로 여전히 Asuka의 확장 버전(텍스트의 한 문자는 단 1바이트의 정보로 인코딩됨)이지만 의사 기호를 사용하지 않는 전체 그룹이 나타났습니다.

이는 American Standards Institute에서 개발한 소위 ANSI 인코딩에 속합니다. 일반적으로 키릴 문자라는 이름은 러시아어를 지원하는 버전에도 사용되었습니다. 이에 대한 예가 될 것입니다.

이전에 사용된 CP866 및 KOI8-R과는 의사 그래픽 기호의 위치가 러시아어 타이포그래피의 누락된 기호(악센트 표시 제외)와 가까운 슬라브어에서 사용되는 기호에 의해 사용된다는 점에서 유리하게 달랐습니다. 러시아어(우크라이나어, 벨로루시어 등):

러시아어 인코딩이 너무 풍부하기 때문에 글꼴 제조업체와 소프트웨어 제조업체는 끊임없이 골치 아픈 일을 겪었고 독자 여러분, 여러분과 저는 종종 똑같은 악명을 얻었습니다. 크라코자브리본문에 사용된 버전과 혼동이 있었을 때.

이메일로 메시지를 주고받을 때 자주 나오는데, 이로 인해 매우 복잡한 변환표가 생성되어 실제로 이 문제를 근본적으로 해결할 수 없었고, 사용자는 악명 높은 속임수를 피하기 위해 서신에 자주 사용했습니다. CP866, KOI8-R 또는 Windows 1251과 같은 러시아어 인코딩.

실제로 러시아어 텍스트 대신 나타나는 균열은 이 언어의 인코딩을 잘못 사용한 결과였으며 이는 문자 메시지가 원래 인코딩된 언어와 일치하지 않습니다.

Windows 1251 코드 테이블을 사용하여 CP866을 사용하여 인코딩된 문자를 표시하려고 하면 동일한 횡설수설(의미 없는 문자 집합)이 나와서 메시지 텍스트를 완전히 대체한다고 가정해 보겠습니다.

유사한 상황은 포럼이나 블로그에서 자주 발생합니다. 러시아어 문자가 포함된 텍스트가 기본적으로 사이트에서 사용되는 잘못된 인코딩으로 실수로 저장되거나 잘못된 텍스트 편집기에 저장되어 표시되지 않는 코드에 개그가 추가되는 경우입니다. 육안.

결국 많은 사람들은 많은 인코딩과 끊임없이 쓰레기를 쏟아내는 이러한 상황에 지쳤으며 기존의 모든 변형을 대체하고 마침내 외관 문제를 해결할 새로운 보편적 변형을 만들기 위한 전제 조건이 나타났습니다. 읽을 수 없는 텍스트. 게다가 중국어 같은 언어는 256자보다 훨씬 더 많은 언어 문자가 있다는 문제도 있었다.

유니코드 - 범용 인코딩 UTF 8, 16 및 32

동남아시아 언어 그룹의 이러한 수천 개의 문자는 ASCII 확장 버전의 문자 인코딩에 할당된 1바이트 정보로는 도저히 설명할 수 없습니다. 그 결과 '컨소시엄'이 탄생했다. 유니코드(유니코드 - 유니코드 컨소시엄)은 범용 텍스트 인코딩의 출현에 관심이 있는 많은 IT 업계 리더(소프트웨어 생산자, 하드웨어 인코딩자, 글꼴 생성자)의 협력을 통해 만들어졌습니다.

유니코드 컨소시엄(Unicode Consortium)의 후원으로 출시된 첫 번째 변형은 UTF32. 인코딩 이름의 숫자는 하나의 문자를 인코딩하는 데 사용되는 비트 수를 의미합니다. 32비트는 새로운 범용 UTF 인코딩에서 단일 문자 하나를 인코딩하는 데 필요한 정보 4바이트와 같습니다.

결과적으로 ASCII 확장 버전과 UTF-32(후자의 경우)로 인코딩된 텍스트가 있는 동일한 파일의 크기(무게)는 4배 더 커집니다. 이것은 좋지 않지만 이제 YTF를 사용하여 2의 30제곱에 해당하는 문자 수를 인코딩할 수 있는 기회가 있습니다( 수십억 개의 문자, 엄청난 마진으로 정말 필요한 값을 모두 다룰 것입니다).

그러나 유럽 그룹의 언어를 사용하는 많은 국가에서는 인코딩에 그렇게 많은 문자를 사용할 필요가 없었지만 UTF-32를 사용할 때 아무 이유없이 텍스트 문서의 무게가 4배 증가했습니다. 그 결과 인터넷 트래픽의 양과 저장되는 데이터의 양이 증가합니다. 이것은 많은 일이며 누구도 그런 낭비를 감당할 수 없습니다.

유니코드의 발전으로 인해 UTF-16, 이는 매우 성공적인 것으로 판명되어 우리가 사용하는 모든 캐릭터의 기본 공간으로 기본적으로 채택되었습니다. 한 문자를 인코딩하는 데 2바이트를 사용합니다. 이것이 어떻게 보이는지 봅시다.

Windows 운영 체제에서는 "시작" - "프로그램" - "보조프로그램" - "시스템 도구" - "문자표" 경로를 따라갈 수 있습니다. 결과적으로 시스템에 설치된 모든 글꼴의 벡터 모양이 포함된 표가 열립니다. "고급 옵션"에서 유니코드 문자 세트를 선택하면 각 글꼴에 포함된 전체 문자 범위를 개별적으로 볼 수 있습니다.

그건 그렇고, 그 중 하나를 클릭하면 2 바이트를 볼 수 있습니다 UTF-16 형식의 코드, 4개의 16진수 숫자로 구성됩니다.

16비트를 사용하여 UTF-16으로 인코딩할 수 있는 문자 수는 몇 개입니까? 65,536(2의 16제곱)이며 이는 유니코드에서 기본 공백으로 채택된 숫자입니다. 또한 이를 이용하여 약 200만 글자를 인코딩하는 방법도 있지만, 이는 100만 글자의 텍스트라는 확장된 공간에 국한되었다.

그러나 이 성공적인 유니코드 인코딩 버전조차도 영어로만 프로그램을 작성한 사람들에게는 큰 만족을 주지 못했습니다. 왜냐하면 확장 버전의 ASCII에서 UTF-16으로 전환한 후 문서의 무게가 두 배로 늘어났기 때문입니다. Aski에서는 문자당 1바이트이고 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가 어떻게 나타나는지, 즉 러시아어 텍스트에 대한 올바른 인코딩이 선택되는 방법을 살펴보겠습니다. 실제로 이는 바로 이 텍스트 또는 텍스트 조각을 사용하는 코드를 생성하거나 편집하는 프로그램에서 설정됩니다.

텍스트 파일을 편집하고 생성하기 위해 저는 개인적으로 아주 좋은 . 그러나 수백 가지 다른 프로그래밍 및 마크업 언어의 구문을 강조할 수 있으며 플러그인을 사용하여 확장할 수도 있습니다. 제공된 링크에서 이 훌륭한 프로그램에 대한 자세한 리뷰를 읽어보세요.

Notepad++의 상단 메뉴에는 "인코딩" 항목이 있으며, 여기서 기존 옵션을 사이트에서 기본적으로 사용되는 옵션으로 변환할 수 있습니다.

Joomla 1.5 이상의 사이트와 WordPress 블로그의 경우 크랙이 발생하지 않도록 옵션을 선택해야 합니다. 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 선언을 생략할 수 있다는 것입니다(인코딩은 BOM이 없으면 UTF-8로 간주되고 BOM이 있으면 UTF-16으로 간주됩니다).

HTML 언어 문서의 경우 인코딩은 다음을 나타내는 데 사용됩니다. 메타 요소, 이는 여는 Head 태그와 닫는 Head 태그 사이에 작성됩니다.

... ...

이 항목은 채택된 항목과 상당히 다르지만 천천히 도입되고 있는 새로운 Html 5 표준을 완전히 준수하며 현재 사용되는 모든 브라우저에서 완전히 올바르게 이해될 것입니다.

이론적으로는 Html 문서 인코딩을 나타내는 Meta 요소를 배치하는 것이 더 좋습니다. 문서 헤더에서 가능한 한 높게따라서 기본 ANSI가 아닌 텍스트의 첫 번째 문자(항상 올바르게 읽혀지고 변형된 문자)를 발견할 때 브라우저는 이러한 문자의 코드를 해석하는 방법에 대한 정보를 이미 가지고 있어야 합니다.

행운을 빕니다! 블로그 사이트 페이지에서 곧 뵙겠습니다.

에 가시면 더 많은 영상을 보실 수 있습니다

당신은 관심이 있을 수도 있습니다

URL 주소란 무엇이며, 사이트의 절대 링크와 상대 링크는 어떻게 다릅니까?
OpenServer - 최신 로컬 서버 및 이를 사용하여 컴퓨터에 WordPress를 설치하는 방법의 예
Chmod란 무엇이며, 파일 및 폴더(777, 755, 666)에 할당할 권한 및 PHP를 통해 이를 수행하는 방법
사이트 및 온라인 상점별 Yandex 검색

문자 오버레이

BS(백스페이스) 문자를 사용하면 프린터에서 한 문자 위에 다른 문자를 인쇄할 수 있습니다. 이러한 방식으로 문자에 발음 구별 부호를 추가하기 위해 ASCII가 제공되었습니다. 예를 들면 다음과 같습니다.

• BS "→ á
• a BS ` → à
• 학사 ^ → â
• o BS / → ø
• c 학사 , → ç
• n 학사 ~ → с

메모: 예전 글꼴에서는 아포스트로피 "를 왼쪽으로 비스듬히 그려넣고 물결표 ~를 위로 옮겨서 예각과 상단의 물결표 역할에 딱 맞습니다.

동일한 문자가 문자 위에 겹쳐지면 굵은 글꼴 효과가 나타나고, 밑줄이 문자 위에 겹쳐지면 밑줄이 그어진 텍스트가 됩니다.

• 학사 a → ㅏ
• ABS_→ ㅏ

메모: 이는 예를 들어 사람 도움말 시스템에서 사용됩니다.

국가별 ASCII 변형

ISO 646(ECMA-6) 표준은 국가 기호를 제자리에 배치할 수 있는 가능성을 제공합니다. @ [ \ ] ^ ` { | } ~ . 이 외에도 현장에서 # 게시할 수 있다 £ , 그리고 그 자리에 $ - ¤ . 이 시스템은 몇 개의 추가 문자만 필요한 유럽 언어에 매우 적합합니다. 국가별 문자가 없는 ASCII 버전을 US-ASCII 또는 "국제 참조 버전"이라고 합니다.

결과적으로 코드 테이블의 하위 절반(0-127)은 US-ASCII 문자로 사용되고 상위 절반(128-255)은 8비트 인코딩(코드 페이지)을 사용하는 것이 더 편리한 것으로 나타났습니다. 국가 문자 세트를 포함한 추가 문자로. 따라서 유니코드가 널리 채택되기 전에 ASCII 테이블의 위쪽 절반은 지역화된 문자, 즉 지역 언어 문자를 나타내는 데 적극적으로 사용되었습니다. ASCII 테이블에 키릴 문자를 배치하기 위한 통일된 표준이 없기 때문에 인코딩에 많은 문제가 발생했습니다(KOI-8, Windows-1251 및 기타). 라틴어가 아닌 스크립트를 사용하는 다른 언어도 여러 가지 다른 인코딩으로 인해 어려움을 겪었습니다.

주소를 지정할 수 있는 최소 메모리 단위가 36비트 워드인 컴퓨터에서는 처음에는 6비트 문자가 사용되었습니다(1워드 = 6자). ASCII로 전환한 후 이러한 컴퓨터는 한 단어에 5개의 7비트 문자(1비트는 추가로 남음) 또는 4개의 9비트 문자를 포함하기 시작했습니다.

ASCII 코드는 프로그래밍 중에 어떤 키를 누르는지 결정하는 데에도 사용됩니다. 표준 QWERTY 키보드의 경우 코드 테이블은 다음과 같습니다.