UTF-8과 GBK UTF8 GB2312의 차이점은 무엇입니까

이 기사의 내용은 UTF-8과 GBK UTF8 GB2312의 차이점에 대한 것입니다. 필요한 친구가 참고할 수 있기를 바랍니다.

UTF-8: Unicode TransformationFormat-8bit, BOM이 허용되지만 일반적으로 BOM을 포함하지 않습니다. 국제 문자를 해결하는 데 사용되는 멀티바이트 인코딩입니다. 영어의 경우 8비트(즉, 1바이트)를 사용하고 중국어의 경우 24비트(3바이트)를 사용합니다. UTF-8은 전 세계 모든 국가에서 필요로 하는 문자를 포함하며 국제적인 인코딩이며 다양한 용도로 사용됩니다. UTF-8로 인코딩된 텍스트는 UTF8 문자 집합을 지원하는 다양한 국가의 브라우저에 표시될 수 있습니다. 예를 들어 UTF8 인코딩인 경우 외국인의 영어 IE에서도 중국어가 표시될 수 있으므로 IE의 중국어 지원 패키지를 다운로드할 필요가 없습니다.

GBK는 국가 표준 GB2312을 기반으로 한 표준이며 확장 후 GB2312와 호환됩니다. GBK의 텍스트 인코딩은 더블바이트로 표현됩니다. 즉, 한자와 영어 문자 모두 더블바이트로 표현됩니다. 한자를 구별하기 위해 최상위 비트가 1로 설정됩니다. GBK는 모든 중국어 문자를 포함하며 UTF8보다 다목적성이 떨어지지만 UTF8은 GBK보다 더 큰 데이터베이스를 차지합니다.

GBK, GB2312 등은 유니코드 인코딩을 통해 UTF8로 변환되어야 합니다:
GBK, GB2312--Unicode--UTF8
UTF8--Unicode--GBK, GB2312

pCSS5는 단순히 기능적입니다:

1, GBK는 일반적으로 간체 한자

만 지원하는 GB2312 인코딩을 의미합니다. 2, utf는 일반적으로 UTF-8을 의미하며 간체 한자, 중국어 번체 문자, 영어, 일본어, 한국어 및 기타 언어를 지원합니다. (더 넓은 범위의 텍스트 지원)

3. 중국에서는 일반적으로 UTF-8 및 gb2312를 사용합니다. 필요에 따라 선택하세요.

구체적인 세부 사항은 다음과 같습니다.

웹사이트 또는 포럼의 경우 영어 문자가 많으면 공간을 절약하기 위해 UTF-8을 사용하는 것이 좋습니다. 그러나 현재 많은 포럼 플러그인은 일반적으로 GBK만 지원합니다.
인코딩 차이점에 대한 자세한 설명
간단히 말하면 유니코드, gbk, 빅파이브 코드가 인코딩된 값이고, utf-8, uft-16 등이 이 값의 표현입니다. 앞의 3개 코드는 동일한 한자에 대해 3개의 코드 값이 완전히 다릅니다. 예를 들어 "중국어"의 언코드 값이 gbk의 값과 다르다고 가정하면, 언코드가 a040이고 gbk가 b030이고, uft-8 코드가 그 값을 표현한 형태라고 가정해보자. utf-8 코드는 완전히 uncode용으로만 구성되어 있습니다. GBK가 UTF-8로 변환하려면 먼저 uncode로 변환한 후 utf-8로 변환하면 괜찮습니다.

자세한 내용은 아래 글을 참고해주세요.

유니코드 인코딩에 대해 이야기하고 UCS, UTF, BMP, BOM 등과 같은 용어를 간략하게 설명합니다.
이 글은 프로그래머를 위해 프로그래머가 쓴 흥미로운 읽기입니다. 소위 재미란 이전에 명확하지 않았던 일부 개념을 쉽게 이해하고 지식을 향상시킬 수 있다는 것을 의미하며 이는 RPG 게임의 업그레이드와 유사합니다. 이 글을 구성하게 된 동기는 두 가지 질문입니다:

