732

完全な電子メール検証について質問しているわけではありません。

メールアドレスの許可されている文字user-nameとその一部を知りたいだけです。serverこれは単純化しすぎている可能性があります。メール アドレスは他の形式をとることもできますが、私は気にしません。私はこの単純な形式user-name@server(例: wild.wezyr@best-server-ever.com) と、両方の部分で使用できる文字についてのみ質問しています。

4

17 に答える 17

883

RFC 5322: Internet Message Formatを参照してください。また、それほどではありませんが、RFC 5321: Simple Mail Transfer Protocolも参照してください。

RFC 822も電子メール アドレスを対象としていますが、主にその構造を扱っています。

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved
 
 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

いつものように、ウィキペディアには電子メール アドレスに関する適切な記事があります。

電子メール アドレスのローカル部分には、次の ASCII 文字を使用できます。

  • 大文字と小文字のラテン文字AtoZおよびato z;
  • 数字0から9;
  • 特殊文字!#$%&'*+-/=?^_`{|}~;
  • ドット.は、引用されない限り最初または最後の文字ではなく、引用されない限り連続して現れないことを条件とします (たとえば、許可されていませんJohn..Doe@example.comが、許可されてい"John..Doe"@example.comます)。
  • スペースと"(),:;<>@[\]文字は制限付きで使用できます (以下の段落で説明するように、引用符で囲まれた文字列内でのみ使用できます。さらに、バックスラッシュまたは二重引用符の前にバックスラッシュを付ける必要があります)。
  • local-part のどちらかの端に括弧を付けてコメントを入れることができます。たとえばjohn.smith(comment)@example.com、 と(comment)john.smith@example.comはどちらも と同等john.smith@example.comです。

ASCII 文字に加えて、2012 年現在、 RFC 6532 仕様で説明され、Wikipediaで説明されているように、UTF-8 としてエンコードされた上記 の国際文字を使用できます。2019 年の時点で、これらの標準はまだ提案済みとしてマークされていますが、ゆっくりと展開されていることに注意してください。この仕様の変更により、国際文字が有効な英数字 (atext) として基本的に追加されましたが、 や などの許可および制限された特殊文字に関する規則には影響しません。U+007F!#@:

検証については、「正規表現を使用して電子メール アドレスを検証する」を参照してください。

このdomain部分は次のように定義されます。

プロトコルのインターネット標準 (Request for Comments) では、コンポーネントのホスト名ラベルにaから(大文字と小文字を区別しない) までの ASCII 文字、からzまでの数字、およびハイフン ( ) のみを含めることが義務付けられています。RFC 952のホスト名の元の仕様では、ラベルを数字またはハイフンで開始することはできず、ハイフンで終了してはなりません。ただし、その後の仕様 ( RFC 1123 ) では、ホスト名ラベルを数字で開始することが許可されました。その他の記号、句読点、空白は使用できません。09-

于 2010-01-12T14:15:23.660 に答える
362

気を付けて！このスレッドには多くの知識の腐敗があります (以前は真実で、現在はそうではありません)。

現在および将来の世界で、世界中のどこからでも実際の電子メール アドレスが偽陽性で拒否されるのを回避するには、少なくともRFC 3490の高レベルの概念、「アプリケーションでのドメイン名の国際化 (IDNA)」を知っておく必要があります。私は、米国と A の人々がしばしばこれについて理解していないことを知っていますが、それはすでに世界中で広範に使用され、急速に増加しています (主に非英語が支配的な部分)。

要点は、mason@Japan.com や wildwezyr@fahrvergnügen.net などのアドレスを使用できるようになったことです。いいえ、これはまだ世の中のすべてと互換性があるわけではありません (上で多くの人が嘆いているように、単純な qmail スタイルの +ident アドレスでさえ、間違って拒否されることがよくあります)。しかし、RFC があり、仕様があり、現在は IETF と ICANN によって支持されています。さらに重要なことに、この改善をサポートする多数の実装が現在稼働しています。

私自身、日本に戻って hei@やる.ca のようなメール アドレスや次のような Amazon の URL を目にするまで、この開発についてあまり知りませんでした。

http://www.amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/b/ref=topnav_storetab_e?ie=UTF8&node=3210981

仕様へのリンクを望んでいないことは承知していますが、インターネット フォーラムのハッカーの時代遅れの知識だけに頼っている場合、メール バリデーターは、英語を話さないユーザーがますます機能することを期待するメール アドレスを拒否することになります。それらのユーザーにとって、そのような検証は、私たち全員が嫌うありふれた脳死形式、+ や 3 部構成のドメイン名などを処理できないものと同じくらい厄介です。

