지겨운 웹 프로그래밍 한글 문제

왜 난 이 글 읽어도 무슨말인지 모르겠지? 원리가 이해가 안돼.. 그래서 매번 마구잡이로 해서 대강 때려맞출뿐.. 언젠가 문자 코드에 대한 모든 스펙을 읽어보고 자바 국제화 지원 클래스들 뜯어보는게 목표중의 하나..

출처 : javaservice.net
——————————-

톰캣 4 한글 에러문제……….
글쓴이: 손님(guest) 2003/08/17 02:54:23 조회수:268 줄수:58

지겨운 한글 문제 입니다. (참고로 저도 한글 관련 Q/A 는 거의다 찾아보았습니다. – 제 생각일 뿐인가요 ? ^^)

환경 : jdk 1.4.1 tomcat 4.1.24 apche 1.3.26 win 2000 입니다.

과정 : jsp 에서 입력받은 이름(한글) 을 DB 에 입력 처리 하는 과정입니다.

< %@ page language="java"% >
< % response.setContentType("text/html"); % >

< jsp:useBean id=bsave ~~~~ 빈즈 선언부분 >

< % String strInUser = new String(request.getParameter("txtInUser").getBytes("8859_1"),"KSC5601"); % >

“한글테스트 케??, 케이크” ^^

이름은 < %=strInUser% > —–> 받아온 한글이 브라우저에선 잘 나옵니다.

< % System.out.println("jsp 이름 ="+strInUser ); ----> 위와 동일한 것을 이렇게 찍어보면 깨짐니다.

왜 여기서 깨질까요 ????????????????

bSave.saveRotaCfrm(strInUser); —–> 빈즈 호출 하며 파라메터로 넘겨도 물론 깨지네요

% >

[참고]

상단 선언부를 이렇게 바꾸어도 보았습니다.

인코딩 부분을
//String strInUser = new String(request.getParameter(“txtInUser”).getBytes(“Cp1252”), “EUC-KR”);

//String strInUser = new String(request.getParameter(“txtInUser”).getBytes(“KSC5601″),”8859_1”);

//String strInUser = new String(request.getParameter(“txtInUser”).getBytes(“EUC-KR”), “KSC5601”);

//String strInUser = new String(request.getParameter(“txtInUser”).getBytes(“8859_1″),”MS949”);

이런 여러 방법으로도 테스트 해보았습니다.

역시 모두다 브라우저에선 나오지만 그 이후에는 깨지네요 ..

제목 : Re: 한글문제는 생각보다 쉽습니다… ^^;
글쓴이: 김상문(guest) 2003/08/21 18:13:15 조회수:497 줄수:96

많은 분들이 jsp에서 한글처리때문에 많은 고생을 하고 계신데 한글처리는

동작원리만 알면 쉽게 풀수 있는 문제입니다.

그럼. 동작원리를 잠깐 알아볼까요…. ^^

먼저 자바는 유니코드를 사용한다는 사실을 인지해야합니다.
(자바하시는 분들은 다 알고 있지만 한글처리를 하실때 많이 빼먹는 부분이기도합니다)

다시 말해서 jsp(java) 안에서는 문자열이 유니코드라는 것입니다.

그럼. 브라우저에서 request를 보낼 때 입니다.

HTTP 요청은 8859_1로 보냅니다. 즉 다시 말하면 한글완성형코드 그대로 변환없이

보냅니다. (byte그대로…)

일단 간략하게 그리면

브라우저 한글완성형코드 그대로 전송 –request(*)–> jsp 컨테이너에서 유니코드로 변환 –> 내부처리

–response(*)–> 결과물을 브라우저로 전송

(*)부분에서 유니코드<-->해당문자열코드로 변환이 일어납니다.

request(*)에서 문자셋이 지정되어 있지 않으면 (이 말은 브라우저가 request를 요청할 때 특별히
문자셋을 지정하지 않았을 때, 가장 일반적인 상황입니다) 8859_1로 처리됩니다.

즉. “한”이라는 문자열을 보냈다고 했을 때 완성형코드 2byte가 그대로 전송되죠.

8859_1 문자셋코드를 유니코드로 변환하면 상위바이트와 하위바이트가 각각 1자의

유니코드로 변환되므로 “한”이라는 글자는 유니코드 2자로 변환됩니다.

아시다시피 유니코드에서 한글은 1자입니다. 이 변환이 있더라도 한글byte가 깨지지는 않습니다.

왜냐하면 상위, 하위바이트가 각각 유니코드 안에 그대로 살아있기때문입니다.

이 경우 유니코드문자열.getBytes(“8859_1”)의 메소드 호출로 원래 byte열로 돌릴 수 있기 때문입니다.

request에서 기본 8859_1 문자셋을 다른 문자셋으로 바꾸는 메소드가 있죠.

request.setCharacterEncoding(“euc-kr”) 이라고 하면(반드시 파라미터를 읽기 이전에 해야합니다)

한글 1자(2byte)를 유니코드 1자로 변환해줍니다..

response(*) 부분은 브라우저에 보내기전에 유니코드를 해당 문자셋의 byte열로 변환하는 부분입니다.

