Lunikism

너는 아름다운 웹사이트가 있는다!
우수한과 아주 도움이 되는!
아주 재미있는 지점. 감사.
중대하고 유용한 위치!
친구는 너의 위치의 현재 팬이 되었다!

구글은 새 프로젝트 ‘국제 청소 주말(International Cleanup Weekend)’을 발표하며 오는 13~14일 세계 각지에서 일제히 지역 청소 활동에 동참하자고 호소했다.

이것은 유저가 청소하는 지역을 ‘구글 맵스’로 지정해 정리하는 것으로 ‘구글 어스’팀의 활동에서 시작됐다.

지역 관계를 위한 사내 환경 활동단체로 시작된 이 활동은 현재 15개국의 커뮤니티에서 받아들여지고 있다. 구글 어스의 사회공헌 활동 팀은 6~10명으로 구성돼 자택 부근을 청소하고 그 모습을 찍은 사진이나 비디오를 이 팀의 구글 맵스에 올려 성과를 공개해 달라고 요구했다.

개인적이고 자주적으로 활동해도 되지만, 구글의 협력 단체인 아이디얼리스트(Idealist.org), 시에라 클럽, 영국 스카우트 협회 등 단체와 상담할 수도 있다. 이들 단체는 지역 활동을 주최할 것을 회원들에게 호소하고 있다.

활동을 주최하는 사람은 우선, 마이 맵스 기능을 사용해 개인 구글 맵을 만든다. 그 다음 구글의 청소 활동 형식에 맵의 URL을 붙여 ‘국제 청소 주말’ 데이터베이스에 등록한다. 그림은 해안 청소를 예로 든 맵이다.

청소 활동을 주최할 때 유의점은 쓰레기봉지나 목장갑 등을 준비하고 팀 멤버의 휴대 전화 번호를 알리는 것 등이라고 구글은 밝혔다. 또 활동 사진이나 비디오를 각 그룹의 구글 맵에 게재해 성과를 공개할 것을 요청했다.

구글의 이런 활동이 뜻밖이라고 생각할 수도 있다. 그러나 결코 그렇지 않다. 구글 어스는 이전에도 워싱턴 D.C.에 있는 대량학살 기념박물관과 협력해 수단 다르푸르 주의 대량학살 현장을 지도에 나타낸 프로젝트를 했었다. 이번 프로젝트는 세계적인 관심을 사서 지구 규모의 활동으로 확대하기 위한 유효한 수단이라고 구글 어스는 밝혔다.

Written by 안재우(Jaewoo Ahn), 닷넷엑스퍼트(.netXpert)

 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을 쓰세요.

서명덕기자님의 블로그에서 재미있는걸 발견했다.

자신의 도메인의 가치를 돈으로 환산해 보여주는 사이트가 바로 그것이다.

http://www.leapfish.com 에 들어가서 도메인을 입력하면

점수와 같이 돈으로 환산해준다.

내 도메인인은?

32점으로

$64.00  ㄷㄷㄷ. 64달러면 5만8천원 정도 나오네.

여기서..

google.com은 어떨까?

무려  23284 점으로

$898,552,844.00 역시 구글인가!! 환산해보면 823,883,102,664원

약 8천억이 나온다.

8천억... 5만8천원  ㅠㅠ;


yahoo.com

32735 점으로

$1,523,846,985  환산하면 1,397,215,300,547원.


naver.com
 
10636 점으로

$48,032,176  환산하면 44,040,702,174원


korea.net

7512 점으로

$7,977,744 환산하면 7,314,793,474원