Тема: Вновь о кодировке по умолчанию для отправляемых писем

В теме "Default encoding" (http://www.forum.nobat.ru/index.php?…;threadid=1361) обсуждение, к сожалению, в очередной раз перешло на свойства Microsoft и её почтовые клиенты, и за этим потерялась реальная проблема. Процитирую:

Sokol
"Версия The Bat! - 2.01.50. В свойствах account поставлен koi8-r как default encoding для новых
сообщений. Порядок действий:
1. New message на самого себя
2. Параметры - Переводировка - там стоит Cyrillic (koi8-r). не меняем этой установки.
3. Отправляем сообщение. Т.е. в нем нет ни одной русской буквы, т.к. все дефолтные подписи - английские.
4. Открываем полученное сообщение и смотрим заголовки:
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Т.е. encoding us-ascii. Дальнейшие проблемы, думаю, очевидны. Можно ли это как-то поправить? Спасибо."

Alexander Kiselev
1) "Если в сообщении все буквы -- us-ascii, то Бат всю жизнь ставил в хедерах us-ascii, независимо от кодировки по умолчанию. Это вполне соответствует духу и букве RFCs, кстати."
2) "RFC2045, см. определение 7bit data и 8bit data. У Вас -- 7bit data, она кодируется, как RFC822, то бишь us-ascii.
Более того, я вот специально проверил: Пегасус работает совершенно по той же логике, что и Бат, к примеру. И Бекки. Так что не говорите мне, что это неверно."

Не могу не возразить уважаемому Александру по следующим пунктам.
Если известно, что у нас 7-битные данные, то, как совершенно правильно говорит Александр, они долны кодироваться "как RFC822, то бишь us-ascii". Однако как определить, какие у нас данные? Заглянем в упоминаемый Александром RFC2045:
"2.7. 7bit Data
"7bit data" refers to data that is all represented as relatively short lines with 998 octets or less between CRLF line separation sequences [RFC-821]. No octets with decimal values greater than 127 are allowed and neither are NULs (octets with decimal value 0). CR (decimal value 13) and LF (decimal value 10) octets only occur as part of CRLF line separation sequences.
2.8. 8bit Data
"8bit data" refers to data that is all represented as relatively short lines with 998 octets or less between CRLF line separation sequences [RFC-821]), but octets with decimal values greater than 127 may be used. As with "7bit data" CR and LF octets only occur as part of CRLF line separation sequences and no NULs are allowed.
Таким образом, в нём говорится, что в 7-битных данных не допускаются символы с кодами выше 127 ("No octets with decimal values greater than 127 are allowed"), однако никак не говорится о том, что любые данные, в которых таких символов не содержится, обязательно 7-битные. Ни из буквы, ни из духа RFC2045 этого не видно. И я соглашусь с автором вопроса Sokol-ом: по логике, задавая koi8-r в качестве "кодировки по умолчанию", мы как раз и говорим The Bat!-у: "Пожалуйста, если ничего другого не скажу - рассматривай все данные как koi8-r". Александр, Вы ведь не станете утверждать, что символы с кодами до 127 не могут кодироваться как 8-битные данные? ;) Т.е. у Вас получилась достаточно стандартная логическая ошибка: из "Если данные в 7-битной кодировке, то они не могут содержать русских букв" (что, собственно, и сказано в стандарте) Вы (и авторы Бат-а) сделали вывод "Если данные не содержат русских букв, значит, они могут быть только в 7-битной кодировке", А второе из первого на самом деле, согласитесь, не вытекает.

Так что это действительно нелогичное поведение Бат-а, и если Пегасус и Бекки работают по той же логике (в деталях проверять сейчас некогда), то это не значит, что она правильна. Что касается Пегасуса, кстати, то (может, это сейчас изменилось - довольно давно на него не смотрел, но с полгода назад в четвёртой версии было ещё так) Харрис в справке вообще пишет: "Allow 8-bit MIME encodings" "If you check this control, Pegasus Mail will generate MIME messages using the MIME "8BIT" transfer encoding whenever you include 8-bit data in your mail. 8-bit data is illegal in Internet mail (sic! - М.К.), but is used in some countries. This is both a very technical, and potentially very dangerous option and should only be used if you know what you are doing. We recommend you do not check this control except on the advice of a properly qualified person." Так что, при всём уважении к Pegasus и его автору, я бы не стал использовать его как пример в части работы с 8-битными данными…

