Angular.js: メール検証ツールが間違っています

ええ、あなたは正しいです、それはEMAIL_REGEXが間違っているように見えます。

http://dev.w3.org/html5/markup/input.email.htmlによると、

/^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/

@後に.含まれていないため、より適切に機能するようです。

このための簡単なパッチを提出してみます。

...実際、これは私が思っていたよりも少し複雑です。これにはもう少し手間がかかるかもしれません。 ピリオドで始まる正規表現も受け入れるようです。 ですから、ここでやるべきことが少しあると思います。

私の前でこれを解決できる場合は、プルリクエストを送信してください

バグレポートをありがとう。 ドキュメントのデモでは、1.2.10がドロップするまで、この修正に気付くことはありません。これは、1.2.9のAngularスクリプトが常に読み込まれるためです。 しかし、数日以内に、これがドキュメントデモで対処されていることを確認する必要があります（コミットが元に戻されない限り、O_Oで発生する可能性があります）

素晴らしい、10倍！

5：32 AMで水曜日、2014年1月22日には、ケイトリン・ポッターの[email protected] ：

バグレポートをありがとう。 ドキュメントのデモでは、この修正に気付かないでしょう
1.2.9角度スクリプトを常にロードするため、1.2.10がドロップするまで。
しかし、数日以内に、これがドキュメントデモで対処されているのを見るはずです

—
このメールに直接返信するか、Gi tHubhttps：//github.com/angular/angular.js/issues/5899#issuecomment-32990587で表示してください
。

「 dummy @ ferferfe 」（ドメインなし）が有効なメールと見なされていることに気付いたときの私の表情はどうでしたか;）

@ mica16ですが、 dummy@ferferfeは有効なメールアドレスです。 ドメインに拡張子を付ける必要はありません。 localhostについて考えてみてください。

@Zequezは正しいですが、例としてWebサイトの登録にローカルホストアドレスを使用しているのは誰ですか？

@mbeckenbach使用
ng-pattern = "/ ^ [a-z0-9！＃$％＆ '* + / =？^ _` {|} 〜.-] + @ [a-z0-9-] +。[a-z0 -9-] / "
理想的ではありませんが、機能します。

@mbeckenbachええ、本当です。 ただし、ドットのないドメイン名は有効なドメインであると考えてください。 ICANNがドメインをTHEMに登録することを許可しないということは、ドメイン名が無効であることを意味するわけではありません。

6 @ 6はメールアドレスではありません。 特別な状況でそれが適切な電子メールアドレスである可能性があるという事実は、私の意見では、それを許可することにつながるべきではありません。 この寛容なパターンを介して通過する間違いの確率は、そのような電子メールアドレスを持つ誰かを除外する確率よりも桁違いに大きいです。

ジェフの+1

@jeffmcmahan申し訳ありませんが、IETFまたはWHATWGに問題を

ここで、もう少し厳密にしたい場合は、パターン検証ツールを追加することもできます。これで問題ありません。

@caitpあなたは上司です。

EMAIL_REGEXPを構成可能にするのはどうですか？ サーバー側の検証は、angularjsの検証よりも厳密です。 具体的には、たとえば、@記号の前の部分が63文字以下である必要があります。 次に、すべての電子メール入力に対してカスタムディレクティブを作成するか、各電子メール入力にng-patternを追加することを忘れないでください。

type = email、 @ rjokelaiに加えてng-patternを使用できます。また、 @ matskoの検証パイプラインの変更により、カスタムの電子メール検証を簡単に追加できるようになります。

「これで、もう少し厳密にしたい場合は、パターン検証ツールを追加することもできます。それで問題ありません。」

デフォルトの検証ツールは、ドットが含まれている通常の電子メールのみを受け入れます。少数派の誰かがより厳しくしたくない場合は、独自の検証ツールを作成できます。 少数の開発者が作成する必要がないように、開発者の大多数が独自のパターンを作成する必要があるのはなぜですか？ これはばかげた基準の純粋主義です

これは基本的にhtml5制約検証のポリフィルであるため、それが理由です。 来週は、これをはるかに簡単にカスタマイズできる機能を出荷する予定です。

ドメインゾーンのないメールは有効ですか？ type = "email"を使用して単純な入力フィールドをテストしており、Angularは_foo @bar_メールを正常に検証します。 （Angular v1.3.0）

ああ、すでにクローズされた問題があります—

ドメインゾーンのないメールは有効ですか？ type = "email"を使用して単純な入力フィールドをテストしており、Angularはfoo @barの電子メールを正常に検証します。 （Angular v1.3.0）

仕様ごとに、これらは有効な電子メールです。 この質問はこの課題追跡システムで何度も回答されており、TLDのない電子メールについて無効なものは何もありません。

カスタム検証ツールを使用して、必要な特定のTLDを要求します

@caitp 、私たちはこれについてあなたを悩ませてきたと思いますが、仕様を守ることが不可欠である理由を説明していただければ役立つと思います。 合理的で有能な開発者は、電子メール検証ツールが。 つまり、標準のフォーム登録状況で使用され、そのような多くの状況で問題が発生します。 そして、仕様を守ることの重要性はそれらの問題よりも重要であると言われています。 わかりました---かっこいいです。 しかし、なぜ？

あなたのブラウザがそれが有効であると言って、角度がそうではないと言うとき、それは本当に奇妙になるだろうから

電子メールの検証ではなく、電子メールの検証に加えてパターンの検証を探しています---特定のパターン（TLDを含む）に一致する有効な電子メールアドレス（角度で処理）が必要です

1. パターン検証を追加してから「ブラウザが有効であると表示し、[A] ngularが無効であると表示する」としたら、それは奇妙なことでしょうか。 いいえ。では、そのパターン検証が組み込まれているとしたら、なぜ奇妙なのでしょうか。
2. 関心のあるユースケースで有効な電子メールに渡されるものが仕様よりも狭いことは誰もが知っています。

_一般的なケースであるため、Angularが関心のあるユースケースに対応できない理由を知りたいだけです。_

では、そのパターン検証が組み込まれているとしたら、なぜ奇妙なのでしょうか。

実際には、ブラウザからも同じ動作が得られます。 http://jsfiddle.net/t6rdmngo/これを最新のブラウザで実行すると、TLDを含めないとパターンが一致しないため、トップフォームを送信できなくなります。

角度バージョンでは、同じ動作が得られます。 これはいい。 これが私たちが望んでいることです。 ネイティブの動作とフレームワークの動作の間の同一の動作。 フレームワークはプラットフォームとの不一致があってはなりません

今、私はそれを手に入れました。 我慢してくれてありがとう！

ng-patternを使用してこれをすばやく修正できます

<input type="email" ng-pattern="/^[_a-z0-9]+(\.[_a-z0-9]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$/">

正規表現の最後の*を+に変更すると、期待どおりに機能します

http://w3c.github.io/html-reference/input.email.html

/^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:.[a -zA-Z0-9-] +）+ $ /