Mozilla 한국 커뮤니티

안녕하세요

몇일 붙잡고 있는데 해결이 안되어 이렇게 질문올려봅니다.

일단 제가 만들고 있는 사이트가 미니홈피나 블로그 같은 형식인데요

http://도메인/모질라홈

이런형식으로 뒤의 "/"를 기준으로 뒷편의 한글 & 영문을 가져옵니다.

그리고 그걸 기준으로 해당 계정을 보여주는것이지요...

그런데 문제가 IE는 괜찮은데

파폭에서 http://aaaaa.aa.aa/모질라홈

이런식으로 사용했을경우

%C6%C1%C6%C1 이런식의 문자가 되어 나옵니다.

반환 -> http://aaaaa.aa.aa/%C6%C1%C6%C1 이런식으로요

그런데 문제는...

이 유니코드처럼 보이는것이 유니코드가 아니란겁니다 ;;

decodeURI하니 형식이 틀리다 나오네요

"팁" 이란 글자를 위에처럼 파폭에서 URL뒤에 넣을경우

"%C6%C1" 라고 나오는데요

유니코드로 "팁"은 "%ED%8C%81" 거든요...

자릿수가 짧은것이 어떤 형태인지 파악이 안되서요

디코딩을 어떻게 해야할지 막막합니다.

힌트 좀 주세요 ㅠ ㅠ

저도 이해는 잘 안 되지만
mozilla.or.kr/모질라
하면 이상한 인코딩이 되는데

ex. http://www.google.com/모질라

라고 하면 올바르게 유니코드가 되네요

-

암튼 유니코드 인코딩으로 하시면 되요

파일이 유니코드로 올라가있다면
서버가 유니코드를 지원한다면
"유니코드 파일명" 으로 하면 잘 인식하구요
저도 한글 파일명으로 전혀 문제없이 이용중이에요

유저들 입장에선

앞에 http://를 붙일지 www.를 붙일지 아무도 예상할수가 없는데...

후움

시작시 강제로 http://www.~ 주소로 새로고침을 해버려야할가여 ㅠ ㅠ

아흄 왜이런 문제가 ㅠ ㅠ

앞의 www, http:// 는 전혀 상관이 없는걸요
유독 mozilla 가 들어간 주소에서만 그런게 아닐가 싶은
아니면 피싱때문에 그런가~_~

제가 운영하는 사이트는
기본 주소에서 www. 를 넣지 않고 쓰는걸요
그래도 한글파일 전혀 문제없이~
물론 주소창에서도 문제없이

모질라가 들어간주소가 아니라

http://????.??.??/팁

이런식으로 사용돼었을때요

404페이지를 index.html로 연결한다고 했을때

index.html에서 서버스크립으로

Request.ServerVariables("QUERY_STRING")를 가져오면

http://????.??.??/%C6%C1 이라고 나옵니다.

("팁"이란 글자가 어떠한 코드로 변형된것같은데..)

근데 저게 유니코드처럼 보이지만 유니코드가 아니란것이 ㅠ ㅠ

정체를 알수없는 글자셋입니다. ㅠ ㅠ

위에 답글다신분 말씀데로

앞에 www.를 붙여서 할경우엔

제대로된 유니코드로 나옵니다;;


거의 버그같은데

미치겠네여;

www. 붙이고 안붙이고는 상관없네여

IE랑 헷갈려서 실행했다는;;

뭘 어캐해도 =_= 이상한 유니코드가 나오네여

이거 대체 왜 ㅠ ㅠ

훙훙이 wrote: "팁" 이란 글자를 위에처럼 파폭에서 URL뒤에 넣을경우

"%C6%C1" 라고 나오는데요

유니코드로 "팁"은 "%ED%8C%81" 거든요...

자릿수가 짧은것이 어떤 형태인지 파악이 안되서요

%C6%C1은 '팁'을 EUC-KR로 나타낸 후 url-encode한 것입니다. '%ED%8C%81'은 '팁'을 UTF-8(유니코드가 아닙니다. 유니코드는 문자 집합의 이름이지 문자 인코딩의 이름이 아닙니다. 유니코드라는 문자 집합을 나타내는 방법은 UTF-8 말고도 UTF-16, UTF-32 등 몇 가지 더 있습니다.)로 나타낸 후 url-encode한 것이고요.

