URL을 항상 UTF-8로 보냄과 유니코드
2007/12/15 23:54 인터넷을 사용하다 보면, 가끔 이런 문구를 보게 된다.
" 'URL을 항상 UTF-8로 보냄'의 체크를 끄세요!"
UTF-8이 뭐길래? UTF-8이 그렇게 나쁜 것인가?
Internet Explorer에서는 UTF-8로 데이터를 보내는 것이 기본 설정이다. 이유는 무엇인가.
UTF-8은 Unicode의 특별한 압축 방법 중 하나이기에 모든 언어를 표현할 수 있다. 즉 일본어용 한자와 중국어의 한자, 안드로메다 외계어(?), 한글의 모든 조합 등 모든 것이 표현 가능하다.
반면 EUC-KR 또는 CP949라 불리는 완성형 한글 규격은 한글만을 부분적으로 표현해 주게 된다.
그런데 왜 많은 사용자들은 URL을 UTF-8로 보내지 않기를 바라는 것인가?
이것은 URL로 전달되는 값에서, 한글과 같은 영어가 아닌 문자의 언어 코드별 인코딩 차이 때문이다.
예를들어 "한글"이 이 코드에서는 ABCD로 해석되는 반면, 다른 코드에서는 DCBA로 해석되어 주소가 달라지기 때문이다.
그렇다면 범용성 적인 측면에서는 어떠한 선택을 하는게 맞는가. 그것은 당연히 UTF-8이다. 한국의 인터넷을 닫힌 세상으로 만들지 않으려면, 그것을 선택하는게 맞다.
그렇다고 간단히 UTF-8로 바꿀 수 있는것은 아니다. 이미 주소가 그런식으로 설정 되어왔고, 그것이 당연한 것으로 생각하기 때문이다.
사용자들이 UTF-8로 주소를 보내도 정상적으로 처리하는 몇가지 대안이 있다.
1. 웹서버 측에서 UTF-8 데이터를 중간에 다른 코드로 변환시킨다.
이것은 아파치의 url encode 기능을 하는 플러그인을 설치하는 것으로 간단히 처리된다. 물론 UTF-8데이터가 아닌 기존의 데이터로 들어오더라도, 정상적으로 처리된다.
이 방식은 사용자로서의 원인 해결이 안된다는 단점이 있지만, 둘 모두로부터 데이터를 정상적으로 가져가게 하는 어떻게 보면 이상적인 방법이기도 하다.
2. 웹브라우저 측면에서 주소를 선택하여 가져온다.
firefox에서 이 방식을 사용하는데, 일단 데이터를 UTF-8로 보내 본 후, 데이터를 가져올 수 있는지를 판단해서 주소의 코드를 재 선택한다.
이 방식은 애초에 URL을 UTF-8로 보낼지 안보낼지에 대한 선택 여부를 없애 버리는 방법이기도 하다. 사실 불필요한 설정이 없을 수록 좋기 때문에, 확실한 방법이기도 하다.
3. CGI를 중간에 둠으로서, 절대 주소를 변경한다. CGI를 통해, 데이터의 절대주소를 숨길 수 있다.
/home/userid/public_html/image/바보.jpg라는 이미지가 저장되어 있을때, 이 이미지의 절대 주소는 http://localhost/~userid/image/바보.jpg가 될것이다.
그에 대해 이 이미지에 대한 접근권한을 아파치만 가능하도록 바꾼 후, 입력 값에 대해, 이미지를 직접 보여주는 기능을 가진 viewer.php라는 CGI를 작성했다고 치자.
http://localhost/~userid/viewer.php?20071201&1 (이 명령이 2007년 12월 1일에 업로드한 첫번째 파일을 보여라. 라는 식의 명령이라고 가정한다.)
이러한 형태로 접근하여, 파일의 위치를 숨겨 보안성도 강화하면서, UTF-8문제를 비켜갈 수 있다.
이 방법들 외에도 웹 브라우저의 언어차이를 없애고, UTF-8을 기본으로 동작하게 하는 방법들이 존재한다.
사실 현대의 네트는 탈 언어권 적으로 흘러가기 때문에, 네트를 연구하는 학자들은 꽤 오래전부터 Unicode를 내부적으로 이용하기를 권고해왔다.
그럼에도 불구하고 네트워킹 강국이라고 말하는 우리나라는, 아직도 URL의 UTF-8 인코드를 불필요하다고 간주하고 있는 것이다. 왜일까? 아마도 z모 웹보드의 영향이 꽤 크게 작용했으리라..
유니코드 문제는 웹 뿐만 아니라, 시스템 자체, DB등에 매우 복잡한 문제가 있다고 할 수 있다. 기본적으로 윈도우는 내부적으로 유니코드를 사용함에도, 실제 인터페이스와 파일구조는 모두 자체 코드를 사용한다. (한국은 cp949로 설정되어 있다. 명령행에서 chcp를 입력해보면, 현재 활성 페이지가 949임을 알 수 있다.)
이는, 실제 유니코드화 된 파일과의 호환성이 일정수준 결여됨을 알 수 있다.
유닉스 시스템에서는 어떨까? 전통적으로 국내의 리눅스 배포본의 코드는 ko_KR.EUC-KR로 맞추어져 왔다. 이 문제는 국내 뿐 아니라, 외국의 경우도 비슷했다. 이유는 윈도우와의 파일 시스템 호환을 위해서였고, 웹 서비스 역시도 이러한 문제가 확장되어 이루어 졌다는 것이다.
하지만 근래의 유닉스 시스템은 점차 ko_KR.UTF-8코드로 변화하고 있다. 해당 언어의 폰트만 존재한다면, 모든 글자를 표현해 줄 수 있다는 큰 장점을 가지고 있기 때문이다.
위에서도 적었지만, 세상은 점차 탈 문화권적으로 바뀌어 간다. 특히 네트에서는 이 변화가 더욱 빠르다. 점차 사람들의 인식이 변해 가면서, 같은 내용의 페이지를 여러 언어로 동시에 개설하기도 한다. 유니코드의 압축기술인 UTF-8, UTF-16은 이런 변화의 선봉에 서 있다고도 할 수 있다.
여러분의 홈페이지는 어떤가? '어차피 내가 아는 사람들만 오는 공간' 이라는 생각에 이런 문제에 무관심 해왔고, 그림이 안보인다는 사람들에게, "URL을 항상 UTF-8로 보냄"의 체크를 끄세요!"라고 말했다면.. 그리고 그것이 당연한 것으로 알았다면, 이제는 유니코드의 세계에 빠져보는 것이 어떨까?
" 'URL을 항상 UTF-8로 보냄'의 체크를 끄세요!"
UTF-8이 뭐길래? UTF-8이 그렇게 나쁜 것인가?
Internet Explorer에서는 UTF-8로 데이터를 보내는 것이 기본 설정이다. 이유는 무엇인가.
UTF-8은 Unicode의 특별한 압축 방법 중 하나이기에 모든 언어를 표현할 수 있다. 즉 일본어용 한자와 중국어의 한자, 안드로메다 외계어(?), 한글의 모든 조합 등 모든 것이 표현 가능하다.
반면 EUC-KR 또는 CP949라 불리는 완성형 한글 규격은 한글만을 부분적으로 표현해 주게 된다.
그런데 왜 많은 사용자들은 URL을 UTF-8로 보내지 않기를 바라는 것인가?
이것은 URL로 전달되는 값에서, 한글과 같은 영어가 아닌 문자의 언어 코드별 인코딩 차이 때문이다.
예를들어 "한글"이 이 코드에서는 ABCD로 해석되는 반면, 다른 코드에서는 DCBA로 해석되어 주소가 달라지기 때문이다.
그렇다면 범용성 적인 측면에서는 어떠한 선택을 하는게 맞는가. 그것은 당연히 UTF-8이다. 한국의 인터넷을 닫힌 세상으로 만들지 않으려면, 그것을 선택하는게 맞다.
그렇다고 간단히 UTF-8로 바꿀 수 있는것은 아니다. 이미 주소가 그런식으로 설정 되어왔고, 그것이 당연한 것으로 생각하기 때문이다.
사용자들이 UTF-8로 주소를 보내도 정상적으로 처리하는 몇가지 대안이 있다.
1. 웹서버 측에서 UTF-8 데이터를 중간에 다른 코드로 변환시킨다.
이것은 아파치의 url encode 기능을 하는 플러그인을 설치하는 것으로 간단히 처리된다. 물론 UTF-8데이터가 아닌 기존의 데이터로 들어오더라도, 정상적으로 처리된다.
이 방식은 사용자로서의 원인 해결이 안된다는 단점이 있지만, 둘 모두로부터 데이터를 정상적으로 가져가게 하는 어떻게 보면 이상적인 방법이기도 하다.
2. 웹브라우저 측면에서 주소를 선택하여 가져온다.
firefox에서 이 방식을 사용하는데, 일단 데이터를 UTF-8로 보내 본 후, 데이터를 가져올 수 있는지를 판단해서 주소의 코드를 재 선택한다.
이 방식은 애초에 URL을 UTF-8로 보낼지 안보낼지에 대한 선택 여부를 없애 버리는 방법이기도 하다. 사실 불필요한 설정이 없을 수록 좋기 때문에, 확실한 방법이기도 하다.
3. CGI를 중간에 둠으로서, 절대 주소를 변경한다. CGI를 통해, 데이터의 절대주소를 숨길 수 있다.
/home/userid/public_html/image/바보.jpg라는 이미지가 저장되어 있을때, 이 이미지의 절대 주소는 http://localhost/~userid/image/바보.jpg가 될것이다.
그에 대해 이 이미지에 대한 접근권한을 아파치만 가능하도록 바꾼 후, 입력 값에 대해, 이미지를 직접 보여주는 기능을 가진 viewer.php라는 CGI를 작성했다고 치자.
http://localhost/~userid/viewer.php?20071201&1 (이 명령이 2007년 12월 1일에 업로드한 첫번째 파일을 보여라. 라는 식의 명령이라고 가정한다.)
이러한 형태로 접근하여, 파일의 위치를 숨겨 보안성도 강화하면서, UTF-8문제를 비켜갈 수 있다.
이 방법들 외에도 웹 브라우저의 언어차이를 없애고, UTF-8을 기본으로 동작하게 하는 방법들이 존재한다.
사실 현대의 네트는 탈 언어권 적으로 흘러가기 때문에, 네트를 연구하는 학자들은 꽤 오래전부터 Unicode를 내부적으로 이용하기를 권고해왔다.
그럼에도 불구하고 네트워킹 강국이라고 말하는 우리나라는, 아직도 URL의 UTF-8 인코드를 불필요하다고 간주하고 있는 것이다. 왜일까? 아마도 z모 웹보드의 영향이 꽤 크게 작용했으리라..
유니코드 문제는 웹 뿐만 아니라, 시스템 자체, DB등에 매우 복잡한 문제가 있다고 할 수 있다. 기본적으로 윈도우는 내부적으로 유니코드를 사용함에도, 실제 인터페이스와 파일구조는 모두 자체 코드를 사용한다. (한국은 cp949로 설정되어 있다. 명령행에서 chcp를 입력해보면, 현재 활성 페이지가 949임을 알 수 있다.)
이는, 실제 유니코드화 된 파일과의 호환성이 일정수준 결여됨을 알 수 있다.
유닉스 시스템에서는 어떨까? 전통적으로 국내의 리눅스 배포본의 코드는 ko_KR.EUC-KR로 맞추어져 왔다. 이 문제는 국내 뿐 아니라, 외국의 경우도 비슷했다. 이유는 윈도우와의 파일 시스템 호환을 위해서였고, 웹 서비스 역시도 이러한 문제가 확장되어 이루어 졌다는 것이다.
하지만 근래의 유닉스 시스템은 점차 ko_KR.UTF-8코드로 변화하고 있다. 해당 언어의 폰트만 존재한다면, 모든 글자를 표현해 줄 수 있다는 큰 장점을 가지고 있기 때문이다.
위에서도 적었지만, 세상은 점차 탈 문화권적으로 바뀌어 간다. 특히 네트에서는 이 변화가 더욱 빠르다. 점차 사람들의 인식이 변해 가면서, 같은 내용의 페이지를 여러 언어로 동시에 개설하기도 한다. 유니코드의 압축기술인 UTF-8, UTF-16은 이런 변화의 선봉에 서 있다고도 할 수 있다.
여러분의 홈페이지는 어떤가? '어차피 내가 아는 사람들만 오는 공간' 이라는 생각에 이런 문제에 무관심 해왔고, 그림이 안보인다는 사람들에게, "URL을 항상 UTF-8로 보냄"의 체크를 끄세요!"라고 말했다면.. 그리고 그것이 당연한 것으로 알았다면, 이제는 유니코드의 세계에 빠져보는 것이 어떨까?
이올린에 북마크하기
이올린에 추천하기category : 네트