질문 1:
Windows 메모장의 "다른 이름으로 저장"을 사용하면 GBK, 유니코드, 유니코드 빅 엔디안 및 UTF-8 인코딩 방법 간에 변환할 수 있습니다. txt 파일이기도 합니다. Windows는 인코딩 방법을 어떻게 식별합니까?

저는 오래 전에 유니코드, 유니코드 빅엔디안 및 UTF-8로 인코딩된 txt 파일의 시작 부분에 FF, FE(유니코드), FE, FF(유니코드 빅엔디안), EF, BB와 같은 몇 바이트가 더 있다는 것을 발견했습니다. , BF(UTF-8). 그러면 이러한 마커는 어떤 기준을 기반으로 하는 것일까요?

질문 2:
최근 인터넷에서 UTF-32, UTF-16 및 UTF-8 인코딩 방법의 상호 변환을 구현하는 ConvertUTF.c를 보았습니다. 유니코드 인코딩(UCS2), GBK, UTF-8과 같은 인코딩 방법에 대해 이미 알고 있습니다. 하지만 이 프로그램은 나를 약간 혼란스럽게 만들고 UTF-16과 UCS2의 관계가 무엇인지 기억이 나지 않습니다.
관련 정보를 확인한 후 마침내 이러한 문제를 명확히 했고 유니코드에 대한 세부 정보도 배웠습니다. 기사를 작성하고 비슷한 질문이 있는 친구에게 보내보세요. 이 기사는 가능한 한 이해하기 쉽게 작성되었지만 독자는 바이트가 무엇인지, 16진수가 무엇인지 알아야 합니다.

0, 빅 엔디안과 리틀 엔디안
빅 엔디안과 리틀 엔디안은 CPU가 멀티바이트 숫자를 처리하는 다른 방식입니다. 예를 들어 "汉" 문자의 유니코드 인코딩은 6C49입니다. 그러면 파일에 쓸 때 6C를 앞에 써야 할까요, 아니면 49를 앞에 써야 할까요? 앞에 6C라고 쓰면 빅엔디안이다. 앞에 49가 적혀 있으면 리틀 엔디안입니다.

"엔디안"이라는 단어는 "걸리버 여행기"에서 유래되었습니다. 릴리푸트 내전은 빅엔디안과 리틀엔디안 중 어느 쪽의 알을 깨뜨릴 것인가에 따라 일어났고, 그 결과 여섯 명의 황제가 목숨을 잃었고, 또 다른 황제는 왕좌를 잃었다.

우리는 일반적으로 엔디안을 "바이트 순서"로 번역하며, 빅엔디안과 리틀엔디안을 "빅엔드", "리틀엔드"라고 부릅니다.

1. 문자 인코딩, 내부 코드, 그리고 한자 인코딩
문자는 컴퓨터에서 처리되기 전에 인코딩되어야 합니다. 컴퓨터에서 사용되는 기본 인코딩 방법은 컴퓨터의 내부 코드입니다. 초기 컴퓨터는 중국어 문자를 처리하기 위해 7비트 ASCII 인코딩을 사용했습니다. 프로그래머는 중국어 간체용으로 GB2312를, 중국어 번체용으로 big5를 설계했습니다.

GB2312(1980)에는 한자 6763자와 기타 기호 682자를 포함하여 총 7445자가 포함되어 있습니다. 한자 영역의 내부 코드 범위는 상위 바이트는 B0~F7, 하위 바이트는 A1~FE이며, 점유되는 코드 비트는 72*94=6768이다. 그 중 5개의 공석은 D7FA-D7FE입니다.

GB2312는 한자가 너무 적습니다. 1995년 한자 확장 규격 GBK1.0에는 21,886개의 기호가 포함되어 있으며 이는 한자 영역과 그래픽 기호 영역으로 구분됩니다. 한자 영역에는 21003자가 포함됩니다.

