출처 : http://ndba.egloos.com/2831611
저도 한글 깨짐 문제로 골머리를 앓고 있다가 깨알같이 정리해놓으신 포스팅을 보고 냅다 퍼왔습니다.
아래부터 원글 입니다. (출처 : http://88oy.tistory.com/223)
처음 JSP 나 서블릿을 하다보면.... 한글이 깨져서 나와 당황하게 된다. (나 또한 그랬다 ㅡ.ㅡ;;;)
하지만 웹프로그래밍에서 " 한글이 깨져서 나와요~!"
라고 말하는 것은 마치 "인터넷이 안되요~!"
라고 말하는 것만큼이나 복잡하고 여러가지 상황을 봐야 한다. ㅡ.ㅡ;;
일단 언어코드가 어떻게 바뀌어 왔는지 살짝만 살펴 보자.
처음에 이놈의 양키 색히들이 만든 컴퓨터에선 당연하게도 영어만 통했었다.
우리가 그냥 무의식적으로 컴퓨터에 한글로 혹은 영어로 입력하지만
사실은 이런 언어는 코드데이터로 처리가 된다.
컴퓨터에서 쓰는 영어코드는 ASCII 코드 이다. 7비트의 코드로 되어있다.
하지만 ACII 코드만 있는 것은 아니고 점점 다른 코드체계들이 나왔다. (종류들은 생략. 귀찮음 궁금하믄 찾아봐)
한글 역시 마찬가지다.
조합형이니, 완성형이니, 확장완성형이니, 유니코드 한글형이니..뭐 잔뜩있다.
간단히 말하면
조합형은 즉석에서 한글 자모를 조합해 한글을 표현한다. 예전 도스 시설에 많이 사용하였으나, 현재는 거의 쓰이지 않는다. 모든 한글 문자를 다 표현 할 수 있다는 장점이 있다.
완성형은 한글에서 많이 쓰이는 것들만 골라 미리 글자를 만들어 놓는다. 예를 들면, "가" "낙" 답" 이런식으로 말이다. 참... 문제가 많은 타입이지 않나 싶다. 윈도우95 까지 순수 완성형 한글을 썼다.
우리나라 표준에는 KSC5601 을 표준한글코드로 정의하고 있는데, 기본은 완성형 한글이고, 자모가 입력될 때 글자를 모은다음 코드테이블에서 코드를 찾아 치환한다. 메모리 낭비가 심하다는 단점이 있다.
확장 완성형한글은 기존의 완성형 한글에 "뺅" "잌" 같은 글자를 억지로 추가해 넣은 것이다. 윈도우98부터 현재버전까지 이놈을 쓴다.(내부적으로는 유니코드를 사용한다.)
유니코드는 한글 뿐 아니라 전세계 모든 언어를 모두 표현 할 수 있다. 한글을 표현 할때 확장 완성형보다 나은 점은, 코드가 순서대로 언어에 일관적으로 할당이 되어 있다는 거다. 조합형과 마찬가지로 모든 한글이 입력 가능하다.
자, 그럼 본론으로 돌아와서 왜 한글이 깨지는지 알아보자.
일단, 우리가 쓰는 한글 웹브라우져에서는 KSC5601 코드를 기본으로 사용한다.
그리고 웹으로 전송 할 때에는 x-www-form-urlencoded 형식으로 인코딩이 된다.
근데 이놈의 서블릿은(JSP도 마찬가지다. 어차피 서블릿으로 컴파일 되니깐) 우리의 훌륭하고 아름다운 한글을 개무시 하는 특성을 가지고 있다.
이 병신같은 서블릿님께서는 우리의 한글 코드 KSC5601 이 인코딩되어 전달되면, KSC5601이 왔다고 생각하지 않고 라틴어가 왔다고 생각한다. (라틴어 표준코드는 ISO-8859-1 이다) 그리고 JAVA 에서는 유니코드를 사용하므로 서블릿은 전달된 한글코드를 ISO-8859-1 형식으로 인코딩하게 된다.
이것은 명백하게 서블릿엔진 자체의 버그다. SUN 은 하루 바삐 이 버그를 고쳐 주기를 바란다.
아무튼 일단 웹->서블릿 으로 전달되는 과정에서 한글이 깨지게 된다.
그럼 이걸 안깨지게 하려면 어째야 하냐??
자~ 한번 보자.
일단 웹에서 KSC5601 코드가 x-www-form-urlencoded 로 인코딩되어 서블릿에 전달되었는데, 서블릿은 이놈이 ISO-8859-1 이 온걸로 인식하고 ISO-8859-1 형식의 유니코드로 인코딩한다.
여기까지가 현재 상황이다. 이걸 원래대로 되돌릴려면
ISO-8859-1 형식의 유니코드로 인코딩된(깨진 상태다)놈을 다시 ISO-8859-1의 바이트 배열로 추출한다. 그 다음에 그놈을 다시 원래의 포맷인 KSC5601 형식으로 변환 해주면 된다.
또 문제는 서블릿에서 웹으로 보낼 때도 한글을 전송하면 이놈이 ISO-8859-1 형식으로 변환한다. 그래서 이것은 KSC5601 을 사용하는 euc-kr 로 변환해서 전송해야 한다.
이것은 좀 간단한 편인데 JSP 페이지나 서블릿에 contentType 의 charset 을 "euc-kr" 로 설정해 주기만 하면 된다.
(참고로 euc-kr 은 한글은 KSC5601 로 표현하고, 영어는 JSC5636을 사용하는 방법인데, 벨 연구소에서 제안한 유닉스 상에서 영어 외의 문자를 표현하는 방법 중에 하나이다. euc-kr 은 Extended UNIX Korea Code 의 약자이다.)
만약에 웹페이지에서 텍스트필드 같은데 입력해서 받아오려고 할때 request.getParameter() 로 한글을 받아왔다면 100% 깨졌다고 생각하면 된다. 그런 이 깨진놈을 위에서 말한대로 복구해야 하는데, 순서대로 해보자.
일단 깨진 스트링이 str 로 왔다면, 이놈의 ISO-8859-1 형태의 바이트 배열로 추출한다고 했다.
str.getBytes("8859_1")
이라고 해주면 일단 바이트 배열로 추출 하게 된다. 그러면 이놈을 KSC5601 형태로 바꿔줘야 하는데, String 객체를 생성 할 때, 생성자 중에 이런 놈이 있다.
String(byte[] bytes, String charsetName)
이놈은 특정한 charset 을 사용하여 바이트배열을 디코딩하여 생성한다.
따라서 다음과 같이 해주면 ISO-8859-1의 바이트코드배열을 KSC5601 로 바꿀 수 있다.
new String(str.getBytes("8859_1"),"KSC5601")
보통 이런 한글처리는 따로 유틸리티 클래스를 만들어 사용하는 편이다.
예를 들어 간단하게 들어온 문자열을, 한글코드로 바꿔서 내 뱉어 내는 메소드를 보이겠다.
public static String toKSC5601(String s){
if(s==null){
return null;
}
try{
return new String(s.getBytes("8859_1"),"KSC5601");
}catch(Exception e){return s;}
}
===================================================================================================================
jsp 한글처리 낙서장
2006/03/12 22:28
http://blog.naver.com/hacoto/50002494194
JSP와 한글처리
1. JSP에서의 한글처리 문제의 필요성
JSP의 한가지 문제점은 한글 처리 문제이다.
특히 user가 입력한 한글정보를 파일이나 DB에 저장할 때 null로 저장되거나
물음표(?) 등과 같은 특수문자가 저장 되는 경우가 있다.
반대로 서버에 저장된 한글정보를 브라우저를 통해 보여주려고 할 때
공백이나 물음표(?) 등으로 표시되기도 한다.
한글 코드에 대한 처리가 불완전하기 때문이며 이에대한 추가 작업이 필요하다.
서블릿 엔진의 버전에 따라 내용이 다른데 JDK1.3 버전에서는 추가작업이 많이 줄었다.
2. Resin에서의 한글처리
JSP 지시문에서 처리해주면 한글문제는 쉽게 해결된다.
<%@ page contentType="text/html; Charset=EUC-KR" %>
참고
* "EUC-KR" 또는 "EUC_KR" 또는 "euc-kr" 모두 상관없다.
3. JSWDK, javaWebServer, WebLogic 에서의 한글처리
DB와 JSP(JAVA)가 사용하는 코드체계가 다르기 때문에 한글처리문제가 발생하는데..
일반적으로 DB는 ASCII나 KSC5601 코드체계를 사용하고 JSP(JAVA)는 유니코드를 사용하기 때문이다.
우선은 JSP 지시문에서 page 지시어에 속성으로 Charset을 한글코드("EUC-KR")로 정의한다.
<%@ page contentType="text/html; Charset=EUC-KR" %>
그 다음엔 JSP 페이지에서 브라우저로 한글을 출력할 때에는 KSC5601(또는 "EUC-KR")로 변환하고,
반대로 한글정보를 DB로 저장할 경우에는 "8859_1" 코드로 변경하면 안전하다.
<%
String str="안녕하세요";
// 브라우저에 한글을 출력하기 전에 먼저 변환해 줌
str = new String(str.getBytes("8859_1"), "KSC5601");
out.println(str);
...
// 파일이나 DB에 한글을 저장할 때 먼저 아래처럼 변환해 줌
str = new String(str.getBytes("KSC5601"), "8859_1");
%>
4. Tomcat 에서의 한글 처리
우선은 JSP 지시문에서 page 지시어에 속성으로 Charset을 한글코드("EUC-KR")로 정의한다.
<%@ page contentType="text/html; Charset=EUC-KR" %>
한가지 더 해주어야 하는것은
Tomcat은 Get이나 POST를 통해 전송되는 값이 Cp1252로 변환되기 때문에
request.getParameter()메소드를 사용할 때는 반드시 "EUC-KR"로 변환해 주어야 한다.
<%
String name;
name=new String(request.getParameter("name").getBytes("Cp1252"), "EUC-KR");
%>
// 유니코드를 한글코드로 변환
protected String uni2ksc (String Unicodestr) throws UnsupportedEncodingException {
return new String (Unicodestr.getBytes("8859_1"),"KSC5601");
}
// 한글코드를 유니코드로 변환
protected String ksc2uni(String str) throws UnsupportedEncodingException {
return new String( str.getBytes("KSC5601"), "8859_1");
}
from:
http://www.senun.com/Left/Programming/Java/Jsp/jsp_syntax_hangul.htm
츨처 : okjsp Tips
makeKor() 메소드
<%!
public String makeKor(String s) throws java.io.UnsupportedEncodingException{
String kor="";
if (s==null)
kor=null;
else
kor=new String(s.getBytes("ISO-8859-1"),"EUC-KR");
return kor;
}
%>
makeKor() 라는 메소드를 먼저 살펴보자.
이 부분은 각 파일의 맨끝에 위치한다.
메소드로 들어오는 가인수 부분을 makeKor(String s)를 통해 s로 선언했고
그 s의 값이 Null인 경우 null 값을 보내주고 null값이 아니라면
String(s.getBytes(“ISO-8859-1”),”EUC-KR”);
자바의 표준 문자셋인 “ISO-8859-1”을 한국어 지원인 “EUC-KR”로 바꾸어주라고
명령한다. 변환후에는 변환값이 있는 kor 변수를 리턴한다.
<%
String id = makeKor(request.getParameter("id"));
String pwd = makeKor(request.getParameter("pwd"));
String name = makeKor(request.getParameter("name"));
String job = makeKor(request.getParameter("job"));
String email = makeKor(request.getParameter("email"));
String company= makeKor(request.getParameter("company"));
String mailing = makeKor(request.getParameter("mailing"));
%>
클라이언트(사용자)가 입력한 자료를 가져다가 각 변수에 저장하는 부분이다.
전과는 틀리게 makeKor() 메소드가 사용되었다.
그 이유는 톰캣사용시 콘트롤에 의하여 파라미터로 한글이 전송되어질때 JSP에서
한글이 깨지는 오류가 발생하기 때문이다.
그래서 넘어온 데이터는 다시 자바프로그램내에서 한글로 바꿔주는 작업을 하여야 한다.
그리하여 임의로 makeKor() 라는 이름으로 메소드를 만들어 사용한다.
출처 : 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 스펙을 확인해보세요..)
대충 한글 문제에 대해서 얘기를 했는데 약속시간이 급해서 확인 안하고 대충 갑니다.
틀린 것이 있으면 리플를 다세요... 그럼... ^^;;; (늦었다)
출처 : Tong - 훈스구락부님의 JSP통
===================================================================================================================
==========================================
(3)mySQL에 저장할 경우 한글 문제 처리법
==========================================
DB저장시 한글 저장 문제가 발생하는 이유는
DB Server와 JSP가 사용하는 코드 체제가 다르기 때문입니다.
DB는 일반적으로 ASCII나 ksc5601코드 체계를 사용하고
JSP는 Unicode를 사용합니다.
-------------------------------------------------------------------
Class.forName(org.gjt.mm.mysql.Driver");
String URL="jdbc:mysql://localhost/myDB<font color=red>?useUnicode=true&characterEncoding=euc-kr</font>"
Connection conn=DriverManager.getConnection("URL","user","password")
----------------------------------------------------------------------
jdbc부분중에서 빨강색으로 적힌 부분을 넣어 주도록 하자.
Tomcat이 아니라 <font color=red>Resin</font>일 경우는 euc-kr이 아니라 <font color=red>ksc5601</font>임에 유의하자.
</pre>
배성환
2004-01-16 13:34:20
x
============================================
(1)JSP 페이지내에서 한글문제 처리법
============================================
아래와 page Directive 속성을 euc-kr(또는 EUC_KR)로 지정하면 된다.
------------------------------------------------------
<%@ page contentType="text/html;charset=euc-kr" %>
-------------------------------------------------------
최근 정보에 따르면 euc-kr대신에 'MS949'(대문자로)를 쓰는 것이 좋단다.
참고; '*.jsp'가 아닌 순수 HTML(*.html or *.htm)파일일 경우
아래와 같이 HTML의 meta태그를 이용한다.(물론 default값이다)
----------------------------------------------------------------------
<meta http-equiv="Content-Type" content="text/html;charset=euc-kr">
----------------------------------------------------------------------
만일, OS(웹서버 말고)가 Win2k일 경우는
맨마지막의 'charset=euc-kr'대신에 'ksc-5601'로 지정한다.
즉 아래와 같다.
----------------------------------------------------------------------
<meta http-equiv="Content-Type" content="text/html;charset=ksc5601">
----------------------------------------------------------------------
배성환
2004-01-16 13:35:20
x
========================================================
(2)HTTP로 전송된 것을 받을 경우 한글문제 처리법
========================================================
이 문제는 JSP Container마다 조금씩 다르게 처리해 줘야 한다.
준비운동 ;
한글을 지원하는 코드에는 euc-kr(또는 ksc5601)과 8859_1이 있다고 했습니다.
# euc-kr : jsp 페이지내에서 사용되는 한글 인코딩 방식.
# 8859_1 : input박스를 통해서 http로 전송되어서 request.getParameter()로 받을 때
저장되는 한글 인코딩 방식.
앞서 페이지 지령문에서 다음과 같이 지정했는데 문제가 일어나게 됩니다.
이 경우 페이지내에서 출력하고자 하는 인코딩형태는 euc-kr인데,
http를 타고 전송된 글은 8859_1로 인코딩되어 있기 때문에 한글이 모두 깨져버립니다.
------------------
해결책
------------------
그 해결방법은 8859_1로 전송되어 온 글을 euc-kr로 변환하는 것입니다.
일반적으로 받은 데이터를 코드 변환할 때는
String형의 값을 byte형으로 변환하는 getBytes()메소드를 기본적으로 이용한다.
원래 문; String name=request.getParameter("name"); //Resin일 경우 처리가 필요없다.
*******************************************************************************************
변경 후; String name=new String(request.getParameter("name").getByets("8859_1"),"euc-kr");
********************************************************************************************
8859_1코드로 전송받은 글을 euc-kr코드로 변환해서 받고 있다.
배성환
2004-01-16 13:36:11
x
======================================
Container에 따른 한글 문제 처리 요약
======================================
한글 처리 작업은 JSP Container에 따라 조금씩 다르며
해당 Container의 버전에 따라 차이가 있을 수도 있어
약간 복잡할 수도 있습니다.
====================================================================
1. Resin ; jsp내의 page 속성변경, 받을 경우 불필요, db저장시 ksc5601로
=====================================================================
이경우는 아래와 page Directive 속성을 euc-kr(또는 EUC_KR)로 지정하면 된다.
------------------------------------------------------
<%@ page contentType="text/html;charset=euc-kr" %>
-------------------------------------------------------
최근 정보에 따르면 euc-kr대신에 'MS949'(대문자로)를 쓰는 것이 좋단다.
다음에는 DB저장시 옵션을 euc-kr이 아닌 'ksc5601'로 준다.
-----------------------------------------------------------------------------------
String URL="jdbc:mysql://localhost/myDB?useUnicode=true&characterEncoding=ksc5601";
------------------------------------------------------------------------------------ㄴ
주의 ; http에서 전송 된 글을 받을 때 어떤 처리도 하지 않는다.
=================================================================================
2. Tomcat
=================================================================================
이 경우는 버전에 따라 다소 차이가 있음을 알아 두자.
물론 Resin처럼 page Directives 속성을 지정해 줘야 한다.
Tomcat은 http로 전송된 글을 받을 때 버전마다 차이가 있어 신경써야 합니다.
Tomcat 버전 3.0이하인 경우
---------------------------
이 버전의 톰캣은 값이 넘어 올때 8859_1형식이 아니라 Cp1252로 넘어 오기때문에 다음과 같이 처리한다.
String name = new String(request.getParameter("name".getBytes("Cp1252"),"EUC_KR");
Tomcat버전 3.1이상인 경우
---------------------------
이 버전은 8859_1로 넘어 옵니다.
String name = new String(request.getParameter("name".getBytes("8859_1"),"EUC_KR");
배성환
2004-01-16 13:36:59
x
----------------------
한글 처리 편하게 하기
----------------------
여기서 알아 볼 것은 한글 변환을 편하게 하는 방법이다.
우리는 지금까지 한글을 euc-kr으로 변환할 때는
다음과 같은 형태로 객체를 생성하였다.
String u_name = new String(request.getParameter("u_name").getBytes(8859_1","euc-kr");
그런데 직접 소스를 입력해 본 사람이라면 알겠지만,
한글 코드 변환할 때마다 일일이 이렇게 길게 치는 것이
조금은 불편하다고 느꼈을 것이다.
그렇다면 아예 한글 코드 변환하는 기능을
메소드나 빈으로 만들어 사용하는 것이 조금은 수고를 덜어 줄 것이다.
우선 메소드로 만들어 사용하는 방법부터 보자...
방법1; 메소드(toEuckr)로 만들어 사용하기
------------------------------------------------------------------------
<%!
String toEuckr(String str) throws java.io.UnsupportedEncodingException
{
if(str != null) return new String(str.getBytes("ISO-8859-1","EUC-KR");
}
%>
---------------------------------------------------------------------------
String u_id = toEuckr(request.getParameter("u_id"));
한글을 포함한 문자열은 toEuckr() 메소드를 이용하여 처리한다.
방법2; class로 만들어 사용하기
----------------------------------------------------------------
makeKOR.java
import java.io.*;
public class makeKor
{
public static String toEuckr(String str) throws UnsupportedEncodingException
{
if(str != null) return new String(str.getBytes("8859_1","euc-kr");
}
}
----------------------------------------------------------------------
빈 사용법;
우선 makeKOR.java을 컴파일한 후(makeKOR.class가 생성)
사용할 때는 import를 이용해서 빈을 포함시킨다.
----------------------------------------------------------------
<%! import="makeKOR" contentType="text/html;charset=euc-kr"%>
<%
String u_name = makeKor.toEuckr(request.getParameter("u_name"));
%>
-------------------------------------------------------------------
--이상으로 두가지 방법이 있음을 알아 보았는데,
자기가 편한 방법을 이용하면 되겠다....^================^
=============================
getByte()메소드 자세히 알기
=============================
사용형식; getByte(String enc)
(1)정 의 ; String을 매개변수로 주어지는 charset으로 변환.
(2)매개변수 ; US-ASCII, ISO-8859-1, UTF-8, UTF-16BE, UTF-16LE, UTF-16등
(3)리턴 값 ; byte[]
(4)예외 상황; 발생되는 exception은 UnsupportedEncodingException이 있다.
이 exception은 'java.io.*'를 import해야 사용가능하다.
네이버 블로그 :: 포스트 내용보기
jsp 컨테이너도 수십가지 jdk 도 sun jdk, ibm jdk 두가지 이상이 있고요, 버전도 가지가지.
더구나 DB 도 한가지가 아니고 각 DB 의 jdbc driver도 수십가지입니다.
물론 영어는 잘 처리하겠지만 문제는 국내에서는 한글입니다.
os 마다 character set 이 또 다르게 설정되어있죠.
아~ 골아픕니다.
이럴 경우 jdbc 에서 한글문제를 해결하는데 막연히 인코딩을 해주면 안됩니다. 거치는 단계가 많기 때문이죠.
form (-> jsp) or (-> bean, servlet) -> jdbc driver -> DB -> jdbc driver (-> bean, servlet) -> jsp -> client browser
이기 때문에 중간에 어떤 놈이 대사를 그르칠지 확인을 해야됩니다.
일단은 가장 처음에 점검할 사항은
DB 에서 확인해 보았을 때 한글이 깨지지 않았나입니다.
만일 깨졌다면 문제는 DB 에 입력하기 전까지의 과정에서 생기는 문제입니다. 그럴 경우 form에서 받아온 값을 다르게 인코딩하거나 아니면 인코딩된 것을 없애주거나 해서 찾아냅니다.
만일 DB 에 입력된 한글이 제대로 보인다면 DB 에서 가져오는 부분을 확인해야 겠죠.
하여간 제가 갖고 있는 debugging 법이었습니다.
도움이 되시길...
추가:
좋은 글 올려주셨군여. 제가 조금 덧붙이면여...
오라클이나 SQL-Server 같은 경우 언어세팅을 할때 유니코드로 지정하면
(예를 들면 UTF-8) 데이터베이스에 한글로 잘 들어갑니다.
물론 쿼리 날려서도 한글 데이터 볼수 있구여.
이걸 모르시는분들은 대부분 데이터베이스에 한글이 깨진것을 다른
문제로 알고 고생을 하시드라구여.
위에 님께서 말씀하신것처럼 일단 데이터베이스에 한글이 들어가는지
부터 확인하는게 좋겠습니다. 그리고나서 한단계씩 나가는거죠.
김영익[youngick]
출처 : Tong - nagne82님의 JSP통
===================================================================================================================
제목 : [Comment] 다국어 인코딩 문제의 위치
많은 분들이 다국어 때문에 헤메이고 있습니다.
이에 대해 저의 짧은 지식이지만 공유할 까 해서 코멘트를 달아봤습니다...
글의 영양가는 뒷부분에 있습니다.
시간 없으신 분들 장문인 만큼 뒷부분을 읽어주십시오. 다만 문자셋의 기본은 --;;
이 글에선 DB는 부분은 범위밖이기 때문에 다루지 않을 것입니다.
사실 대부분의 문제는 DB외의 곳에서 발생할 것입니다.
저는, 엔코딩에서 제일 중요한 것을 아래와 같이 분류하였습니다.
1. 각 문자셋의 종류와 이해
2. 소스 파일의 엔코딩 형태
3. 컴파일된 파일의 엔코딩 형태
4. 컴파일된 파일을 사용하는 엔코딩 형태
5. UTF-8의 필요성 인식.
6. WebBrowser의 이상한 행동(?)
"new String(str.getBytes("8859_1"), "EUC_KR");"
와 같은 문제는 별개입니다. (문자셋의 종류와 이해가 우선이지요)
<
1번에서 주의해야 할 것은. Unicode와 Unicode(UTF-8)을 동일시 여겨셔는 안된다는 것입니다.
Unicode는 코드페이지 1200이며, Unicode(UTF-8)은 65001 입니다.
그 크기 또한 다릅니다. (하늘과 땅차이 -_-)
- Unicode와 Unicode(UTF-8)을 간단 정리
Unicode는 모든 문자를 2Byte로 표시한다. - ISO-2022형태의 다국어와 차이점.
(영문이고 다국어고 필요없다. 어떤 언어든 65536가지를 표현 가능하다.
이 뜻은 2Byte가 어떤 형태로 구성되는지를 알 수 있게 하는 말.)
UTF-8은 기존 ASCII 1xx까지 유지하며 다국어는 2, 3Byte로 표시한다.
(즉, 영문은 1Byte처리 - 아래에서 다시 설명하기 때문에 매우중요)
고로, UTF-8은 프로그래밍 언어에 사용하여도 손색이 없다.
☆다국어 - 여기서 필자 맘대로 재정의한 뜻으로 기존 2Byte이상을 필요하던 언어.
(영어등도 포함해서 말한다고 딴지 걸지 말란 뜻에서;;;)
>
<
2번을 이해하지 못하였을 경우에는 이러한 문제들이 발생합니다.
가. 만약 소스가 JSP일 경우 파일을 Include할 때 A는 정상인데 B는 깨지거나
하는 문제 발생. (혹은 그 반대)
※주의! 와는 별개이므로 소용 없습니다.
나. *.java를 컴파일 한뒤 다국어 사용시 깨어져 나온다. --;;
(static이나 비교문등에 미리 입력해 놓은 다국어...)
물론 Runtime시 복구할 수 있는 경우도 겠지만 그렇게 하는 사람 있다면 따돌림 당한다는.... --;;
해결법 :
가. 소스파일을 만들어 저장할 시에 자신이 작성한 소스의 문자셋을 확인한뒤
그 와 동일하게 저장하도록 하고, 프로젝트에 관련된 모든 파일을 동일한 문자셋으로 작업해야 한다는...
의 xxx에 자신이 작성한 문자셋을 동일하게 입력.
만약 기존에 미리 만들어둔 소스가 있을 경우라면 밑에서 다시 언급하겠습니다.
나. 소사파일을 만들어 저장할 시에 자신이 작성한 소스의 문자셋을 확인한뒤
그 에 따라 컴파일 할 수 있도록 한다.
>
<
3, 4번의 경우는 현재로써는 가정이다. (혹은 사실 - 물론 내 자신은 아직 접한적은 없다.)
컴파일된 파일이 JVM에 의하여 로딩되는 과정과 Runtime의 과정에서 엔코딩이 서로다른 형태의
Class를 불러 들였다면? 그렇다면 이중 entrypoint가 있는 클래스가 디코딩의 기준이
되는 것일까? 그렇다면 entrypoint외의 타 클래스에서 사용된 다국어는 모두 깨어질 것이다.
아니라면 클래스간 호출시 JVM은 그 에 따른 처리를 해야한다. (느려진다.)
물론 현재의 JVM은 일반적으로 모든 소스를 Unicode 혹은 UTF-8로 불러들일 테지만 아닐 경우는 어찌 해야 할 까?
(컴파일된 파일의 원본의 형태가 뭐건 Unicode 혹은 UTF-8로 변형)
이렇게 3, 4번을 넘기자 --;;
>
<
5는 2번의 경우만으로도 UTF-8의 필요성을 느끼지 않을 수 없겠습니다.
번거롭게 경우에 따라 소스를 다시 원하는 형태로 엔코딩하여 만들어야 한다는 것은
Tool과의 노가다를 감행해야한다는 것인데 말이죠.
그러므로 할 일 많(-_-)은 프로그래머로써는 UTF-8을 사용해야 한다는...
또한, UTF-8의 정렬속도 쥑입니다. --b (Unicode와의 비교를 제외한다면.)
한글이 모두 순차배열되어 있기 때문입니다. :)
그에 비해KSC5601(KSC5601-1992)는 정렬속도는 떨어진다는... (공포의 8822자)
>
<
Application에서 프로그램 소스등(*.JSP, *.JAVA, *.TXT)의 엔코드 타입을 자동으로 인식!?!
결론은 자동 인식 가능한 문자셋이 있기도 없기도 입니다.
일반적으로 2Byte로 된 문자셋은 인식이 불가능 하지만 Unicode는 가능 합니다.
첫 시작을 16진수로 FF FE로 시작하는 문서는 Unicode를 알리는 문서입니다.
또한 Unicode(UTF-8)은 서명있는 Unicode(UTF-8) 문서일 경우는 대부분 가능합니다.
없는 경우는 가능한 툴이 있기도 하고요. (말이 자동이기 거의 강제 --)
만약 서명이 있는 경우라면 EF BB BF로 시작합니다.
이에 따라 각종 Tool에서 자동으로 읽을 수 있는 것입니다.
>
소스의 문자셋을 변경사용하기...
일반적으로 프로젝트의 모든 소스는 엔코딩 형식이 동일해야 하겠죠?
만일 기존 소스가 있는데 다르다면 현 프로젝트와 맞추어야 할 텐데...
쉽게 구할 수 있는 툴은 UltraEdit가 정도가 되겠네요 저는 v9.10을 가지고 있고
File -> Conversions에 있습니다. 이 곳에서 원하는 형태로 가능하겠습니다.
-단, 한글들의 문자셋변환 툴은 아직 보질 못했음. 혹시 보신분 손 ^^/
한글에서 하위변환은 완벽히 안되므로 이를 염두해야함.
JSP에서 와
META TAG의 contentType="text/html;charset=xxx"
이둘을 사실상 모두 사용하는 경우는 웃지 못할 일입니다.
(실로 대단한 이슈입니다.)
이곳 게시물중
----------------------------------------------------------------------------------
==게시물 1========================================================================
euc-kr 이나 ksc5601 을 사용할 경우 브라우저의 한글은 잘 나온다.
대신 확장한글을 표시할 수 없어서 ?? , ?d , ?? 같은 글자는 ? 로 깨어져 나온다.
소스보기를 해도 완전히 깨진다.
...
...
중략
...
서버쪽 한글처리는 MS949 로 정하고, 브라우저의 한글처리는 ksc5601, euc-kr 등으로
한다. 즉 서버쪽은 @page 의 contentType 속성을 charset=MS949 로 태그 내의
태그에서 Content-type 의 값을 charset=ksc5601 로 주면 브라우저쪽의
한글처리를 마무리지을 수 있다.
==게시물 2========================================================================
NOTE: '??'과 같은 확장한글의 경우는 추가적인 테스트가 필요합니다.
추정컨데,
1) MS949(Cp949)를 DB(Oracle,DB2,..)가 지원하는가?
2) JVM file.encoding MS949->Cp949 에서 정상적인 동작을 하는가?
3) default.client.encoding/client.encoding.override MS949->Cp949 에서 정상적인
동작을 하는가?
4) 위 팁문서처럼 META tag에서 KSC5601을 반드시 써 주어야 하는가?
==게시물 3========================================================================
Windows에서의 JVM의 한글디폴트 인코딩 캐릭터셋 문자열은 "EUC_KR" 입니다.
Linux에선 "KSC5601"이라 나오는 군요.
그러나 "EUC_KR", "KSC5601", "EUC-KR"은 모두 동일합니다.
==================================================================================
----------------------------------------------------------------------------------
이런 내용이 있었습니다.
MS949는 엄밀히 "KSC5601-1987" 입니다. 또한 "KSC5601-1992" 입니다.
KSC5601이들의 차이점은 1992는 1987를 모두 포함하고 문자의 위치까지 호환이 되며
1987에 추가된 문자 8822(공포의)개가 있다는 것 뿐입니다.
(현재 MS OS에서는 단순한 폰트차이로 봐도 무방)
그러므로 일반적으로 KSC5601라고 통합하여 사용하는 것입니다.
(엄밀히 MS949는 META TAG에서 windows-949 혹은 ks_c_5601-1987 에 해당합니다.)
그러니 위에 언급된 게시물에 있는 MS949관련 사건들은 무효-_-가 아닐까요?
무슨 의미인고 하니 EUC-KR(Extended Unix Code-Korean)에서는 ?揚? 깨지지만 KSC5601은 깨지지 않습니다.
쓩, ??, ??, ??, ?嶽? 비교해보면 EUC-KR은 쓩만을 표현할 뿐 입니다.
KSC5601-1992는 확장을 표함합니다. (물론 UTF-8과는 비교할 것이 못되지만...)
하지만 EUC-KR은 확장을 포함하지 않습니다.
(위의 게시물 3은 2000/05/28일자로 오래되었기에
그 시절 KSC5601 = EUC-KR 라고 한 표현한 것은 그다지 문제 삼을필요는 없는듯 --;;
다만 저 게시물을 보고 아직 맞다고 생각하시는 분들을 위하여 언급하였음.)
어쨌든 어떠한 환경이던 WebBrowser간엔 어떤 문자셋이건 쌍통합니다.
(이점이 중요합니다. 왜 깨어져야할 확장 글씨가 정상 표시되는지를 이제 설명합니다.
-MS Win XP에서 IE 6.0과 Nescape Navigator 7.0을 테스트 해봄. Linux, Unix에서 안해봄)
제가 위에서 언급한 확장글씨가 왜 이곳 게시판이 EUC-KR임에도 불구하고 깨지지 않고 정상으로 보일까요?
WebBrowser는(어쩌면 OS레벨) HTML 소스의 문자셋이 뭐건 Unicode (단, UTF-8 문자셋은 제외)로 변환시킵니다.
그리고 화면에 출력합니다. 이 때 필드(INPUT TAG, TEXTAREA TAG등)에 입력한 값 역시
당연 Unicode(UTF-8인지는 정확히 확인하지 않았음. 하지만 UTF-8문자셋은 그대로 UTF-8) 데이터 입니다.
(눈으로는 구분 못하죠.)
그래서 입력할 당시에는 모든 문자를 입력할 수가 있는 것입니다.
허나 값을 서버로 보내면 HTTP Header (혹은 META TAG)에 정의된 문자셋으로 컨버팅 합니다.
(Server로 전송되는 TCP/IP 데이터를 보면 증명 가능)
이 때 컨버팅 불가능한 문자는 &# + Unicode값 으로 변경됩니다. 그렇게 서버로 날라가는 것입니다.
(이 값만으로도 알 수 있겠지만 EUC-KR은 KSC5601에 비해 확장한글이 부족하단것을 알 수 있습니다.)
만약 서버에 날라간 엔코딩 타입이 KSC5601이였지만 깨지는 문자가 있었다면, 그 깨지는 문자는
&# + Unicode 형태로 계속 보존되게 되는 것입니다. DB에 역시 그렇게 입력됩니다.
그렇다고 한다면 눈치빠른 분들은 벌써 한가지 이상의 문제를 지적하실 것입니다.
첫째. &# + Unicode 로 표현된 문자는 특수처리를 하지 않는다면 영원히 그렇게 되어 있다는 것을...
(많은 문자셋을 보시면 알겠지만 ACSII는 유지되기 때문입니다.)
고로, WebBrowser 이외의 곳에서는 문제가 --;;
-이 때문에 DB에서 검색할 경우에 문제가 있다.
둘째. 기존 &# + Unicode를 추후 Unicode, UTF-8등에 마이그레이션 할 때 따로 작업 해야 할 것입니다.
(제가 아직 자동변경해주는 툴은 못 봤습니다. --;;
뭐 그리 어려운건 아니지만 양이 크면 큰일인 것 만은 확실합니다.)
셋째. DB의 필드의 길이가 개발자가 원했던 길이를 벗어날 수도 있는 문제.
&# + Unicode는 최대 7자의 길이를 가집니다. (MAX : ??) 그럼 EUC-KR이나 KSC5601로 DB용량 아끼려다
필드깨지고 필드길이 제한 없으면 오히려 Unicode혹은 UTF-8보다 용량만 증가하고 --;;
넷째. 간혹 게시물등 내용을 보면 &# + Unicode값이 그 대로 보이는 경우가 있습니다.
이유는 제가 일전에 올린 게시물 내용에도 언급했듯 & 을 &로 변형하였기 때문입니다.
즉, &를 &로 원래대로 놓으면 첨에 입력했을 당시의 문자가 보이는 것입니다.
다섯째. 어쩌면 MS외의 OS환경은 그 문자를 표현할 방법은 특수처리를 하지 않는 이상
현재로써는 없을 수도 있습니다. (제가 Linux, Unix에선 안해본지라 --;;)
참고.
'?' <- 이 문자는 Unicode와 UTF-8문자셋이 아니면 깨집니다.
WebBrowser에서 보는 데는 지장 없습니다. 지금도 보이시죠?
이 '?'는 서버에 전달 될 때 ? 이렇게 변형되어 전달 됩니다.
(지금 이 게시판에서 WebBrowser의 소스보기를 해도 알 수 있습니다.)
정리하자면
1. 정말이지 UTF-8은 꼭 필요하며 (한글만 사용한다 할 지라도) 필요한 시기는 지금입니다.
2. MS949 와 KSC5601은 같으니 위에서 언급한 MS949사건(?)은 정확성을 위해
여러 환경에서 (JAVA의 각 버젼별 등등) 재 테스팅이 필요할 것으로 사료됩니다.
- 실제 제가 MS949로 서버에서 처리라는 곳에 가서 HTTP프로토콜로 전송되는 값을 확인한 결과
KSC5601과의 차이를 못 봤습니다.
Servlet, JSP, HTML페이지 = ksc5601로 해서 다시 한번 테스트 해보셨으면 함.
3. WebBrowser가 버젼과 OS별로 어떠한 형태로 서버에 값을 전달하는지 정확히 알아야 합니다.
또한 이 때문에 JSP등 WebBrowser와 통신하는 처리는 DB의 특성을 안탄다고 봐도 무방.
(대부분 DB의 엔코딩을 EUC-KR, KSC5601로 하고 프로그램 역시 그렇게 짜기에)
4. JAVA에서 EUC-KR을 사용하실 거라면 KSC5601을 추천합니다.
(단, 정렬시 속도저하 혹은 엉뚱한 순서 우려)
5. EUC-KR과 KSC5601의 상호변환을 허용하지 말자. (특히 KSC5601-1992에 문제가 있음)
※ 문자는 bits와 Font의 장난이란걸 잊지 마세요.
(Font의 장난에 특별히 주의하십시오.
bits값은 정상인데 OS따라 표시되지 않는 경우도 있고 Tools에 따라 표시되지 않는 경우도...
그러므로 문제가 되는 곳에서는 항상 bits값을 확인하는 습관을...)
지금껏 정리가 안되었다면 안된 장문 읽어주신것 감사드립니다.
잘못된점 있으면 지적하여 주시구요
건승하십시오.
==================================================================================
이 글은 EmotionalBrain이 작성하였으며 처음 게시된 곳은 www.javaservice.net 입니다.
이 글을 어디에 사용하든 작성자와 원 출처는 지울 수 없습니다.
2002.12.01
==================================================================================
P.S
위에 "게시물 1" 에서 언급된 내용을 잠깐 말하자면
JSP에서 라고하면 아시겠지만
XXX가 META TAG보다 HTTP Header에 Context-Type이 먼저 날라갑니다.
이 때 JSP에서 MS949라고 하면 HTTP Header에서도 MS949라 날라가는데 WebBrowser에 그런게
없다는 걸 감안하면 JAVA의 황당함이 --;;
MS949는 엄밀히 말하면 META TAG에서 "windows-949" 혹은 "ks_c_5601-1987" 에 해당하는데
그대로 "MS949"가 -_-;;
그덕에 META TAG에 따로 windows-949나 "ks_c_5601-1987"를 무조건 넣어야 한다는...
어찌됐건 MS949는 KSC5601이기 때문에 KSC5601로만 모두 처리하면 MS949는 필요 없습니다.
P.S 2
이거 작성할라구 이것과 관련된 윈도우 창만 지금 30개가 떠 있네요 --;;
무려 5시간 허비 --;; (확실하게 쓰려구 많은 노력을 했기에...)
Navigator두 MS OS에 첨 깔아보고 --;;
(근데 제 컴이 빨라서인지 Navigator가 예전에 비해 실행속도 무지 빨라졌네요!)
===================================================================================================================
한글 문제 정리
1.Servlet/JDBC연동에서 한글문제
---------------------------------
>Oracle JDBC를 설치하구요, 예제 EmpServlet를 수행하면
>한글이 깨져서 나오는군요.
>
>하라는데로 HDriverManager를 사용하였는데 Compile에러가 나오는데요..
>어찌된건지..
>
>그리구 오라클 Setting이 USA7ASCII로 되어있으면 상관없지 않나요
Servlet에서 DB와 연결하여 작업시 한글 문제는 상당히 골치 아픈 문제
입니다.
이는 Java에서는 내부적으로 Unicode를 사용하고 DB와 OS에서는 다른
encoding을 사용하기 때문에 일어나는 문제입니다.
먼저 어떤 OS에서 Servlet을 구동하고 있는지 궁금하군요.
Windows라는 OS에서 MS949라는 encoding을 기본적으로 사용하고 있고
Java 소스 파일을 컴파일할때 이를 사용합니다.
Servlet에서 한글 문제를 해결하기 위해서는 모든 encoding방법을 하나로
통일하면 됩니다.
Java 소스를 MS949 encoding형태로 컴파일 하여 사용하고 DB를 US7ASCII
형태로 사용한다면 DB에 자료를 넣을때는 자료를 ISO-8859-1 형태로 encoding
하고 DB에서 자료를 가져올 때는 KSC5601또는 MS949형태로 encoding하면
됩니다.
encoding하기 위해서는 String object를 byte[]로 만들고 이를 다시 String으로
만들면서 encoding rule을 적용하도록 하면 됩니다.
2.한글 읽어오기에 문제가 있는데여...
----------------------------------------
>JDK1.3을 사용하다가 JDK1.4로 업글 중인데여..
>웹에서 받아들인 한글 값들(request.getParameter()한 값들을)을
>지금까지 JDK1.3에서는
>URLDecoder.decode(String str) 로 해서 변환해 이용했거든여..
>그러면 컴퓨터의 환경 설정에 따라서 잘 변환이 되었습니다.
>그런데 JDK1.4 부터는 URLDecoder.decode(String str, String enc)로 되어 있구여
>URLDecoder.decode(String str)은 deprecate 되어서 사용이 안되거든여..
>그래서 URLDecoder.decode(String str, String enc)를 이용하려고 하는데
>enc 값을 "UTF-8", "euc-kr", "ISO-8859-1"로 해서 해봤는데
>웹에서 받아들인 한글 값을 제대로 decoding 하지 못하네여..
>enc 값을 어떻게 설정해야 하나여?
>
>JDK1.3에서 한글 값을 읽어오기는 아래와 같이 했습니다.
>String hangul = URLDecoder.decode(request.getParameter("hangul"));
>
>JDK1.4에서는 어떻게 해야 하는 거져?
decode를 하지마시구요..
전역으루
<%! String makeKOR(String str)throws java.io.UnsupportedEncodingException
{
String kor="";
if(str==null)
kor=null;
else
kor=new String(str.getBytes("ISO-8859-1"),"EUC-KR");
return kor;
}
%>
한 다음에 불러올때
makeKOR(request.getParameter("hangul")); 로 사용하세요...
3.한글화일 다운로드 문제..
----------------------------
import java.io.*;
public class JDU{
public static String get8859_1(String ko){
if (ko == null) {
return null;
}
try {
return new String(ko.getBytes("EUC_KR"),"8859_1");
} catch(Exception e) {
return ko;
}
}
public static String getEUC_KR(String en){
if (en == null) {
return null;
}
try {
return new String (en.getBytes("8859_1"), "EUC_KR");
} catch(Exception e) {
return en;
}
}
위 소스를 패키화 시켜서...
한글화 하고자 하는 부분에서
String filename = req.getParameter("filename");
filename = JDU.getEUC_KR((filename));
static 메소드 이기 때문에 쓰실때 객체 생성없이 클래스.메소드()
이런식으로 쓰시면 됩니다..
>
>String filename = req.getParameter("filename");//다운 받을때 저장되는 이름
>filename = URLDecoder.decode(filename);//한글 땜시 넣어줌
>
>===========================================
>
>그런데 컴파일을 해보니 에러표시는 아닌데 아래와 같은 메세지가 나옵니다.
>
>Note: Down_Bean.java uses or overrides a deprecated API.
>Note: Recompile with -deprecation for details.
>
>그래도 일단 실행을 시켜봤습니다.. 역시나 안되더군요..
>
>그래서 api를 찾아서 봤더니 메소드가 두개 있었습니다..
>인수를 하나 넣은거랑 두개 넣는거랑 두개 있길래 하나 넣어서 위와 같은 메세지가 출력이 되었으므로 인수를 임의 대로 아래와 같이 두개 넣어봤더니 메세지도 안뜨고 에러 표시도 안났습니다..
>
>filename = URLEncoder.encode(filename,filename);
>
>그래서 실행을 해봤더니 이번에는 아에 페이지가 아무것도 안뜨면서 하얀 상태로 있습니다..
>
>그래서 제 나름대로 아래와 같이 소스 수정을 해봐서 실행을 해 봤더니 역시 똑같은 하얀페이지만 나옵니다..
>
>filename = URLEncoder.encode("",filename);
>
>도 해보고
>
>filename = URLEncoder.encode(filename,"");
>
>도 해봤습니다..
4. 황당한 한글 문제로...
----------------------------
6.0에서 0.5 %의 확률로 한글이 깨진다는 것입니다..
이런 황당할때가..
혹시 해결책 아시는분 있습니까???
5.한글 문제....
--------------------
처음에 윈도우 NT 서버에서 테스트 할때는 한글이 안깨졌습니다
IE 버전에 전혀 영향을 받지 않고 그러나 리눅스(와우7.3)에서는 한글이 깨지더군요..
테스트 해본 결과 5.0에서는 안깨지고 6.0에서만 깨지더군요..
소스 약간 고쳐서 5.0과 6.0일때의 정보를 가지고 와서 각각 다른 소스로 한글 변환을 했습니다
첫날은 되더니만.. 둘째날은 또 안돼고..
셋째날은 또 되더니만 네째날 부터는 낮에는 되고 아침과 밤에는 한글이 안돼는
지경에 빠졌습니다
6.jsp:include page 에서 한글이 깨짐
----------------------------------------
jsp:include page include 당하는(?) 파일의 한글이 깨짐니다.
근데.. 이것을 java.net.URLEncode 해서 할수 없는게.. session 에 들어 있는 String[] 의 한글이 깨지거든요.. 난감합니다..
물로 System.out.print로 찍으면.. 잘나오고요...
page도 euc-kr ,ksc5601도 해보고.. String.getBytes("8859_1"),"KSC5601" 이것도 해봤는데.. 안돼더라고요.. 에라 모르겠다 하는마음에.. decode한다음에 encode도 해봤는데.. 역시나.. 안나옵니다..
방법좀 알려주세요..
resin 1.25 입니다.
j2sdk 1.4.0_03입니다.
java.net.URLEncode(str)
java.net.URLEncode(str,"ksc5601")
결과)
%B0%AD%BD%C2%C8%C6+++++++++ (ㅠ(ㅠ(ㅠ.ㅠ)ㅠ)ㅠ)
7.애플릿에서 한글이 안되네요.
---------------------------------
저 또한 실시간 챠트를 애플릿으로 구현 했는데..
윈 2000 이외에 윈도우에선 한글이 깨지더라구요..
어케 해결 했냐면..
자바 플러그인 설치시 언어를 International로 했습니다..
그 담부터는 잘 나오죠..
근데 한가지 질문이 있거든요..
유료 애플릿 챠트 컴포넌트를 사용하면..
3차원 챠트등도 가능한건지? && 소스도 볼수 있는지?
볼수 있다면.. 소스좀 올려주실 수 있는지 부탁드립니다..^^
좋은 하루 보내세요..^^
첨엔 한글이 ㅁㅁㅁ 이렇게 네모로 나오다가
한글 인코딩을 넣어주니 이번엔 ??? 이렇게 나오는 거 있죠.
웃기게도 다른 애플릿은 정상적으로 보인다는 거죠..
유독 한가지(컴포넌트 - rchart라는 유료 애플릿 차트 컴포넌트)만 한글이 문제가 되거든요.
font.properties라는 파일을 font.properties.ko의 내용으로 바꾸고 저장한 다음 톰캣을 다시 실행한 다음 에도 안되네요..
-----------------한글 인코딩 클래스---------------
public static String ConvertUniToKsc(String str)
{
String rtn = null;
try
{
if (str != null) {
rtn = new String(str.getBytes("8859_1"), "KSC5601");
}
}
catch (java.io.UnsupportedEncodingException e)
{
}
return rtn;
}
8.mysql과 jsp 연동에서 한글문제요...
-----------------------------------------------
resultSet 객체에 담아서 오겠죠.
이 인스턴스를 rs 라 하면
new String(rs.getString(1).getBytes("8859_1"),"KSC5601")
이렇게 받아보실래요?
>mysql과 jsp연동 프로젝트를 하고있는데여;;;
>
>mysql 에서 insert한 데이터를 웹에서 불러오면 깨져서 나옵니다.
>
>테스트를 한 결과.....
>
>웹에서 인코딩해서 mysql에 insert/select한것은 한글로 잘 반영이 되는데요
>
>mysql자체에서 인서트한걸 웹에서 불러오면 깨진다는거까진 알았습니다.
>
9.폼값을 넘기면 받는 페이지에서는 한글이 깨지는데~
-------------------------------------------------------
한글이 깨지는 문제는 보통 db에저장하고 꺼내서 화면에 뿌려질때 생기는 일이 많습니다만(db의 한글 인코딩과 다를때) 님의 경우에는 보내는 페이지에 문제가 있을것으로 생각 됩니다. 보통 <form>을 통한 value값의 전송은 get 또는 post방식으로 한글에 전혀 지장을 주지 않지만 직접 전송방식 예로,
받는 페이지를 receive.jsp라 했을경우
보내는 페이지에서 <a href="receive.jsp?name=홍길동">
이와 같은 식으로 전송했을경우는 한들의 인코딩 양식에 문제가 있어 인코딩을 변환 해주어야 정상적으로 한글이 깨지지 않고 보여지게 됩니다.
음..우선은 보내는 페이지의 코딩에 <form>태그를 사용하지않고 위와 같은 식으로 전송하는코드가 있는지 살펴보시기 바랍니다.
>한글 문제인데여~
>입력값을 넘기면 받는 페이지에서 다른 한글은 깨지지가 않는데 Parameter로 넘어온 값만 깨지는 겁니다.
>해결 방안이 없나요?
>
>고수님들의 많은 조언 부탁 드리겠습니다.
>
>받는 페이지 소스는...연습코드라...
><%@ page contentType="text/html;charset=euc-kr" %>
><html>
><body>
> JSP를 이용한 Form 처리<BR>
> <li>이름 :
> <%
> String name = request.getParameter("name");
> if(name != null && name.length() !=0){
> out.println(name);
> }else{
> out.println("이름이 없네요~");
> }
> %>
> <li>주소 :
> <%
> String addr = request.getParameter("addr").trim();
> if(addr != null && addr.length() !=0){
> out.println(addr);
> }else{
> out.println("집이 없어요?");
> }
> %>
></body>
10.다운로드시 첨 한글이 깨짐...ㅜㅜ
---------------------------------------
저같은 경우는 엑셀로 저장하는거였거든요...
weblogic을 웹서버로 사용하였었구요...
파라미터 설정이 뭐가 바뀌었는지는 기억이 안나지만
그런데 처음에는 님처럼
response.setContentType("application/x-msdownload");
new String(filename.getBytes("euc-kr"),"8859_1");
이렇게 해도 되었구요
나중에 보니까
다시 안되더라구요...
그래서 아래와 같이 타입을 바꿔주니까 되더군요...
<%@ page contentType="text/vnd.ms-excel";%>
그 이후로는 이렇게 사용하고 있네요...
>new String(filename.getBytes("euc-kr"),"8859_1");
>요 부분이 잘못된거 아네요..?
>반대로 적어주시던가..
>("8859_1"), "ksc5601"이렇게요..(원래 이거 아닌가요..?) ^^
>그래두 이렇게 해서두 깨지는 경우가 있던데.. ㅠ.ㅠ
>
>이런경우에는 어케 해야돼요..? ㅠ.ㅠ 정말 난감..
>그래서 제가 이렇게저렇게 하다 나온결론은..
>new String(filename.getBytes("ksc5601"),"ksc5601");
>이렇게 하니깐.. 신기하게 안깨지데요.. 이게 맞는건가..?
>암튼 한글은 안깨지니 전 걍.. 이렇게 놓구 쓰네요..
>><%@ page contentType="application;" %><%@ page import="java.util.*,java.io.*,java.sql.*,java.text.*"%><%@ include file="/korean/pub/file_dir.jsp" %><%
>> String filename = java.net.URLDecoder.decode(request.getParameter("file"));
>> String filename2 = new String(filename.getBytes("euc-kr"),"8859_1");
>> File file = new File(dir_seminer+filename); // 절대경로입니다.
>> byte b[] = new byte[(int)file.length()];
>> response.setHeader("Content-Disposition", "attachment;filename=" + filename2 + ";");
>> if (file.isFile())
>> {
>> BufferedInputStream fin = new BufferedInputStream(new FileInputStream(file));
>> BufferedOutputStream outs = new BufferedOutputStream(response.getOutputStream());
>> int read = 0;
>> while ((read = fin.read(b)) != -1){
>> outs.write(b,0,read);
>> }
>> outs.close();
>> fin.close();
>> }
>>%>
>>
11.[질문]jsp와 오라클에서의 한글처리
---------------------------------------
쿼리문 자체를 찍어보세요.
맞게 한글로 들어가는지.
그리고 나서 데이터베이스에 직접접속을해서
select 해 보세요.
정말로 잘 되는지.
그러구 난다음에 데이터를 가지고 와보세요
과연 어디에 문제가 있는지 찾아야 답이 나오겠지요
각각의 원인에 따라서 처방법도 틀려진답니다.
>name = new String(request.getParameter("name").getBytes("8859_1"),"euc-kr");
>
>이렇게 넘긴 값을 오라클에 저장을했는데요
>
>오라클에서 값을 가져올때..계속 ???? 로 나오네요
>
>java.net.URLEncoder.encode(address_2);
>
>이렇게 해서 출력을 해보기도 했는데 여전히 ???
>
>로 나와요
>
>어떻게 가지고와야 한글이 그대로 나오죠??
오라클에서 값을 select해올때 ???로 나오는것은 과다 인코딩 문제입니다.
그러니 값을 넣을때 인코딩을 하지말고 넣어보시기 바랍니다.
그리구 테스트해보시면 좋을듯 싶네요.. 제경험입니다.
12.리눅스에서 한글 이름으로 된 파일 ㅠ.ㅠ
-------------------------------------------------
upload 할때 사용자가 upload 한 파일과 시스템에서 만든 파일 이름을
디비에 저장 합니다.
그럼 한글 깨질 염려는 없구여. 다운 받을때도 사용자 이름을 넣어
주면 큰 무리 없이 다운 받을수 있습니다.
물론 file 객체를 사용해서 쓸려면 시스템에서 만든 이름을 쓰면 되겠지여
답변이 되었나여 !!! 도움이 되었으면 합니다.
수고 하세요
>리눅스에서 한글 파일을 전혀 인식하지 못하네요.
>
>o/s 상의 문제라는 사람도 있고...
>
>File file=new File("한글파일.txt");
>
>이렇게 했을때 file에 정확히 File 객체가 인식되도록 하는 방법이 없을까요?
>
>파일 삭제, 다운로드가 안되는 등 문제가 상당히 심각하네요.
13.sqlserver 2000 insert시 한글 유실? 문제
-------------------------------------------------
DB에 데이터를 넣을때는 아래의 메소드를 이용해서 넣어주시고여..
new String(str.getBytes("KSC5601"),"8859_1")
반대로 꺼내 올때는
new String(str.getBytes("8859_1"),"KSC5601")를 통해서 꺼내와 보세여..
저도 예전에 SQLServer에 한글이 제대로 입출력이 되지 않아서 썻던 방식입니다..
도움이 되셨길..
>SQL2000 에 메세지 입력시 한글이 유실됩니다.-.-;;
>
>코드는 아래와 같습니다.
>메세지에 'DB 넣기' 이렇게 할 경우 DB에는 'DB' 이렇게만 들어가고요..
>메세지에 '한글 DB' 이렇게 입력하면 실제적으로 '\' 이 문자가 들어가네요-_-;;;
>왜그럴까요?.... 답변좀 부탁 드립니다....
>
>// DB Insert
>public int dbInsert(String messageid, String from_number, String to_number, String messages, String ins_time){
>String sql ;
>System.out.println("in insert function");
>System.out.println(messages);
>
>try {
>conn = getConnection();
>pstmt = conn.prepareStatement("insert into smslist ( messageid, from_number, to_number, messages, ins_time, result) values(?,?,?,?,?,?)");
>pstmt.setString(1, messageid);
>pstmt.setString(2, from_number);
>pstmt.setString(3, to_number);
>pstmt.setString(4, messages);
>pstmt.setString(5, ins_time);
>pstmt.setString(6,"0000");
>
>pstmt.executeUpdate();
>
>
>} catch (Exception e) {
>System.out.println(e);
>e.printStackTrace();
>return 0;
>} finally{
>closeAll();
>}
>return 1;
>}
>
14.JSP에서 My SQL로 한글 자료를 입력할 때..
---------------------------------------------------
get 방식을 post로 바꾸어서 입력을 하시는 것이 좋습니다.
만약에 post 방식으로 한글을 넘긴다면
DB에 데이터를 넣을때는 아래의 메소드를 이용해서 넣어주시고여..
new String(str.getBytes("KSC5601"),"8859_1")
반대로 꺼내 올때는
new String(str.getBytes("8859_1"),"KSC5601")를 통해서 꺼내와 보세여..
>jsp에서 mysql로 한글 자료를 입력할 때 한글코드가 맞지 않아서 그런지 한글이 제대로 입력되지 않습니다. 이상한 글자가....
>어떻게 해야 하나요?
15.xml에서 추출한 한글값이 깨집니다.
-------------------------------------------
<?xml version="1.0" encoding="euc-kr"?>
삽입해서 문제 해결
>xml에서 추출한 한글값이 깨집니다.
>깨진 한글을 복원시킬려면 어떻게 해야하는지요.
16.WebLogic은 왜 기본적으로 JSP를 사용치 않도록 했을 까요...
------------------------------------------------------------
아래 부분 처럼 주석 처리되어 있는 부분을 풀어야 합니다.
또 한글지원을 위해 추가적인 Parameter를 넣어야 합니다.
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# WEBLOGIC JSP PROPERTIES
# ------------------------------------------------
# Sets up automatic page compilation for JSP. Adjust init args for
# directory locations and uncomment to use.
weblogic.httpd.register.*.jsp=\
weblogic.servlet.JSPServlet
weblogic.httpd.initArgs.*.jsp=\
pageCheckSeconds=1,\
compileCommand=e:/jdk1.1.7b/bin/javac.exe,\
workingDir=/weblogic/myserver/classfiles,\
encoding=euc-kr,\
verbose=true
출처 : http://ndba.egloos.com/2831611