앞서의 포스트들에서 한글 인코딩과 관련한 이해를 위하여 여러가지 실험을 해 보았다. 간단히 정리하자면
윈도우즈 커맨드 프롬프트모드 및 전반적인 파일 시스템에서는 기본적으로 EUC-KR (CP949) 를 따르는데 비해 리눅스(우분투)는 UTF-8 을 기반으로 한글을 처리하는 것으로 보인다.
한편 대다수의 웹 페이지들은 오늘날은 UTF-8 인코딩으로 작성되어 있으나 일부 소수의 사이트는 예전방식을 따를 경우 웹브라우저에서 코딩 방식을 맞추어 주지 못하면 한글이 다 깨어져서 보이질 않는 상황이 발생한다.
이번 포스트는 웹페이지에 를 파이썬으로 다룰때 한글이 들어간 경우의 한글 코드 인코딩에 대한 를 어떻게 처리하는가에 대한 이야기이다.
일전에 어느분의 부탁으로 대법원의 판례 자료들을 파이썬 코드로 자동으로 다운로드 받도록 프로그램을 만들어 드린 바 있다. (일종의 web scraping) 총 9000여개의 데이터여서 손으로 하나씩 하기에는 너무도 버겁기 때문이다. 비슷한 일들을 미국 웹사이트에서는 가끔 해 보았기에 해 드린다고 시작하고 나니 내 파이썬 실력으로는 한글 코드 관련한 지식의 부족으로 한글 검색을 못하겠다는 사실... 결국은 웹 소스 봐가면서 다운받을 링크 근방의 다른 영어 키워드를 가지고 찾아가도록 겨우 겨우 프로그램을 해 드렸다. 당시 한글 인코딩 지시어가 어떤 의미를 지니는지도 정확히 이해를 못하는 상황에서 (지금은 이해하고 있는가?) 그냥 UTF-8 로 코드 시작부에 넣어 놓고 EditPlus 로 Plain Text (ANSI) 코드를 작성해서 그냥 시행착오로 코드를 만들고 테스트해 가면서 일을 마쳤다. 그래서 이제는 이것을 다시 되짚어보고 싶어졌다.
비교 테스트를 위하여 다음의 두 링크를 준비해 보았다.
천리안에 있는 개인 홈페이지 (매우 오래전에 만든 학교 선생님의 홈페이지인듯 함. 원래는 프레임이 있는데 프레임 내의 소스 링크만 가져와서 테스트함)
첫번째 것은 크롬 브라우저에서 안깨지고 잘 보인다. 두번째 것은 한글이 다 깨져서 파이어폭스 또는 IE 를 꼭 써야 내용을 볼 수 있는 상황이었다.
다음과 같은 간단한 파이썬 코드로 웹페이지를 다운받아 텍스트 파일로 저장하고 비교해 본다.
import urllib2
def WebLinkSave(url, savedfilename):
try:
f = urllib2.urlopen(url)
except:
ReportError("Cannot find url: " + url)
return None
output = open(savedfilename,'wb')
binaryfile = f.read()
output.write(binaryfile)
output.close()
return binaryfile
#### main #############################
WebLinkSave("http://www.scourt.go.kr/portal/dcboard/DcNewsListAction.work?gubun=44&searchOption=", "1.html")
WebLinkSave("http://user.chol.com/~deuckgi/main-b.htm", "2.html")
그런데 두 파일 확장자를 .txt 로 바꾸어 저장한 후 notepad로도 열어 보면 둘다 한글이 잘 보인다.
두 소스에서 가장 큰 차이라면 좌측것은 content charset 이 euc-kr 로 정의되고 우측은 그런 정의가 없다는 사실. 노트패드로 각각의 파일 포맷은 둘 다 동일하게 Plain Text 임은 이미 확인해 둔 상태이다. 그래서 이 문자세트 부분만을 우측 소스에도 복사해 넣고 크롬 브라우저에서 열어보면 더이상 한글이 깨지지 않는다.
이상의 실험 결과를 바탕으로 조금 더 체계적으로 다양한 테스트를 시도하기로 한다. 기본 아이디어는 HTML 소스 자체의 포맷을 EUC-KR (Plain Text) 과 UTF-8 로 저장해 놓고 HTML 시작부분에 charset 정의를 넣거나 빼고, 정의된 인코딩 방식도 바꾸는 식으로 테스트해 보는 것이다. 테스트를 위한 HTML 소스는 전부 노트패드로 만든다.
코드는 다음과 같다.
<html>
<body>
한글<br>
English<br>
</body>
</html>
우선 Plain Text 로 저장한 결과이다. 다음 세 그림은 윈도우7 에서 크롬, IE, 파이어폭스로 본 경우이다.
파이어폭스나 IE 의 경우는 인코딩 옵션을 Autodetect - Korean 을 선택해 놓았다.
같은 파일을 우분투에서도 Chromium 과 파이어폭스로 열어본다. 역시 파이어폭스는 Autodetect - Korean 선택.
개인적으로 이런 인코딩 우선순위를 크롬에서는 어떻게 잡아주는 줄 모르기에 매번 이런 깨지는 사이트가 나오면 링크 복사해서 파이어폭스 또는 IE 를 다시 열어서 보곤 한다. -_-
다음으론 동일한 코드에 charset 알려주는 문장 한줄을 첨가한다.
<html>
<meta http-equiv="Content-Type" content="text/html; charset=euc-kr" />
<body>
한글<br>
English<br>
</body>
</html>
이제는 크롬, Chromium 에서도 잘 보인다.
마찬가지 방법으로 HTML 파일 자체를 UTF-8 포맷으로 저장한 후 동일한 실험을 해 본다. 그림에서 파일 이름을 잘 보면 P-N / P-U / U-N / U-U 로 되어 있으며 앞의 글자는 P는 plain text, U 는 utf-8 포맷으로 저장했음을 의미하고 뒤의 글자는 N 은 charset 정의가 없는 경우, U 는 EUC-KR (실수다... E 라고 하려고 생각했었는데... 귀찮으니까 그냥~~) 을 의미한다.
모두 다 잘 보인다. 한가지 재미있는 점은 charset 을 euc-kr 로 정의해 주거나 파일 자체를 UTF-8 로 저장해 놓은 경우 크롬 계열은 영문 폰트가, 파폭은 윈도우에서는 영문 폰트만, 우분투에서는 영문/한글 폰트 모두 변한다는 사실. 파폭의 경우는 옵션에서 인코딩에 따른 폰트를 따로 정의할 수 있어서 이것과 관련되었다고 생각된다. 어쨌거나 브라우저에서는 소스 파일의 인코딩도 체크하고, 소스 내에서의 charset 정의도 판단해 가면서 적절한 방법으로 웹페이지를 보여주는 모양이다. 다만 IE, 파폭의 경우 소스내에 코드에 한글 등 비 아스키 문자가 섞이는 경우 인코딩 기본설정에 따라서 코드의 코딩 방식을 체크해서 적절한 디코딩을 해서 보여주는 듯 하다.
이 가정을 확인해 보기 위해 IE 와 파이어폭스에서 소스 인코딩 옵션을 바꾸면서 글자가 잘 보이는지 테스트 해 보았다. 다음은 FF의 예이다. FF는 한글 인코딩 방식을 무려 4가지나 지원한다.
UTF-8 인 경우
EUC-KR
JOHAB
ISO-2022-KR
대략 도표를 만들어 보면 다음과 같다.
내용을 들여다 보면 브라우저의 인코딩 옵션이란 것이 소스코드의 저장 포맷의 파악 방법을 의미하는 것 같은데 (내부의 charset 정의가 아니라) 파이어폭스의 경우 EUC-KR(plain text)로 저장된 파일 속에 charset을 UTF-8 로 정의해 놓으면 UTF-8 인코딩으로 자동으로 잡히면서 글자는 깨어진다. 그리고 charset 정의가 실제 한글 코드의 인코딩을 바꾸는 것이 아니라 물리적인 코드는 저장된 코드 포맷에 의해 정해지는 것 같다.
그렇다면 charset 의 역할이 뭔지 많이 햇갈린다. 아마도 웹개발 전문으로 하는 분들은 이런거는 거의 기본으로 다 알고 할 터이지만 역시 정식으로 배우거나 일하지 않는 나같은 취미 아마추어 입장에서는 이런식으로 하나하나 테스트하면서 이해하려니 거의 왕 삽질이다.
본 포스트들에서는 유니코드 포맷(초기 UCS-2, UTF-16 방식들)의 파일은 아예 취급하지 않으려 한다. 실제 소프트웨어 업계에서는 그런 방식들을 어디에 어떻게 쓰는지는 모르겠지만 나같은 취미 컴 라이프를 즐기는 입장에서는 현재로는 그런 것 까지 생각하고 싶지도 않다.
이것 저것 테스트는 잔뜩 하는데 하다보니 내가 무엇을 목표로 이런 테스트를 하고 있는지 잊고 있다. 조금 생각을 정리한 후 더 나아가야 할 듯 하다.
'IT > 컴퓨터와 한글' 카테고리의 다른 글
| 한글 인코딩에 대한 이해 (0) | 2013.07.06 |
|---|---|
| 컴퓨터에서의 한글 처리 (8) Geany 에디터의 문제점 ? (0) | 2013.05.05 |
| 컴퓨터에서의 한글 처리 (6) 윈도우즈 vs 우분투 (0) | 2013.05.05 |
| 컴퓨터에서의 한글 처리 (5) 에디터별 차이점 (0) | 2013.05.05 |
| 컴퓨터에서의 한글 처리 (4) 유니코드, UTF-8, 글자수 vs 바이트수 (0) | 2013.05.05 |