面倒ではないと言っているわけではありませんが、「一部/任意/なしの条件で許可される」文字の完全なリストは、すべての言語の (ほぼ) すべての文字です。「すべての有効な電子メール アドレス (および多くの無効な電子メール アドレスも) を受け入れる」場合は、IDN を考慮する必要があります。これにより、最初に国際化された電子メール アドレスを変換しない限り、基本的に文字ベースのアプローチは役に立たなくなります(申し訳ありません)。 2015 年 9 月、以前はこのようなものでした — Punycodeの実用的な代替案はこちらです。

それを行った後、上記のアドバイス (ほとんど) に従うことができます。

于 2010-01-15T12:01:00.740 に答える
25

ウィキペディアにはこれに関する優れた記事があり、公式の仕様はこちらにあります。ウィキペディアから：

電子メール アドレスのローカル部分には、次の ASCII 文字を使用できます。

  • 大文字と小文字の英字 (az、AZ)
  • 数字の 0 ～ 9
  • キャラクター！# $ % & ' * + - / = ? ^ _ ` { | } ~
  • キャラクター 。(ドット、ピリオド、ピリオド) ただし、最初または最後の文字ではなく、2 回以上連続して現れないことを条件とします。

さらに、引用符で囲まれた文字列 (例: "John Doe"@example.com) が許可されているため、通常は禁止されている文字を使用できますが、通常は使用されません。RFC 5321 は、「メールを受信することを期待するホストは、ローカル部分が引用文字列形式を必要とする (または使用する) メールボックスを定義することを避けるべきである」とも警告しています。

于 2010-01-12T14:20:18.243 に答える
16

ウィキペディアの記事から始めることができます：

  • 大文字と小文字の英字 (az、AZ)
  • 数字の 0 ～ 9
  • キャラクター！# $ % & ' * + - / = ? ^ _ ` { | } ~
  • キャラクター 。(ドット、ピリオド、ピリオド) ただし、最初または最後の文字ではなく、2 回以上連続して現れないことを条件とします。
于 2010-01-12T14:20:10.897 に答える
14

Google は gmail.com アドレスで興味深いことをしています。gmail.com アドレスでは、文字 (az)、数字、およびピリオド (これらは無視されます) のみを使用できます。

たとえば、pikachu@gmail.com は pi.kachu@gmail.com と同じで、両方のメール アドレスが同じメールボックスに送信されます。PIKACHU@gmail.comも同じメールボックスに届きます。

したがって、質問に答えるために、RFC 標準のどの程度に従いたいかは、実装者に依存する場合があります。Google の gmail.com アドレス スタイルは、標準と互換性があります。彼らは、異なる人々が同様の電子メールアドレスを使用する場合の混乱を避けるために、そのようにしています。

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

ウィキペディアのリンクは、電子メール アドレスが一般的に許可するものについての良いリファレンスです。 http://en.wikipedia.org/wiki/Email_address

于 2012-01-18T09:34:30.153 に答える
10

名前：

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

サーバ：

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.
于 2012-01-18T09:34:16.837 に答える
7

簡単に言えば、答えは 2 つあります。やるべきことの基準はひとつ。つまり、賢明で、あなたをトラブルから遠ざけてくれる行動です。問題を起こさずに受け入れる必要がある別の (より広い) 基準があります。この二重性は、電子メールの送受信に機能しますが、生活の中で幅広い用途があります。

作成するアドレスのガイドとして。参照: https://www.jochentopf.com/email/chars.html

有効な電子メールをフィルタリングするには、次のステップを確認するのに十分なわかりやすいものを渡すだけです。または、たくさんの RFC を読み始めてください。注意してください。

于 2012-03-01T01:50:28.017 に答える
6

受け入れられた回答は、電子メール アドレスの有効なローカル部分について議論する際にウィキペディアの記事を参照していますが、ウィキペディアはこれに関する権威ではありません。

IETF RFC 3696 はこの問題に関する権威であり、セクション 3 で参照する必要があります。5 ページの電子メール アドレスの制限:

現在の電子メール アドレスは、アットマーク (「@」) によって「ドメイン部分」(完全修飾ドメイン名) から分離された「ローカル部分」で構成されます。ドメイン部分の構文は、前のセクションの構文に対応しています。フィルタリングと名前のリストに関するそのセクションで特定された懸念は、電子メール コンテキストで使用されるドメイン名にも適用されます。ドメイン名は角括弧内の IP アドレスに置き換えることもできますが、テストとトラブルシューティングの目的以外では、その形式は使用しないことを強くお勧めします。

