プラスはmailto：ハイパーリンクでエンコードする必要がありますか？

mailtoハイパーリンクにアドレスタグ（別名サブアドレス）を含む電子メールアドレスを配置する場合…

<a href="mailto:username+foo@example.com">mail us now!</a>

…電子メールのプラスをURLエンコードする必要がありますか？

<a href="mailto:username%2Bfoo@example.com">mail us now!</a>

私はこれを理解することができず、ドキュメントは矛盾しています。私たちの実世界のテストでは、結果も複雑になり、さらに混乱を招いています。

プラスは、HTMLおよびSMTP（RFC2821）ではなく、URLのスペースをエンコードするために使用されます。ただし、mailto:address@server.comURI（プロトコル、プロトコルセパレータ、およびプロトコルアドレスを持っている）であるため、URIとして扱われ、パーセントエンコードされる必要があります。

したがって、エンコードされた表現を正確に解決し、適切な範囲でデコードするのはクライアント次第です。ここにMicrosoftの公式の問題があります。

メールアドレスの文字がURIで予約されている場合、mailto：HTMLに埋め込まれたURLにURLエンコードを適用する必要があります。これにより、正しいことを実行できます。URIを受信した場所から適切にデコードするのはクライアント次第です。はい、this+address@gmail.com非常に有効なメールです。yes this%2Baddress@gmail.comも有効です。はい、これら2つは異なりますが、それらが異なる方法で扱われるかどうかはクライアント次第です...

前述したように、すべてのクライアントがこれを正しくレンダリングするわけではありません。ユーザーが使用する可能性が最も高いクライアント（gmail？ブラウザーベースのクライアント？Outlook？）を見つけて、そのクライアントが行うことを行うことをお勧めします。GMailでテストしたと言いましたか？どのようにテストしましたか？「ブラウザベースのmailto：クライアント（firefoxやgmailオファーへのアドオンなど）を使用すると、URIがデコードされない可能性が高くなります（そうあるべきです）。

エンコード+できますが、そうする必要はありません。

まず、RFC 2396mailtoで指定されている汎用URIの例であることに同意する必要があります。（これはXHTMLおよびHTML 4が使用するものです）。

次に、RFC 2396の予約文字のリストを調べてみましょう。

reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
              "$" | ","

URIは絶対と相対に分割されます：

URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

スキームmailto:が指定されているため、これは絶対URIです。

absoluteURI   = scheme ":" ( hier_part | opaque_part )

そして用両方のパターン以降hier_partで始まり/、mailto不透明な部分です。

opaque_part   = uric_no_slash *uric

uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
                "&" | "=" | "+" | "$" | ","

uric          = reserved | unreserved | escaped

その/ため、最初の文字についてはエスケープする必要がありますが、その後、+やなどの予約文字を入れることができます@。

これをサポートする別のRFCを次に示します。2010年に公開されたRFC 6068と呼ばれるmailtoスキームの最新のRFC では、次のように述べています。

'mailto'同様に、URIを作成するソフトウェアは、使用される予約文字をエンコードするように注意する必要があります。HTMLフォームは、'mailto'URI を作成するソフトウェアの一種です。現在の実装では、スペースをとしてエンコードしますが、 URIのスペースを実際に区別できないため、'+'問題が発生します。URIを生成するとき、すべてのスペースはとしてエンコードされるべきであり（SHOULD ）、文字はとしてエンコードされる 場合があります（MAY）。 たとえば、のように、サブアドレスを示すために文字が電子メールアドレスの一部として頻繁に使用されることに注意してください。'+''+''mailto''mailto'%20'+'%2B'+'<bill+ietf@example.org>

関連するRFCを厳密に読むと、「+」をエンコードする必要があるとされています。

http://tools.ietf.org/html/rfc2368のセクション2、ページ2の上部には次のように記載されています。

「「to」のすべてのURL予約文字はエンコードする必要があることに注意してください。特に、括弧、コンマ、およびパーセント記号（「％」）は、「メールボックス」構文でよく使用されます。」

URIのRFC（http://tools.ietf.org/html/rfc3986#section-2.2）では、予約文字として「+」がリストされています。

つまり、「正しい」とは、必ずしもすべてのブラウザーで機能するわけではありません。一部のブラウザは、明らかに正しいものを間違っているように、正しくないものを正しいかのように常に処理します。

編集：RFC6068とその「MAY」については、コンテキスト依存として読みます。あなたが読んでテキストのURLを記述している場合は、「+」、より理にかなってしかし、あなたはHTMLでそれを書いているならば、RFC3986の厳しい解釈が値を使用して、「有効なHTML」のアイデアで、何ので、より多くのインラインだろうべきエンコードされることを期待してください。

新しいRFCごとhttp://tools.ietf.org/html/rfc6068#section-5

  ... '+' MAY BE encoded as %2B

だから私は答えはそうではないと思うが、多分？

エンコードしてもしなくても、実際の違いはないと思います。問題はメールクライアントです。たとえば、Yahoo Mailはサブアドレスにハイフンのみを使用しますが、gMailはプラスを使用します。

それは私の2セントです...

編集：以下の応答にはしっかりしたポイントがあります。

RFC1738

3.5。MAILTO

mailto URLスキームは、個人またはサービスのインターネットの住所を指定するために使用されます。インターネットの郵送先住所以外の追加情報は存在または暗示されません。

mailto URLは次の形式を取ります。

    mailto:<rfc822-addr-spec>

RFC 822で指定されている addr-spec（のエンコード）です。mailto URLには、予約文字はありません。

パーセント記号（ "％"）はRFC 822アドレス内で一般的に使用され、エンコードする必要があることに注意してください。

多くのURLとは異なり、mailtoスキームは直接アクセスされるデータオブジェクトを表しません。オブジェクトを指定する意味はありません。MIMEのmessage / external-bodyタイプとは異なる用途があります。

予約文字がないため、エンコードする必要があります。

パーRFC 6068の回答で述べたように、あなたにプラス記号を符号化することができます%2B。

混乱する理由は、スペースをプラスに変換することは実際には標準のURLエンコーディングの一部ではなく、フォームパラメータエンコーディングの一部であるということです（つまりapplication/x-www-form-urlencoded）

これは、PHPの違いのようなものだrawurlencode()とurlencode()。

したがって、RFC 6068が言っているのは、mailto:URLが「RFC 3986による」「生の」標準URLエンコーディングを使用する必要があることです。フォームエンコードされています。

ローカルクライアントがプラスをスペースに変換すると、破損します。