트랙백

• 태터툴즈 고쳐쓰기 #11 - UTF-8 RSS 읽기, 트랙백 보내기 - CRIZIN+

코멘트

1. 2005년 4월 2일 오후 8시 23분, H.Moon 작성:

와, UTF-8 사용 환영합니다.
저는 MT에서 WP로 이어지며서 본의 아니게 계속 UTF-8을 사용하고 있었는데, 이젠 제발 신경 안쓰고 트랙백, RSS 자유롭게 사용했으면 좋겠습니다.

# 2005년 4월 2일 오후 8시 31분, likejazz 작성:

저도 트랙백때문에 UTF-8 변경을 그간 주저해왔습니다만 트랙백이 깨질경우 최신의 수작업머신으로 수정하기로 합의보았습니다. 다국어를 자유로이 볼수있는 꿈의환경을 위해서 그정도 고생쯤이야 새발의 껌 아니겠습니까.

2. 2005년 4월 2일 오후 9시 23분, ari 작성:

rss 인코딩이 정상적인지 한번 확인해주시기 바랍니다. 제 rss 리더에서 다른 utf-8 인코딩의 rss들을 모두 제대로 처리하고 있습니다만, likejazz님의 rss만 제대로 처리가 안되고 있습니다.
야후 블로그, 무버블 타입, nucleus, 워드프레스 등에서 utf8로 rss를 제공하는 것들을 모두 정상적으로 처리하고 있습니다.

3. 2005년 4월 2일 오후 9시 24분, ilovja 작성:

드디어 유니코드로 완전 이주하셨군요. 그간 제가 트랙백 인코딩 테스트를 할 때마다 늘 도와주셨음을 늦게 나마 감사드립니다.

4. 2005년 4월 2일 오후 11시 4분, crizin 작성:

태터툴즈 리더로 구독하고 있는 사람중 한명입니다 ^^

UTF-8 RSS만 제공하시는 분들이 요즘 늘어나서 간단하게 컨버터를 만들어 쓰고있었는데요 태터툴즈 리더를 쓰는 likejazz님 구독자분들 중에 혹시 도움이 되는분이 있을까 싶어 포스팅하고 트랙백 보냈습니다.

그보다도 UTF-8 트랙백 보내기를 추가하면서 제대로 동작하는지 테스트하는 목적이 컸는데 제목은 제대로 표시되네요;;

어서 태터툴즈도 UTF-8이 기본지원 됐으면 좋겠네요..

5. 2005년 4월 2일 오후 11시 26분, Tokigun 작성:

soojung은 RSS를 UTF-8과 EUC-KR로 둘 다 제공합니다. :) (정작 스킨에는 없지만... orz rss2.php 뒤에 ?charset=cp949를 붙이면 됩니다.)

6. 2005년 4월 2일 오후 11시 32분, 백일몽 작성:

최신의 handling machine 멋집니다. 효율이 떨어져서 그렇지.
그런데 다음 rss 에서는 잘 보이는데요.

7. 2005년 4월 3일 오후 2시 14분, ari 작성:

rss파일의 처음 3바이트에 이상한 문자가 포함되어 있습니다.
다른 utf-8로 인코딩된 rss들은 <?xml로 시작하고 있는데 likejazz님의 rss에서는 癤??xml 처럼 처음 3바이트가 깨져서 시작하고 있습니다. substr로 3바이트를 제외하고 읽으면 <?xml로 제대로 시작합니다.

8. 2005년 4월 3일 오후 2시 52분, yser 작성:

>rss파일의 처음 3바이트에 이상한 문자가 포함되어 있습니다.

Byte Order Mark 가 아닐까요 ^^;
emeditor 로 읽어보니, 맞군요. UTF-8 with signature.
BOM 처리는... 우움~ 지금의 rss 에선 없어도 되지 않나 싶은데, 처리하는 쪽에서 체크해서 있으면 그냥 무시하고 건너뛰면 될 듯. 다음 RSS 도 그걸 고려한 모양이군요.

# 2005년 4월 3일 오후 2시 56분, likejazz 작성:

UTF-8 문서에는 처음 2bytes 에 0xFF 0xFE 식별자가 들어가게되는데 asp, aspx 의 문서의 경우 asp.dll, aspnet_isapi.dll 을 거치며 이 식별자를 제외하고 보내주는데반해 xml 파일은 아무런 dll 을 거치지않는 static 문서이고 UTF-8 식별자까지 바디에 포함하여 전송하게 됩니다. 그러니까 최초 2bytes 에 불필요한 내용이 전송됩니다.

물론 클라이언트가 처음부터 UTF-8 로 인코딩하여 읽게되면 0xFF 0xFE 를 식별자로 인지하고 정상적으로 처리해주지만 cp949 가 기본인상태에서 받게되면 깨진문자열로 받게됩니다.

IIS 에서만 이런현상이 발생하며 아파치등에서는 이 식별자를 제거하고 보내주는걸로 보입니다.

해결책으로는 asp.dll, apsnet_isapi.dll 등의 통과를 통해 처리해주는 방법이 있는데 이 경우 xml 파일을 static 하게 가져간다는 본연의 취지에 어울리지 않는 문제가 있습니다.

예전에는 rss.xml 또한 asp 코드였습니다. 그래서 asp.dll 로 처리를 해주었고 Last-Modified 도 수동으로 처리해준적이 있습니다만 UTF-8 로 바꾸면서 rss.xml 을 미리 생성하여 보내는 진정한 형태의 static 으로 변경하였습니다.

