출처: http://www.javaservice.net/

 

제목 : [Comment] 다국어 인코딩 문제의 위치 및 까발리기
  글쓴이: EB(goEB)   2002/12/02 12:42:10  조회수:2182  줄수:289
======== 2002.12.03 23:12 공지 ========
이 글의 KSC5601-1992는 잘 못되었으므로 걸러서 읽어주시기 바랍니다.
이 글과 관련된 "2부"에서 설명합니다.
=======================================



제목 : [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는 깨지거나
 하는 문제 발생. (혹은 그 반대)
 ※주의! <%@ page contentType="text/html;charset=xxx"%> 와는 별개이므로 소용 없습니다.
나. *.java를 컴파일 한뒤 다국어 사용시 깨어져 나온다. --;;
 (static이나 비교문등에 미리 입력해 놓은 다국어...)
 물론 Runtime시 복구할 수 있는 경우도 겠지만 그렇게 하는 사람 있다면 따돌림 당한다는.... --;;

해결법 :
가. 소스파일을 만들어 저장할 시에 자신이 작성한 소스의 문자셋을 확인한뒤
 그 와 동일하게 저장하도록 하고, 프로젝트에 관련된 모든 파일을 동일한 문자셋으로 작업해야 한다는...
 <%@ page contentType="text/html;charset=xxx"%>의 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에서 <%@ page contentType="text/html;charset=xxx"%>와
META TAG의 contentType="text/html;charset=xxx"

이둘을 사실상 모두 사용하는 경우는 웃지 못할 일입니다.
(실로 대단한 이슈입니다.)

이곳 게시물중
----------------------------------------------------------------------------------
==게시물 1========================================================================
euc-kr 이나 ksc5601 을 사용할 경우 브라우저의 한글은 잘 나온다.

대신 확장한글을 표시할 수 없어서 샾 , 햏 , 잌 같은 글자는 ? 로 깨어져 나온다.

소스보기를 해도 완전히 깨진다.
...
...
중략
...
서버쪽 한글처리는 MS949 로 정하고, 브라우저의 한글처리는 ksc5601, euc-kr 등으로
한다. 즉 서버쪽은 @page 의 contentType 속성을 charset=MS949 로 <head> 태그 내의
<meta> 태그에서 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 : &#65536) 그럼 EUC-KR이나 KSC5601로 DB용량 아끼려다
필드깨지고 필드길이 제한 없으면 오히려 Unicode혹은 UTF-8보다 용량만 증가하고 --;;

넷째. 간혹 게시물등 내용을 보면 &# + Unicode값이 그 대로 보이는 경우가 있습니다.
이유는 제가 일전에 올린 게시물 내용에도 언급했듯 & 을 &amp;로 변형하였기 때문입니다.
즉, &amp;를 &로 원래대로 놓으면 첨에 입력했을 당시의 문자가 보이는 것입니다.

다섯째. 어쩌면 MS외의 OS환경은 그 문자를 표현할 방법은 특수처리를 하지 않는 이상
현재로써는 없을 수도 있습니다. (제가 Linux, Unix에선 안해본지라 --;;)

참고.
'葶' <- 이 문자는 Unicode와 UTF-8문자셋이 아니면 깨집니다.
WebBrowser에서 보는 데는 지장 없습니다. 지금도 보이시죠?
이 '葶'는 서버에 전달 될 때 &#33910; 이렇게 변형되어 전달 됩니다.
(지금 이 게시판에서 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에서 <%@ page contentType="text/html;charset=XXX"%> 라고하면 아시겠지만
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가 예전에 비해 실행속도 무지 빨라졌네요!)
제목 : Re: encoding 관련 url
  글쓴이: 허광남(heogn)   2002/12/04 01:42:33  조회수:478  줄수:36
게시물1 의 저자입니다. 
EB 님의 명성은 익히 보아온 바라 제 글을 토대로 연구결과를 공유해주셔서 감사드립니다.
(사실 좀 뜨끔했습니다. ^^;)
MS949 는 CP949 와 같다는 것
iana 에는 빠져있는 문자셋이며 윈도우즈와 java 진영에서 공유하는 OS 기반의 문자셋
라는 것
제가 이해하고 있는 것이었고, EB님의 글처럼 한글의 한계상황을 넘어가는데는 UTF-8 
문자셋을 해야된다는 것에 공감합니다.

Hangul and Internet in Korea FAQ 신정식님 8번글 참고
http://jshin.net/faq/index.html

iana 에 등록된 문자셋에 관한 링크
http://www.iana.org/assignments/character-sets

cp949 의 unicode mapping table
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP949.TXT

Extended Encoding Set (contained in i18n.jar)
http://www.mobilejava.co.kr/bbs/temp/lecture/personal/encoding.html

윤경구님과 김필호님의 Cp949 에 관한 글
http://java.freehosting.co.kr/java/messages/1297.html

사실 아직 정리가 완전히 안된 상태입니다.
EB님의 글을 저 또한 참고하고 두가지 인코딩을 표시해야되는 우스꽝스런 jsp 
코딩스타일을 빨리 벗어나야겠습니다.(^^; 언제가 될지는 저도... )

행복하세요.
---------------------------------
jakarta-seoul project 
jakarta 문서 한글화 사이트
http://www.apache-korea.org

---------------------------------
http://okjsp.pe.kr
제목 : [Comment] 다국어 인코딩 문제 2부 - 2002.12.04 13:20
  글쓴이: EB(goEB)   2002/12/04 12:28:11  조회수:1132  줄수:269
제목 : [Comment] 다국어 인코딩 문제 까발리기 2부

먼저, 첫글을 작성시 짧은 시간에 많은 것을 하려다 보니 본의아니게 큰 실 수를 저질렀다는 것
사과드립니다. (이런 실수는 해서는 안돼는데... 쩝)

대신 이 글에서 만회합니다. ^^;;

뿌리가 흔들리는 부분입니다. (쿠..쿨럭)
KSC5601-1992 는 KSC5601-1987 과 혼환 안된다고 보셔두 무방합니다. --;;
제가 가지고 있는 자료를 제가 잘 못 본 탓입니다... (변명이란 이런것 --;;)
완성형과 조합형의 차이는 아실겁니다.
KSC5601-1987는 KS완성형이라고도 합니다. KSC5601-1992 는 표준(상용이 아님) 조합형입니다.

헉헉 --;;

제가 저 부분 하나를 잘 못 읽었습니다;;;
그러한 이유로 뿌리가 안 흔들릴 수 없습니다.


KSC5601 = ks_c_5601-1987 = MS949 입니다.


KSC5601-1987는 확장이 아니라 제가 말씀드렸습니다. - 잌 등의 문자.

그럼 확장을 포함하는 것은 무엇일까요?
(기존엔 저의 글에서 KSC5601-1992라는 짜가가 이를 대신 했었습니다만... --;;)



제가 MS949 = KSC5601 = KSC5601 + 확장한글 이라고(확장이 KSC5601의 배열과 100% 호환) 하였는데 그렇다면?
(KSC5601 = KSC5061 + 확장한글이라는 정보는 예전 1998.11년 에도 마이크로 소프트웨어 잡지에 실렸음.
이 내용을 틀렸을 것이라 생각하지 않음. 이유는 테스트과정에서 밝혀낼 것. - 첨부자료참고)

바로 MS949 이였습니다.

제가 첨 게시물을 올리기 전에 어떤 아이러니한 점이 있었는데 그게 JAVA의 버그인줄만 알았으나
KSC5601-1992와 MS949가 별개라른 점을 알자 드디어 원인을 알게 되었습니다.
(또한 그당시 KSC5601-1992 도 문제가 있다고 봤습니다. -_ㅜ)

먼저 MS949으로 JAVA소스에 확장을 포함하여 작성하고 JAVAC -ENCODING옵션을 KSC5601로 하면
소스작성시 넣은 확장 한글이 깨지지 않습니다.

하지만 MS949의 확장한글을 Runtime환경에서 KSC5601로 하면 확장한글이 깨집니다.
(KSC5601로 변환할 때 변환기에서 확장한글영역은 ?로 바꾼다는 얘기)

즉, KSC5601 <> MS949는 호환이 되지만 안돼는 것입니다.

풀어서 말하면 MS949를 KSC5601으로 변경시에 MS949디코더기는 정확히 풀었으나 KSC5601엔코더기는
KSC5601표준정의에 의하여 MS949의 확장영역을 처리할 필요가 없어도 KSC5601의
디코더/엔코더가 정상 인증이 된다는 것입니다.
그러므로 표준정의에 의한 KSC5601밖의 DBCS영역은 ?로 처리해도 문제가 없는 것이 되겠습니다.
(KSC5601이 MS949의 확장영역을 ?로 변경하지 않으면 완존 MS949 De/Endcoder 라는 것입니다. -_-;;
이러한 경우가 실무에 존재하는데 그 예는 모르는 사람이 없을 정도로 유명한
JSP에서의 @Page와 HTML의 META에 각기 다르게 적용하는 경우와 제가 위에서 방금말한
JAVA소스는 MS949로 JAVA -ENCODING 은 KSC5601로 주었을 경우가 되겠습니다.
- 이곳에서 MS949가 확장을 포함하는 장본인이라는게 또 다시 증명되네요 --;;)

※ 참고. 확장완성형은 MS 독단으로 만든것입니다. - MS에게만 표준 = 국민의 표준 -_-;;


정리하자면 그리하여 JAVA에서 KSC5601외에 MS949를 따로 보유하고 있는 것이 되겠습니다.





많은 분들이 MS949 = CP949로 알고 있습니다. 여기서 CP는 CodePage를 말합니다.

하지만... 과연 그럴까요? 한번 까발려 보도록 하겠습니다.

---------------------------
첨부 소스 설명...

-첨부파일의 Class는 ISO8859-1 로 Encoding하여 컴파일 하였음.-

어떤한 OS이건 어떤한 형태로 Compile하건 특성을 없애기 위하여
한글은 Bytes(Source 변수에 해당)로 입력하였습니다.

그러므로 100% JAVA의 Runtime환경의 특성만을 탑니다.

입력된 한글의 내용은
가잌덁
이렇게 MS949를 기반으로한 Byte값 3글자입니다.

테스팅시 주의 사항은 문자를 출력할 때 OS에 따라 한글의 표현이 안될터이니
반드시 Byte[] 값을 확인해 보시기 바랍니다. Byte[] 값이야 말로 어떠한 상황이든
JAVA에서 처리한 처리 결과를 정확히 확인할 수 있기 때문입니다.


아래, 제가 테스팅한 결과를 올려보겠습니다. (JDK v1.3.1

============================================================
System.getProperty      : MS949

Source Output...
Source                  : -80, -95, -97, -27, -120, -28

String Output...
strMS949                : 가잌덁
strCP949                :
strCP949fix             : 가쌧
strKSC5601              : 가??
strKSC56011992          : 쌰?걳
strEUCKR                : 가??

Byte[] Output...
byteMS949               : -80, -95, -97, -27, -120, -28
byteCP949               :
byteCP949fix            : -80, -95, -101, 81
byteKSC5601             : -80, -95, 63, 63
byteKSC56011992         : -101, 88, 63, -127, -102
byteEUCKR               : -80, -95, 63, 63
============================================================

위의 값을 보시면 여지껏 제가 말씀드렸던 것들이 무엇인지 결과를 보고난뒤니 감이 잘 올 것입니다.

※ 보는 방법
- Source 변수 : 원본 데이터 이며 OS의 (Encoding문제) 특성을 없애기 위하여
 Byte[]로 구성되었다.
- strXXX 변수 : Source를 기준으로 각 문자셋으로 변환하여 화면에 출력해본다.
- byteXXX 변수 : strXXX로는 OS에 따라 보이는 문자가 있고 없고 하므로 정확성을 위하여
 strXXX를 Byte[] 로 변환하여 출력한 결과이다.
 이 값이 만약 저의 결과와 다르다면 제 시스템 혹은 결과가 다른 시스템 혹은 둘다 이상있는 겁니다. -_-;;
 (OS가 아닌 JAVA만 이상있다.)
- CP949와 CP949fix의 차이점은 CP949는 Source의 3글자를 표현하도록 했던 것이고
 CP949fix는 2글자까지만 표현하도록 했던 것의 차이입니다.
 이유는 제 시스템에선 3글자를 전혀 출력하지 못했기 때문입니다.
 (Byte[]가 안나왔으므로 엔코딩/디코딩 자체 문제.)
- Byte에서의 숫자 '63' 은 문자 '?'에 해당하는 것으로써 OS의 폰트문제로 글씨가 깨지는 것이 아닌
 엔코딩/디코딩 자체에서 처리할 수 없다는 뜻입니다.

※ 위의 Byte 코드에서 63이라고 나온 곳이 제일 중요한 곳이 되겠습니다.
63은 압축으로 비유하자면 손실 압축기법입니다.
무슨 뜻인고 하니 63이 아닌 다른 값들로 변환되었다면 실제 그 문자셋을 표현해주는 시스템
(위에서 저는 MS949였기 때문에 MS949만 모두 정상처리 된 것 입니다.)
에서는 글씨가 정상으로 출력된다는 얘기입니다.
(또한, 원래 문자셋으로 복원해도 정상으로 된다는 얘깁니다.)
위의 "byteKSC56011992" 결과를 본다면 그 시스템에서(표준 조합형)는 "기?덁"으로 보이는 것입니다.
그러니 문자셋 상호변환시 63으로 되는 곳이 있다면 그들간 변환은 절대 금물~!

위의 결과를 보시면 아시겠지만 JAVA에서는 MS949와 CP949는 100% 호환되지 못합니다.

그러므로 많은 분들이 알고계신 MS949 = CP949는 JAVA에선 딴 얘기로 통합니다. --;;





정리하면

가. 여전히 JAVA에서 EUC-KR(KS_C_5861-1992)은 사용하지 말아야할 존재 입니다.
- 메일 때문에 사용해야한 다면 차라리 KSC5601-1987과 ISO-2022-KR을 이용하여 처리하십시오.
 오직 MS949때문입니다. - Client가 MS환경이 많으니...
(얄미운 MS지만 UTF-8정의할 때 우리나라가 세계에서 두번째로 많은 코드를 사용할 수 있게 해주었습니다.)

나. Oracle에서 KO16KSC5601를 사용할 때 KSC5601 디코딩/엔코딩이 MS949를 무시 하는지 확인해야 할 것입니다.
 또한, KO16KSC5601이 EUC-KR을 100% 지원해주는가 의문이 들지 않을 수 없습니다.
 적어도 KSC5601에 MS949의 확장문자가 포함되었을 경우에
 EUC-KR로 컨버팅하여보면 특정문자가 깨지기 때문입니다.
 - Oracle에서도 Unicode 있지 않나요? (UTF-8 말고) 그럼 그거 쓰면 될텐데 --;;
   (UTF-8 쓰기 싫은 사람들에겐... 혹은 UTF-8사용하면 안되는 이들에겐 - 이런 경우가 있다;;)

다. Client가 WebBrowser이고 문서의 문자셋이 Unicode, UTF-8이 아닐경우
 WebBrowser가(어쩌면 OS레벨) HTTP header나 HTML의 META에 정의된 문자셋이 지원하지 않는
 문자가 있을 경우 이를 자동으로 &# + Unicode(Int16)로 변경한다는 것에 주의하셔야 하며
 이에 따른 문제는
 1. WebBrowser외의 곳에서는 한글 변환이 어려우며 100% 처리하기 위해서는 Unicode나 UTF-8를 이용하여
    직접제작한 처리기를 통해야만 표현할 수 있다.
 2. &# + Unicode로 입력된 내용을 검색시 부작용이 많이 있다.
    (이곳두 제가 '덁' 이라고 입력한거 검색 안됨... 제가 이곳 소스를 보진 않았지만
    모두 EUC-KR루 처리했으니 서버에 항상 &# + Unicode로 갔을 것이고 검색어 역시
    그렇게 처리되어 쿼리를 날릴 텐데두 안되는거 보면 이곳 소스한번 보구잡따. --;;
    더욱 재밌는 것은 파일명을 '덁'으루 하면 EUC-KR인 이곳에서 본문은 &# + Unicode로 가지만
    파일명은 제대로 간다. --;; 역쉬 %xx 로 전달되는게 짱이얌 -0-;; %xx 형태 원츄 --b
    - JAVA에서 직접 EUC-KR 스트링의 Byte를 편집할 수 있다면 이것이 쉽게 가능하게 한다.
     문제는 Byte를 편집하였기 때문에 표준에 어긋나는 일이라는거 --;; 그래서 무효 --;;
     또한, 눈에 보이는 '덁'이 실제 '덁'이 아닌 OS가 꺼벙해서 보이는 경우 있다. - 어렵지만 중요한 말)

라. Red Hat Linux 7.1 에서 UTF-8.
 - RedHat Linux v7.1 한글판 OS에서 (WebBrowser는 Navigator v7 한글판) '잌'
   등의 문자는 '이ㅋ' 이렇게 표현되었었다. --;;
   확장문자 입력은 아예 되지도 않는다. --;;
   Linux에서 JAVA코딩시 이들을 주의하자. (또한 실제적으로 정상인데 Font문제로 표시되지
   않을 수 있으므로 Byte값을 확인하자. 특히 Linux에서 "아햏햏"이 출력되지 않는 다고 하신분 -_-+
 - UTF-8관련 자료
    영문
    (인증문제가 걸린다면 상위디렉토리부터 접근해본다. --;;)
    한글

마. MS OS에서 Win NT 2000부터는 파일 시스템의 기본이 UTF-8이지만 Win98은 잘 모르겠다.
 이 것을 언급한 이유는 제가 올린 "UTF-8로 URL 요청할 시 한글 처리 가능케" 바꾸는 게시물에 올린
 *.htc의 소스를 보면 URL이 "file:///"이면 KSC5601(MS949)로 바꾸지 말라는 부분이 있는데 이 때문이다.

바. JAVAC -ENCODING   옵션을 잊지 말자. (이거 아직도 모르고 계시는 분이 있다는 -_-+)
 이 때, -ENCODING은 소스파일과 동일하게 해주어야 한답니다. ^^
 JSP에서는 @PAGE contentType의 charset 셋이 이 역할을 합니다.
 (또한, Application, Session Scope를 지닌 변수에도 적용됨, 그러므로 프로젝트의 모든
  ENCODING타입이 같아야 득이됨.)
 "JAVA -Dfile.encoding=" 이 옵션은 기본으로 통한다. ㅡㅡ;;

사. JSP에서 @PAGE 를 사용할 시 반드시 INCLUDE되는 파일이 아닌 불러들인 파일에 넣어주어야 한다.

아. MS949와 CP949는 다르다. (적어도 JAVA에선 다르다.)

자. JSP에서 MS949를 HTTP header로 보낼 땐 "KS_C_5601-1987" 로 보내게 만들어 달라구 항의 하자;;;
 아니면 우리 프로그래머가 그렇게 되도록 직접 뜯어 고치자;;



결론, 테스트고 모고 귀찮으니 그냥 UTF-8 사용하자 -0-;;



그럼 즐프~~~



p.s 글이 너무 길어 더는 못 쓰겠습니다. --;;
또한 글만 길었지 여러분께 많이 도움이 되는지도 모르겠음. ㅠㅠ (쿠..쿨럭;;)


첫 글에서 KSC5601-1992 를 잘 못 말씀드린것 다시한번 죄송합니다.



이 글에 도움을 주신분.
1. 허광남(heogn)
2. 기타 인터넷 사이트에서 참고자료 제공자...
끝 --;;


============================================================
작성자 : EmotionalBrain
처음 게시된 곳 : www.JavaService.net
============================================================






Update 2002.12.04 13:20

위에서
--------------
먼저 MS949으로 JAVA소스에 확장을 포함하여 작성하고 JAVAC -ENCODING옵션을 KSC5601로 하면
소스작성시 넣은 확장 한글이 깨지지 않습니다.

...
...

JAVA소스는 MS949로 JAVA -ENCODING 은 KSC5601로 주었을 경우가 되겠습니다.
--------------

은 제가 그 당시 만들었던 소스가 없어서 그걸 다시 테스팅 할 수 없지만 "심민우(smwpower)"
님 말씀대로 첨부된 소스로 재 테스팅 해보니 제 테스팅이 잘 못 되었던것 같습니다.

그럼 -encoding을 KSC5601로 하고 String(KSC5601) Byte[]를 편집해서 만들어 놓거나
컴파일된 Class파일에 확장문자를 찾아서 Byte[]를 변경하면 되겠습니다.
- 목적은 KSC5601에 Byte를 수정해서 확장을 넣는 것입니다. -




Update 2002.12.06 19:29
--------------------------

위의 업데이트 사항에서 EUC_KR 상태의 문자를 Byte(CharCode)가 편집된 경우는
3번째 [Comment]에서의 JSP와 DB "EUC_KR"에 관련된 내용에서도 있습니다. ^^;;

Download TTT.java (2331 Bytes) TTT.java (2331 Bytes)
Download TTT.class (2074 Bytes) TTT.class (2074 Bytes)
제목 : Re: mizi linux 에서의 한글
  글쓴이: 허광남(heogn)   2002/12/04 15:05:12  조회수:196  줄수:33
EB 님의 글 잘 읽었습니다. 
재밌는 글이 있어서 퍼옵니다. 
--------------------------------------------------------
1 cp949 또는 uhc(unified hangul code 통합완성형)
1995년 윈도95의 등장과 함께 나타났다.
처음에는 각계각층의 반대에 의해 입력만 막아놨지만 윈도98부터는 자연스럽게 포함이
되면서 일반적으로 쓰이는 글자셋이 되어버렸다.
이전부터 쓰이던 euc-kr이나 완성형에서 쓰이지 못했던 글자들을 마음대로 입/출력 할
수 있게 된것은 환영할 만한 일이나 다른 운영체제나 환경을 전혀 고려하지 않은
것이라 문제의 소지가 컸다.
지금 모질라에서는 euc-kr 글자셋 환경이라도 uhc글자를 읽을 수 있게 바뀌어졌다.
(지금 uhc가 컴퓨터바닥에서 얼마나 큰 영향을 끼치는지 알 수 있는 하나의 예라 할
수 있다)

2 MiziLinux에서 cp949 또는 uhc에 대한 대비
제일 근본적으로 처리할 수 있는 것은 유니코드 글자셋이라 볼 수 있을것이다. See
ko_KR.UTF-8 ( http://linux.mizi.com/wim/ko_5fKR_2eUTF_2d8 )
하지만 우리가 할 일이 너무 많아진다.
glibc의 gconv(iconv)에서도 cp949가 지원이 된다.
전에 농담조로 나온 말이지만 ko_KR.cp949라는 새로운 로케일을 만드는 것도 그럴듯
만한 대안이 될 수 있을것이다.
리눅스환경에서 한글입력기의 표준이다시피 한 아미는 아직 euc-kr밖에 지원을 하지
않는다.
from:
http://linux.mizi.com/wim/_ed_95_9c_ea_b8_80_ed_99_98_ea_b2_bd

---------------------------------
jakarta-seoul project 
jakarta 문서 한글화 사이트
http://www.apache-korea.org

---------------------------------
http://okjsp.pe.kr
제목 : Re: EB(goEB)님에 대한 테스트중 이상한점..
  글쓴이: 심민우(smwpower)   2002/12/05 00:42:16  조회수:197  줄수:60
주신 소스를 가지고 
javac TTT.java 와
javac -encoding ksc5601 TTT.java
로 컴파일 했을 경우 이상이 없었읍니돠..

그런대..
byte[] Source = new byte[] {-80, -95, -97, -27, -120, -28}; 을
byte[] Source = "가잌덁".getBytes(); 로 수정하거나..

strMS949		=	new String(Source,"MS949"); 을
strMS949		=	new String("가잌덁".getBytes(),"MS949"); 로
수정해서 테스트 할땐..

javac TTT.java로 컴파일 하면 출력결과에 이상이 없었읍니돠.

그런대
javac -encoding ksc5601 TTT.java 로 하면
출력결과가 아래와 같읍니돠..

System.getProperty      : MS949

Source Output...
Source                  : -80, -95, 63, 63

String Output...
strMS949                : 가??
strCP949                : 가??
strCP949fix             : 가쌧
strKSC5601              : 가??
strKSC56011992          : 쌰??
strEUCKR                : 가??

Byte[] Output...
byteMS949               : -80, -95, 63, 63
byteCP949               : -80, -95, 63, 63
byteCP949fix            : -80, -95, -101, 81
byteKSC5601             : -80, -95, 63, 63
byteKSC56011992         : -101, 88, 63, 63
byteEUCKR               : -80, -95, 63, 63

또한 
javac -encoding MS949 TTT.java 로 컴파일 하면
이상이 없읍니돠..

설명중 
/******
먼저 MS949으로 JAVA소스에 확장을 포함하여 작성하고 JAVAC -ENCODING옵션을 KSC5601로 하면
소스작성시 넣은 확장 한글이 깨지지 않습니다
********/
이부분이 바뀌지 않았나 싶어서여..
아님 제가 잘못 했나 싶기도 하구여...

참고로 UTF-8은 코드상에서 어떻게 구현 되남여?
혹  strUTF	 = new String(Source, "UTF-8"); 이렇게 하는 게 맞나여?





제목 : Re: Win95와 Win98에서의 문자셋
  글쓴이: EB(goEB)   2002/12/05 03:13:07  조회수:222  줄수:48
"허광남(heogn)" 님께...

제가 아는 정보는 Win95는 MS949가 맞지만(확장통합완성형), Win98은 Unicode 인데요
(KSC5700 표준 한글코드)

그리고 그 때문에 대부분의 글씨가 입력가능한 건데, (아시겠지만 확장통합완성형은
글씨 입력 시스템 제작시 두려움을 안겨줍니다. - 순서 엉망. 그래서 리눅스에서
EUC-KR말고 확장통합완성은 입력기를 만들기 어렵기에 아직 없음)

단지 확장문자는 원시스템인 Unicode에서 MS949(KSC5601)의 확장 영역에 넣어서
표현해줄 수 있는 것이기 때문에 Win98이 MS949인 것 처럼 보일 뿐이지요.

- 여기서 중요한 점은 한글만으로는 Unicode와 MS949의 비교가 안된다는 것입니다.
왜냐면 양쪽모두 한글 "11172"자를 지원하기 때문이죠.
그러므로 한글외의 것으로 비교를 해야 합니다.

MS949는 완전 Unicode안에 포함됩니다. 그래서 제가 Oracle에서 Unicode를
권장하였습니다. Oracle이 Unicode일 때 JAVA에서는 MS949라면 제한 문자가 MS949이기
때문에 사용시 전혀 지장이 없기 때문입니다.

그리고 MS에서 처리하는 방식이 표준에 의거한 것인지 (OS 버젼에 따라.)

또한 JAVA에서의 MS949와 CP949는 현재 차이를 보이는데 그 원인은?

MS측에서도 MS949와 CP949는 다릅니다... ...

CP949는 MS IDE 툴에서는 기본적으로 KS_C_5601-1987로 처리되게 되어 있더군요.
MS949와 CP949를 표준에 정의된 대로인지 문자셋 전체를 까봐야 할 것입니다.
(겉으로 확인할 수 없는 이유는 MS949가 CP949와 다르다 하더라도
CP949가 MS949시스템에서 같은 코드만 같구 있으면 정상인것 처럼 보이기 때문이죠.
그래서 많은 CP949의 디코더, 엔코더를 검증해야하며 관련 자료를 찾아
어떤 것이 진실인지 밝혀야 합니다.)


- 실제 차이가 있다면 Linux등의 시스템에서 MS949도 지원해주었으면 하네요...
그래야 지금 사용할 JAVA에서 MS949가 계속 문제 없이 돌아가죠 --;;


==================================================================================
"심민우(smwpower)" 님께...

o.O?

정말 그러네요? JAVAC 에서 엔코딩을 정상 처리는 군요! 그 당시 제가 테스팅 했던
파일을 지웠는데 (넘 지저분해서) 그럼 그 때 제가 잘 못 했었던것 같습니다.
그럼 String(KSC5601)을 Runtime환경에서 Byte[]를 편집해서 만들어 놓는 방법 밖에 없겠군요.
아니면 KSC5601로 컴파일된 Class파일에 KSC5601문자를 찾아서 Byte[]를 변경하거나요. ^^
시간 나면 이부분 다시 해보도록 하겠습니다.
제목 : Re: [Comment] 이 곳 사이트의 검색이 제대로 이루어 지지 않는 이유
  글쓴이: EB(goEB)   2002/12/07 02:13:20  조회수:1820  줄수:230
---------------------------------------------------------------------------------------------------
저희 나라에서 프로그래머 개인이 알고 있는 지식의 공유가 활발하지 않다고 느끼는 것은 건 저 뿐일까요?

어쩌면 저의 시각이 좁아서 그런 것일 수도 있겠습니다만 -ㅁ-;;
---------------------------------------------------------------------------------------------------



제가 2부의 글에서 말씀 드렸듯 제가 입력한 글이 검색되지 않았었습니다.
그것을 파헤처본 결과를 이 곳에서 다룹니다.

이 글은 여러분에게 Server Page개발/코딩시 주의해야할 점이 무엇이며 가짜 문자를 다룹니다.

이 본문의 주된 내용은 2부의 "결론"
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
나. Oracle에서 KO16KSC5601를 사용할 때 KSC5601 디코딩/엔코딩이 MS949를 무시 하는지 확인해야
 할 것입니다.
 또한, KO16KSC5601이 EUC-KR을 100% 지원해주는가 의문이 들지 않을 수 없습니다.
 적어도 KSC5601에 MS949의 확장문자가 포함되었을 경우에
 EUC-KR로 컨버팅하여보면 특정문자가 깨지기 때문입니다.
 

다. Client가 WebBrowser이고 문서의 문자셋이 Unicode, UTF-8이 아닐경우
 WebBrowser가(어쩌면 OS레벨) HTTP header나 HTML의 META에 정의된 문자셋이 지원하지 않는
 문자가 있을 경우 이를 자동으로 &# + Unicode(Int16)로 변경한다는 것에 주의하셔야 하며
 이에 따른 문제는
 1. WebBrowser외의 곳에서는 한글 변환이 어려우며 100% 처리하기 위해서는 Unicode나 UTF-8를 이용하여
    직접제작한 처리기를 통해야만 표현할 수 있다.
 2. &# + Unicode로 입력된 내용을 검색시 부작용이 많이 있다.
    (이곳두 제가 '덁' 이라고 입력한거 검색 안됨... 제가 이곳 소스를 보진 않았지만
    모두 EUC-KR루 처리했으니 서버에 항상 &# + Unicode로 갔을 것이고 검색어 역시
    그렇게 처리되어 쿼리를 날릴 텐데두 안되는거 보면 이곳 소스한번 보구잡따. --;;
    더욱 재밌는 것은 파일명을 '덁'으루 하면 EUC-KR인 이곳에서 본문은 &# + Unicode로 가지만
    파일명은 제대로 간다. --;; 역쉬 %xx 로 전달되는게 짱이얌 -0-;; %xx 형태 원츄 --b
    - JAVA에서 직접 EUC-KR 스트링의 Byte를 편집할 수 있다면 이것이 쉽게 가능하게 한다.
     문제는 Byte를 편집하였기 때문에 표준에 어긋나는 일이라는거 --;; 그래서 무효 --;;
     또한, 눈에 보이는 '덁'이 실제 '덁'이 아닌 OS가 꺼벙해서 보이는 경우 있다. 
     - 어렵지만 중요한 말)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
에 해당합니다.

이곳의 게시판의 문자셋은 EUC-KR이니 Form과 QueryString의 내용을 전송할 때
서버에 MS949에 포함된 문자(확장통합완성형)는 (eg. 덁, 횽, 햏)
&# + Unicode(Int16)의 형식으로 날라갑니다. (KSC5601은 문자그대로)

그럼 DB에 역시 그렇게 입력됩니다.
- 어떤한 문자셋으로 변경하건 ASCII문자들(7bit)이기 때문에 깨지지 않을 것입니다.


이제 제가 이곳에서 글을 올리는 과정과 검색하는 과정을 설명해보겠습니다.
(기본이라 다 알고 계신다구요? 그래도 보세요.)

1. 본문에 확장문자인 "아햏햏"을 입력하고 글을 작성합니다.
2. "아햏햏"을 검색합니다.
3. 결과를 지켜 봅니다. -_-;;
 결과는 성공적으로 "아햏햏"을 검색하였습니다.

히~ 검색이 정상으로 되어서 기쁘군요. ^^ 아이 저아 ^.~

그렇게 장난좀 치고 심심해서 "덁"을 검색했습니다.
왜... 왠걸? 제가 1부의 글과 2부의 글에 "덁"을 입력했는데 그 게시물은 검색이 안되고
타인이 올린 "덁"은 검색이 되는 것입니다. @.@ 화... 황당 --;;

이런 --;; 제가 작성해서 올린글은 '왕따'를 당한 것이였습니다. 쩌..쩝...
거..검색이 안 이루어지다뉘 --;;

다음날 이 문제를 까발리기루 했습니다.... 하나부터 열까정 많은 테스팅을 했던것...

이들간의 차이를 분석하니 "덁"은 &# + Unicode로 입력되었었고
"햏"'은 EUC-KR이 아닌대두 "햏" 으로 입력되었던 것입니다.

화...황당;;;
아시는 분도 있으시겠지만 EUC-KR에서의 "햏"은 존재하지 않습니다.
즉, "햏"이 보이긴 하지만 실제 EUC-KR에서의 "햏"은 가짜입니다.
그 가짜를 만드는 방법은 제가 2부에서 언급했듯 현재 문자셋 상태에서 문자셋간 변환하지 않고
직접 Byte(혹은 CharCode)를 수정하면 가능케 합니다.

2부의
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"다". 의 내용중
    더욱 재밌는 것은 파일명을 '덁'으루 하면 EUC-KR인 이곳에서 본문은 &# + Unicode로 가지만
    파일명은 제대로 간다. --;; 역쉬 %xx 로 전달되는게 짱이얌 -0-;; %xx 형태 원츄 --b
    - JAVA에서 직접 EUC-KR 스트링의 Byte를 편집할 수 있다면 이것이 쉽게 가능하게 한다.
     문제는 Byte를 편집하였기 때문에 표준에 어긋나는 일이라는거 --;; 그래서 무효 --;;
     또한, 눈에 보이는 '덁'이 실제 '덁'이 아닌 OS가 꺼벙해서 보이는 경우 있다. 
     - 어렵지만 중요한 말)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
내용에 해당합니다.

그럼 이제 원인을 알게 되었습니다. 서버에 전송될 때 EUC-KR형태이지만 어떤 문제로 인하여
&# + Unicode형태로 전달 되지 않는 다는 것!

하지만 여기서 이상한 점이 있습니다. 제가 작성했던 "덁"은 EUC-KR형태라 &# + Unicode형태로
서버로 갔는데 왜 "햏"은 처리되지 않고 가는 것일까? (--?)

그래서 게시물을 또 다시 작성하였는데 본문에 "덁", "햏" 모두 입력했습니다.
근데 역시 &# + Unicode 형태가 처리 되지 않는 것입니다.

이런 말도 안돼는 --;; 아까 "덁"으로 검색됐던 타인의 게시물을 봐도 &# + Unicode 형태가
아니였습니다.

타 사이트에서 EUC-KR로 처리된 것은 어떻게 처리될까아?
그래서 그곳에 가서 테스팅 했더니 "덁", "햏" 모두 &# + Unicode 처리로 되어 정상으로
동작하더란 것입니다.

그럼 이제 남은것은 웹브라워의 버그와, 이곳 사이트의 HTML Source의 이상 문제 였는데...

일단 제가 이곳에 입력했던 "덁" 처리가 "&# + Unicode" 로 처리된 게시물과
"덁"이 짜가 "덁"으로 처리된 게시물의 차이를 (아시겠지만 엄청난 분량임;;;) 확인시작후

10초만에 제가 입력한 글들의 차이를 발견하였습니다. (의외로 빨리 찾음 --v)

그 차이는 바로 1부에서 설명했던
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
참고.
'葶' <- 이 문자는 Unicode와 UTF-8문자셋이 아니면 깨집니다.
WebBrowser에서 보는 데는 지장 없습니다. 지금도 보이시죠?
이 '葶'는 서버에 전달 될 때 &#33910; 이렇게 변형되어 전달 됩니다.
(지금 이 게시판에서 WebBrowser의 소스보기를 해도 알 수 있습니다.)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"葶" 요 문자였습니다.

즉, 본문에 "葶"과 "덁", "햏"등의 확장문자를 포함하면 확장문자는 "&# + Unicode"
로써 정상처리된다는 것이였습니다. (어..엄청 황당;;)
(본문에 "葶"만 딸랑 하나 넣으면 이 것도 정상처리 되지 않습니다.)
그러니 저의 글에 있던 "덁"은 검색되지 않을 수밖에 --;;
본문엔 "&# + Unicode"이렇게 입력되고 검색어는 "%88%E4"(짜가 "덁") 로 전달되었으니...

그렇담 왜 이 곳 사이트에서만 그런일이 발생할 까?

그래서 이곳 사이트의 HTML Source를 분석하니...

이곳, 웹페이지는 HTML의 META TAG에 CharSet을 포함하지 않았습니다.
다만, Server에서 Header에 "Content-Type: text/html; charset=euc-kr" 를 보냅니다.
이 때문에 IE(WebBrowser)는 인코딩을 "한국어(EUC)"라고 인식하게 되는 것입니다만...

이 때, IE에서도 인코딩을 "한국어(EUC)"라고 표시하고,
또 Jscript를 이용하여 현재 보여지는 화면의 인코딩을 확인하여도 "euc-kr"이라고 인식을 하지만

IE의 버그 때문에 정상처리 되지 않았던 것이였습니다.


결론.
***************************************************************************************************
가. META TAG에 반드시 CharSet을 포함해야한다.
    - Unicode, UTF-8형태의 CharSet에서는 있어도 그만 없어도 그만인지는 확인하지 않았음;;;

	EUC-KR환경은 당연포함해야하지만
	
	KSC5601환경의 경우 당연 서버에서 모두 확장문자는 정상처리 하니 문제가 없겠지만
	위에서 언급한 "葶"는 META TAG에도 KSC5601을 포함하여야만 정상처리 되었고
	그렇지 않을 시엔 "匪" 이 문자가 이를 대신하였다. (짜가가 판치는 세상;;)
	그러므로 META TAG는 필수적으로 처리되어야 하며
	또한 META TAG앞에 다른 어떠한 화면에 출력되는 문자는 있어서는 안되었다.
	
	예로써 다음과 같은 환경엔 META TAG가 있으나 마나였다.
	---------------------------------------------------
	먼저 출력해본다.
	<html>
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=EUC-KR">
	...
	---------------------------------------------------
	즉, 위의 환경엔 확장문자도 EUC-KR기준이 아닌 KSC5601(MS949)기준으로 처리된다.

***************************************************************************************************
나. DB의 "KO16KSC5601" 과 JAVA EUC-KR의 궁합.

 2부에선 언급했던 "나"의 내용

『나. Oracle에서 KO16KSC5601를 사용할 때 KSC5601 디코딩/엔코딩이 MS949를 무시 하는지 확인해야
 할 것입니다.
 또한, KO16KSC5601이 EUC-KR을 100% 지원해주는가 의문이 들지 않을 수 없습니다.
 적어도 KSC5601에 MS949의 확장문자가 포함되었을 경우에
 EUC-KR로 컨버팅하여보면 특정문자가 깨지기 때문입니다.』

 은 이곳 JAVAservice.net DB의 환경이 "KO16KSC5601" 이라면 이곳 본문에서 실험해봐서
 알겠지만 EUC-KR의 잘 못 된 내용까지도 DB에 모두 넣을 수 있다는 결론이기 때문에
 MS949를 "KO16KSC5601"에 넣어도 된다는 것이다.(이원형님이 우려하시던 내용)
 
 다만, EUC-KR에서 확장문자는 실질적으로 지원하지 않는 것이기 때문에
 String strNEW = new String(EUCKRsource.getBytes("EUC_KR"), "Some...");
 으로 변형해서는 절대로 그 확장문자는 보존할 수 없음에 주의하고 트릭을 사용하고 싶다면
 비록 현 문자가 EUC_KR (혹은 JSP의 @Page에서 EUC_KR이지만) 이긴해도
 String strNEW = new String(EUCKRsource.getBytes("MS949"), "Some...");
 라고 뻥을 처주는 트릭을 사용하여야만 EUC_KR에 입력된 가짜 확장문자도 복구할 수 있다.
 ※ 주의! 이 트릭은 반드시 IE WebBrowser에서 넘겨받은 값만 100% 오류없이 처리할 수 있습니다.
***************************************************************************************************
다. Navigator는 확장어 처리가 완전 엉뚱하게 된다.
 (다양한 셋팅으로 시도 하였으나, 본좌는 방법이 없다는 결론을 내었다. --)
***************************************************************************************************



테스팅 환경. WinXP, IE6, Navigator 7.0



이글의 모든 내용은 많은 테스팅을 거쳤으며 많은 증거들이 있으니 믿으셔도 됩니다. --;;



이 곳에 언급된 검색의 문제점은 이 내용 파헤치기 전 자체테스팅한 

검색 엔진의 문제 20% 정도에 해당하는 내용이 되네요...

그 테스팅 결과가 어마마해서뤼.. 어떻게 글을 작성해야할 지 --;;



---------------------------------------------------------------------------------------------------
미약한 저의 글 읽어 주셔서 감사드리며, 지식 공유하고 서로 부족한점 매꾸워 줍시다. ^_^

EmotionalBrain...
---------------------------------------------------------------------------------------------------




---------------------------------------------------------------------------------------------------
Update - 2002.12.06 19:42

기존
"가. META TAG에 반드시 CharSet을 포함해야한다. - Unicode, UTF-8은 있어도 그만 없어도 그만;;;"
을
"가. META TAG에 반드시 CharSet을 포함해야한다.
    - Unicode, UTF-8형태의 CharSet에서는 있어도 그만 없어도 그만인지는 확인하지 않았음;;;"
로 변경.
(죄송합니다. 문서를 몇번이고 읽어본뒤 올려야 했었는데)
---------------------------------------------------------------------------------------------------
제목 : Re: 그러면 "나"의 결론 DB부분은 꼭 검증해야...
  글쓴이: EB(goEB)   2002/12/07 21:50:52  조회수:234  줄수:66
전 확장자만 cgi 인줄 알았는데...

실질적으로 JSP 이거......


***************************************************************************************************
나. DB의 "KO16KSC5601" 과 JAVA EUC-KR의 궁합.

 2부에선 언급했던 "나"의 내용

『나. Oracle에서 KO16KSC5601를 사용할 때 KSC5601 디코딩/엔코딩이 MS949를 무시 하는지
 확인해야 할 것입니다.
 또한, KO16KSC5601이 EUC-KR을 100% 지원해주는가 의문이 들지 않을 수 없습니다.
 적어도 KSC5601에 MS949의 확장문자가 포함되었을 경우에
 EUC-KR로 컨버팅하여보면 특정문자가 깨지기 때문입니다.』

 은 이곳 JAVAservice.net DB의 환경이 "KO16KSC5601" 이라면 이곳 본문에서 실험해봐서
 알겠지만 EUC-KR의 잘 못 된 내용까지도 DB에 모두 넣을 수 있다는 결론이기 때문에
 MS949를 "KO16KSC5601"에 넣어도 된다는 것이다.(이원형님이 우려하시던 내용)
***************************************************************************************************

라는 부분이 이곳 DB환경이 "KO16KSC5601" 두 아니구 JSP 두 실제 아니니

이것은 검증해야 되겠네요....

(다른 내용은 모두 Client 부분이니까 이미 검증 되었고...
Socket상으로 전달되는 값도 확인했고...)


단순히 폼값만 받아서 DB에 저장해보면 돼는데...


아햏햏 으로 --;;


환경이 안되니 원...

오라클을 --;;


제가

"이곳 JAVAservice.net DB의 환경이 "KO16KSC5601" 이라면"

이라하였으니 다행히 제가 문법을 정확히 썼네요.... (글들에서 오타두 많은 편이였는데..)


테스팅 환경 돼시는분 부탁드립니다. ㅠㅠ



p.s 전 cgi(CGI 말고), php엔 관심이 없는지라 ... 분석할 의향이 --;;
굳이 분석할 필요도...

META TAG의 CHARSET 넣구 이미 만들어진 파일(DB)의 내용을 전부 바꾸시면 되니깐... ^^
(문자셋을 뭐로 하건간에 변경해야 함)

EUC-KR로 했지만 KSC5601을 흡수 하는걸 봐서 KSC5601로 해도 돼겠습니다.
다만 Unicode, UTF-8을 cgi에서 처리할 수 있는지는... 안해봐서..


p.s 2 여러분 META TAG 꼭 쓰세요.... --;; 안그럼 먼 훗날 후회해요 --;;
기회가 된다면 검색엔진에서 META TAG의 문자셋의 중요성을 (반다시!!)
언급할 까 합니다만.... 언제가 될지..

세상 이렇게 바쁘게 살아서야 원.. --;;
제목 : Re: 메타태그
  글쓴이: 서민구(4baf)   2002/12/08 06:09:42  조회수:244  줄수:46
캐릭터셋에 대해서 너무나 모른상태라서 이해가 안가는 것 몇가지를
질문드리겠습니다.

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=EUC-KR">

는 있으나 마나라고 하셨는데

그렇다면, 

<meta http-equiv="Content-Type" content="text/html; charset=EUC-KR">
<html>
<head>

이런 방식으로 해야한다는 말씀이신가요?

두번째로 

이곳, 웹페이지는 HTML의 META TAG에 CharSet을 포함하지 않았습니다.
다만, Server에서 Header에 "Content-Type: text/html; charset=euc-kr" 를 보냅니다.
이 때문에 IE(WebBrowser)는 인코딩을 "한국어(EUC)"라고 인식하게 되는 것입니다만...

라고 말씀하셨는데,

이 얘기는 jsp의 @page태그에서 contentType을 지정해야하고 동시에
meta 태그를 지정해야한다는 말씀으로 이해하면 될런지요...

세번째로 utf-8을 쓰라고 하셨는데 정작 리눅스에서 LANG을 utf-8로
지정할 수 있는건가요? 자바에서 컴파일 및 실행을 utf-8로 하면 되기야
하겠지만 리눅스에서 텔넷으로 들어가서 utf-8인코딩으로 문자를 입력하려면
어떤 환경을 써야하나요? 울트라 에디트로 편집하고 ftp로 올리는건
힘든것 같은데요..

마지막으로
전체적으로 내용을 정리했으면 하는데...

제가 했으면 좋겠지만 , 제가 요즘 시간이 안나서 저는 여력이 없군요... 
이달말이 되야 시간이 나는 관계로 이렇게 직접 해보지도 않고 질문을
드립니다.. 죄송하네요.

-----------------------------------------------
서민구 (NO---SPAM4baf@orgio.net)
제게 메일을 보내시려면 이메일 주소의 'NO---SPAM'을
제거하시고 메일을 보내주세요.
제목 : Re: 서민구님께~
  글쓴이: EB(goEB)   2002/12/08 12:09:14  조회수:239  줄수:174
제가 말씀 드린 것은
*--------------------------------------------------------------------------------------------------
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=EUC-KR">
--------------------------------------------------------------------------------------------------*
이 아니구요.

위에서 말씀 드렸듯
*--------------------------------------------------------------------------------------------------
먼저 출력해본다.
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=EUC-KR">
...
--------------------------------------------------------------------------------------------------*
요겁니다.
위에 EUC-KR 앞에 출력된 문자 보이시죠? "먼저 출력해본다." 라는 글귀
그걸 가르킨 겁니다.

다시 한번 말씀드리자면 CharSet 정의 앞에 어떠한 것도 화면에 출력되어서는 안된다는 것입니다.

즉,
*--------------------------------------------------------------------------------------------------
<input type=button>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=EUC-KR">
...
--------------------------------------------------------------------------------------------------*
은 정상처리 되지 않으며

*--------------------------------------------------------------------------------------------------
<input type=hidden>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=EUC-KR">
...
--------------------------------------------------------------------------------------------------*
은 정상처리 된다는 것이죠.

간혹 CharSet 앞에 먼저 출력하시는 분이 있어서 설명드린 거구요.

왜 CGI들을 디버깅 할 때도 그런경우가 있짜나요.. 괜히 입력받은값 확인 한답시구.
*--------------------------------------------------------------------------------------------------
<%폼이나 쿼리스트링값 디버깅을 위해 출력하기%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=EUC-KR">
...
--------------------------------------------------------------------------------------------------*
라는 형식 말입니다.

이런 경우를 조심하잔 것이죠.

그러므로 CharSet을 설정하기전엔 어떠한 것도 화면에 출력해서는 안됩니다.
(Client측의 버그 때문에 --;;)




그리고 JSP의(엄밀히 이런류의 CGI 모두해당. eg. ASP, ASP.NET)
@page에도 넣어야 하는게 맞습니다.

그래야 소스를 제대로 읽을 수 있습니다. (javac -encoding과 같은 맥락입니다.)


*--------------------------------------------------------------------------------------------------
세번째로 utf-8을 쓰라고 하셨는데 정작 리눅스에서 LANG을 utf-8로
지정할 수 있는건가요? 자바에서 컴파일 및 실행을 utf-8로 하면 되기야
하겠지만 리눅스에서 텔넷으로 들어가서 utf-8인코딩으로 문자를 입력하려면
어떤 환경을 써야하나요? 울트라 에디트로 편집하고 ftp로 올리는건
힘든것 같은데요..
--------------------------------------------------------------------------------------------------*
라는 질문에 대한 답변은 불행히도...

UTF-8관련부분은 한글환경에선 리눅스에서는 어떠한 것도 해당하지 못합니다.

제가 아는 바로는 리눅스에서 UTF-8한글 입력도 안되고...
그렇다고 EUC-KR이나 KSC5601이나 MS949등등을 UTF-8로 변경해주는 툴도 없으니까요..
UTF-8로된 한글을 출력해주는 환경은 몇가지 제공된다지만 전혀 쓸모 없는 기능이라는;;;
(입력두 안되는데 어케 코딩을 해요 --;; 글타구 변환기두 없꽁)


그러니 JAVA를 이용해서 제작하심이 ^^;;
 - 그냥 간단히 InputStream과 OutputStream으로만으로도 할 수 있떠여

그리구 제가 언급한
*--------------------------------------------------------------------------------------------------
일반적으로 프로젝트의 모든 소스는 엔코딩 형식이 동일해야 하겠죠?
만일 기존 소스가 있는데 다르다면 현 프로젝트와 맞추어야 할 텐데...
쉽게 구할 수 있는 툴은 UltraEdit가 정도가 되겠네요 저는 v9.10을 가지고 있고
File -> Conversions에 있습니다. 이 곳에서 원하는 형태로 가능하겠습니다.

-단, 한글들의 문자셋변환 툴은 아직 보질 못했음. 혹시 보신분 손 ^^/
 한글에서 하위변환은 완벽히 안되므로 이를 염두해야함.
--------------------------------------------------------------------------------------------------*
라고 했듯

한글 변환은 제대로 처리되지 않더라구요.
(특히 왜 자꾸 UTF-8과는 어쩌다가 되는지 ㅠㅠ)

좋은 플그램 구하는 것보다 JAVA로 자작하는 것이 더 빠를 겁니다.
(그냥 작성한 내용 자동으로 UTF-8로 변환해주는 거)

-JBuilder로 작업하신다면 좋은 결과가 있을 수도 있겠네요
 * 참고. JBuilder의 프로젝트 옵션에 있습니다.




그리구 저...정리 라구요? --?

여기에 올린 내용은 문자셋 문제의 40% 정도 밖엔 해당 되지 않는데요 --;;
(많은 시간을 소비하였지만 애석하게도 아직 이것 밖엔 정리되지 않았기 때문에
완전한 모습이 나오기 전엔 현재 정리가 어렵습니다.)


제가 UTF-8 형식을 추구하는 진정한 이유와, 목적은 여지껏 설명했던 부분 속에 있어요!
겉에 드러나 있는 단순한 문제가 아니구요.

(현실적으로 가능만 하다면야 UTF-8이상의 것을 써야 하지만)

제가 첨부터 자세한 설명과 이곳 사이트의 검색 문제를 올린 이유는 왜 UTF-8이여야만 하는지를
내면적으로 나타내려 했기에 그런건데~
(내면을 직설적으로 표현 해봐야 그냥 결론만 날 뿐이겠네요
항상 그렇듯 그냥 그렇게 하라구 알려주고 이유는 설명않고 --;;)


굳이 표면적으로 말하자면
검색을 한다고 했을 때

"내가 입력한 검색어가 과연 검색어 일까?" <= 무지 어렵지만 상당히 의미있는말...

수수께끼라여기시는 분들은 문자셋 이해를 아직 못하신 것일 테고
아시는 분들이라면 이것은 상당한 의미를 지닌말로 해석하시겠네요.


요 수수께끼를 정확히 이해하셨다면 전세계에 있는 웹 검색엔진은 (Yahxx, Emxx, Hanxxx, 등등)
새롭게 만들어져야 한다는 걸 아실 겁니다. ^^
(최소한 수정은 불가피 합니다.
특히 몇몇 서버는 DB내용 자체를 바꿔야 한다는... 쩌비... <- 증거 있습니다. --;;
Yahxx도 DB를 바꿔야 --;;)

하지만 딱 한군데는 꼭(UTF-8초과 필요시만 아니라면. 현재 필요한 곳이 있던가요? 어느나라였더라?)
그럴 염려는 없겠더군요 ^^ 어딜까요? ^.~
(역시 그 곳은 세계 최고라 하여도 손색이 없습니다. 유명한.. GxxGxx)

흥미롭지 않나요? ㅡㅡ;;


저 역시 언능 정리는 하고 싶지만
전 아마 1개월 이후에나 가능할 것 같습니다.
지금 하는 작업이 저에게 중요하기 때문에

이 문제 저를 흥분시키지만 여지껏 테스팅한거 대충 메모만 한뒤 잠시 접으렵니다.


p.s
현재의 검색엔진에는 EUC-KR이나 KSC5601이 더 났지만 어디까지나 아주짧은 미래까지만
해당합니다.


p.s 2
나머지 60%를 언제 쯤 정리 하게 될런지.. ㅠㅠ


p.s 3
제가 테스팅 환경이 되지 않는 부분은 서로 해주었으면 합니다.
그래야 추후 정리할 때 깔끔히 할 수 있지 않겠어요?
어떤 사람이 정리할 진 모르지만


즐프 하십시오. ^^

Posted by '김용환'

댓글을 달아 주세요