Может ли отсутствие тире в UTF-8 в заголовках сообщений электронной почты приводить к неправильному отображению текста в почтовых клиентах?
Subject: Newsletter
MIME-Version: 1.0
From: <>
Reply-To: <>
Content-Type: text/plain; **charset=utf8**
Message-Id: <>
Sender: www-data <>
Date: Mon, 29 Aug 2011 12:19:37 +0200
X-SmarterMail-Spam: SPF_None
В отличие от:
Return-Path: <>
Received: from g with SMTP;
Tue, 30 Aug 2011 17:19:03 +0200
Received: from www-data by serwis with local (Exim: PJ server v1.0
id <>
for <>; Tue, 30 Aug 2011 17:18:53 +0200
To: <>
Subject: <>
From: WWW <>
MIME-Version: 1.0
Content-type: text/plain; **charset=utf-8**
Message-Id: <>
Sender: www-data <>
Date: Tue, 30 Aug 2011 17:18:53 +0200
X-SmarterMail-Spam: SPF_None
Я спрашиваю, поскольку мы заметили в некоторых электронных письмах, что если есть charset utf8 символы полировки не читаются.
Из Запись в Википедии о UTF-8:
Официальное название - «UTF-8». Все буквы в верхнем регистре, а имя расставлено через дефис. Это написание используется во всех документах, касающихся кодировки.
В качестве альтернативы, имя «utf-8» может использоваться всеми стандартами, соответствующими списку Internet Assigned Numbers Authority (IANA) (который включает заголовки CSS, HTML, XML и HTTP) [15], поскольку в объявлении регистр не учитывается.Другие описания, в которых дефис отсутствует или заменяется пробелом, например «utf8» или «UTF 8», не считаются правильными в соответствии с действующими стандартами. Несмотря на это, большинство агентов, таких как браузеры, могут их понимать, и поэтому стандарты, предназначенные для описания существующей практики (например, HTML5), могут фактически требовать их признания.
Так что в основном utf8 является технически некорректным (Худший вид неправильного ™), и программы не обязаны принимать его и поступать правильно (хотя многие могут делать это по доброте сердца).