저는 지난 며칠간 UTF-8 인코딩에 대해 공부했는데 너무 혼란스러워서 제 의견을 여러분과 논의하겠습니다. 승인을 환영합니다. 다음은 제 생각입니다. 잘못된 점이 있으면 알려주시고 지적해 주시기 바랍니다.
관련 여담:
1. 운영체제
윈도우 시스템은 내부적으로 모두 유니코드입니다. 폴더 이름, 파일 이름 등은 모두 유니코드이므로 어떤 언어 시스템에서도 정상적으로 표시될 수 있습니다.
2. 입력 방법:
Microsoft Pinyin 출력은 유니코드이고 Smart ABC 출력은 중국어 간체입니다(따라서 Smart ABC는 중국어 간체 시스템에서는 전혀 사용할 수 없으며 영어로만 입력할 수 있습니다).
3. 웹페이지의 텍스트 영역
웹페이지의 텍스트 영역은 유니코드로 표시됩니다. 따라서 입력한 내용이 모두 표시됩니다. 하지만 플래시로 만든 일부 입력 상자는 작동하지 않습니다.
4. 액세스2000
액세스에 저장된 데이터는 유니코드이며 모든 언어 시스템으로 표시될 수 있습니다.
데이터 보기에서 일부 문자가 정상적이지 않은 경우 표시에 사용된 글꼴이 유니코드 글꼴이 아니기 때문입니다.
모든 것을 표시하려면 Arial Unicode MS 글꼴로 변경하세요. (도움말 액세스, 검색, 유니코드 입력, 지침 이용 가능)
5. 말씀
Word에서 중국어 간체와 중국어 간체 간 변환 중국어 간체에서 중국어 번체로 변환한 후에도 내부 코드는 여전히 중국어 간체입니다. 실제로는 중국어 간체의 중국어 번체 문자입니다.
6. ASP는 내부적으로 유니코드이며 모든 텍스트는 유니코드로 저장됩니다. 필요한 경우 지정된 문자 집합으로 변환합니다.
먼저 결론을 내리자면:
<%@ codepage=936%>중국어 간체
<%@ codepage=950%>중국어(번체)
<%@ codepage=65001%>UTF-8
코드 페이지는 IIS가 전달된 문자열(양식 제출, 주소 표시줄 전송 등)을 읽는 인코딩을 지정합니다.
또한 모든 텍스트 변수가 유니코드에서 변환되는 인코딩을 지정합니다.
또한 데이터베이스에서 검색된 데이터가 유니코드에서 변환되는 인코딩을 지정합니다. (이것은 매우 중요합니다.)
키워드:
읽기: 문자열입니다. 중국어 간체로 읽으면 일부 문자가 되고, 중국어 번체로 읽으면 일부 문자가 됩니다. 문자열 자체의 인코딩은 변경되지 않았습니다.
변환: 시스템은 예를 들어 유니코드의 "화" 문자를 Big5의 "화" 문자로 적극적으로 변환하고 내부 코드는 Big5의 문자가 됩니다. Big5에 해당 단어가 없으면 유니코드 형식이 유지됩니다(&#xxxx;).
중국어 간체: 여섯 가지 결론
유니코드 16진수 형식: 여섯 가지 결론
유니코드 십진수 형식: 여섯 가지 결론
제가 추측한 인코딩 변환 과정은 다음과 같습니다.
클라이언트: 입력 방법 유니코드--입력 상자 유니코드--문자 집합()을 통해 유니코드에서 해당 인코딩으로 변환--양식 전송 인코딩
서버 측: IIS는 양식을 디코딩합니다. - 코드 페이지에 지정된 인코딩에 따라 읽습니다. - 해당 유니코드로 변환합니다. - request("")로 읽을 수 있습니다. - 일부 처리를 수행합니다. - 유니코드 인코딩으로 데이터베이스에 저장합니다.
서버 측: 데이터베이스에서 유니코드 데이터를 읽고 코드 페이지에 지정된 인코딩으로 변환 --- 소스 코드 생성 -- IE는 문자 세트에 따라 이를 읽고 표시합니다.
다음은 몇 가지 예입니다.
예시 1:
일반적인 메시지 페이지인 세 개의 ASP 페이지가 있다고 가정합니다.
1.write.asp는 간단한 입력 양식이며 add.asp에 제출됩니다.
<META http-equiv="Content-Type" content="text/html; charset=big5">
2.add.asp는 메시지를 수신하여 데이터베이스에 저장합니다.
<%@ 코드페이지=936%>
3.read.asp는 데이터베이스에서 메시지를 가져와 표시합니다.
<%@ codepage=936%> charset=GB2312 또는
<%@ codepage=950%> charset=big5
추측해 볼 수 있습니다. 저는 write.asp에 "Hua Liu Discussion"을 입력하기 위해 Microsoft Pinyin 입력 방법을 사용했습니다. 결국 read.asp에는 무엇이 표시되나요?
현기증이 나나요? 처음부터 분석해보자.
예시 2:
예제 1의 add.asp에 있는 <%@ codepage=936%>를 <%@ codepage=950%>로 변경하면 어떻게 될까요?
여기서 무엇을 찾았나요?
1. 입력된 텍스트가 해당 Charset과 다를 경우 변환 후 유니코드 형식의 문자가 나타날 수 있습니다. 이유는 다음과 같습니다. 지금부터 전체 프로세스가 유지됩니다.
2. Add.asp의 코드 페이지는 데이터베이스에 저장된 텍스트와 유니코드에 해당하는 언어를 결정합니다. 예: codepage=936,
그런 다음 데이터베이스는 중국어 간체 유니코드를 저장합니다(데이터베이스는 중국어 간체 시스템을 다시 가져오며 모든 것이 정상입니다).
Codepage=950은 중국어 번체 유니코드를 저장합니다. 중국어 간체 시스템을 복원하는 것은 잘못된 것입니다.
3． 문자열이 변경되는 과정에 주의하세요.
1) 입력 방법 --- CharsetUnicode---- 문자 집합의 매핑을 지정합니다.
2)Charset----형식 인코딩 문자열 단순 인코딩
3) 이전 폼 디코딩 단계의 역과정으로, 두 단계가 상쇄됩니다.
4) 문자열 à 코드 페이지를 눌러 문자열을 읽으면 문자열이 변경되지 않습니다. 이 단계에서는 "읽기의 오해"가 발생할 수 있습니다.
5) 해당 유니코드 코드페이지 지정 문자 집합으로 변환----유니코드 매핑
6) 중간 처리, 데이터베이스 변경 없음, 유니코드 형식으로 직접 입력
7) 데이터베이스 유니코드를 읽으려면 코드 페이지를 누릅니다.----코드 페이지 지정 문자 집합 매핑
8) Charset에 지정된 문자 집합에서 읽어온 문자열이 변경되지 않았음을 나타냅니다.
예제 1을 통해 설명해 보겠습니다.
예시 2:
어지러운. 이제 지식을 활용해 보겠습니다.
사례 1.
중국어 간체 시스템에서 잘 돌아가던 코드가 외국 공간에 배치되면 데이터베이스에서도 깨져서 원본 데이터도 깨집니다.
분석: 대부분의 사람들이 일반적으로 중국어 간체 시스템을 사용하기 때문에 기본 코드 페이지는 936이므로 모두가 작성하지 않아도 문제가 되지 않습니다.
그런데 해외에 나가면 공간 문제가 발생한다. 데이터베이스의 유니코드가 영어 인코딩으로 변환되었으므로 데이터베이스의 원래 중국어 간체를 영어로 변환한 후에는 GB 표시가 자연스럽게 깨집니다.
그림과 같이 새로 입력한 텍스트는 정상적으로 표시되지만, 데이터베이스에는 영어 유니코드가 저장되어 있습니다.
해결 방법: 모두에 <%@codepage=936%>를 추가하세요.
전체 프로세스에는 중국어 간체와 해당 유니코드 간의 변환만 포함됩니다.
사례 2:
중국어 간체 코드와 데이터를 중국어 번체 버전으로 변환하려면 어떻게 해야 합니까?
분석: 1. 모든 코드 파일의 인코딩은 Big5로 변경되며, 파일 자체는 중국어(번체)로 저장됩니다.
2. <%@ 코드페이지=936 %>
3.문자셋=big5
4. 액세스하는 데이터는 유니코드이므로 액세스 버전은 중요하지 않습니다.
5. 좋습니다. 코드는 순수 중국어 번체 시스템에서 실행될 수 있습니다.
6. 남은 문제: 원본 중국어 간체 데이터를 읽을 때 몇 가지 물음표가 있을 것입니다. 효과는 big5 디스플레이의 예 1의 950 판독값과 동일합니다. 중국어 간체의 유니코드가 중국어 번체로 변환되기 때문에 일부 문자가 중국어 번체가 아니므로 물음표가 나타납니다.
7. 해결 방법: 임시 ASP 페이지(codepage=65001)를 사용하여 중국어 간체 유니코드로 읽고 유니코드->Big5 함수를 사용하여 중국어 번체로 변환한 다음 다시 데이터베이스에 작성합니다.
두 가지 사례는 제가 이론에 근거하여 완전히 추론한 것으로 아직 확인된 바는 없습니다.
비슷한 경험이 있으신 분들의 비판과 수정을 환영합니다.