iWiz ShareBase

IT Specialist 윤태현의 iWiz ShareBase는 IT뿐 아니라 각종 잡다한 지식들을 함께 나누는 지식공유 커뮤니티입니다.

iWiz,ShareBase,윤태현,Java,JSP,EJB,IT,정보기술,웹프로그래밍,PHP,ASP,DBMS,MySQL,서버,네트워크,server,network,WAS,웹애플리케이션,블로그,blog,웹서버,DB,오라클,oracle,mysql,JRun,웹로직,톰캣,tomcat,아파치,자동차,EF쏘나타,로또 6/45

갤러리 Pixelgrapher.com | 로또 6/45 번호생성 및 통계 데이터 | 전체기사보기 | 전체글 #1 | 전체글 #2 | 전체글 #3 | 전체글 #4 | 전체글 #5 | 전체글 #6 | 전체글 #7 | 전체글 #8 | 전체글 #9 | 전체글 #10 |

iWiz
ShareBase

Cool Sense

Mania Zone

IT Paper

Be FREE!

My Blog

Gallery

About me

Member

지식은 나눌수록 커집니다 - iWiz's ShareBase

웹프로그래밍(기타)

PHP, ASP, Perl, CGI 등 각종 웹프로그래밍에 관한 자료들입니다.

iWiz

(2004-01-04 22:55:12, Hit : 8306, Vote : 37)

http://www.wz.pe.kr

IE에서 euc-kr 캐릭터셋 사용시의 주의사항

MSIE에서 character-set을 euc-kr로 사용할때 발생할 수 있는 문제점입니다.
우리나라에서의 주 개발환경이 IE와 euc-kr이므로 대부분 공통적으로 해당되는 내용입니다.

혹시 인터넷 신조어인 "아햏햏"를 들어보셨나요?  저도 정확히는 모르는데 뭐 엽기적이다 그런뜻인듯 합니다.
그런데 이 "아햏햏"라는 단어가 문제의 소지를 안고 있습니다. (정확히는 아햏햏뿐만 아니라 쿜, 햏 등 좀 특수한 한글 문자에서 공통적으로 발생합니다)  이것은 브라우져와 캐릭터셋 설정의 문제로 보여지므로, 서버사이드의 PHP, ASP, Perl, Java, C 등 언어 종류를 불문하고 모두 문제의 소지를 안고 있습니다.

정확히 어떤 문제가 있냐하면 IE에서 웹페이지의 캐릭터셋이 euc-kr로 설정되어 있을 경우(charset=euc-kr) 아햏햏라는 단어를 폼에 입력해서 POST로 날리게되면 실제 데이터는 "아햏햏"이 아니라 "아햏햏"으로 자동으로 인코딩되어 날아갑니다.  이걸(아햏햏) 그대로 화면에 뿌리면 브라우져에 의해 디코딩이 되어 화면상으로는 "아햏햏"이라고 나오지만, 실제 소스를 보면 "아햏햏"이라고 나옵니다.

이런 현상이 문제가 될 수 있는 것은 폼에서 받은 데이터를 파일에 쓰거나 DB에 저장, 또는 메일로 보내면 "아햏햏"이 아니라 "아햏햏"로 되기 때문입니다.

<문제가 발생할 수 있는 상황>

- 메일제목 : HTML을 지원하지 않으므로 아햏햏 이라고 표시됩니다.
- 파일저장 : 아햏햏 으로 저장되므로 필터링 구현 등에 문제가 발생합니다.
- DB : 아햏햏 으로 저장되므로 소팅이나 검색에 문제가 발생할 수 있습니다.
- 기타 : 게시판 제목 등에서 태그사용을 막기위해 htmlspecialchars 같은 함수로 html 태그를 이스케이프 처리해주면 아햏햏가 그대로 출력됩니다.

이 현상은 페이지의 charset이 euc-kr로 되어있을 때만 발생합니다. (즉 페이지가 로드된 후 IE의 [보기]-[인코딩] 메뉴를 봤을때 선택되어 있는 문자셋이 한국어(EUC)로 되어 있을때만 발생)

<해결방안>
1. 폼이 들어간 페이지의 charset을 ks_c_5601-1987로 지정. (일부 유닉스/맥 버젼의 Netscape에서 문제 발생 소지)
2. 폼 페이지의 charset을 지정하지 않으면 IE에서 KSC로 자동인식 (그러나 1번보다 더 큰 문제의 소지를 안고 있음)
3. 폼 페이지의 charset을 korean으로 지정. (PHP School 방식)
4. 서버 사이드에서의 처리 (브라우져에서 자동으로 인코딩된 유니코드 엔티티를 ISO-8859-1 캐릭터셋으로 디코딩)

1번과 2번은 검토해볼 가치가 없기 때문에 생략하고 3번과 4번을 검토해본 결과
3번 : 다양한 사용자가 이용하는 PHP School에서 사용중인 방식이므로 별다른 문제는 없어보임. 그러나 MSDN 조회결과 korean은 ks_c_5601-1987의 alias라고 나와있어 1번과 동일한 문제가 있지 않을까 우려됨.
4번 : 서버사이드에서의 처리를 가장 비중있게 검토해보았으나 Get/Post로 넘어온 모든 데이터를 검사해서 유니코드 엔티티가 있을 경우 이를 디코딩하는 과정이 복잡하고 서버 부하도 우려됨(디코딩 함수 만들어야 함 -_-).  또한 사용자가 원래 입력한 값이 "햏"이 아니라 "햏"일 경우에도 넘어오는 값은 동일해 구분할 방법이 없기 때문에 "햏"으로 디코딩 처리될 우려가 있음.  따라서 현실적으로 적용하기 매우 힘듬.

<결론>
최선책은 없지만 차선책은 있습니다.  바로 입력폼이 있는 페이지의 charset을 PHP School처럼 korean으로 바꾸는 것입니다.  가장 손쉽고 빠르고 완벽한 해결방법입니다.  혹시 X윈도에서 넷스케이프로 접속한 사람에게 입력폼의 한글이 깨져보일 가능성도 일부 있지만 어쩔 수 없습니다.