1 gendoh이 작성한 주제

  • gendoh
  • 육종학자
  • 오프라인
  • 가입일자 2006-04-05
  • 글: 625

주제: newMediaObject 문제

http://www.sixapart.com/developers/xmlr … bject.html

왜이렇게 멍청한 짓을 하였는지 모르겠습니다만 base64 encoding을 xml rpc 레이어가 아닌 어플레이케이션 레이어에서 한 후  스트링으로 보내는 만행이 표준이군요. 허나 지금까지 프로그램들이 잘 동작해 온것을 보면 당연히 바이너리 파일은 base64 타입으로 자동적으로 보내져 온것으로 보이고;;; (아무튼 이동네 api들은 좀 웃기는)

아무튼 표준적으로는 string으로 올때 이것을 base64_decode 하는 것이 정상일것 같습니다만, base64로 인코딩 되어 온것을 지원 안할수도 없고. 문제는 xml-rpc 레이어에서 자동으로 처리되는지라 api 처리 루틴에서 이게 string으로 왔는지 base64로 왔는지 알 방법이 없다는 것.

textcube 전 버전과 tistory가 이 버그를 가지고 있군요.

아이디어 생각나시는분?

http://www.tistory.com/forum/viewtopic.php?id=1129
http://www.cybervill.net/entry/루비에서-티스토리로의-글-포스팅

gendoh의 웹사이트

2 crizin이 작성한 답글

  • crizin
  • 정원사
  • 오프라인
  • 가입일자 2006-04-18
  • 글: 90

답글: newMediaObject 문제

다른애들 어떻게 하나 봤는데 Movable Type도 표준대로 안하고 받은 그대로 저장하네요 (이놈들 뭐임;)

Wordpress도 마찬가지고 제로보드XE가 저장하기전에 무조건 decode 하더군요

XMLRPC 클래스랑 다 뜯어고치면 둘다 처리할수야 있겠지만 그래야 하나라는 생각이..

ps. http://www.xmlrpc.com/metaWeblogNewMediaObject 근데 이거 보면 지금처럼 하는게 맞는거같기도 한데요

crizin (2008-02-21 20:00:47)에 의해 마지막으로 수정

crizin의 웹사이트

3 nineclue이 작성한 답글

  • 가입일자 2008-02-21
  • 글: 4

답글: newMediaObject 문제

"type" 변수로 MIME type을 살펴보고 text가 아닌데 base64 인코딩에 따르면 decode를 하는 것이 가장 맞지 않나 생각합니다.

현재 사용중인 mephisto란 툴에서도 decode를 하지 않고 그냥 저장하더군요. 그런데 티스토리의 경우 인코딩을 하지 않은 이진파일을 보내도 제대로 동작하지 않습니다. ruby 1.8에서는 url까지 받아오지만 이미지로 인식하지 못하는 것 같고 1.9에서는 에러가 발생합니다. python 2.5로 시험해 보았는데 이진파일을 그대로 보내니 오류가 발생했습니다.

아무래도 xmlrpc 처리에 언어나 버전에 따른 호환성 차이가 있는게 아닐까 싶습니다. base64 encoding한 상태로 보내는 것이 아무래도 표준에 맞지 않을까요.

nineclue (2008-02-21 21:56:23)에 의해 마지막으로 수정

4 nineclue이 작성한 답글

  • 가입일자 2008-02-21
  • 글: 4

답글: newMediaObject 문제

Creorix 작성:

1. Six Apart측 문서를 살펴보면 "The type key (media type of the file) is currently ignored."라는 표현이 있는데 이 때문에 MIME type이 포함되지 않고 전송되는 경우 판단이 불가능합니다.

2. 만약 type이 포함된다고 해도 text file이 base64로 encoding되어 <string> 타입으로 전송되는 경우에 문제가 발생할 수 있습니다. 이 경우에 XMLRPC 컴포넌트에서는 string 타입이니까 decode를 하지 않고, 어플리케이션 측에서는 text file이니까 decode를 하지 않아서 결과적으로 decode되지 않고 저장되게 됩니다.

그냥 base64 인코딩을 체크하기에는 너무 일반적인 문자들(alphabet)로 이루어져 있어서 이 또한 문제가 있을것 같고 =_=

두 가지 경우 모두를 처리하려면 컴포넌트를 뜯어고치는수밖에 없을듯 싶습니다만 ;;

제가 생각하지 못했던 부분이 있었네요.

먼저 SixApart측 문서가 표준이라면 decoding을 하는 것이 맞다고 생각합니다. 그리고 MIME type을 무시하는 것을 전제로 한다면 사실 encoded string과 non-encoded string을 구분할 수 있는 방법이 없을 것 같습니다만... 컴포넌트를 어떻게 고치더라도 불가능한 일이 아닐까요.

함수의 이름이 newMediaObject인점, 압축하지 않은 text 파일을 blog 문서에 첨부할 일이 얼마나 있을까를 고려할때, 그리고 decoding을 하는 것이 표준이라면 decoding을 하지 않은 경우를 골라내는 것이 가장 현실적인 판단이 아닐까 싶습니다.

적어도 ruby, python (2.5)에서는 encoding하지 않은 파일을 올리는 것이 불가능한것 같으니 어떻게든 가능한 방향으로 수정이 되면 좋겠습니다. roll

5 nineclue이 작성한 답글

  • 가입일자 2008-02-21
  • 글: 4

답글: newMediaObject 문제

한가지 또 배웠습니다.

이론적으로는 구현상의 문제가 되겠네요. 하지만 gendoh님의 SixApart 링크를 보면 XML파일의 샘플에 bits
의 type이 string으로 되어 있습니다. 거기다가 type도 포함되어 있지 않구요. string으로 들어와 버리면 정말 구분할 수 있는 방법이 없을것 같습니다만... 이런건 설계상의 문제인가요?

그렇다면 xmlrpc 레이어에서의 처리, string 형식이라도 type이나 name의 확장자가 이진파일일 경우 문자열이라면 decoding을 하는 것이 나름 최선의 방법이 아닐까요... neutral

nineclue (2008-02-22 08:59:56)에 의해 마지막으로 수정

6 nineclue이 작성한 답글

  • 가입일자 2008-02-21
  • 글: 4

답글: newMediaObject 문제

네, 일단 구현에 대한 것은 고수님들께 맡기고 저는 일단 ruby나 python에서 base64로 보내는 방법을 알아봐야 되겠습니다. smile

base64로 보내니까 문제없이 잘 저장되는군요. 저장하는 방법은 알았는데, 태터나 티스토리를 고칠지 말지는 다시 고수님들께... wink

nineclue (2008-02-22 12:15:33)에 의해 마지막으로 수정