Отсылка письма в японской кодировке.

← →
pusrg (2006-01-16 20:10) [0]

Всем доброго времени суток!

Помогите разобраться в следующей проблеме:
Небольшая предистория: дорабатываю mail-клиент для заказчика-японца. До моих доработок в программе корректно использовались две кодировки для отсылаемых писем: iso_2022_jp - для японских символов и
us_ascii - для латинских.

По требованию заказчика пришлось ввести ряд новых популярных кодировок (планируется продавать программу по всему миру). Среди них, две новые для японских символов: shift_jis и euc_jp. С ними то и возникла проблема:
Письма в этих кодировках отсылаются нормально. Но при приеме их Outlook-ом или Outlook-Express-ом, если в принимаемом письме установлена такая же кодировка как и при отсылке все японские символы заменяются на кракозяблы :(. Интересный факт, если в принятом письме установить кодировку "японская(автовыбор)", то все символы отображаются корректно. Но заказчика естественно это не
устраивает :(.

В чем может быть проблема? Программа "Получатель" некоректно распознает мои письма или мой клиент неверно формирует содержимое? Возможно перед отсылкой необходима перекодировка символов?

Ниже я привожу два урезанных листинга заголовков принятых писем в Outlok. Из листингов удалена информация о промежуточных узлах передачи:
1. Это листинг заголовка отосланного разрабатываемым клиентом (японские символы отображаются некорректно):
From: "PUSRG" <pusrg@rambler.ru> Subject: JPN_NEW To: testindy@rambler.ru Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="shift_jis" Date: Mon, 16 Jan 2006 00:39:10 +0900 MIME-Version: 1.0 Message-ID: <200601160039100947.9878F4B8801BF6062E4ED09BE36A5864@pop3.rambler.ru> X-Mailer: MailMagicPro 3.5 In-Reply-To: <200601160039100947.9878F4B8801BF6062E4ED09BE36A5864@pop3.rambler.ru> X-Auth-User: pusrg, whoson: (null)

2. Это листинг заголовка отосланного Outlook (японские символы отображаются корректно):
From: "Pusrg" <testindy@rambler.ru> To: <testindy@rambler.ru> Subject: FW: OutLook Send Date: Mon, 16 Jan 2006 00:52:41 +0900 Message-ID: <FCEHKJJIMGBBBBGEDNDCOEABCAAA.testindy@rambler.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="shift_jis" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Auth-User: testindy, whoson: (null)

Как я понимаю, проктически полная идентичность за исключением уникальной информации.

P.S.
Используемые компоненты - Инди 10. Среда разработки - Билдер 5 (К сожалению, т.к. гораздо больше привык к Делфи). Такой факт - чтобы установить эти компоненты на Билдер пришлось немного пошаманить
с дефайнами в среде и создать свои файлы пакетов, т.к. на родном сайте в начале октября прошлого года пакетов для билдера еще не было, только делфийские... Сейчас возможно уже появились пакеты для
билдера, но пользуюсь пакетами из оригинальной сборки, т.к. общая функциональность по отсылке писем работает нормально. Да и врядли моя сборка могла повлиять на кодировку отсылаемых писем.

Заранее благодарен за содействие и любые полезные советы и ссылки.
С уважением,

← →
Rem © (2006-01-16 21:51) [1]

Content-Type: text/plain;
charset="shift_jis"

1. Перед Charset должен стоять WSP.
2. Возможно, баг где-то при преобразованиях String <-> WideString

Используемые компоненты - Инди 10

Перед этими компонентами бессилен сам Борланд.

← →
pusrg (2006-01-17 03:08) [2]

To Rem © (16.01.06 21:51) [1] .
Большое спасибо за Ваш ответ.

Но простите мне мою серость, что такое "WSP" в пункте 1?
Ничего лучше чем WideString Pascal, я придумать не мог :).
Посмотрел документацию по формату электронного письма на
http://web.opennet.ru/docs/RUS/mime_rfc/index.html
там тоже ничего подобного не нашел.

По второму пункту, я так понял, что есть вероятность, что глючат Инди?
Я никаких преобразований не выполняю, просто заношу текст письма с помощью assign в св-во TIdMessage->Body. Если быть точным, то этот код уже существовал, до того как я взялся за проект.

← →
Verg © (2006-01-17 07:33) [3]

WSP - White SPace

charset - это атрибут поля Content-Type, а не отдельное поле.
Поля начинаются с символа в новой строке. Если же в новой строке продолжение значения поля, то эта строка должна начинаться с пробела (WSP).

Content-Type: text/plain; charset="shift_jis"

или

Content-Type: text/plain;
charset="shift_jis"

← →
Verg © (2006-01-17 07:34) [4]

вот, между прочим, пробел перед charset съелся форумом.

← →
pusrg (2006-01-17 12:52) [5]

Verg © (17.01.06 07:33)
Большое спасибо за Ваш ответ.

Пробел у меня в листинге стоит (он тоже "съелся" форумом). Причем я пробовал оба варианта формирования письма, указанных Вами (charset в одной строке и charset в разных строках с Content-Type), но к сожалению это никак не повлияло на решение проблемы :(.

Не знаю, как в Builder. Как известно, в Visual C++ проблемы с юникодом устраняются на этапе препроцессинга определением #define UNICODE, опосля чего происходит разрешение TCHAR в wchar, но TCHAR-ы я ненавидел всю свою сознательную жизнь и поэтому использовал BSTR, bstr_t и CComBSTR - эти классы не зависят от упомянутого дефайна и всегда работают с двухбайтовыми символами. Насколько я знаю, в Builder дела с юникодом обстоят много хуже и предлагаемый борландом тип WideString просто-напросто выполняет работу по транслированию юникодовых строк в ANSI текущей кодовой страницы.

Заканчиваю мысль: мне кажется, нужно попробовать преобразовать строку, содержащую тело сообщения, в байтовый массив и записать этот массив в тело сообщения.
Другая причина некорректного распознавания кодировки может быть в том, что Outlook не находит какой-нибудь хитрый маркер юникода, который должен предшестовать телу сообщения.

Отсылка письма в японской кодировке. Найти похожие ветки