아직도 UTF-8을 안 쓰십니까?

ASP 등으로 되어 있는 이전 사이트들을 .NET으로 마이그레이션하다가 한번씩 겪는 문제점 중 하나는 그놈의 지긋지긋한 한글 인코딩 문제입니다.

 

그 유명한 베스트셀러(?)인 '조엘 온 소프트웨어'에서도 이러한 인코딩 문제에 대해 언급을 하고 있습니다. 미국애들 중에 몇몇이 여전히 ASCII를 쓰는 것처럼, 우리나라 개발자들 역시 여전히 KSC-5601이나 ECU-KR 인코딩을 고집하는 사람들이 많습니다.

 

심지어 일반 사용자들마저도 한글 인코딩과 관련된 문제를 겪어보지 않은 사람들이 없을 것입니다. 가장 대표적인 사례로, 페이지의 이미지가 보이지 않는 일은 누구나 겪어 봤을 것입니다. 실제 이미지가 없는 경우는 제외하고, 이 문제의 원인 중 99%는 이미지 파일 이름이 한글로 되어 있는 경우입니다.

대부분의 사이트 또는 지식검색 등에서는 IE의 옵션에서 URL을 항상 UTF-8로 보냄이라는 옵션을 꺼서 해결하라고 말하곤 합니다. 문제는 이것이 근본적인 해결책은 아니며, 한글 인코딩 문제의 해결을 더더욱 멀게 만드는 장벽이 된다는 것입니다.

 

잠깐 빗나갔는데 다시 개발에 대해서 초점을 맞춰서 다시 얘기해보겠습니다.

일반적으로 한글 인코딩과 관련된 문제가 말썽을 부릴 소지가 있는 경우는 다음과 같습니다.

1. 웹 페이지의 한글 컨텐츠가 KSC-5601이나 EUC-KR로 되어 있는 경우

2. 브라우저에서 호출하는 URL에 한글이 포함되어 있는 경우

3. 데이터베이스에서 한글 인코딩이 UTF-8이 아닌 다른 것으로 지정되어 있는 경우

 

먼저 1번의 경우..

근본적인 문제가 생기는 원인은 ASP.NET을 비롯하여 .NET에서는 기본 인코딩이 UTF-8인 것부터 출발합니다. 그러므로 예를 들어, 웹 페이지의 한글 컨텐츠가 KSC-5601이나 EUC-KR로 되어 있는 경우, 인코딩이 깨지게 되는 것입니다.

물론 이 문제의 잘못이 무조건 개발자에게만 있느냐하면, 절대 그렇지는 않습니다. 일반적으로 웹 페이지를 디자인하는 것은 웹 디자이너들의 몫이며, 이 디자이너들이 페이지를 디자인할 때 KSC-5601이나 EUC-KR을 사용해서 작성해버리는 경우가 대다수입니다.

또, 종종 개발자를 당혹스럽게 하는 것 중 하는 .inc나 .js를 통해 include한 파일의 경우입니다. 아무 이상 없이 잘 돌던 .js였는데, 단지 ASPX 내에 붙여 넣었다는 이유만으로 스크립트 에러가 발생합니다. 이러한 경우, 역시 십중팔구는 스크립트 파일 내에 한글이 포함되어 있는 경우입니다.

 

일단 이 문제를 해결할 수 있는 방법은..

각 페이지의 meta 태그 등에서 charset을 지정해주거나,

web.config에서 다음과 같이 인코딩을 지정해주는 방법이 있습니다.

 

<configuration>
   <system.web>
      <globalization 
         requestEncoding="ksc5601-1987"
         responseEncoding="ksc5601-1987"
         fileEncoding="ksc5601-1987"/>
   </system.web>
</configuration>

그런데, 이렇게 하면 정말 해결이 된 것일까요?

역시 이것 역시 임시적인 해결책에 지나지 않습니다.

더이상 인코딩 문제를 겪지 않으려면, UTF-8을 쓰는 것이 확실한 답입니다.

