Python 프로그래밍의 역사적 발전

소개	일단 프로그래밍의 길에 들어서더라도 코딩 문제를 파악하지 못하면 경력 전반에 걸쳐 유령처럼 당신을 괴롭힐 것이며, 다양한 초자연적인 사건들이 연달아 뒤따르며 오래 머물게 될 것입니다. 끝까지 싸우는 프로그래머의 정신을 최대한 발휘해야만 코딩 문제로 인한 문제를 완전히 없앨 수 있습니다.

처음 코딩 문제를 접한 것은 JavaWeb 관련 프로젝트를 작성할 때였습니다. 브라우저에서 애플리케이션 코드까지 문자열이 떠돌다가 데이터베이스에 스며들면 언제든지 코딩 광산을 밟을 수 있습니다. 어딘가에. 두 번째로 코딩 문제를 접한 것은 Python을 배울 때였습니다. 웹 페이지 데이터를 크롤링할 때 코딩 문제가 다시 나타났습니다. 그때 요즘 가장 인기 있는 문장은 "그때 혼란스러웠습니다." .

문자 인코딩을 이해하려면 컴퓨터의 기원부터 시작해야 합니다. 텍스트, 사진, 비디오, 오디오 파일 등 컴퓨터의 모든 데이터는 기본적으로 01010101과 유사한 디지털 형식으로 저장됩니다. 다행스럽게도 시대는 우리에게 컴퓨터를 접할 수 있는 기회를 주었습니다. 불행하게도 컴퓨터는 우리 나라 사람들이 발명한 것이 아니므로 컴퓨터의 표준은 그 사람들의 습관에 따라 설계되어야 합니다. 미국 제국. 결국 컴퓨터는 처음에 문자를 어떻게 표현했는가? 이는 컴퓨터 코딩의 역사에서 시작됩니다.

ASCII

JavaWeb 개발을 수행하는 모든 초보자는 잘못된 코드 문제에 직면하게 되며, Python 크롤러를 수행하는 모든 초보자는 인코딩 문제에 직면하게 됩니다. 왜 인코딩 문제가 그렇게 고통스럽습니까? 이 문제는 Guido van Rossum이 1992년에 Python 언어를 만들면서 시작되었습니다. 당시 Guido는 Python 언어가 오늘날 이렇게 인기를 끌 것이라고는 전혀 예상하지 못했고, 컴퓨터 개발 속도가 이렇게 놀라울 것이라고는 예상하지도 못했습니다. Guido는 원래 이 언어를 설계할 때 인코딩에 신경 쓸 필요가 없었습니다. 왜냐하면 영어 세계에서는 문자 수가 26자(대소문자), 10자 숫자, 구두점 및 제어 문자로 매우 제한되어 있기 때문입니다. , 키보드에서 모든 키에 해당하는 문자를 합하면 100개가 조금 넘습니다. 이는 1바이트가 8비트에 해당하고 8비트는 256개의 기호를 나타낼 수 있기 때문에 컴퓨터에서 1바이트의 저장 공간을 사용하여 1문자를 표현하기에 충분합니다. 그래서 똑똑한 미국인들은 ASCII(American Standard Code for Information Interchange)라는 문자 인코딩 표준 세트를 개발했습니다. 각 문자는 고유한 숫자에 해당합니다. 예를 들어 문자 A에 해당하는 이진수 값은 01000001이고 해당 십진수 값은 65입니다. 처음에 ASCII는 96개의 텍스트와 32개의 제어 기호를 포함하여 총 128개의 문자 코드만 정의했습니다. 모든 문자를 표현하려면 1바이트의 7비트만 필요하므로 ASCII는 마지막 7비트와 1바이트만 사용합니다. 가장 높은 비트는 모두 0이다.

EASCII(ISO/8859-1)