ローカル部分は、以下で説明する引用規則を使用して表示される場合があります。引用された形式が実際に使用されることはめったにありませんが、いくつかの正当な目的のために必要です。したがって、それらはフィルタリング ルーチンで拒否されるべきではなく、宛先ホストによる評価のために電子メール システムに渡される必要があります。

正確な規則は、制御文字を含むすべての ASCII 文字が引用符で囲まれているか、または引用符で囲まれた文字列で表示される可能性があるということです。引用が必要な場合は、バックスラッシュ文字を使用して次の文字を引用します。例えば

  Abc\@def@example.com

は、電子メール アドレスの有効な形式です。次のように空白が表示されることもあります。

  Fred\ Bloggs@example.com

バックスラッシュ文字は、それ自体を引用するために使用することもできます。

  Joe.\\Blow@example.com

バックスラッシュ文字を使用した引用に加えて、従来の二重引用符文字を使用して文字列を囲むことができます。例えば

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

上記の最初の 2 つの例の代替形式です。これらの引用されたフォームはめったに推奨されず、実際には一般的ではありませんが、上記で説明したように、電子メール アドレスを処理するアプリケーションでサポートされている必要があります。特に、引用された形式は、他のシステムやコンテキストからの遷移に関連付けられたアドレスのコンテキストで表示されることがよくあります。これらの移行要件は依然として発生します。ユーザー提供の電子メール アドレスを受け入れるシステムは、そのアドレスがレガシー システムに関連付けられているかどうかを「認識」できないため、アドレス フォームを受け入れて電子メール環境に渡す必要があります。

引用符がなければ、ローカル部分は
アルファベット文字、数字、または特殊文字の任意の組み合わせで構成できます

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

ピリオド (".") も使用できますが、ローカル部分の開始または終了に使用したり、2 つ以上の連続したピリオドを使用したりすることはできません。別の言い方をすれば、アットマーク ("@")、バックスラッシュ、二重引用符、コンマ、または角括弧以外の ASCII グラフィック (印刷) 文字は、引用符なしで表示できます。除外された文字のリストのいずれかが表示される場合は、引用符で囲む必要があります。次のようなフォーム

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

は有効であり、かなり定期的に見られますが、上記の文字のいずれかが許可されています。

他の人が行ったように、PHP と JavaScript の両方で機能する正規表現を送信して、電子メール アドレスを検証します。

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i
于 2015-12-04T20:35:15.463 に答える
5

問題についてよく読んでください。

抜粋：

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com
于 2015-01-06T16:33:05.603 に答える
3

このウィキペディアのリンクにあるように

電子メール アドレスのローカル部分には、次の ASCII 文字を使用できます。

  • 大文字と小文字のラテン文字AtoZおよびato z;

  • 数字0から9;

  • 特殊文字!#$%&'*+-/=?^_`{|}~;

  • ドット.は、引用されない限り最初または最後の文字ではなく、引用されない限り連続して現れないことを条件とします (たとえば、許可されていませんJohn..Doe@example.comが、許可されてい"John..Doe"@example.comます)。

  • スペースと"(),:;<>@[\]文字は制限付きで使用できます (以下の段落で説明するように、引用符で囲まれた文字列内でのみ使用できます。さらに、バックスラッシュまたは二重引用符の前にバックスラッシュを付ける必要があります)。

  • local-part のどちらかの端に括弧を付けてコメントを入れることができます。たとえばjohn.smith(comment)@example.com、 と(comment)john.smith@example.comはどちらも と同等john.smith@example.comです。

上記の ASCII 文字に加えて、UTF-8 としてエンコードされた U+007F を超える国際文字がRFC 6531で許可されていますが、ローカル パーツを割り当てるときに使用する文字がメール システムによって制限される場合があります。

