Loading article…
現在、多くのメールクライアントがUnicodeをサポートしています。一部のクライアントは、メールの内容に応じて、自動的に[ 1 ]、またはユーザーが要求したときに[ 2 ]、従来のエンコーディングとUnicodeを自動的に選択します。
ASCII以外の文字を含むメッセージを電子メールで送信するための技術要件は以下のとおりです。
送信者または受信者のメールアドレスに非ASCII文字が含まれている場合、メッセージを送信するには、これらの文字をメールサーバーが理解できる形式にエンコードする必要があります。
RFC 6531は、 SMTP [ 3 ]およびLMTPプロトコルでUTF-8としてエンコードされた非ASCII電子メールアドレスを許可するメカニズムを提供します。
件名、送信者名、受信者名などの特定のメールヘッダーフィールドでUnicodeを使用するには、UnicodeテキストをMIMEの「Encoded-Word」でエンコードし、文字セットとしてUnicodeエンコーディングを指定する必要があります。電子メールアドレスのドメイン部分でUnicodeを使用するには、従来はIDNAエンコーディングを使用する必要がありました。あるいは、SMTPUTF8 [ 3 ]では、電子メールアドレス（ローカル部分とドメイン名の両方）およびメールヘッダーセクションでUTF-8エンコーディングを使用できます。元々ASCIIのみの電子メールプロトコルに非ASCIIデータの処理を後付けするために、さまざまな標準が作成されました。
US-ASCII以外のすべてのエンコーディングと同様に、電子メールでUnicodeテキストを使用する場合は、テキストにUnicode変換フォーマットが使用されていることを指定するためにMIMEを使用する必要があります。
廃止されたエンコーディングであるUTF-7 は、旧式の非8 ビットクリーンネットワークでは Unicode エンコーディングよりも優位性がありました。それは、従来のインターネット メール サーバーの 7 ビット制限内に収まるように転送エンコーディングを必要としないからです。一方、UTF-16 はSMTP のデータ フォーマットに適合させるために転送エンコードする必要があります。厳密には必須ではありませんが、UTF-8も 7 ビット メール サーバー間での問題を回避するために通常は転送エンコードされます。UTF-8 の MIME 転送エンコーディングは、プレーン テキストとして読み取れない ( base64の場合) か、一部の言語やテキストの種類ではサイズ効率が非常に悪くなります ( quoted-printableの場合)。
HTML、PostScript、リッチテキスト形式などの一部のドキュメント形式は、非ASCII文字用に独自の7ビットエンコーディング方式を備えているため、特別なメールエンコーディングを使用せずに送信できます。HTMLメールは、HTMLエンティティを使用することで、メールのHTMLソーステキストが従来のエンコーディング（例：7ビットASCII）であっても、Unicodeの任意の文字を使用できます。