Mozilla 한국 커뮤니티

안녕하세요 오늘 처음으로 Thunderbird를 쓰기 시작한 초보 유저 입니다.

아직은 익숙해지지 않았지만 기본적인 사용은 쉬운 것 같아서 다행이네요


OE에서 메일 몇개를 가져오기로 받아 놓았는데요

다른 메일들은 모두 괜찮은데 한 사이트에서 보내온 두개의 메일만 이상하게 글자가 깨져 보입니다.

보기->문자 인코딩->한국어(EUC-KR)

옆에 기본적으로 체크 되어 있습니다만 메일을 처음 클릭하면 깨져 보입니다.

메일을 보고 있는 화면에서 다시 인코딩을 체크 해 주면 예쁘게 원래 글들이 보입니다.

처음 체크 되어 있었던 것이 사실은 그런게 아니었단 말일까요

WindowsXP SP1을 쓰고 있고 Thunderbird 0.7.3한글판입니다.

의견이나 충고 부탁드립니다

Wannabana wrote: OE에서 메일 몇개를 가져오기로 받아 놓았는데요

다른 메일들은 모두 괜찮은데 한 사이트에서 보내온 두개의 메일만 이상하게 글자가 깨져 보입니다.

보기->문자 인코딩->한국어(EUC-KR)

옆에 기본적으로 체크 되어 있습니다만 메일을 처음 클릭하면 깨져 보입니다.

메일을 보고 있는 화면에서 다시 인코딩을 체크 해 주면 예쁘게 원래 글들이 보입니다.

보통 제목이나 Form/To 의 경우에는

=?EUC-KR?B?t6+zysTauK6+xiDIqMH2seI=?=

와 같은 식으로 됩니다. 즉 처음의 EUC-KR 은 charset, 다음의 B 는 base64 인코딩을 의미하며, 나머지는 B(base64) 로 인코딩된 문자열 입니다. ? 는 구분자입니다.
보통 메일러에서는 이것을 판단하여 charset 을 변환해서 보여주게 됩니다.

그리고 본문의 경우 multi-part 메일일 경우 각 파트마다 charset 과 mime-type 을
받아서 파싱을 하게 됩니다. 단일 파드일 경우에는 헤더에서 이 정보들을 가져 옵니다.

즉, charset 이 지정이 되어 있을 경우에는 이 charset 으로 파싱을 하는 것이고, 지정이 되어 있지 않을 경우에는 프로그램 설정에서 지정한 default charset 으로 변환을 하게 됩니다.

문제가 되는 경우라면, charset 이 엉뚱하게 지정이 되어 있을 경우가 있고,
프로그램의 default charset 구현 쪽에 버그가 있을 수 있으며, 간혹,
base64 인코딩이 RFC 규약에 맞지 않게 인코딩 해서 보냈을 경우 파싱 과정에서 깨지게 될 수도 있습니다. (이건 저도 확인한 바는 아니지만, 제가 예전에 웹메일 만들때 경혐해본 바에 의해 프로그램에서 예외 처리를 해 주지 않을 경우 가능한 일이라는 겁니다. 천둥새의 코드를 본적이 없으니 천둥새가 잘 해 주고 있는지 아닌지는 저로서 판단할 근거는 없습니다.)

답변 감사드립니다 (__)

김정균 wrote: 보통 제목이나 Form/To 의 경우에는

=?EUC-KR?B?t6+zysTauK6+xiDIqMH2seI=?=

와 같은 식으로 됩니다. 즉 처음의 EUC-KR 은 charset, 다음의 B 는 base64 인코딩을 의미하며, 나머지는 B(base64) 로 인코딩된 문자열 입니다. ? 는 구분자입니다.
보통 메일러에서는 이것을 판단하여 charset 을 변환해서 보여주게 됩니다.

제목도 인코딩을 정할수 있는 것이었군요 일본어로 된 편지들을 가끔 받으면 본문은 인코딩을 알아서 하던데 제목은 거의 깨져서 보이더라구요 보낸쪽이 잘못 보낸 거라고 생각할 수 있겠네요

김정균 wrote: 그리고 본문의 경우 multi-part 메일일 경우 각 파트마다 charset 과 mime-type 을
받아서 파싱을 하게 됩니다. 단일 파드일 경우에는 헤더에서 이 정보들을 가져 옵니다.

즉, charset 이 지정이 되어 있을 경우에는 이 charset 으로 파싱을 하는 것이고, 지정이 되어 있지 않을 경우에는 프로그램 설정에서 지정한 default charset 으로 변환을 하게 됩니다.

multi-part 메일이 무엇인지는 잘 모르겠지만 몇 개 소스 보기를 해 보았더니
Content-Type: multipart/mixed;
이렇게 되어 있는 것이 있던데 이걸 말씀 하시는 걸지도 모르겠네요
문제의 메일은 아래쪽과 같이 되어 있던데요
Content-Type: text/html; charset=EUC_KR
Content-Transfer-Encoding: 8BIT
이렇게 되면 왠지 한국어로 잘 인코딩 해줘야 할 것만 같네요 @_@

김정균 wrote: 문제가 되는 경우라면, charset 이 엉뚱하게 지정이 되어 있을 경우가 있고,
프로그램의 default charset 구현 쪽에 버그가 있을 수 있으며, 간혹,
base64 인코딩이 RFC 규약에 맞지 않게 인코딩 해서 보냈을 경우 파싱 과정에서 깨지게 될 수도 있습니다. (이건 저도 확인한 바는 아니지만, 제가 예전에 웹메일 만들때 경혐해본 바에 의해 프로그램에서 예외 처리를 해 주지 않을 경우 가능한 일이라는 겁니다. 천둥새의 코드를 본적이 없으니 천둥새가 잘 해 주고 있는지 아닌지는 저로서 판단할 근거는 없습니다.)

문제는 천둥새가 힘내서 잘 해주고 있는거 같은데 저 메일만 왜그럴까라는 고민 정도예요 @_@
사실 제가 드리는 정보들이 거의 겉에서 보고 그냥 안된다는 거 밖에 없어서 정확한 이유를 찾아주시기가 힘든거 같아요
답변 감사드려요 ^^

바보같은 문제였네요 @_@

Wannabana wrote: Content-Type: text/html; charset=EUC_KR
Content-Transfer-Encoding: 8BIT

위에 있듯이 EUC-KR 이 아닌 EUC_KR 이라고 적혀 있어서 그랬던 거네요 ;;

_ 를 - 로 제대로 고치거나 아예 저 부분을 지우거나 하면 제대로 나와요 ^^

메일 보낸 사이트에 말해 두어야겠네요~

만약 charset 부분이 없을 경우에는 default charset 으로 인코딩을 잘 하고 있는 것 같지만 위와 같이 틀린 charset 이라면 왜 default charset 으로 인코딩을 하지 않을까요.
깨져서 보인다는 말은 무언가 다른 charset 으로 알아서 인코딩을 해서 보여주고 있다는 말인 것 같은데 그게 왜 default charset이 아니고 무언가 다른 charset 으로 할까요 ;;