ASCII, GB2312에서 GBK까지 이러한 인코딩 방법은 이전 버전과 호환됩니다. 즉, 동일한 문자는 이러한 구성표에서 항상 동일한 인코딩을 가지며 이후 표준은 더 많은 문자를 지원합니다. 이러한 인코딩에서는 영어와 중국어를 균일하게 처리할 수 있습니다. 중국어 인코딩을 구별하는 방법은 상위 바이트의 최상위 비트가 0이 아닌 것입니다. 프로그래머가 부르는 이름에 따르면 GB2312와 GBK는 모두 더블바이트 문자 집합(DBCS)에 속합니다.

GB18030은 2000년에 GBK1.0을 대체한 공식 국가 표준입니다. 이 표준에는 27,484개의 한자와 티베트어, 몽골어, 위구르어 및 기타 주요 소수민족 언어가 포함됩니다. 한자어휘 측면에서 GB18030은 GB13000.1의 20902자에 CJK 확장자 A(유니코드 코드 0x3400-0x4db5)의 6582자를 추가하여 총 27484자가 포함된다.

CJK는 중국, 일본, 한국을 의미합니다. 유니코드는 코드 비트를 절약하기 위해 중국, 일본, 한국 3개 언어의 문자를 균일하게 인코딩합니다. GB13000.1은 ISO/IEC 10646-1의 중국어 버전으로 유니코드 1.1과 동일합니다.

GB18030의 인코딩은 싱글바이트, 더블바이트 및 4바이트 방식을 채택합니다. 그중 싱글바이트, 더블바이트 및 GBK는 완벽하게 호환됩니다. 4바이트 인코딩의 코드 비트에는 CJK 확장 A의 한자 6582자가 포함되어 있습니다. 예를 들어 GB18030의 UCS 0x3400 인코딩은 8139EF30이어야 하고 GB18030의 UCS 0x3401 인코딩은 8139EF31이어야 합니다.

Microsoft에서는 GB18030에 대한 업그레이드 패키지를 제공하지만, 이 업그레이드 패키지는 CJK 확장자 A: New Song-Ti-18030의 6582자를 지원하는 새로운 글꼴만 제공하며 내부 코드는 변경하지 않습니다. Windows의 내부 코드는 여전히 GBK입니다.

여기에 몇 가지 세부 사항이 있습니다.

GB2312의 원본 텍스트는 여전히 지역 코드입니다. 지역 코드에서 내부 코드까지 각각 상위 바이트와 하위 바이트에 A0을 추가해야 합니다.

모든 문자 인코딩의 경우 엔디안과 관계없이 인코딩 체계에 따라 코딩 단위의 순서가 지정됩니다. 예를 들어, GBK의 코딩 단위는 바이트이고, 한자를 표현하는데 2바이트가 사용된다. 이 두 바이트의 순서는 고정되어 있으며 CPU 바이트 순서의 영향을 받지 않습니다. UTF-16의 인코딩 단위는 단어(더블바이트)입니다. 단어 사이의 순서는 인코딩 체계에 따라 지정됩니다. 단어 내의 바이트 배열만 엔디안의 영향을 받습니다. UTF-16은 나중에 도입될 예정입니다.

GB2312의 2바이트 중 가장 높은 비트는 모두 1입니다. 하지만 이 조건을 충족하는 코드 포인트는 128*128=16384개뿐입니다. 따라서 GBK와 GB18030의 하위 바이트의 최상위 비트는 1이 아닐 수 있습니다. 그러나 이는 DBCS 문자 스트림의 구문 분석에 영향을 주지 않습니다. DBCS 문자 스트림을 읽을 때 상위 비트가 1인 바이트가 발견되는 한 다음 두 바이트는 형식에 관계없이 더블 바이트로 인코딩될 수 있습니다. 낮은 바이트.높은 위치란 무엇입니까?

2, 유니코드, UCS 및 UTF
앞서 언급했듯이 ASCII, GB2312, GBK에서 GB18030까지의 인코딩 방법은 이전 버전과 호환됩니다. 유니코드는 ASCII(더 정확하게는 ISO-8859-1과 호환 가능)하고만 호환되며 GB 코드와는 호환되지 않습니다. 예를 들어 문자 "汉"의 유니코드 인코딩은 6C49이고 GB 코드는 BABA입니다.

