중국어 JSP 및 Servlet 처리에 대한 심층 분석

세계의 모든 지역에는 고유한 현지 언어가 있습니다. 지역적 차이는 언어 환경의 차이로 직결됩니다. 국제 프로그램을 개발하는 과정에서 언어 문제를 다루는 것이 중요합니다.

이는 전세계적으로 존재하는 문제이므로 Java는 전세계적인 솔루션을 제공합니다. 본 글에서 설명하는 방법은 중국어를 처리하기 위한 방법이지만, 더 나아가 세계 다른 나라, 지역의 언어를 처리하는 경우에도 적용 가능하다.

한자는 2바이트입니다. 소위 더블 바이트는 더블 워드가 두 개의 BYTE 위치(즉, 16비트)를 차지하는 것을 의미하며, 이를 각각 상위 비트와 하위 비트라고 합니다. 중국에서 지정된 중국어 문자 인코딩은 GB2312이며, 현재 중국어를 처리할 수 있는 거의 모든 애플리케이션은 GB2312를 지원합니다. GB2312는 1급 및 2급 한자와 9개의 영역 기호를 포함합니다. 상위 비트의 범위는 0xa1부터 0xfe까지이며, 그 중 한자의 인코딩 범위는 0xb0a1부터 0xf7fe입니다.

GBK라는 또 다른 인코딩이 있지만 이는 필수 사항이 아닌 사양입니다. GBK는 GB2312와 호환되는 20902개의 한자를 제공하며 인코딩 범위는 0x8140 ~ 0xfefe입니다. GBK의 모든 문자는 유니코드 2.0에 하나씩 매핑될 수 있습니다.

가까운 시일 내에 중국은 GB18030-2000(GBK2K)이라는 또 다른 표준을 발표할 예정입니다. 티베트, 몽골 등 소수민족의 글꼴을 포함하고 있어 글자 위치가 부족한 문제를 근본적으로 해결합니다. 참고: 더 이상 고정 길이가 아닙니다. 2바이트 부분은 GBK와 호환되며 4바이트 부분은 확장 문자 및 글리프입니다. 첫 번째와 세 번째 바이트의 범위는 0x81부터 0xfe까지이고, 두 번째와 네 번째 바이트의 범위는 0x30부터 0x39까지입니다.

이 기사에서는 유니코드를 소개하려는 의도가 없습니다. 관심 있는 분은 "http://www.unicode.org/"를 검색하여 더 많은 정보를 보실 수 있습니다. 유니코드에는 특징이 있습니다. 즉, 세계의 모든 문자 글리프를 포함합니다. 따라서 다양한 지역의 언어는 유니코드와 매핑 관계를 구축할 수 있으며, 자바는 이를 활용하여 이종 언어 간의 변환을 달성합니다.

JDK에서 중국어 관련 인코딩은 다음과 같습니다.

표 1 JDK의 중국어 관련 인코딩 목록

실제로 지원되는 JDK는 거의 없습니다. 프로그래밍할 때 더 많이 접하게 되는 JDK는 GB2312(GBK) 및 ISO8859-1입니다.

"?" 기호는 왜 있는 걸까요?

위에서 언급한 것처럼 서로 다른 언어 간의 변환은 유니코드를 통해 완료됩니다. 두 가지 다른 언어 A와 B가 있다고 가정합니다. 변환 단계는 먼저 A를 유니코드로 변환한 다음 유니코드를 B로 변환합니다.

예를 들어보세요. GB2312에는 한자 "lee"가 있고 해당 코드는 "C0EE"이므로 ISO8859-1 코드로 변환해야 합니다. 단계는 다음과 같습니다. 먼저 문자 "lee"를 유니코드로 변환하여 "674E"를 얻은 다음 "674E"를 ISO8859-1 문자로 변환합니다. 물론 ISO8859-1에는 "674E"에 해당하는 문자가 없기 때문에 이 매핑은 성공하지 못합니다.

매핑이 실패할 때 문제가 발생합니다! 특정 언어에서 유니코드로 변환할 때 해당 문자가 특정 언어에 없으면 결과는 유니코드 코드 "uffffd"가 됩니다("u"는 유니코드 인코딩을 의미함). 유니코드에서 특정 언어로 변환할 때 특정 언어에 해당 문자가 없으면 "0x3f"("?")가 표시됩니다. 여기서 "?"가 유래됩니다.