여하튼 해당문제는 버그라기보다는 IIS 의 특징에 가까운것같습니다만 리포팅하고 추이를 지켜보도록 하겠습니다.

수고스럽겠지만 2bytes 에 0xFF 0xFE 가 들어올경우 식별자로 인지하도록 처리해주시길 부탁드립니다 ^^;

다행히도 블로그라인스나 다음RSS넷, planet 등에서는 정상적으로 처리해주고있네요.

# 2005년 4월 3일 오후 3시 1분, likejazz 작성:

yser 님 말씀대로 UTF-8 식별자가 맞습니다. 없어도 되는데 생성할때나 IIS 가 뿌려줄때나 모두 포함하여 보내게되어 발생하는 문제입니다.

아파치는 뿌려주지않는걸로 보이는데 미리 제거하고 뿌려주는걸로 보입니다. IIS 도 dll 을 통해 한번 걸러주면 뿌려주지 않습니다만 static 하게 바로(direct) 보내려다보니 이런 문제가 발생하네요.

9. 2005년 4월 3일 오후 3시 4분, yser 작성:

p.s
http://www.unicode.org/faq/utf_bom.html#22
ari님 요길 참조하세요.
(유니코드 사이트는 아무도 번역할 사람 없나.. ㅡㅡ; w3c 도 엄청나긴 하지만 요즘 시대엔 저 사이트도 필수일 듯 한데)

UTF-16 에서 U+FEFF 인 값을 UTF-8 로 인코딩 하면 3바이트의 나열이 된다..라고 합니다.

http://b.mytears.org/2005/01/13/byte-order/
bom 참조는 정태영 님의 글이 잘 정리되어 있군요 ^^;

음... 관심 있는 분들 모아서 문자셋/인코딩 튜토리얼이라두 만들어야 할텐데...
(재원은 조사중... kebil님 송효진님 김정균님 거친마루님 등등 -_- ..헉 스토킹??)

10. 2005년 4월 3일 오후 3시 4분, yser 작성:

헉스~ 빠른 피드백!! 고새 답글이 달렸군요. >>ㅑ~

11. 2005년 4월 3일 오후 3시 9분, yser 작성:

>IIS 에서만 이런현상이 발생하며 아파치등에서는 이 식별자를 제거하고 보내주는걸로 보입니다.

제가 아는 한도에서는, 아파치는 그걸 자동으로 해주지 않습니다. 만약, php 로 구동한다면 그 php 자체가 utf-8 인코딩 되어 있고, bom 포함해서 저장했다면, 출력시에 bom 도 고스란히 출력됩니다. 왜냐면 php 파일 시작 <?php 이전에 이미 bom 이 들어가 버리거든요. 그래서 setcookie 같은 header 보내는 함수 쓰면 이미 나갔다고 에러 내죠 ^^; asp 는 자동으로 제거하는가 보군요..

해결법은 emeditor 같은 에디터로 utf-8 without signature 로 저장하면 bom 을 쏙 빼고 저장합니다. 다른 cpu 간의 해석 차를 방지하는 목적인데 이게 은근히 문제가 되요..

# 2005년 4월 3일 오후 3시 13분, likejazz 작성:

yser 님 감사합니다. 그런데 유니코드 페이지는 안그래도 글자가 많은데다 폰트또한 상당히 읽기가 부담스럽네요 ^^

12. 2005년 4월 3일 오후 3시 13분, yser 작성:

쓰고보니 아파치2 에선 안해봐서 모르겠는데 어쩌면 설정에 따른 것일 수도 있겠다 생각이 듭니다. 아파치도 자동으로 제거해 줄지도.. ^^;

13. 2005년 4월 3일 오후 3시 59분, Tokigun 작성:

생각해 보니까 UTF-8에 쓸데 없이 BOM 넣어 주는 notepad.exe 같은 게 좀 짜증나죠. (UTF-8에는 Endian이라는 구분 자체가 없는데 -_-;) 물론 UTF-8에서는 BOM을 무시해야 정상입니다. (U+FEFF랑 U+FFFE 둘 다)

14. 2005년 4월 3일 오후 4시 8분, ari 작성:

byte-order mark라는 것이었군요. 알려주신 likejazz, yser님 감사드리고 제 리더는 수정했습니다.

# 2005년 4월 3일 오후 4시 14분, likejazz 작성:

ari님 감사합니다 ^^

15. 2005년 4월 4일 오전 7시 29분, yser 작성:

Tokigun//

UTF-8 is byte oriented and therefore does not have that issue. Nevertheless, an initial BOM might be useful to identify the datastream as UTF-8.

라는군요 ^^; utf-8 에 bom 이 별 필요 없다는 얘기는 다른 분에게도 들은 적이 있는데.. 포함해주면 명시적으로 알기는 쉽겠네요. 지금으로선 전통적으로 charset 표시해주면 좋지만 안해주면 추측을 해야하니..

16. 2005년 4월 4일 오전 11시 14분, wafe 작성:

UTF-8에는 BOM이 필요하지는 않지만, MS에서 만든 에디터들은 UTF-8 무서라는 것을 확실히 구분하기 위해서 UTF-8 BOM을 문서 앞에 삽입합니다. 이게 없으면 UTF-8 문서인지 아닌지 판단하기 위해서 파일 내용을 전부 읽어보아야 하는데... BOM이 없어도 잘 판단해주기는 하더군요.

off topic 이지만 Panther의 TextEdit이 텍스트 파일을 열었을 때 UTF-8 인코딩인지 아닌지 자동으로 판단을 못하는 게 너무 불편하더군요. 이것만 잘되면 참 좋을텐데 말이죠.