오늘은 ASP.NET 페이지에서 javascript 스크립트를 이용해 메뉴툴을 만들어서 menuScript.js로 저장했습니다. <script 언어="javascript" src="../js/MenuScript.js"></script를 사용하세요. >통화 페이지에서, 조작 중 이상한 현상이 발생했습니다. 페이지에서는 한자가 정상적으로 표시되었으나, 메뉴에서는 한자가 깨져서 표시되었습니다.
물어볼 필요도 없습니다. 인코딩에 문제가 있는 것입니다. 페이지의 "보기"-"인코딩" 옵션에서 UTF-8과 GB2312 인코딩 간에 전환하면 됩니다. 페이지의 문자와 메뉴의 한자가 교대로 깨집니다.
해결책: 구성 파일에 인코딩 설정이 있습니다: <globalization requestEncoding="utf-8" responseEncoding="utf-8" />
menuScript.js 파일을 저장할 때 인코딩 옵션이 있습니다(이 파일을 Word로 열고 다른 파일로 저장할 수 있으며 인코딩을 선택하세요). 두 인코딩을 동일하게 유지하세요.
코딩 문제를 더 잘 이해하기 위해 CSDN에서 작성자: fmddlmyy에 대한 기사를 찾았습니다. 참조용으로 여기에서 다시 인쇄하십시오.
코딩에 대해 이야기해보자 코딩에 대해 이야기해보자 #region 코딩에 대해 이야기해보자
/**//*
0. 빅엔디안과 리틀엔디안
빅 엔디안과 리틀 엔디안은 CPU가 멀티바이트 숫자를 처리하는 다른 방식입니다. 예를 들어 "汉" 문자의 유니코드 인코딩은 6C49입니다. 그러면 파일에 쓸 때 6C를 앞에 써야 할까요, 아니면 49를 앞에 써야 할까요? 앞에 6C라고 쓰면 빅엔디안이다. 아니면 앞에 49를 적어주세요. 리틀엔디안이죠.
"엔디안"이라는 단어는 "걸리버 여행기"에서 유래되었습니다. 릴리푸트 내전은 빅엔디안(Big-Endian)에서 알을 깨느냐, 아니면 작은엔디안(Little-Endian)에서 알을 깨느냐에서 비롯됐다. 그 결과 여섯 번의 반란이 일어나 황제 중 한 명이 목숨을 잃었다. 다른 하나는 왕좌를 잃었습니다.
우리는 일반적으로 엔디안을 "바이트 순서"로 번역하며, 빅엔디안과 리틀엔디안을 "빅엔드", "리틀엔드"라고 부릅니다.
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자가 포함됩니다. 2000년 GB18030은 GBK1.0을 대체하는 공식 국가 표준입니다. 이 표준에는 27,484개의 한자와 티베트어, 몽골어, 위구르어 및 기타 주요 소수민족 언어가 포함됩니다. 현재 PC 플랫폼은 GB18030을 지원해야 하며 임베디드 제품에 대한 요구 사항은 없습니다. 따라서 휴대폰과 MP3는 일반적으로 GB2312만 지원합니다.
ASCII, GB2312, GBK에서 GB18030까지 이러한 인코딩 방법은 이전 버전과 호환됩니다. 즉, 동일한 문자는 이러한 구성표에서 항상 동일한 인코딩을 가지며 이후 표준은 더 많은 문자를 지원합니다. 이러한 인코딩에서는 영어와 중국어를 균일하게 처리할 수 있습니다. 중국어 인코딩을 구별하는 방법은 상위 바이트의 최상위 비트가 0이 아닌 것입니다. 프로그래머들이 부르는 명칭에 따르면 GB2312, GBK부터 GB18030까지 모두 2바이트 문자 집합(DBCS)에 속합니다.
일부 중국어 Windows의 기본 내부 코드는 여전히 GBK이며 GB18030 업그레이드 패키지를 통해 GB18030으로 업그레이드할 수 있습니다. 그러나 GBK에 비해 GB18030이 추가한 문자는 일반 사람들이 사용하기 어렵습니다. 일반적으로 우리는 여전히 중국어 Windows 내부 코드를 참조하기 위해 GBK를 사용합니다.
자세한 내용은 다음과 같습니다.
GB2312의 원본 텍스트는 여전히 지역 코드입니다. 지역 코드에서 내부 코드까지 각각 상위 바이트와 하위 바이트에 A0을 추가해야 합니다.
DBCS에서 GB 내부 코드의 저장 형식은 항상 빅 엔디안입니다. 즉, 상위 비트가 먼저 옵니다.
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입니다.
유니코드도 문자 인코딩 방법이지만 국제기구에 의해 설계되었으며 전 세계 모든 언어에 대한 인코딩 방식을 수용할 수 있습니다. 유니코드의 학명은 "Universal Multiple-Octet Coded Character Set", 줄여서 UCS입니다. UCS는 "Unicode Character Set"의 약자로 볼 수 있습니다.
Wikipedia( http://zh.wikipedia.org/wiki/ )에 따르면, 역사적으로 유니코드를 독립적으로 설계하려고 시도한 두 조직, 즉 ISO(국제 표준화 기구)와 소프트웨어 제조업체 협회(unicode. 조직). ISO는 ISO 10646 프로젝트를 개발했고 유니코드 컨소시엄은 유니코드 프로젝트를 개발했습니다.
1991년경 양측은 호환되지 않는 두 문자 집합이 세상에 필요하지 않다는 점을 인식했습니다. 그래서 그들은 두 당사자의 작업을 병합하고 협력하여 단일 코딩 목록을 만들기 시작했습니다. Unicode2.0부터 Unicode 프로젝트는 ISO 10646-1과 동일한 글꼴 및 글꼴을 사용합니다.
두 프로젝트 모두 여전히 존재하며 자체 표준을 독립적으로 게시합니다. 유니코드 컨소시엄의 최신 버전은 2005년 유니코드 4.1.0입니다. 최신 ISO 표준은 10646-3:2003입니다.
UCS는 여러 바이트를 사용하여 다양한 텍스트를 나타내는 방법을 지정합니다. 이러한 인코딩을 전송하는 방법은 UTF(UCS Transformation Format) 사양에 규정되어 있습니다. 일반적인 UTF 사양에는 UTF-8, UTF-7 및 UTF-16이 포함됩니다.
IETF의 RFC2781 및 RFC3629는 UTF-16 및 UTF-8의 인코딩 방법을 RFC의 일관된 스타일로 명확하고 명확하며 엄격하게 설명합니다. IETF가 Internet Engineering Task Force의 약자라는 사실을 늘 잊어버리곤 합니다. 그러나 IETF가 관리하는 RFC는 인터넷상의 모든 사양의 기초입니다.
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개의 행으로 나뉘며, 각 행에는 256개의 셀이 포함됩니다. 물론, 같은 행의 셀은 마지막 바이트만 다를 뿐 나머지는 동일합니다.
그룹 0의 평면 0을 기본 다국어 평면 또는 BMP라고 합니다. 또는 UCS-4에서는 상위 2바이트가 0인 코드 비트를 BMP라고 합니다.
UCS-2는 UCS-4의 BMP에서 처음 2개의 0바이트를 제거하여 얻습니다. UCS-4의 BMP를 얻으려면 UCS-2의 2바이트 앞에 0바이트 2개를 추가합니다. 현재 UCS-4 사양에는 BMP 외부에 할당된 문자가 없습니다.
4. UTF 인코딩 UTF-8은 UCS를 8비트 단위로 인코딩합니다. UCS-2에서 UTF-8로의 인코딩은 다음과 같습니다.
UCS-2 인코딩(16진수) UTF-8 바이트 스트림(2진수)
0000-007F 0xxxxxxx
0080-07FF 110xxxxx 10xxxxxx
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx
예를 들어 문자 "중국어"의 유니코드 인코딩은 6C49입니다. 6C49는 0800-FFFF 사이이므로 3바이트 템플릿(1110xxxx 10xxxxxx 10xxxxxx)을 사용해야 합니다. 6C49를 바이너리로 쓰면 0110 110001 001001입니다. 이 비트 스트림을 사용하여 템플릿의 x를 바꾸면 11100110 10110001 10001001, 즉 E6 B1 89가 됩니다.
독자는 메모장을 사용하여 코딩이 올바른지 테스트할 수 있습니다.
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-break SPACE"라는 문자가 있고, 인코딩은 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-break SPACE" 문자의 UTF-8 인코딩은 EF BB BF입니다(독자는 앞서 소개한 인코딩 방법을 사용하여 이를 확인할 수 있습니다). 따라서 수신기가 EF BB BF로 시작하는 바이트 스트림을 수신하면 UTF-8로 인코딩되었음을 알 수 있습니다.
Windows는 BOM을 사용하여 텍스트 파일의 인코딩을 표시합니다.
6. 추가 참고 자료 이 기사의 주요 참고 자료는 "ISO-IEC 10646 및 유니코드에 대한 간략한 개요"( http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html )입니다.
또한 좋아 보이는 두 가지 정보를 찾았지만 초기 질문에 대한 답을 이미 알고 있었기 때문에 읽지 않았습니다.
"유니코드 이해 유니코드 표준에 대한 일반 소개"( 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 )
Windows API를 사용하는 버전과 Windows API를 사용하지 않는 버전을 포함하여 UTF-8, UCS-2 및 GBK를 서로 변환하기 위한 소프트웨어 패키지를 작성했습니다. 앞으로 시간이 된다면 정리해서 개인 홈페이지( http://fmddlmyy.home4u.china.com )에 올려보도록 하겠습니다.
모든 문제를 고민한 후에 이 글을 쓰기 시작했는데, 시간이 지나면 끝낼 수 있을 것 같았습니다. 의외로 문구를 고려하고 내용을 확인하는 데 시간이 오래 걸려서 오후 1시 30분부터 9시까지 썼습니다. 일부 독자들이 이로부터 혜택을 받을 수 있기를 바랍니다.
*/
#endregion