그러나 컴퓨터가 서서히 다른 서유럽 지역으로 확산되면서 ASCII 인코딩 테이블에 없는 서유럽 고유의 문자가 많이 있다는 사실을 발견하여 이름에서 알 수 있듯이 나중에 EASCII라는 확장 가능한 ASCII가 등장했습니다. 7비트에서 8비트까지 확장된 ASCII에서는 확장된 기호에는 테이블 기호, 계산 기호, 그리스 문자 및 특수 라틴 기호가 포함됩니다. 그러나 EASCII 시대는 통일된 표준이 없는 시대입니다. 그들은 각자의 표준에 따라 자체 문자 인코딩 표준 세트를 구현하기 위해 가장 유명한 것은 CP437입니다. 아래와 같이 Windows 시스템에서 사용됩니다.

널리 사용되는 또 다른 EASCII는 ISO/8859-1(Latin-1)입니다. 이는 국제 표준화 기구(ISO)와 국제 전기 기술 위원회(IEC)가 공동으로 개발한 일련의 8비트 문자 집합 표준입니다. /8859-1은 CP437 문자 인코딩의 128-159 사이의 문자만 상속하므로 160부터 정의됩니다. 불행하게도 이러한 수많은 ASCII 확장 문자 세트는 서로 호환되지 않습니다.

GBK

시대가 발전하면서 컴퓨터는 수천 가구에 퍼지기 시작했고, 빌 게이츠는 모든 사람이 데스크탑에 컴퓨터를 가질 수 있게 해주었습니다. 그러나 컴퓨터가 중국에 진출할 때 직면하게 되는 한 가지 문제는 문자 인코딩이다. ASCII 인코딩이 표현할 수 있는 것보다 훨씬 뛰어납니다. EASCII조차도 양동이에 떨어지는 것처럼 보였기 때문에 똑똑한 중국인은 GB0이라고도 알려진 GB2312라는 자체 코드 세트를 만들었습니다. 이 코드는 국가 표준 관리국에서 발표했습니다. 1981년 중국. GB2312 인코딩에는 총 6763개의 한자가 포함되어 있으며 ASCII와도 호환됩니다. GB2312의 출현은 기본적으로 한자의 컴퓨터 처리 요구를 충족합니다. 여기에 포함된 한자는 중국 본토에서 사용되는 빈도의 99.75%를 차지합니다. 그러나 GB2312는 여전히 한자의 요구 사항을 100% 충족할 수 없습니다. GB2312는 일부 희귀 문자와 전통 문자를 처리할 수 없습니다. 나중에 GB2312를 기반으로 GBK라는 코드가 만들어졌습니다. GBK에는 27,484개의 한자뿐만 아니라 티베트어, 몽골어, 위구르어 등 주요 소수민족 언어도 포함되어 있습니다. 마찬가지로 GBK도 ASCII 인코딩과 호환됩니다. 영어 문자는 1바이트로 표시되고 중국어 문자는 2바이트로 표시됩니다.

유니코드

한자를 다루기 위해 별도의 산꼭대기를 설치하고 필요에 따라 일련의 코딩 표준을 개발할 수 있습니다. 그러나 컴퓨터는 미국인과 중국인뿐만 아니라 유럽과 아시아의 다른 나라의 문자도 사용합니다. 일본어 등 전 세계적으로 수십만 개의 한국어 문자가 있는 것으로 추정되는데, 이는 ASCII 코드나 심지어 GBK가 표현할 수 있는 범위를 훨씬 뛰어넘는 것입니다. 게다가 사람들은 왜 GBK 표준을 사용합니까? 이렇게 거대한 문자 라이브러리를 어떻게 표현할까요? 그래서 United Alliance International Organization에서는 유니코드 인코딩을 제안했습니다. 유니코드의 학명은 "Universal Multiple-Octet Coded Character Set", 즉 UCS입니다.