С уважением, Максим.

Я отвечу коротко…
Объявлять семибитные данные восьмибитными для удобства ублюдочных клиентов???
Вам не к доктору ли пора, ась?
И не надо до#$#$#;ваться до Харриса… Англичанин может ничего не знать про восьмибитные заморочки, а 8бит в хидерах и действительно запрещены

>Объявлять семибитные данные восьмибитными для удобства ублюдочных клиентов???
Вам не к доктору ли пора, ась?

Весьма вежливо, м-да. Но я отвечу. Меня может не интересовать "удобство ублюдочных клиентов", но меня, знаете ли, интересует по крайней мере _своё_ удобство. Я объявляю свои данные 8-битными в кодировке koi8-r, и хочу, чтобы по умолчанию это действовало независимо от того, что в новом письме по ходу его написания я, возможно, передумаю писать его по-русски, а напишу по-английски, у меня изменится кодировка, а я об этом должен буду догадывыаться. Мне казалось, что смысл "кодировки по умолчанию" именно таков. Если Вы считаете, чтол я хочу слишком многого, - право Ваше. Но в RFC2045-2047 этого нету. Ни в букве, ни в духе.

>И не надо до#$#$#;ваться до Харриса…

Четвёртое слово - не из моего лексикона. И хотелось надеяться, что не из лексикона этих форумов.

>Англичанин может ничего не знать про восьмибитные заморочки, а 8бит в хидерах и действительно запрещены

Вы где-то нашли у меня предложение употреблять/разрешать употребление открытых 8-битных заголовков ("хидеров")? Хотелось бы видеть, где.

И последнее. Кажется, статус "бывалого" даёт Вам повод писать в достаточно хамском тоне. Не знаю, чем измеряется "бывалость", но позволю себе заметить, что Ваш покорный слуга впревые подошёл к компьютеру (ЕС-1030) в 1982 году, к IBM-совместимому персональному компьютеру - если не ошибаюсь, в 1987, а первые сообщения электронной почты отправил и принял уж и не помню в каком году, - архивы не все храню, - но, пожалуй, где-то в 1992, и примерно с тех пор читаю RFC. Работал с Windows начиная с 3.x, с FreeBSD - начиная с 2.2.x… И если, трижды подумав, высказываюсь в форуме, то ожидаю в ответ - ответа, а не хамской "распальцовки".

Ну ладушки, поговорим чуть более спокойно…
<INTRO (offtop)>
Я груб не потому что я тут много наговорил, это природное - не люблю тупое упрямство, обоснованное только спекуляциями вокруг собственного толкования RFC и собственных хотелок.
И грубость - не самый страшный мой недостаток, я еще и про Мыша таки кое-что знаю…
Не стоит цепляться к таким мелочам, как категория писателя в данном конкретном форуме, ну и тем более - меряться девайсами… Это пусть мОлодежь выясняет у кого длинее и больше, OK? С СМ-1420 я начал работать чутка раньше… если уж пошел такой базар :-)
</INTRO>
Ни один из упомянутых RFC не упоминает о 8-bit data даже в терминах SHOULD, не говоря уж о MUST - т.е. полностью оставляет это за решением имплементатора
И из этого совершенно законно следует предположение, что указание 8-битного чарсета относиться может только к случаям, где возможно неоднозначное толкование возможного чарсета для 8битных данных, т.е тогда и только тогда когда эти восьмибитные данные имеют место быть, потому что как для 7-битных предусмотрен только один безальтернативный вариант
Так что - это НЕпротиворечащее ничему явноуказанному толкование RFC, создающее меньше проблем, чем предложенное Вами расширительное толкование, и посему широко используемое в любых MUA, знающих о том, что есть 8bit в природе, но следующих принципу бритвы Оккама

А у него все "ответы" либо про руки, либо про доктора.

Насчёт ублюдочных клиентов.
Если переписка по работе, то в этом случае деление почтовых клиентов на ублюдочные и неублюдочные не к месту. По работе важно, чтобы корреспонденция была доставлена и прочитана. Деловых партнёров/клиентов и т.п. публику не интересует, какой клиент ты предпочитаешь и тот факт, что их клиент хуже. И для тебя же лучше. если ты учтёшь их конфигурацию.

Так что фанатизм уместен, когда не работешь и используешь почту для удовольствия. Тогда можно ложить на "ублюдочных клиентов", и кричать "вот мой клиент полностью соответствует RFC, а вы все нахрен со своими идите" и т.п.

