0

目的

私は電子メールアドレスの最低限の検証をしようとしていますが、そうしないようにアドバイスするアドバイスがたくさん見られます。私がこれを行っている理由は、私が実装している仕様では、電子メール アドレスが次の形式である必要があるためです。

mailto:<uri-encoded local part>@<domain part>

私は単純に開始部分mailto:と最終部分を分割し@、「ローカル部分」がこれらの間にあると仮定したいと思います。「ローカル部分」が URI エンコードされていることを確認します。

これ以上のことはしたくありません。仕様では、ほとんどの場合、「ベスト エフォート」の検証を行うことができますが、URI エンコーディングとmailto:プレフィックスについては非常に具体的です。

問題

私が読んだすべてのことから、分割は私に@は危険に思えます。

Web と Stack Overflow の回答で多くの矛盾するアドバイスを見てきましたが、そのほとんどは「RFC を読んでください」と言っており、ドメイン部分は特定の文字、つまり1-9 a-z A-Z -.他のいくつかの文字にしかできないと言っているものもあります。 、しかしこれ以上のものではありません。例えば：

ドメイン名に関するさまざまな RFC を読むと、「任意の CHAR」( dtext)または「ASCII 33 から 90 までの任意の文字」( dtext)が許可されていることがわかります。これは、@記号が許可されていることを意味します。「コメント」は括弧( )で許可され、ASCII 42 から 91 までの文字を含むことができるため、これはさらに複雑になります@。

RFC1035 は文字 + 数字 + ダッシュ + ピリオドの要件をサポートしているようですが、RFC5322の「ドメイン リテラル」構文ではより多くの文字が許可されているようです。

RFC を誤解していますか、それとも@電子メール アドレスのドメイン部分に a を許可しない何かが欠けていますか? 「ドメイン リテラル」構文は、私が心配する必要がないものですか?

4

1 に答える 1

2

インターネット上の電子メールに関する最新の RFC はRFC 5322で、具体的にはアドレスに対応しています。

addr-spec       =   local-part "@" domain
local-part      =   dot-atom / quoted-string / obs-local-part

dot-atom は、仕様で定義された非常に制限された文字セットです。ただし、quoted-stringここで問題が発生する可能性があります。あまり使用されませんが、遭遇する可能性という点では、それ自体が文字を含む可能性のある引用符で囲まれた何かを得ることができます@.

ただし、文字列を最後の から分割した場合は、と@を安全に見つけることができます。これは、検証方法に関して仕様で明確に定義されています。local-partdomain

問題はpunycodeにあり、ほとんどすべての Unicode 文字を有効な DNS 名にマッピングできます。フロントエンドのシステムがプニコードを理解して解釈できる場合、有効なユニコード文字を含むほとんどすべてを処理する必要があります。Punycode を使用しないことがわかっている場合は、より制限されたセット (通常は文字、数字、およびハイフン文字) を使用できます。

偉大な故ジョン ポステルの言葉を引用すると、TCP の実装は、堅牢性の一般原則に従う必要があります。つまり、行うことは保守的であり、他者から受け入れることは寛大であるということです。

ローカル側の補足事項: もちろん、インターネット上には、仕様に厳密に準拠する必要のない多くのシステムが存在する可能性があることを念頭に置いてください。リベラルな受容/保守的な伝達哲学。

于 2013-06-08T18:09:15.277 に答える