유니코드에는 UCS-2와 UCS-4의 두 가지 형식이 있습니다. UCS-2는 2바이트를 사용하여 총 16비트를 인코딩합니다. 이론적으로는 최대 65536자를 표현할 수 있지만, 전 세계의 모든 문자를 표현하려면 거의 65536개의 문자가 있기 때문에 65536개 숫자로는 충분하지 않습니다. 문자만 100,000이므로 유니코드 4.0 사양은 추가 문자 인코딩 세트를 정의합니다. UCS-4는 4바이트를 사용합니다(실제로는 31비트만 사용되며 가장 높은 비트는 0이어야 합니다).
유니코드는 이론적으로 모든 언어에서 사용되는 기호를 다룰 수 있습니다. 세계의 모든 문자는 유니코드 인코딩으로 표시될 수 있습니다. 문자의 유니코드 인코딩이 결정되면 변경되지 않습니다. 그러나 유니코드에는 특정 제한이 있습니다. 유니코드 문자가 네트워크에서 전송되거나 최종적으로 저장될 때 반드시 각 문자에 대해 2바이트가 필요하지는 않습니다. 예를 들어, "A"라는 문자 하나는 1바이트로 표현될 수 있습니다. 2바이트인데 이는 분명히 공간 낭비입니다. 두 번째 문제는 유니코드 문자가 컴퓨터에 저장되면 01 숫자의 문자열이라는 것입니다. 그러면 2바이트 유니코드 문자가 2바이트 문자를 나타내는지 아니면 두 개의 1바이트 문자를 나타내는지 컴퓨터는 어떻게 알 수 있습니까? 컴퓨터에게 미리 말하지 않으면 컴퓨터도 혼란스러워질 것입니다. 유니코드는 인코딩 방법만 규정할 뿐, 이 인코딩을 전송하거나 저장하는 방법은 지정하지 않습니다. 예를 들어, 문자 "汉"의 유니코드 인코딩은 6C49입니다. 이 인코딩을 전송하고 저장하기 위해 4개의 ASCII 숫자를 사용할 수 있으며 UTF-8로 인코딩된 3개의 연속 바이트를 사용할 수도 있습니다. 핵심은 의사소통의 양쪽 당사자가 동의해야 한다는 것입니다. 따라서 유니코드 인코딩에는 UTF-8, UTF-16 등과 같은 다양한 구현 방법이 있습니다. 여기서 유니코드는 영어와 마찬가지로 국가 간 통신을 위한 보편적인 표준으로, 각 국가마다 고유한 언어가 있으며, 이는 UTF-8과 마찬가지로 표준 영어 문서를 자국의 텍스트로 변환하는 방식입니다.

UTF-8

UTF-8(Unicode Transformation Format)은 유니코드를 구현한 것으로 인터넷에서 널리 사용되며, 특정 상황에 따라 문자를 표현하기 위해 1~4바이트를 사용할 수 있는 가변 길이 문자 인코딩입니다. 예를 들어 원래 ASCII 코드로 표현할 수 있는 영어 문자를 UTF-8로 표현하면 ASCII와 동일한 1바이트의 공백만 있으면 됩니다. 멀티바이트(n바이트) 문자의 경우 첫 번째 바이트의 처음 n 비트는 1로 설정되고, n+1번째 비트는 0으로 설정되며, 다음 바이트의 처음 2비트는 10으로 설정됩니다. 나머지 이진수는 해당 문자의 유니코드 코드로 채워집니다.

한자 "好"를 예로 들면, "好"에 해당하는 유니코드는 597D이고, 해당 간격은 0000 0800 - 0000 FFFF이므로 UTF-8로 표현하면 저장하는데 3바이트가 필요하다. 597D는 이진수로 표현됩니다: 0101100101111101, 1110xxxx 10xxxxxx 10xxxxxx를 입력하여 11100101 10100101 10111101을 얻고 16진수로 변환: E5A5BD이므로 "좋은" 유니코드 "597D"에 해당하는 UTF-8 인코딩은 "E5A5BD입니다. ".

중국어 OK
유니코드 0101 100101 111101
인코딩 규칙 1110xxxx 10xxxxxx 10xxxxxx
-------------
UTF-8 11100101 10100101 10111101
-------------
16진수 utf-8 e 5 a 5 b d Python 문자 인코딩

이제 드디어 이론이 끝났습니다. Python의 코딩 문제에 대해 이야기해 보겠습니다. Python은 유니코드보다 훨씬 일찍 탄생했으며 Python의 기본 인코딩은 ASCII입니다.
>>> 시스템 가져오기
>>>sys.getdefaultencoding()
'아스키'
따라서 Python 소스 코드 파일에 인코딩을 명시적으로 지정하지 않으면 구문 오류가 발생합니다

으아악

"안녕하세요" 인쇄
위는 test.py 스크립트입니다.

