4

PHP を使用して電子メールを送受信しようとしています。これまでのところ、関数を使用して特殊文字をエンコードする必要があることがわかりましたが、mb_encode_mimeheader()スペースをエンコードする必要はありません。

また、アドレスファイルの括弧が機能しないこともわかりました: (括弧付きのヘッダーを読み取るときに、PHP の imap_fetch_overview() 関数にエラーはありますか? )。たとえば、PHP は header-section にアクセスできませんが、header-sectionFrom: Admin [] <user@mail.tld>を読み取ることはできますFrom: "Admin []" <user@mail.tld>。

そのため、メール ヘッダーでは明らかに括弧が特別な意味を持ちます (少なくとも PHP の場合)。Mailheader の特殊文字には何があり、その意味は何ですか?また、どこでエンコード/引用する必要がありますか?

たとえば、件名はヘッダーの一部でもありますが、PHP では件名の角括弧に問題はありません。

引用符が問題の解決に役立つようです ( https://www.rfc-editor.org/rfc/rfc5322#section-3.2.4 - これが PHP の問題なのか、メールヘッダーが正しくありません)。しかし、引用符を使用する方法と、引用符によって何がエスケープされるのでしょうか?

https://www.rfc-editor.org/rfc/rfc5322#section-3.2.4には次のように書かれています。

アトムで許可されている文字以外の文字を含む文字列は、文字が引用符 (DQUOTE、ASCII 値 34) 文字で囲まれた引用符付き文字列形式で表すことができます。

それでは、各文字を個別に「エスケープ/引用」する必要がありますか

From: Admin "[""]" <user@mail.tld>

または、すべてをまとめて引用してもよろしいですか？

From: "Admin []" <user@mail.tld>

しかし、他の制御シーケンスが引用符で囲まれている場合はどうなるでしょうか? たとえばÄÖÜ、文字列内に特殊文字があり、これは にエンコードされてい=?UTF-8?B?w4PChMODwpbDg8Kc?=ます。では、RFC によれば、「引用されてエンコードされた」文字列は問題ないのでしょうか?

From: "Admin [=?UTF-8?B?w4PChMODwpbDg8Kc?=]" <user@mail.tld>
4

1 に答える 1

5

RFC2047 を使用している場合は、ヘッダー全体を RFC2047 としてエンコードし、引用を忘れることもできます。

どうやら、RFC5322 を既に見つけたようです。これは、何を引用する必要があるか、およびその理由に関する信頼できる情報源です。基本的に、電子メール アドレスの一部でない場合、電子メール アドレスとして意味のあるものはすべて引用する必要があります。従来の引用メカニズムはバックスラッシュや二重引用符でしたが、MIME を使用すると、利用可能な MIME エンコーディングを使用してすべてを透過的に簡単にエンコードできます。

あなたが与えたリンクは、「アトム」で許可されていない文字には引用が必要であることを説明しています。アトムで許可される文字のリストは、前のセクションにあります。

ALPHA / DIGIT /    ; Printable US-ASCII
                   "!" / "#" /        ;  characters not including
                   "$" / "%" /        ;  specials.  Used for atoms.
                   "&" / "'" /
                   "*" / "+" /
                   "-" / "/" /
                   "=" / "?" /
                   "^" / "_" /
                   "`" / "{" /
                   "|" / "}" /
                   "~"

ASCII テーブルと照合すると、次のようになります。

32   (space)                    not OK
33 !                            OK
34 "                            not OK
35 # through $%& 38             OK
39 ' through () 41              not OK
42 * through + 43               OK
44 ,                            not OK
45 -                            OK
46 .                            not OK
47 / through 0123456789 57      OK
58 : through ;< 60              not OK
61 =                            OK
62 >                            not OK
63 ?                            OK
64 @                            not OK
65 A through BCD...XYZ 90       OK
91 [ through \] 93              not OK
94 ^ through _ 95               OK
96 `                            not OK
97 a through bcd...xyz{|}~ 126  OK
127 DEL                         not OK

一部のコンテキストでは、上記のプラス ドット (ピリオド、ピリオド、ASCII 46) である "dot-atom" のセットは、引用なしで許可されます。

一部のクライアントは明らかに用心深く過ちを犯します (一部のクライアントは、あたかも本名が本当の本名ではないかのように、単にすべてを二重引用符で囲みます。それは最悪です)。

私の理解では、アトムが許可されている場所では RFC2047 シーケンスが許可されていますが、それは別のアトムに隣接することはできないことを意味します。とにかく、引用と RFC2047 ラッピングを同じヘッダーに混在させようとすることさえしないように勧めます。それを理解するときの間違い、または仕様の複数の有効な解釈があるため)。

于 2012-08-20T10:44:47.347 に答える