引用符で囲まれた文字列は、ローカル部分内にドットで区切られたエンティティとして存在する場合があります。または、最も外側の引用符がローカル部分の最も外側の文字である場合に存在する場合があります (たとえば、abc."defghi".xyz@example.comまたは"abcdefghixyz"@example.com許可されます。逆に、そうでabc"defghi"xyz@example.comはなく、どちらもありませんabc\"def\"ghi@example.com)。ただし、引用符付きの文字列や文字は一般的に使用されていません。RFC 5321は、「メールを受信することを期待するホストは、ローカル部分が引用文字列形式を必要とする (または使用する) メールボックスを定義することを避けるべきである」とも警告しています。

local-partpostmasterは特別に扱われます。大文字と小文字は区別されず、ドメインの電子メール管理者に転送する必要があります。技術的には、他のすべてのローカル部分は大文字と小文字が区別されるため、異なるメールボックスjsmith@example.comを 指定します。JSmith@example.comただし、多くの組織では、大文字と小文字を同等のものとして扱っています。

技術的に有効な特殊文字の広い範囲にもかかわらず; 組織、メール サービス、メール サーバー、およびメール クライアントは、実際にはそれらすべてを受け入れないことがよくあります。たとえば、Windows Live Hotmail では、英数字、ドット ( .)、アンダースコア ( _)、およびハイフン ( -) を使用した電子メール アドレスのみを作成できます。一般的なアドバイスは、電子メールが拒否されるリスクを回避するために、一部の特殊文字の使用を避けることです。

于 2014-03-21T12:06:26.633 に答える
0

簡単にするために、二重引用符内のすべてのテキストと二重引用符で囲まれた関連するテキストを検証前に削除して送信をサニタイズし、許可されていないものに基づいて電子メール アドレスの送信にキボッシュを置きます。誰かが John.."The*$hizzle*Bizzle"..Doe@whatever.com のアドレスを取得できるからといって、システムで許可しなければならないわけではありません。私たちは、お尻をきれいに拭くよりも、無料のメールアドレスを取得する方が時間がかからない未来に生きています。また、許可されているものと許可されていないものを示す入力のすぐ隣に電子メールの条件が貼り付けられていないわけではありません。

また、引用された資料が削除された後、さまざまなRFCで特に許可されていないものをサニタイズします. 特に許可されていない文字とパターンのリストは、テストするのにはるかに短いリストのようです。

不許可:

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

与えられた例では：

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

電子メール アドレスを追加または変更しようとしたときに残りの結果に確認電子メール メッセージを送信することは、送信された電子メール アドレスをコードが処理できるかどうかを確認する良い方法です。必要な数のサニタイズ ラウンドを経て電子メールが検証に合格した場合は、その確認を開始します。リクエストが確認リンクから戻ってきた場合、新しい電子メールは保留||一時||パージ状態またはストレージから移動され、本物の真正なファーストクラスの保存された電子メールになります。

配慮したい場合は、メールアドレス変更の失敗または成功の通知を古いメールアドレスに送信できます。未確認のアカウント設定は、妥当な時間が経過すると完全に失敗するため、システムから除外される可能性があります。

私は自分のシステムで悪臭を放つ電子メールを許可していません。おそらくそれはお金を浪費しているだけです。しかし、99.9% の確率で、人々は正しいことを行い、エッジ ケースの互換性シナリオを利用して適合限界を瀬戸際まで押し上げない電子メールを持っています。正規表現 DDoS には注意してください。これはトラブルに巻き込まれる可能性がある場所です。これは、私が行う 3 番目のことと関連しています。1 つのメールを処理できる期間に制限を設けています。検証のためにマシンの速度を落とす必要がある場合、着信データ API エンドポイント ロジックを通過していません。

編集：この答えは「悪い」と非難され続けましたが、おそらくそれに値するものでした。まだ悪いかもしれないし、そうでないかもしれない。

于 2016-01-24T06:21:38.013 に答える
0

答えは (ほぼ) ALL(7 ビット ASCII) です。
包含ルールが「...一部/任意/なしの条件で許可されている...」の場合

17 ページの上部にあるRFC 5322の「ドメイン テキスト」部分で許可されるテキストのいくつかの可能な包含規則の 1 つを見るだけで、次のことがわかります。

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

この説明で欠落している 3 つの文字のみが domain-literal[]で使用され、引用されたペア\と空白文字 (%d32) を形成します。これにより、32 ～ 126 (10 進数) の範囲全体が使用されます。同様の要件が「qtext」および「ctext」として表示されます。多くの制御文字も許可/使用されます。このような制御文字のリストの 1 つが、RFC 5322 のセクション 4.1 の31 ページに obs-NO-WS-CTL として表示されます。

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

セクション 3.5 の冒頭で述べたように、次のすべての制御文字を使用できます。

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

したがって、そのような包含規則は「広すぎる」のです。または、別の意味で、予想されるルールは「単純すぎる」ものです。

于 2015-06-21T04:56:14.970 に答える
-1

私のPHPでは、このチェックを使用しています

<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!\.)){0,61}[a-zA-Z0-9_-]?\.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

自分で試してみてくださいhttp://phpfiddle.org/main/code/9av6-d10r

于 2015-07-23T02:00:19.183 に答える