유니코드도 문자 인코딩 방식이지만 세계 모든 언어를 수용할 수 있도록 국제기구에서 설계한 인코딩 방식입니다. 유니코드의 학명은 "UniversalMultiple-Octet Coded Character Set"이며, UCS라고도 합니다. UCS는 "Unicode CharacterSet"의 약자로 볼 수 있습니다.

Wikipedia(http://zh.wikipedia.org/wiki/)에 따르면: 역사적으로 유니코드를 독립적으로 설계하려고 시도한 두 조직, 즉 ISO(국제 표준화 기구)와 소프트웨어 제조업체 협회( unicode .org). ISO는 ISO 10646 프로젝트를 개발했고 유니코드 컨소시엄은 유니코드 프로젝트를 개발했습니다.

1991년경 양측은 호환되지 않는 두 개의 문자 집합이 필요하지 않다는 것을 깨달았습니다. 그래서 그들은 두 당사자의 작업을 병합하고 협력하여 단일 코딩 목록을 만들기 시작했습니다. 유니코드 2.0부터 유니코드 프로젝트는 ISO 10646-1과 동일한 글꼴을 사용합니다.

현재 두 프로젝트 모두 여전히 존재하며 각각의 표준을 독립적으로 게시합니다. 유니코드 컨소시엄의 최신 버전은 2005년 유니코드 4.1.0입니다. ISO의 최신 표준은 ISO 10646-3:2003입니다.

UCS에서는 인코딩 방법만 규정하고 있으며, 이 인코딩을 전송하거나 저장하는 방법은 지정하지 않습니다. 예를 들어 문자 "중국어"의 UCS 인코딩은 6C49입니다. 이 인코딩을 전송하고 저장하기 위해 4개의 ASCII 숫자를 사용할 수 있습니다. UTF-8 인코딩을 사용하여 이를 표현할 수도 있습니다. 핵심은 의사소통의 양쪽 당사자가 동의해야 한다는 것입니다. UTF-8, UTF-7 및 UTF-16은 모두 널리 사용되는 솔루션입니다. UTF-8의 특별한 이점은 ISO-8859-1과 완벽하게 호환된다는 것입니다. UTF는 "UCS 변환 형식"의 약어입니다.

IETF의 RFC2781 및 RFC3629는 RFC의 일관된 스타일로 UTF-16 및 UTF-8의 인코딩 방법을 명확하고 명확하며 엄격하게 설명합니다. IETF가 Internet Engineering Task Force의 약자라는 사실을 늘 잊어버리곤 합니다. 그러나 IETF가 관리하는 RFC는 인터넷상의 모든 사양의 기초입니다.

2.1, 내부 코드 및 코드 페이지
현재 Windows 커널은 이미 유니코드 문자 집합을 지원하므로 커널은 전 세계 모든 언어를 지원할 수 있습니다. 그러나 다수의 기존 프로그램과 문서는 GBK와 같은 특정 언어 인코딩을 사용하기 때문에 Windows가 기존 인코딩을 지원하지 않고 모두 유니코드를 사용하는 것은 불가능합니다.

Windows는 코드 페이지를 사용하여 다양한 국가 및 지역에 적응합니다. 코드페이지는 앞서 언급한 내부코드로 이해하면 된다. GBK에 해당하는 코드 페이지는 CP936입니다.

Microsoft에서는 GB18030에 대한 코드 페이지인 CP54936도 정의했습니다. 그러나 GB18030에는 일부 4바이트 인코딩이 있고 Windows 코드 페이지는 1바이트 및 2바이트 인코딩만 지원하므로 이 코드 페이지는 실제로 사용할 수 없습니다.

3, UCS-2, UCS-4, BMP
UCS에는 UCS-2와 UCS-4의 두 가지 형식이 있습니다. 이름에서 알 수 있듯이 UCS-2는 2바이트로 인코딩되고 UCS-4는 4바이트로 인코딩됩니다(실제로는 31비트만 사용되며 가장 높은 비트는 0이어야 함). 몇 가지 간단한 수학 게임을 해보겠습니다.

UCS-2에는 2^16=65536개의 코드 포인트가 있고 UCS-4에는 2^31=2147483648개의 코드 포인트가 있습니다.

UCS-4는 최고 비트가 0인 최고 바이트를 기준으로 2^7=128개의 그룹으로 나뉩니다. 각 그룹은 다음으로 높은 바이트를 기준으로 256개의 평면으로 나뉩니다. 각 평면은 세 번째 바이트를 기준으로 256개의 행(row)으로 나뉘며, 각 행에는 256개의 셀이 포함됩니다. 물론, 같은 행의 셀은 마지막 바이트만 다를 뿐 나머지는 동일합니다.

그룹 0의 평면 0을 기본 다국어 평면 또는 BMP라고 합니다. 또는 UCS-4에서는 상위 2바이트가 0인 코드 비트를 BMP라고 합니다.

UCS-4의 BMP에서 처음 2개의 0바이트를 제거하여 UCS-2를 가져옵니다. UCS-4의 BMP를 얻으려면 UCS-2의 2바이트 앞에 0바이트 2개를 추가합니다. 현재 UCS-4 사양에는 BMP 외부에 할당된 문자가 없습니다.

4. UTF 인코딩

UTF-8은 UCS를 8비트 단위로 인코딩합니다. UCS-2에서 UTF-8까지 인코딩 방법은 다음과 같습니다.

예를 들어 "중국어" 문자의 유니코드 인코딩은 6C49입니다. 6C49는 0800-FFFF 사이이므로 3바이트 템플릿(1110xxxx 10xxxxxx10xxxxxx)을 사용해야 합니다. 6C49를 바이너리로 쓰면 0110 110001 001001입니다. 이 비트 스트림을 사용하여 템플릿의 x를 교체하면 1110011010110001 10001001, 즉 E6 B1 89가 됩니다.

독자는 메모장을 사용하여 코딩이 올바른지 테스트할 수 있습니다. UltraEdit는 UTF-8로 인코딩된 텍스트 파일을 열 때 자동으로 UTF-16으로 변환되므로 혼동을 일으킬 수 있다는 점에 유의하세요. 설정에서 이 옵션을 끌 수 있습니다. 더 나은 도구는 Hex Workshop입니다.

UTF-16은 UCS를 16비트 단위로 인코딩합니다. 0x10000보다 작은 UCS 코드의 경우 UTF-16 인코딩은 UCS 코드에 해당하는 16비트 부호 없는 정수와 같습니다. 0x10000 이상의 UCS 코드에 대해서는 알고리즘이 정의됩니다. 그러나 실제로 사용되는 UCS2나 UCS4의 BMP는 0x10000보다 작아야 하므로 현재로서는 UTF-16과 UCS-2는 기본적으로 동일하다고 볼 수 있다. 그러나 UCS-2는 인코딩 방식일 뿐이고 실제 전송에는 UTF-16이 사용되므로 바이트 순서 문제를 고려해야 한다.

5. UTF 바이트 순서 및 BOM

UTF-8은 바이트를 인코딩 단위로 사용하므로 바이트 순서 문제가 없습니다. UTF-16은 2바이트를 인코딩 단위로 사용합니다. UTF-16 텍스트를 해석하기 전에 먼저 각 인코딩 단위의 바이트 순서를 이해해야 합니다. 예를 들어 "Kui"의 유니코드 인코딩은 594E이고 "B"의 유니코드 인코딩은 4E59입니다. UTF-16 바이트 스트림 "594E"를 수신하면 "Ku"입니까, "B"입니까?

유니코드 사양에서 바이트 순서를 표시하는 데 권장되는 방법은 BOM입니다. BOM은 "Bill Of Material"의 BOM 목록이 아니라 Byte order Mark입니다. BOM은 약간 영리한 아이디어입니다.

UCS 인코딩에는 "ZERO WIDTH NO-breakspace"라는 문자가 있고 해당 인코딩은 FEFF입니다. FFFE는 UCS에 존재하지 않는 문자이므로 실제 전송에서는 나타나지 않아야 한다. UCS 사양에서는 바이트 스트림을 전송하기 전에 "ZERO WIDTH NO-break SPACE" 문자를 전송할 것을 권장합니다.

이런 식으로 수신자가 FEFF를 수신하면 바이트 스트림이 Big-Endian이라는 의미이고, FFFE를 수신하면 바이트 스트림이 Little-Endian이라는 의미입니다. 따라서 "ZERO WIDTH NO-break SPACE" 문자를 BOM이라고도 합니다.

UTF-8은 바이트 순서를 나타내는 데 BOM이 필요하지 않지만 BOM을 사용하여 인코딩 방법을 나타낼 수 있습니다. "ZERO WIDTH NO-breakspace" 문자의 UTF-8 인코딩은 EF BB BF입니다(독자는 앞서 소개한 인코딩 방법을 사용하여 이를 확인할 수 있습니다). 따라서 수신기가 EF BBBF로 시작하는 바이트 스트림을 수신하면 UTF-8로 인코딩되었음을 알 수 있습니다.

Windows는 BOM을 사용하여 텍스트 파일의 인코딩 방법을 표시합니다.

6. 추가 참고 자료

이 기사의 주요 참고 자료는 "ISO-IEC 10646 및 유니코드에 대한 간략한 개요"(http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview)입니다. HTML).