를 실행하세요. 으아악

다음 오류가 포함됩니다:

으아악

소스 코드에서 ASCII가 아닌 문자를 지원하려면 소스 파일의 첫 번째 또는 두 번째 줄에 인코딩 형식을 명시적으로 지정해야 합니다.

으아악

또는:

으아악

Python에서 문자열과 관련된 데이터 유형은 str과 unicode입니다. 둘 다 basestring의 하위 클래스입니다. str과 unicode는 두 가지 다른 유형의 문자열 객체임을 알 수 있습니다.

으아악

같은 한자 "好"에 대해 str로 표현하면 UTF-8 인코딩 '/xe5/xa5/xbd'에 해당하고, 유니코드로 표현하면 해당 기호는 u'/u597d'입니다. 는 "좋다"와 같습니다. str 유형 문자의 특정 인코딩 형식은 운영 체제에 따라 UTF-8, GBK 또는 기타 형식이라는 점을 추가해야 합니다. 예를 들어 Windows 시스템에서는 cmd 명령줄에 다음이 표시됩니다.

으아악

Linux 시스템의 명령줄에 표시되는 내용은 다음과 같습니다.

으아악

Python3x, Java 또는 기타 프로그래밍 언어이든 유니코드 인코딩은 해당 언어의 기본 인코딩 형식이 되었습니다. 데이터가 최종적으로 미디어에 저장되면 다른 미디어는 다른 방법을 사용할 수 있습니다. 그리고 일부 사람들이 GBK를 사용하기를 좋아하는지 여부는 중요하지 않습니다. 플랫폼에 통일된 코딩 표준이 있는 한 구현 방법은 중요하지 않습니다.

str을 유니코드로 변환

그렇다면 Python에서 str과 유니코드를 어떻게 변환하나요? 이 두 가지 유형의 문자열 유형 간의 변환은 디코드와 인코딩이라는 두 가지 방법에 의존합니다.

으아악

This'/xe5/xa5/xbd'는 encode 함수를 통해 유니코드 u'ha'로 인코딩된 UTF-8로 인코딩된 str 유형 문자열입니다. 반대로, str 유형 c는 decode 함수를 통해 유니코드 문자열 d로 디코딩됩니다.

str(들) 대 유니코드

str(s) 및 unicode(s)는 각각 str 문자열 객체를 반환하는 두 개의 팩토리 메서드이고, str(s)는 s.encode('ascii')의 약어입니다. 실험:

으아악

위 s3은 유니코드 형식의 문자열입니다. str(s3)은 s3.encode('ascii')를 실행하는 것과 동일합니다. 두 개의 한자 "Hello"는 ASCII 코드로 표시할 수 없으므로 오류가 보고됩니다. 인코딩: s3.encode('gbk') 또는 s3.encode('utf-8') 은 이 문제를 일으키지 않습니다. 비슷한 유니코드에도 같은 오류가 있습니다:

으아악

unicode(s4)는 s4.decode('ascii')
와 동일합니다. 이므로 올바른 변환을 위해서는 인코딩 s4.decode('gbk') 또는 s4.decode('utf-8')를 올바르게 지정해야 합니다.

깨진 코드

문자가 왜곡되는 모든 이유는 다음과 같이 다양한 인코딩 및 디코딩 후 문자 인코딩 프로세스에 사용되는 일관되지 않은 인코딩 형식 때문일 수 있습니다.

으아악

UTF-8로 인코딩된 문자 '好'는 3바이트를 차지합니다. 유니코드로 디코딩한 후 GBK를 사용하여 디코딩하면 결국 문자 길이가 2바이트만 나타나게 되므로 문자 깨짐을 방지하세요. 가장 좋은 방법은 항상 동일한 인코딩 형식을 사용하여 문자를 인코딩하고 디코딩하는 것입니다.

기타 팁

유니코드 형식의 문자열(str 유형):

으아악

실제 유니코드로 변환하려면 다음을 사용해야 합니다.

으아악

테스트:

으아악

위의 코드와 개념은 Python2.x를 기반으로 합니다.

위 내용은 Python 프로그래밍의 역사적 발전의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!