예를 들어, 문자 스트림 buf = "0x80 0x40 0xb0 0xa1"에 대해 new String(buf, "gb2312") 작업을 수행하면 결과는 "ufffdu554a"가 되고 이를 인쇄하면 결과는 " ?ah", "0x80 0x40"은 GB2312가 아닌 GBK의 문자이기 때문입니다.

또 다른 예로, 문자열 String="u00d6u00ecu00e9u0046u00bbu00f9"에 대해 새 문자열(buf.getBytes("GBK")) 작업을 수행하면 결과는 "3fa8aca8a6463fa8b4"입니다. "u00d6 ""GBK"에는 해당 문자가 없으므로 "3f", "u00ec"는 "a8ac"에 해당, "u00e9"는 "a8a6"에 해당, "0046"은 "46"에 해당합니다. (ASCII 문자이기 때문에) "u00bb"는 발견되지 않았고, "3f"는 획득되었습니다. 마지막으로 "u00f9"는 "a8b4"에 해당합니다. 이 문자열을 인쇄하면 결과는 "?ìéF?ù"입니다. 그거 봤어? GBK와 유니코드 간에 매핑된 콘텐츠에는 한자 외에 문자도 포함되어 있기 때문에 여기에 물음표가 전부 있는 것은 아닙니다.

따라서 한자를 트랜스코딩할 때 혼동이 발생하더라도 반드시 물음표가 나오지 않을 수도 있습니다! 하지만 실수는 결국 실수입니다. 50걸음과 100걸음 사이에는 질적인 차이가 없습니다.

또는 다음과 같이 질문할 수도 있습니다. 소스 문자 집합에는 포함되어 있지만 유니코드에는 포함되어 있지 않으면 결과는 어떻게 될까요? 대답은 모르겠다 이다. 왜냐하면 이 테스트를 수행하기 위한 소스 문자 세트가 없기 때문입니다. 그러나 한 가지 확실한 점은 소스 문자 집합이 충분히 표준화되지 않았다는 것입니다. Java에서는 이런 일이 발생하면 예외가 발생합니다.

UTF란 무엇입니까?

UTF는 Unicode Text Format의 약자로 유니코드 텍스트 형식을 의미합니다. UTF의 경우 다음과 같이 정의됩니다.

(1) 유니코드 16비트 문자의 처음 9비트가 0이면 이 바이트의 첫 번째 비트는 "0"이고 나머지 7비트는 바이트로 표시됩니다. 원래 문자와 동일합니다. 예를 들어 "u0034"(0000 0000 0011 0100)는 "34"(0011 0100)로 표시됩니다(소스 유니코드 문자와 동일)

. 2) 유니코드의 16비트 문자 중 처음 5개가 비트가 0이면 2바이트로 표현되며, 첫 번째 바이트는 "110"으로 시작하고, 그 다음 5비트는 소스의 상위 5비트와 동일하다. 처음 5개의 0을 제외한 문자; 두 번째 바이트는 "10"으로 시작합니다. 처음에는 다음 6비트가 소스 문자의 하위 6비트와 동일합니다. 예를 들어 "u025d"(0000 0010 0101 1101)는 "c99d"(1100 1001 1001 1101)로 변환됩니다.

(3) 위의 두 가지 규칙을 충족하지 않으면 3바이트로 표시됩니다. 첫 번째 바이트는 "1110"으로 시작하고, 마지막 4비트는 소스 문자의 상위 4비트이고, 두 번째 바이트는 "10"으로 시작하고, 마지막 6비트는 세 번째 문자의 중간 6비트입니다. 바이트는 "10"으로 시작합니다. 마지막 6자리는 소스 문자의 하위 6자리입니다. 예를 들어 "u9da7"(1001 1101 1010 0111)은 "e9b6a7"(1110 1001 1011)로 변환됩니다. 0110 1010 0111);

JAVA 프로그램에서 유니코드와 유니코드의 차이점은 다음과 같이 설명할 수 있습니다. UTF의 관계는 절대적이지 않습니다. 문자열이 메모리에서 실행될 때 유니코드 코드로 나타나고 파일에 저장될 때 또는 다른 미디어의 경우 UTF가 사용됩니다. 이 변환 프로세스는 writeUTF 및 readUTF에 의해 완료됩니다.

자, 기본적인 논의는 거의 끝났습니다. 본론으로 들어가겠습니다.