또한 좋아 보이는 두 가지 정보를 찾았지만 초기 질문에 대한 답을 이미 찾았기 때문에 읽지 않았습니다.

"Understanding Unicode 유니코드 표준에 대한 일반 소개"(http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a)
"문자 세트 인코딩 기본 사항 문자 세트 인코딩 이해 및 레거시 인코딩" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03)
저는 UTF-8, UCS-2 및 GBK 변환을 위한 소프트웨어 패키지를 작성했습니다. Windows API가 포함된 버전과 포함되지 않은 버전. 앞으로 시간이 된다면 정리해서 개인 홈페이지에 올려보도록 하겠습니다

모든 문제를 고민하다가 조금 있으면 끝낼 수 있을 것 같아 이 글을 쓰기 시작했습니다. 의외로 문구를 고려하고 내용을 확인하는 데 시간이 오래 걸려서 오후 1시 30분부터 9시까지 썼습니다. 일부 독자들이 이로부터 혜택을 받을 수 있기를 바랍니다.

부록 1 위치 코드 GB2312, 내부 코드 및 코드 페이지에 대해 이야기합시다
몇몇 친구들은 여전히 ​​기사의 이 문장에 대해 질문합니다.
“GB2312의 원문은 여전히 ​​위치 코드부터 위치 코드까지입니다. 내부 코드는 상위 문자여야 합니다. 섹션과 하위 바이트에 각각 A0을 추가합니다. "