Ситуацию чувствовать в любом деле полезно.
Понятно, что всё могло бы быть лучше и люди могли бы не пользоваться плохими клиентами. Но жизнь есть жизнь и выбор почтового клиента - далеко не самая приоритетная задача в жизни и в работе.

Брателло, каков вопрос таков и ответ
Еще в первом треде давали решение - "воткните в ваши развесистые сиги безвредный восьмибитный символ, который одинаков во всех чарсетах - и живите спокойно"
Alt+0249 - мне нравится во всех шрифтах…
Так нет, вам же не решение, а погундеть надо
А если это работа, так думай, как сделать, а не стрелки переводи! инструменты есть, а голову я свою не подарю - бо не расплатишься

У меня-то как раз по работе с почтой проблем нет…
Просто я могу понять тех, у кого они есть.

Сообщение от Dzhyn

Просто я могу понять тех, у кого они есть.

А они есть по лени и природному нелюбопытству… которое нужно опять же не для красоты в данном случае, а чтобы обезопасить свою "спину"

"Меряться", как Вы изволили выразиться, я ни с кем не собирался. Пролсто возникает впечатление, что стаж и знание "кое-чего" дают Вам право на хамский тон. А по сути - Вы так и не поняли, о чём я говорю. Речь идёт _не_ о расширительном или любом другом толковании RFC, а, прежде всего, о толковании слов "Default character set" в Бат-е. Я бы действительно ничего не писал по этому поводу, если быв Бат (или любой другой MUA) не знал о 8-битных кодировках. Но он о них _знает_, и позволяет задать такую кодировку как кодировку _по умолчанию_ для всех новых сообщений. Я всегда считал, что если я указываю в качестве Default character set KOI8-R, то это значит, что любое сообщение, содержащее только символы, которые можно выразить в этой кодировке, он в этой кодировке и уйдёт, и в заголовке у него будет стоять "charset=koi8-r" и "Content-Transfer-Encoding: 8bit". Точно так же логично ожидать, что в любом почтовом клиенте, умеющем отправлять письма в UTF-8, если в качестве кодировки по умолчанию указана эта кодировка, то сообщение уёдёт именно в ней, - независимо от того, содержит оно иероглифы, или только латиницу и кириллицу, или вообще только латиницу. Но вы, наверное, скажете: "Какая же это двухбайтная кодировка, если там только латиница!"
"…указание 8-битного чарсета относиться может только к случаям, где возможно неоднозначное толкование возможного чарсета для 8битных данных, т.е тогда и только тогда когда эти восьмибитные данные имеют место быть" - абсолютно согласен. Но Вы делаете предположение: "Там, где только символы 0-127 - там восьмибитных данных нет". Прошу прощения, если повторюсь, однако с первого раза это, кажется, услышано не было - этого _нигде_ в RFC не сказано и не подразумевается. Когда я пишу английскую букву "t", я пишу английскую букву "t", а уж будет она в 7-битной, 8-битной или какой-то ещё кодировке, никак не определяется самой этой буквоой. Если в том же сообщении будет иметься русская буква "т", то, конечно, задать для него 7-битную кодировку уже нельзя. Но отсутствие в нём русской буквы "т" _никак_ не подразумевает то, что вместо заданной пео умолчанию 8-битной кодировки должна (даже без уведомления!) применяться 7-битная.

Решение же Вы действительно предложили, однако решение это, до которого долго додумываться не надо, - обходное и кривое. Если есть default character set, то сообщения должны уходить в нём by default, а не после добавления символа, которого нету в другой кодировке (us-ascii).

Ссылку на это обсуждение стоит, наверное, послать разработчикам - что скажут по этому поводу Стефан с Максом, меня, честно говоря, интересует уже больше, чем Ваша "логика".

Сообщение от Maksym Kozub

"Меряться", как Вы изволили выразиться, я ни с кем не собирался.

Хорошо, но именно такое впечателение у меня сложилось, раво как и у Вас - о том, что я грубый хам… Можно считать, что оба ощущения не соответствуют реальности?

Ссылку на это обсуждение стоит, наверное, послать разработчикам - что скажут по этому поводу Стефан с Максом, меня, честно говоря, интересует уже больше, чем Ваша "логика".

OK
Обсуждение можно увидеть будет тутhttps://www.ritlabs.com/bt/bug_view_…bug_id=0002343