먼저 문제를 블랙박스로 생각해보세요. 먼저 블랙박스의 첫 번째 수준 표현을 살펴보겠습니다.

input(charsetA)->process(Unicode)->output(charsetB)

이는 IPO 모델, 즉 입력, 처리 및 출력입니다. 동일한 콘텐츠를 charsetA에서 유니코드로 변환한 다음 charsetB로 변환해야 합니다.

SourceFile(jsp,java)->class->output을

살펴보겠습니다

이 그림에서 입력은 처리 중에 클래스 파일이 캐리어로 사용되는 것을 볼 수 있습니다. 그런 다음 출력합니다. 그런 다음 세 번째 수준으로 구체화합니다.

jsp->temp file->class->browser,os console,db

app,servlet->class->browser,os console,db

이 그림은 더 명확합니다. Jsp 파일은 먼저 중간 Java 파일을 생성한 다음 클래스를 생성합니다. 서블릿과 일반 앱을 직접 컴파일하여 클래스를 생성합니다. 그런 다음 클래스에서 브라우저, 콘솔 또는 데이터베이스 등으로 출력됩니다.

JSP: 소스 파일에서 클래스까지의 과정

Jsp의 소스 파일은 ".jsp"로 끝나는 텍스트 파일이다. 이 섹션에서는 JSP 파일의 해석 및 컴파일 프로세스를 설명하고 중국어 변경 사항을 추적합니다.

1. JSP/Servlet 엔진에서 제공하는 JSP 변환 도구(jspc)는 JSP 파일에서 <%@ page contentType ="text/html; charset=<Jsp-charset>"%>에 지정된 charset을 검색합니다. JSP 파일에 <Jsp-charset>이 지정되지 않은 경우 JVM의 기본 설정 file.encoding이 사용됩니다. 이 값은 ISO8859-1입니다.

jspc는 "javac –encoding <Jsp"와 동등한 기능을 사용합니다. -charset> " 명령은 한자, ASCII 문자 등 JSP 파일에 나타나는 모든 문자를 해석한 후 이를 유니코드 문자로 변환한 후 UTF 형식으로 변환하여 JAVA 파일로 저장합니다. ASCII 문자를 유니코드 문자로 변환할 때 "A"와 같이 앞에 "00"을 추가하기만 하면 "u0041"로 변환됩니다(이유는 필요하지 않습니다. 이것이 유니코드 코드 테이블이 컴파일되는 방식입니다). 그런 다음 UTF로 변환한 후 다시 "41"로 변경되었습니다!

된

JAVA 파일을 볼 수 있는 이유입니다.

엔진은 "javac -encoding UNICODE"에 해당하는 명령을 사용하여 JAVA 파일을 CLASS 파일로 컴파일합니다.

이러한 프로세스 변환 상황. 다음과 같은 소스 코드가 있습니다:

<%@ page contentType="text/html; charset=gb2312"%>
<html><본문>
<%
문자열 a="중국어";
out.println(a);
%>
</body></html>

이 코드는 Windows용 UltraEdit에서 작성되었습니다. 저장 후 두 문자 "중국어"의 16진수 인코딩은 "D6 D0 CE C4"(GB2312 인코딩)입니다. 표를 조회한 후 "중국어"라는 단어의 유니코드 인코딩은 "u4E2Du6587"이며 UTF에서는 "E4 B8 AD E6 96 87"입니다. 엔진에서 생성된 JSP 파일에서 변환된 JAVA 파일을 열고 "중국어"라는 단어가 실제로 "E4 B8 AD E6 96 87"로 대체되었는지 확인합니다. 그런 다음 JAVA 파일 컴파일로 생성된 CLASS 파일을 확인하고 찾습니다. 결과는 JAVA 파일과 정확히 동일합니다.

JSP에 지정된 CharSet이 ISO-8859-1인 상황을 살펴보겠습니다.

<%@ 페이지 contentType="text/html; charset=ISO-8859-1"%>
<html><본문>
<%
문자열 a="중국어";
out.println(a);
%>
</body></html>