자세히 설명하겠습니다.

"GB2312의 원문"은 1980년 국가 표준 "The Basic Set of 중화인민공화국 국가표준정보교환을 위한 한자 코드 문자 집합 "GB2312-80》. 이 표준은 한자와 한자 기호를 인코딩하기 위해 두 개의 숫자를 사용합니다. 첫 번째 숫자를 "영역"이라고 하고 두 번째 숫자를 "비트"라고 합니다. 그래서 위치코드라고도 합니다. 영역 1-9는 중국어 기호이고, 영역 16-55는 1급 한자이며, 영역 56-87은 2급 한자입니다. 이제 Windows에는 위치 입력 방법도 있습니다. 예를 들어 "아"를 얻으려면 1601을 입력하세요. (이 위치 입력 방법은 16진수 GB2312와 10진수 위치 코드를 자동으로 인식할 수 있으므로 B0A1을 입력해도 "ah"가 표시됩니다.)

내부 코드는 운영 체제 내의 문자 인코딩을 나타냅니다. 초기 운영 체제의 내부 코드는 언어에 따라 다릅니다. 오늘날의 Windows는 시스템 내에서 유니코드를 지원하며 코드 페이지를 사용하여 다양한 언어에 적응합니다. "내부 코드"라는 개념은 비교적 모호합니다. Microsoft에서는 일반적으로 기본 코드 페이지에 지정된 인코딩을 내부 코드라고 부릅니다.