page 태그나 response.setContentType() 메소드에서 “text/html; charset=euc-kr” 식으로 설정가능합니다.

지정하지 않으면 역시 8859_1로 처리되므로 request에서 8859_1이면 들어온 그대로 다시 보내므로

어떤 문자코드라도 깨지지 않습니다. 그러나 euc-kr로 되어 있으면 유니코드 –> 한글완성형

변환시 유니코드 1자를 한글 1자로 인식하기때문에 한글유니코드는 2byte의 완성형 코드로 변환됩니다.

여기서 한글유니코드를 8859_1으로 변환하면 유니코드의 상위byte가 없어지고 하위byte만 사용됩니다.

그러니 한글이 깨져서 브라우저로 전송됩니다.

이 경우 글자의 상위byte가 없어지므로 되돌릴 수 없습니다.

그래서 한글이 정상적으로 처리될려면

1, 브라우저 — 8859_1(default) –> jsp 컨테이너(jsp/java) — 8859_1(default) –> 브라우저
(* 비추전)

2. 브라우저 — euc-kr(요청시 브라우저에서 지정하던지, 아니면 setCharacterEncoding사용 –>
jsp 컨테이너(jsp/java) — euc-kr(response에서 contentType으로 지정) –> 브라우저
(* 추전)

3. jsp 내에서 (실행시간include)로 jsp가 아닌 한글화일(html등) 포함할 때는 jsp컨테이너가 실행될 때
시스템 문자셋에 따라서 변환이 됩니다.
그래서 1의 경우일 경우 시스템은 반드시 8859_1로 문자셋(로케일의 문자코드셋)으로 되어야하고
2의 경우는 한글코드(리눅스, 원도우즈에 따라 명칭이 다르지만 기본적으로 완성형표준코드입니다)로
지정되어 있어야 깨지지 않습니다.

4. 자바빈이나 db에서 한글처리 1의 경우를 비추천으로 하는 이유는 자바빈이나 db에서도
모두 8859_1로 맞추어 주어야한다는 것입니다. 즉 클래스를 컴파일할 때도 컴파일 옵션에 8859_1로
지정해주어야 클래스안의 한글이 깨지지 않습니다. (디폴트로 시스템 문자셋으로 컴파일, 원도는 당근 한글셋)
2의 경우는 euc-kr로 맞추어 주어야합니다. 대부분 개발시스템의 문자셋은 당근 한글이겠죠 ^^
2의 경우에서 mysql의 연결url에 unicode사용 옵션을 주고 문자셋을 주면 그냥 됩니다.
(상세한 옵션: jdbc:mysql://localhost/디비명?useUnicode=true&characterEncoding=euc-kr)

오라클도 시스템 문자셋에 따라 알아서 동작하는데
db가 asc7인가(갑자기 기억안남) 일때 문제가 있는 경우가 있는데 이경우 오라클 클라이언트를
같이 맞추어주고 getString(…)메소드를 읽을 때 new String(XXX.getBytes(8859_1), “euc-kr”)로
변환해주어야 합니다. 이건 오라클 jdbc드라이버가 db asc7 –> client euc-kr 변환을 못해주는 것 같습니다.
asc7 –> 8859_1 –> euc-kr 요렇게 두번 해주어야 하는데 asc7 –> euc-kr 요렇게 바로 해버리니까
한글이 깨지는 것 같습니다.(오라클 jdbc 스펙을 확인해보세요..)

대충 한글 문제에 대해서 얘기를 했는데 약속시간이 급해서 확인 안하고 대충 갑니다.
틀린 것이 있으면 리플를 다세요… 그럼… ^^;;; (늦었다)

제목 : Re: 정말 고마운 글이네요…^^
글쓴이: 손님(guest) 2003/10/16 00:51:25 조회수:126 줄수:7

이해가 되네요…

여지껏.. 해메왔던 경험들이..

정말 고맙습니다.

Similar Posts:

Comments 4

  1. 김병우 wrote:

    이거 글보니깐 기억나느게 있네요

    여기 중간에 euc-kr이거 하믄 안깨지던데요 ^^

    Posted 21 Oct 2003 at 4:12 am
  2. 김병우 wrote:

    씁 위에꺼 ㅡ.ㅡ 소스 코드로 먹었나보다 ㅎㅎ

    request.setCharacterEncoding(“euc-kr”);

    암튼 이거하니깐 안깨지던데요 근 1년간 문제 없이 ^^

    Posted 21 Oct 2003 at 4:14 am
  3. 김지현 wrote:

    액셀다운로드시 한글이 깨집니다.
    왜일까요?

    Posted 18 Jan 2005 at 2:10 pm
  4. 서민구 wrote:

    글쎄요.. 저도 한글은 워낙 주먹구구로 하던가 딴 사람이 시키는대로 코딩하는 주의라서요.. 지식도 부족하고. weblogic 이면 j2eestudy.co.kr 을, 그 외의 환경이라면 javaservice.net을 찾아보세요.

    Posted 07 Apr 2005 at 1:02 am

Post a Comment

Your email is never published nor shared.