이런 것을 시험할 때에는 아무 글자나 가지고 하지 마시고, '가각'과 같이 코드표의 처음에 나오는 글자를 가지고 하셔야 따로 코드 변환을 하지 않고도 어떤 인코딩인지 쉽게 알 수 있습니다.

몇 가지 다른 경우가 있어서 헛갈릴 것입니다.

1. http://www.example.com/가각
라는 링크가 웹 페이지에 걸려 있으면 그 URL이 서버에 전달되는 방식은 'network.standard-url.encode-utf8'라는 preference의 값이 결정합니다. true이면 무조건 UTF-8이고, false이면 그 링크가 걸린 웹 페이지의 인코딩을 따릅니다. 내년에 나올 FF 3.0에서는 이 문제가 좀 정리가 될 것입니다. 관련 버그는 다음과 같습니다.

https://bugzilla.mozilla.org/show_bug.cgi?id=261929#c37 (그 근처 다른 커멘트)
https://bugzilla.mozilla.org/show_bug.cgi?id=320807
https://bugzilla.mozilla.org/show_bug.cgi?id=284474

2. 같은 주소를 주소창에 직접 입력했을 때
기본적으로 UTF-8로 보냅니다. 그런데, 유독 mozilla.or.kr에 보낼 때만 좀 이상하군요. 서버 로그를 볼 수 없으니 자세한 것은 모르겠습니다. (어쩌면, 아래에 언급한 fileiri 모듈이 설치되어 있어서 UTF-8로 들어 오는 것을 서버에서 사용하는 EUC-KR로 자동 변환하기 때문인지도...)

이럴 때 서버측에서 할 수 있는 일 :

1. UTF-8이라고 가정하고 변환해 본다. 유효한 UTF-8[1]이고 그 path에 해당하는 리소스가 있으면 그렇게 처리한다.
2. 1이 실패하면 다음 후보 인코딩이라고 가정하고 시도해 본다. 한국어 웹 사이트라면 후보는 EUC-KR이나 Windows CP949이겠지요.

Apache 2.x용으로 나온 fileiri 모듈이 비슷한 일을 합니다. 다른 웹 서버라면 서버측 프로그램에서 비슷한 일을 하면 되겠지요.
http://www.w3.org/2003/Talks/0904-IUC-IRI/Overview.html


[1] http://www.w3.org/International/questio ... orms-utf-8

Mozilla Hacker 답변 감사합니다.

그런데 제가 좀 알아듣지를 못하겠네여 ㅠ ㅠ

윈도우 서버이고 ASP를 사용중인데

어떻게 해결을 해야하나여... ㅠ ㅠ

Windows에서 IIS를 쓰신다면 IIS는 url-encode된 path 부분을 UTF-8로 여기니까 <http://www.foo.com/%B0%A1>은 페이지가 없다고 나오겠지요. 이 404 에러 페이지를 별도의 서버측 프로그램에서 가로채서 (시험용으로 하셨던 것처럼) 다음과 같이 하시면 되겠네요. 이미 IIS가 1에서 3까지는 이미 한 상태이니까 4만 하시면 되겠군요.

1. %C6%C1을 url-deocde를 하면 0xc6 0xc1이 되죠?

2. 이게 유효한 UTF-8 문자열인지 검사합니다.

3. 유효하면 UTF-8로 간주해서 그런 리소스가 서버에 있는지 검사해 보고 있으면 제공합니다.

4. 2에서 유효하지 않은 것으로 판정이 되거나 3에서 그런 리소스(그런 웹 페이지)가 없다는 결과가 나오면 0xc6 0xc1을 EUC-KR 혹은 Windows-949 (통합 완성형)으로 간주해서 다시 처리를 합니다. 즉, 0xc6 0xc1을 EUC-KR이나 CP949로 간주하고 이 바이트 열을 현재 서버측 프로그램에서 사용하는 인코딩(UTF-8)으로 변환한 후 그 다음 작업을 진행합니다.

완벽하지 않지만, 대부분의 경우 잘 동작합니다.

서버쪽 스크립트로 decodeURI를 이용해서

try로 에러 캐치를 해가지구

글자셋상태를 확인해서

asp에서 euc-kr을 디코딩하는 방법으로 해결했습니다.

알갱이님 감사합니다 ^^