그러므로 바람직한 방법은 설사 디자이너가 다른 인코딩으로 전달을 해왔다고 하더라도, 메모장 등을 통해서 UTF-8로 변환해서 저장하는 것입니다. 스크립트 파일들 역시 메모장에서 연 다음 UTF-8로 변환해서 저장합니다.

 

2번의 경우.. 한글이 포함된 URL의 경우, 올바른 전송을 위해서는 한글을 URL에 맞게 인코딩을 수행해야 합니다.

 

예를 들어..

http://search.naver.com/search.naver?where=nexearch&query=한글인코딩&frm=t1

이 아니라..

http://search.naver.com/search.naver?where=nexearch&query=%C7%D1%B1%DB%C0%CE%C4%DA%B5%F9&frm=t1

가 되어야 한다는 것입니다.

(물론 네이버는 euc-kr 인코딩을 쓰고 있긴 합니다. -_-;;)

 

.NET의 경우..

문자열을 신뢰할 수 있는 URL 문자열로 만들기 위해 두 개의 메서드를 제공합니다.

HttpServerUtility.UrlEncode

HttpUtility.UrlEncode

 

이와는 반대로 다시 디코딩해서 원래의 문자로 돌리도록 다음 메서드들도 제공됩니다.

HttpServerUtility.UrlDecode

HttpUtility.UrlDecode

 

결국 Response 시에는 UrlEncode를 사용해서 인코딩을 하고, Request 받은 것을 처리할 때는 다시 UrlDecode를 사용해서 디코딩을 하는 형태로 해결을 하면 됩니다.

 

물론 이러한 부분을 처리하는데는 개발자의 귀차니즘이 수반되게 됩니다. 그 귀차니즘 덕분에 수많은 사용자들이 URL을 항상 UTF-8로 전송 옵션을 꺼야 합니다.

 

3번의 경우.. SQL 서버에서보다는 Oracle에서 많이 볼 수 있는 경우입니다.

상당수 Oracle 데이터베이스가 UTF-8이 아닌.. 심지어 US-ASCII7을 사용하는 경우가 있습니다.

대표적인 경우가 회사 내부에서 SAP을 사용하는 경우인데, 제가 알고 있기론 SAP 설치 시 기본 인코딩이 US-ASCII7인 걸로 압니다.

그래서 어떤 문제가 생기느냐? .NET에서 Oracle에 연결하기 위한 프로바이더로 ODP.NET이라는 놈이 있습니다. 이놈은 .NET이 붙은 넘 답게.. UTF-8을 사용합니다.

고로 ODP.NET을 사용하여 데이터베이스 인코딩이 US-ASCII7로 지정된 DB에서 한글 데이터를 읽으면 한글이 깨져버리는 사태가 발생하게 됩니다.

이에 대한 해결책은 DB 서버의 인코딩을 바꿔주거나, 쿼리에서 일일이 Encode 메서드를 사용해서 UTF-8로 변환하거나, 받은 후 애플리케이션 코드에서 인코딩을 변환시켜주는 수 밖에 없다는 것입니다. 어느 것 하나 쉬운게 없는데, 이러한 고생을 하는 이유가 한글 인코딩에 대해 무지했던 과거의 개발자/시스템 관리자들이 저질러 놓은 사고입니다.

 

사실 가장 이상적인 것은 Windows에서 인코딩을 UTF-8만 사용하도록 해버리면 확실한 해결책이 될지도 모릅니다. 대신 언젠가 만약 그런 날이 온다면, 기존의 UTF-8을 사용하지 않은 웹 사이트들은 문제가 생기게 되겠죠.

그러나, UTF-8이 표준화되었으므로 언젠가는 정말로 그런 날이 올지도 모릅니다. 그런 날이 오지 않기를 빌면서 통일을 반대하는 것보다는 하나씩 하나씩 바꿔 나가야 하지 않을까 합니다.

 

제발 이제는.. UTF-8을 쓰세요.

[출처] 아직도 UTF-8을 안 쓰십니까?|작성자 안재우

[출처] 아직도 UTF-8을 안 쓰십니까?|작성자 안재우

http://blog.naver.com/saltynut/120020091973