[Comm] Re[2]: [Comm] Re[2]: [Comm] Re: [JT] Так лучше?
ASA
=?iso-8859-1?q?llb_=CE=C1_udm=2Eru?=
Пн Окт 28 18:25:26 MSK 2002
Hello Sergey,
Monday, October 28, 2002, 6:56:56 PM, you wrote:
>> Его сильфида, работая в локали CP1251, не поняла мой 8-битный
>> заголовок в koi8-r, что соответствует кодировке письма (может
>> это и не по RFC, но логично). Так кто из нас имеет кривый клиент?
SV> А что прикажете делать, если частей text/plain несколько, и все в разных
SV> кодировках?
Ничего не делать.
SV> Если text/plain вообще нет, а есть text/html? А если сверху
брать его кодировку.
SV> вообще multipart/encrypted, под ним multipart/signed, под ним... ?
Для encrypted в сабже вообще не будет ничего существенного ;)
SV> Нет, можно, конечно, вводить всякие предположения, типа "а вот если письмо
SV> послано вот таким клиентом, то он, скорее всего, послал его в кодировке
SV> XXX" - но для чего же тогда писали стандарты? К тому же всякий такой
SV> обход ведет к тому, что другие начинают считать это поведение нормальным,
SV> что приводит к умножению бардака.
отквоченные предположения - это и есть бардак.
Предлагается простое правило: если для поля "Subject:" нет явно
указанной кодировки, то проверить выполнения условий:
1. игнорируем все binary/* или multipart/* более высокого уровня
вложенности.
2. Если все оставшиеся части письма - text/* и все они имеют
одну кодировку, то берем эту кодировку для "Subject:"
3. Если условие 2 не выполняется - то бардак и делаем что хотим.
4. Прописать все это в RFC.
Кстати, если бы США использовал бы русский алфавит, а СССР -
английский (при условии сохранения прочих условий), как бы
сейчас выглядели кодовые таблицы?
--
Best regards,
ASA mailto:llb на udm.ru
Подробная информация о списке рассылки community