van_grieg
Исходник письма мне нужен затем же, что и, наверное тебе:
- смотреть, в чем проблема, если письмо отображается неправильно (решение проблем кодировок с конкретным почтовиком),
- смотреть, как построено само письмо (в образовательных целях),
- просто любопытно,
- и др.
Но даже если бы мне лично это не надо было, то разве это правильная постановка вопроса? Получается примерно такая логика диалога:
1. Доказать, что Opera все делает правильно, в отличие от других почтовиков.
2. Если не получилось (1), то доказать, что пользователю данная фича не нужна.

То, что в приниципе нормальный просмотр исходника нужен (по крайней мере тестерам), ты же не будешь спорить?
А в качестве примера для подражания можно взять Thunderbird (там, как я уже говорил, можно выбирать кодировку при просмотре источника).

Сейчас заметил, что в opera.russian идет обсуждение на эту же тему. Важные момент, который там упоминается, и о котором я еще не сказал: при передаче исходника через буфер обмена нет никакой уверенности в том, что таким образом удастся получить неискаженную последовательность байт письма. Ведь факт, что сброс в буфер и выброс оттуда связан с преобразованиями содержимого, которые к тому же зависят от внешних факторов, напр. от текущей раскладки клавиатуры (точнее: от input language).

Сами разработчики Оперы, интересно, каким методом пользуются?


-------------------

В ответ на:
Вставляем точку с запятой в название файла и получаем
Content-Disposition: attachment; filename=im; age.jpg

В ответ на:
- смотреть, в чем проблема, если письмо отображается неправильно (решение проблем кодировок с конкретным почтовиком),

В ответ на:
Получается примерно такая логика диалога

Может хватит мне приписывать логику, которой я не пользуюсь? Я спросил зачем тебе это нужно потому, что может вместо обсуждения кодировки дампов стоит избрать другой способ для достижения твоих целей?

Для того, что ты перечислил, нужен как раз тот способ, который делает Опера. Им разработчики и пользуются. Вот куда они потом это копируют - другой вопрос.

В ответ на:
А в качестве примера для подражания можно взять Thunderbird

А вот этого не надо. Возможно, именно это TB делает удобней. Но насколько это важная фича? Чего, кроме удовлетворения любопытства, можно ей добиться? Для дебаггинга нужен "чистый" дамп, а не удобочитаемый.

В ответ на:
Я пробовал делать тесты из OE и M2.

Ты OE в качестве правльно работающего почтовика приводишь? Он еще получателей разделяет точкой с запятой, символом, зарезервированным для групп. Из-за чего нормально пользоваться группами невозможно. Или например русские названия файлов неправильно кодирует. И кодировку писем не всегда указывает. И еще страницы на три можно привести примеров.

В ответ на:
Сейчас заметил, что в opera.russian идет обсуждение на эту же тему.

В ответ на:
Мне просто один человек постоянно шлет сканы документов, сделанные в "MS Office Document Scanning", так там такой формат имени файла:

Ну так пиши багрепорт в Майкрософт. Или, если считаешь, что ОЕ в данном случае ведет себя правильно, в Оперу.

В ответ на:
Пусть пока нельзя сохранить все вложения за один раз (или уже есть метод?)

В ответ на:
Опера выдает "The file is being written to, choose another filename" и не дает сохранять.

В ответ на:
может быть можно сделать, чтобы хоть это окно Transfers каждый раз не активизировалось?

В ответ на:
для этого нужен дамп письма, а не перекодированный прилизанный вариант

Так ведь в том варианте, о котором я говорю (просомтр источника с выбором кодировки) никакого искажения последовательности байт (= дамп)письма не происходит!

Выбор кодировки есть выбор варианта сопоставления числу (байту) графического образа (символа). И все.

Ньюансы могут заключаться тольков том, что символу будет соответствовать не один байт, а несколько (Unicode и его UTF-реализации).
И все это используется только потому, что нам, людям, графические образы воспринимать проще, чем цифры.
(Я понимаю, что ты это понимаешь, просто пишу с рачетом на то, что и другие будут это читать.)

Насчет "логики диалога" - шутка, конечно
А насчет того, куда разработчики этот дамп письма вставляют и почему они его прямо в Опере не смотрят - мне тоже интересно.

Хорошо, может OE далеко не все правильно делает, но считать с ним приходится в силу его распространенности. Кстати, а какой мейлер можно рассматривать в качестве примера (относительно) правильной реализации стандартов?

В ответ на:
в opera.russian ... приводится способ экспорта, который приведет к результатам, которые тебе нужны, насколько я понимаю.

