[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