마찬가지로 이 파일은 UltraEdit으로 작성되었으며 "중국어"라는 두 글자도 "D6 D0 CE C4"로 인코딩된 GB2312로 저장됩니다. 먼저 JAVA 파일 및 CLASS 파일 생성 프로세스를 시뮬레이션합니다. jspc는 ISO-8859-1을 사용하여 "중국어"를 해석하고 이를 유니코드에 매핑합니다. ISO-8859-1은 8비트이고 라틴어이므로 매핑 규칙은 각 바이트 앞에 "00"을 추가하는 것이므로 매핑된 유니코드 인코딩은 다음으로 변환한 후 "u00D6u00D0u00CEu00C4" 여야 합니다. UTF는 "C3 96 C3 90 C3 8E C3 84"여야 합니다. 자, 파일을 열고 살펴보세요. JAVA 파일과 CLASS 파일에서 "중국어"는 실제로 "C3 96 C3 90 C3 8E C3 84"로 표시됩니다.

위 코드에서 <Jsp-charset>이 지정되지 않은 경우, 즉 첫 번째 줄이 "<%@ page contentType="text/html" %>"로 작성된 경우 JSPC는 file.encoding 설정을 사용하여 해석합니다. JSP 파일. RedHat 6.2에서 처리 결과는 ISO-8859-1을 지정하는 것과 정확히 동일합니다.

지금까지 JSP 파일에서 CLASS 파일로의 변환 과정에서 한자의 매핑 과정을 설명하였다. 한마디로: "JspCharSet에서 유니코드, UTF로"입니다. 다음 표에는 이 프로세스가 요약되어 있습니다.

표 2 JSP에서 CLASS로의 "중국어" 변환 프로세스

서블릿(Servlet): 소스 파일에서 클래스까지의 과정입니다.

서블릿 소스 파일은 ".java"로 끝나는 텍스트 파일입니다. 이 섹션에서는 서블릿 컴파일 프로세스에 대해 논의하고 중국어 변경 사항을 추적합니다.

Servlet 소스 파일을 컴파일하려면 "javac"를 사용하십시오. javac는 "-encoding <Compile-charset>" 매개변수를 사용할 수 있습니다. 이는 "<Compile-charset>에 지정된 인코딩을 사용하여 Serlvet 소스 파일을 해석합니다"를 의미합니다.

소스 파일을 컴파일할 때 <Compile-charset>을 사용하면 한자, ASCII 문자를 포함한 모든 문자를 해석할 수 있습니다. 그런 다음 문자 상수를 유니코드 문자로 변환하고 마지막으로 유니코드를 UTF로 변환합니다.

서블릿에는 출력 스트림의 CharSet을 설정하는 또 다른 장소가 있습니다. 일반적으로 결과를 출력하기 전에 HttpServletResponse의 setContentType 메소드를 호출하여 JSP에서 <Jsp-charset>을 설정한 것과 동일한 효과를 얻을 수 있는데 이를 <Servlet-charset>이라고 합니다.

기사에는 <Jsp-charset>, <Compile-charset> 및 <Servlet-charset>의 총 세 가지 변수가 언급되어 있습니다. 그 중 JSP 파일은 <Jsp-charset>에만 관련되어 있고, <Compile-charset>과 <Servlet-charset>은 Servlet에만 관련되어 있습니다.

다음 예를 살펴보십시오.

import javax.servlet.*;

import

javax.servlet.http.*;

{
공개 무효 doGet(HttpServletRequest req,HttpServletResponse resp)
ServletException,java.io.IOException이 발생합니다.
{
resp.setContentType("text/html; charset=GB2312");
java.io.PrintWriter out=resp.getWriter();
out.println("<html>");
out.println("#中文#");
out.println("</html>");
}
}

이 파일 역시 Windows용 UltraEdit으로 작성되었으며 "중국어"라는 두 글자가 "D6 D0 CE C4"(GB2312 인코딩)로 저장되어 있습니다.

컴파일을 시작하세요. 다음 표는 <Compile-charset>이 다를 때 CLASS 파일에서 "English"라는 단어의 16진수 코드를 보여줍니다. 컴파일 중에는 <Servlet-charset>이 적용되지 않습니다. <Servlet-charset>은 CLASS 파일의 출력에만 영향을 미칩니다. 실제로 <Jsp-charset>과 <Compile-charset>은 JSP 파일의 <Jsp-charset>과 동일한 효과를 얻기 위해 함께 작동합니다. charset >CLASS 파일의 컴파일 및 출력에 영향을 미칩니다.

표 3 "중국어"를 서블릿 소스 파일에서 클래스로 변환하는 과정