Ты имеешь ввиду помещение письма в отдельный AP и экспорт оттуда в .MBX ?

Баг-репорт по поводу ";" в именах аттачей написал. В Оперу

"The file is being written to, choose another filename" - легко воспроизводится по моему описанию. Другое дело, что на такую мелочь можно просто закрыть глаза.

"Show transfers page on new transfer" - спасибо, уже удобнее.

В ответ на:
Если Raw copy из М2 вставить в EmEditor, то русские текст показывается нормально.

В ответ на:
А насчет того, куда разработчики этот дамп письма вставляют и почему они его прямо в Опере не смотрят - мне тоже интересно.

В ответ на:
OE далеко не все правильно делает, но считать с ним приходится в силу его распространенности.

В ответ на:
Кстати, а какой мейлер можно рассматривать в качестве примера (относительно) правильной реализации стандартов?

Не знаю.

В ответ на:
"The file is being written to, choose another filename" - легко воспроизводится по моему описанию.

В ответ на:
У меня две раскладки - немецкая и русская, system locale - cyrillic (Win-1251), Win XP Pro en SP2.

В ответ на:
Баг-репорт по поводу ";" в именах аттачей написал. В Оперу

А теперь пиши в Майкрософт. Твой багрепорт - RESOLVED INVALID, как и следовало ожидать.

В ответ на:
Воспроизведение "The file is being written to, choose another filename"

В ответ на:
Может, у тебя EmEditor настроен по молчанию на Win-1251?

В ответ на:
"багрепорт - RESOLVED INVALID": что это означает

В ответ на:
И как мне найти мой баг-репорт?

"Файл нормально сохраняется" - странно, почему же у меня - нет? Opera 7.54.

Надо будет попробовать более новый EmEditor, может, там автоопределение кодировок?

Т.е. ты можешь видеть этот баг-репорт, т.к. являешься официальным тестером? Если да, то есть ли возможность им стать, или дверь уже навсегда закрыта?

-------------------

В Microsoft писать баг-репорт бесполезно.

Во-первых,
"MS Office Document Scanning" ведь не отправляет файлы по почте, а сохраняет на диск. А ";" является допустимым символом для имен файлов в файловых системах FAT(VFAT) и NTFS. Скорее всего и в других распространенных ФС - тоже.

Во-вторых,
почтовые программы от MS - OE, Outlook - сами нормально отображают имена вложенных файлов с ";" (как в письмах, отправленных ими самими, так и в письмах, отправленных другими программами).

В-третьих,
да, ";" является зарезервированным символом в заголовках (Headers). Но заголовком считается только содержимое письма до первой пустой строки (даже Опера так считает - достаточно посмотреть на то, что она отображает по "Display All Headers" или в примерах Оперы по фильтрам прямо об этом говорится). А имя вложенного файла указывается не в заголовке, а в теле письма, в его соответствующей части (сообщение с вложениями ведь всегда является "multipart"). Так что стандарты на символы в заголовках выполняются. Т.е. даже сама Опера, сохраняя имя файла в теле письма как есть (с ";"), стандартов по счастливой случайности не нарушает А если нарушает, то почему не признается багом само включение файла с таким именем в тело письма?
(Если я чего не понял в стандартах, то просьба указать, где утверждается иное)

Если же Опера все-таки всерьез считает (а не просто так получилось), что ";" в именах аттачей недопустима, то кто ей мешает кодировать имя файла, аналогично тому, как кодируется Subject (inline-encoding)?! Или может это пользователь должен заранее подготовить все содержимое письма в нужной кодировке и в нужном транспортном формате?
Пример из OE (раз нет более подходящего мейлера в качестве примера ):
(пришлось использовать символы из разных кодовых таблиц, иначе OE, как и Опера, отправляет имя файла в незакодированном виде)

В ответ на:
Content-Type: application/octet-stream;
name="=?utf-8?B?0YDRg9GB0YHQutC40LkgYW5kIHVtbGF1dHMgw6TDtsO8w58uanBn?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="=?utf-8?B?0YDRg9GB0YHQutC40LkgYW5kIHVtbGF1dHMgw6TDtsO8w58uanBn?="

В ответ на:
Вот поэтому я и считаю, что обрезание имен вложений, содержащих ";", при просмотре и сохранении - это баг Оперы.

В ответ на:
Символ ";" - символ, который запрещено использовать в именах файлов.

В ответ на:
Name Limits and Character Sets
... The following six special characters are ... allowed in a long name. ...
+ , ; = [ ]

В ответ на:
... NTFS Naming Conventions
... Names can contain any characters except for the following:
? " / \ < > * | :