빛알갱이 wrote:2. 같은 주소를 주소창에 직접 입력했을 때
기본적으로 UTF-8로 보냅니다. 그런데, 유독 mozilla.or.kr에 보낼 때만 좀 이상하군요. 서버 로그를 볼 수 없으니 자세한 것은 모르겠습니다. (어쩌면, 아래에 언급한 fileiri 모듈이 설치되어 있어서 UTF-8로 들어 오는 것을 서버에서 사용하는 EUC-KR로 자동 변환하기 때문인지도...)

네 맞습니다. mozilla.or.kr 의 경우 서버가 euc-kr 이기 때문에 utf-8 로 들어오는 URI 를 euc-kr 로 변환 시킵니다. 이는 프로그램들에서 이런 문제를 처리해 주지 못하는 경우가 많기 때문에, 서버에서 강제로 설정을 하는 거죠. 현재 mozilla.or.kr 의 서버에서 apache mod_url module 이 작동하고 있습니다. mod_url 의 방식에 대해서는 말들이 많기는 한데, 이보다 뾰족하고 광범위하게 모든 프로그램들을 만족시킬 수 있는 모듈은 현재 찾기가 쉽지 않기 때문입니다.

김정균 wrote: 네 맞습니다. mozilla.or.kr 의 경우 서버가 euc-kr 이기 때문에 utf-8 로 들어오는 URI 를 euc-kr 로 변환 시킵니다. 이는 프로그램들에서 이런 문제를 처리해 주지 못하는 경우가 많기 때문에, 서버에서 강제로 설정을 하는 거죠. 현재 mozilla.or.kr 의 서버에서 apache mod_url module 이 작동하고 있습니다. mod_url 의 방식에 대해서는 말들이 많기는 한데, 이보다 뾰족하고 광범위하게 모든 프로그램들을 만족시킬 수 있는 모듈은 현재 찾기가 쉽지 않기 때문입니다.

위에서 언급한 mode_fileiri와 어떤 점에서 다른가요?
원래 박원규님이 Apache 1.x용으로 만든 mode_uri는 EUC-KR과 UTF-8만 처리할 수 있었습니다. (W3C의 Durest한테 이에 대해서 알려 주었습니다. 그가 2003년 유니코드 컨퍼런스에서 fileiri module에 대해 발표할 때 reference에 넣어 두었군요. 위에 그 링크는 있습니다). 제가 마지막으로 본 mode_uri는 fileiri에 비해 단순했는데, 그 뒤에 apache 2.x용으로 (정균님이) 이식하면서 기능 보강이나 변화가 있었나요?

빛알갱이 wrote:

김정균 wrote: 네 맞습니다. mozilla.or.kr 의 경우 서버가 euc-kr 이기 때문에 utf-8 로 들어오는 URI 를 euc-kr 로 변환 시킵니다. 이는 프로그램들에서 이런 문제를 처리해 주지 못하는 경우가 많기 때문에, 서버에서 강제로 설정을 하는 거죠. 현재 mozilla.or.kr 의 서버에서 apache mod_url module 이 작동하고 있습니다. mod_url 의 방식에 대해서는 말들이 많기는 한데, 이보다 뾰족하고 광범위하게 모든 프로그램들을 만족시킬 수 있는 모듈은 현재 찾기가 쉽지 않기 때문입니다.

위에서 언급한 mode_fileiri와 어떤 점에서 다른가요?
원래 박원규님이 Apache 1.x용으로 만든 mode_uri는 EUC-KR과 UTF-8만 처리할 수 있었습니다. (W3C의 Durest한테 이에 대해서 알려 주었습니다. 그가 2003년 유니코드 컨퍼런스에서 fileiri module에 대해 발표할 때 reference에 넣어 두었군요. 위에 그 링크는 있습니다). 제가 마지막으로 본 mode_uri는 fileiri에 비해 단순했는데, 그 뒤에 apache 2.x용으로 (정균님이) 이식하면서 기능 보강이나 변화가 있었나요?

이식을 하면서 기능이 보강된 것은 없고, 2.0 이식 이후에, Client 문자셋과 서버 문자셋을 지정할 수 있도록 변경이 된거죠. 예전 버전은 무조건 utf8 -> euc-kr 변환이었으니까요. (물론 이 기능은 1.3 용 모듈에도 적용이 되었고요.)

현재 버전은 다른 언어도 가능하다는 점만 다릅니다.

그리고, mozilla.or.kr 의 apache 1.3 으로 작동하고 있습니다.