「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を - 若くない何かの悩み

メールアドレスのルールのまとめ系のサイトの内容が間違っています。 なので、この類のまとめは安易に信じないように 、という注意喚起をしておきます。 追記（2013/11/27） twitterやはてブをみていたところ、「ユーザーへの啓蒙という観点ではまとめの内容間違ってない」というご意見をたくさんいただきましたので、補足をしておきますね。 どうも「ルール」と「トラブルを避けるためのガイドライン」が混同されているように思います。まとめで紹介されている内容がユーザ向けの「ガイドライン」なのであれば、「+ 記号使わせてよ」ぐらいしか文句はありません。 ですが、ほとんどのまとめは上記の内容を「ルール」として説明しています。ひどいものにはRFCに基づいてまとめを書いたようにミスリードさせる記事もありました。このような現状を憂い、このような記事を書いたのです。 そもそもこれに気づいた発端は@kusano

[kz78]

ところがRFCをみんなが順守してるわけではないのである。docomoとか、docomoとか、docomoとか。であれば「原則使えない」としてしまうのが不正確でも現実的であろう。

[nekoruri]

現実的にRFC5322にすら違反するメールアドレスが実在(例:quoted-stringじゃないのにピリオド連続)するうえに、RFC5335でaddr-specのUTF-8化が来るので、地球人類にメールアドレスのバリデーションは無理。 //書いた http://goo.gl/2qCSA9

[iqm]

なので、RFC的に正しいメールアドレスを入力フォームで弾くサイトを作らないでください。何度、弾かれたことか...

[localnavi]

とはいえ、＠の前全体を"と"で囲んでとか実質「やるな」と言っているようなものだし、メアド入力欄でエラーが出たりしそうなので、一般人は「間違ってるルール」に従っておく方が安全だと思う。

[a2de]

ユーザー登録する時は+付アドレス許可してたくせに、暫くして仕様変更したのか+付アドレスだとログイン出来なくした某通販サイトは許さないよ

[uasi]

「RFC はこうです」と書いてるまとめに「RFC はそうじゃねえ」とツッコんでる記事なのに実装が〜とか一般的には通用しねえ〜とか言ってる人ヤバい / 改訂前（RFC822,2822）だとまとめが正しい？→そんなことなかった

[gregminster]

法定速度40kmの道路を50kmぐらいで走っていると一言言うタイプ

[uturi]

これを読む限り、「アドレスを登録する業者が考えるべきこと」は細かくたくさんあるけど、「ユーザーが新しいアドレスを作る」には冒頭のまとめで充分な気がする。システム側は大変だなぁ。

[harumomo2006]

現実世界で使えないことが多いのであれば使えないと言ってもいいんじゃないだろうか

[konaken]

他の人も書いてるけど、ケータイキャリアとか、広く使われてる独自運用の仕様をまとめて最大公約数的に「こうしとけば問題ない」って説明のほうが役に立つので欲しいなあ

[tototti]

意外といろんな記号が使えるんですね...(実際は大変だけど)。

[minoton]

このとおりだと問題起きるけどベースとして

[s-tomo]

「アンダースコアは2つ以上連続してはいけない」ってどこルールだよ？

[nyop]

備忘に。

[tyoro1210]

エンジニアが実装する為に"ルール"を調べたい時にガイドラインばっかりヒットして辛いからまとめといてやったぜ！って事か。 / 個人的には完成した正規表現くれればそれでいい。

[nasu_t]

mail rfc

[Yeshi]

ほわー

[rin51]

RFC読め で終了じゃないのか

[atsushi1972]

reading 「メールアドレスのルール」系まとめがそろって ... reading 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を - 若き JavaScripter の悩み … [] via Pocket http://twitter.com/koizuka/status/405964020923920384 November 2

[sigC]

まぁ、そりゃ、quoted-string 使えば結構何だって通っちゃうのは確かだけど。

[koba789]

使う側は「無難な文字だけ使おう」でいいんだけど、作る側はそれじゃダメなんだよクソが。ということで良記事。

[akasata]

ふむ・・・

[ngyuki]

（メールアドレスを発行する側でないかぎり）メールアドレスのチェックは「届けばおｋ」かな

[mujisoshina]

"IDOLM@STER"もアドレスに使えるのか / 「例外のほうが多い規則（アンリミテッド・ルールブック）」

[naga_sawa]

「RFCこうなっている」に対して「現実は」の問題/RFCを狭めて使っているvalidatorと逸脱していているサービスがあるのでぶつかる

[himomen]

エントリ主「道交法では、最低速度の規定がない車道は15km/hで走り続けても良い。ご注意を」　反論のほとんど「そんな車がいたらうざい」　って感じの内容。「ご注意を」さえ無ければ普通のエントリ。

[champlasonic]

ケータイメールとウェブサービスの連携機能開発でキャリア独自仕様に泣かされたことを思い出す。今でもGmailだと「.」や「+」をいれてもスキップするような仕様があるけどあれもRFC準拠とちゃうんちゃうんちゃうん？

[istb16]

Wikipediaに書いてあるし、RFCに準拠してないアドレスもいっぱいあるけどね "「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を"

[nyomonyomo]

メールアドレスの記号でもググって見てください(´・ω・｀)

[kazuyadesse]

( ´ ▽ ` )ﾉ

[kintoki3]

これでメル鯖を作っても正当化出来ない。

[tmtms]

良い解説 / RFCより実装見ろってコメントはイマイチ / RFC準拠の形式を正規表現で書けないというのも間違い

[inulab]

昔の携帯の@前のドットとか弾いてクレームとかあったけどチェック外してもメール受けるシステムと送る方で扱い違くて結局ごめんなさいしてた。

[knakamura1977]

この記事があるのを覚えとこ。

[uzuki-first]

しかし、この正規表現は書けないのであった・・・

[haru-no-hajimari]

＋を使ってフィルタリングしたいのに、無理ぽん、っていわれて悲しいです！

[vid]

RFCがバージョンアップして、最新の分はそれでいいのかも。古いバージョンでは、まとめ系のが間違っていない可能性は無いのかな？

[yoshi-na]

W3Cに合わせたらIEで表示が崩れるみたいな状態

[y-kawaz]

受け付けるメアドのバリデーションは緩く、発行するメアドは厳しくが鉄板対応。どうせメアドの正当性なんて後々メール送信してURLクリックさせるなりバウンスの除外なりで確認するから適当でいい。

[cheesesouffle]

<input type=email>のルールあたりが現実的です。http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#valid-e-mail-address