내부코드라는 용어에 대한 공식적인 정의는 없으며, 코드페이지는 단지 마이크로소프트라는 회사 이름일 뿐입니다. 프로그래머로서 우리가 그것이 무엇인지 아는 한 이러한 용어를 너무 많이 조사할 필요는 없습니다.

소위 코드 페이지(코드 페이지)는 언어에 대한 문자 인코딩입니다. 예를 들어, GBK의 코드 페이지는 CP936이고, BIG5의 코드 페이지는 CP950이며, GB2312의 코드 페이지는 CP20936입니다.

Windows에는 기본 코드 페이지, 즉 문자를 해석하기 위해 기본적으로 사용되는 인코딩이라는 개념이 있습니다. 예를 들어 Windows 메모장은 텍스트 파일을 열고 내부 콘텐츠는 BA, BA, D7, D6과 같은 바이트 스트림입니다. Windows는 이를 어떻게 해석해야 합니까?

유니코드 인코딩, GBK, BIG5 또는 ISO8859-1에 따라 해석해야 하나요? GBK로 해석하면 "한자"라는 단어가 나옵니다. 다른 인코딩 해석에 따르면 해당 문자를 찾을 수 없거나, 잘못된 문자를 찾을 수도 있습니다. 소위 "오류"는 텍스트 작성자의 원래 의도와 일치하지 않으며 왜곡된 문자가 생성되는 것을 의미합니다.

대답은 Windows가 현재 기본 코드 페이지에 따라 텍스트 파일의 바이트 스트림을 해석한다는 것입니다. 기본 코드 페이지는 제어판의 국가별 옵션을 통해 설정할 수 있습니다. 메모장의 다른 이름으로 저장에 ANSI 항목이 있는데, 이는 실제로 기본 코드 페이지의 인코딩 방식에 따라 저장됩니다.

Windows의 내부 코드는 유니코드로, 기술적으로 동시에 여러 코드 페이지를 지원할 수 있습니다. 파일이 사용하는 인코딩을 설명할 수 있고 사용자가 해당 코드 페이지를 설치했다면 Windows는 이를 올바르게 표시할 수 있습니다. 예를 들어 HTML 파일에 문자 세트를 지정할 수 있습니다.

일부 HTML 파일 작성자, 특히 영어 작성자는 전 세계 모든 사람이 영어를 사용하고 파일에 문자 세트를 지정하지 않는다고 믿습니다. 0x80-0xff 사이의 문자를 사용하고 중국어 Windows가 기본 GBK에 따라 이를 해석하는 경우 잘못된 문자가 나타납니다. 이때 HTML 파일에 charset을 지정하는 문을 추가하면 됩니다. 예를 들면 다음과 같습니다.

원본이 작성자는 코드 페이지가 ISO8859-1과 호환되므로 문자가 깨질 수 없습니다.

위치 코드에 대해 이야기해 보겠습니다. 아의 위치 코드는 1601이며 16진수로는 0x10, 0x01입니다. 이는 컴퓨터에서 널리 사용되는 ASCII 인코딩과 충돌합니다. 00-7f의 ASCII 인코딩과 호환되도록 지역 코드의 상위 및 하위 바이트에 각각 A0을 추가합니다. 이렇게 하면 "ah"에 대한 코드는 B0A1이 됩니다. GB2312의 원본 텍스트에서는 이에 대해 전혀 언급하지 않지만 두 개의 A0이 추가된 인코딩을 GB2312 인코딩이라고 부르기도 합니다.

위 내용은 UTF-8과 GBK UTF8 GB2312의 차이점에 대한 완전한 소개입니다. html 튜토리얼에 대해 더 알고 싶다면 PHP 중국어 웹사이트에 주목하세요.

위 내용은 UTF-8과 GBK UTF8 GB2312의 차이점은 무엇입니까의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!