開発者ツール · URL エンコーダーとデコーダー
mailto をエンコードする方法: 件名、本文の改行、アンパサンドを含むリンク
· なぜそれが重要なのか
メールアドレス URLエンコーディング html
件名と本文を含む mailto: リンクは URL であるため、スペース、改行、& はパーセントでエンコードする必要があります。この投稿では、何が壊れていないのか、そしてメール クライアントで正しく開くリンクを構築する方法を示します。
件名が最初のスペースで停止している連絡先リンク — 具体的な壊れた mailto: とメール クライアントが受信した内容
<a href="mailto:test@example.com?subject=Support Inquiry">送信</a> のような連絡先リンクは、「Support Inquiry」の空白によってメールクライアント内でリンクが途切れます。多くのクライアントでは件名が「Support」だけになります。mailto: リンクは RFC 6068 に従い、クエリパラメーター内の空白と特殊文字をパーセントエンコードする必要があるためです。アンパサンドはパラメーター区切りと誤解されないよう %26 にします。
壊れた mailto: リンクは問題を明確に示します。<a href="mailto:test@example.com?subject=Support Inquiry&body=Reply">連絡</a> のようなリンクでは、件名が「Support」だけのメッセージになります。メールクライアントごとに許容度は異なり、Apple Mail は一部を処理し、Gmail は「Support」だけを表示し、Outlook は完全に失敗します。
mailto: は URL スキーム — RFC 6068 の概要であり、どの部分がクエリ文字列であるか
RFC 6068 は、コンポーネント固有のエンコード規則を使用して mailto: URL スキームを定義します。通常の URL とは異なり、mailto: にはコンポーネントごとに特定のルールがあります。アドレス部分 (test@example.com) はエンコードされないままになります。 @ とドメインは構造的なものです。クエリパラメータ (件名、本文、cc、bcc) にはエンコードが必要です。 RFC 6068 はルールについて RFC 3986 を参照し、スペースと特殊文字のパーセント エンコーディングを義務付けます。値内のアンパサンドは、区切り文字ではなくデータとして表示される場合は %26 になります。
mailto: スキーム構造を理解すると、エンコードの間違いを防ぐことができます。形式は、mailto:address?parameter1=value1¶meter2=value2 です。疑問符はクエリ セクションを示します。パラメータを区切るアンパサンドはエンコードされないままになります。値内のアンパサンドのみが %26 としてエンコードされます。件名に「トムとジェリー」が含まれる場合は、Tom%20%26%20Jerry としてエンコードします。件名と本文の間のアンパサンドはエンコードされないままになります。このネストされたエンコーディングはエラーが発生しやすくなります。
件名と本文のエンコード - 値内のスペースは %20、改行は %0D%0A、& は %26 として
件名と本文をエンコードするには、スペースと特殊文字を慎重に扱う必要があります。 mailto: リンク内のスペースは、HTML フォームとは異なりプラス記号ではなく、%20 になります。この決定的な違いは、Web フォームに慣れている開発者をつまずかせます。改行は %0D%0A (電子メールでは CRLF 行末) としてエンコードされます。アンパサンドは %26 になります。パーセント記号は %25 になります。通常、件名にはスペース、アクセント、括弧が含まれます。本文にはスペース、アクセント、改行が含まれます。
mailto: リンクの一般的なエンコードには、スペース %20、改行 %0D%0A、アンパサンド %26、パーセント %25、ハッシュ %23、質問 %3F が含まれます。非 ASCII のようなアクセントは、まず UTF-8 バイトに変換され、次にパーセント エンコードされます。 「ユーバー レポート」は %C3%9ber%20report になります。 「こんにちは！ さようなら」は Hello%21%0D%0AGoodbye になります。構造ではなく値のみをエンコードしますか?と&の文字。
作業例: 件名、2 行の本文、cc を含むリンクの構築 — エンコードされた結果とメール クライアントでの表示方法
作業例: 件名「会議の議題 (9 月)」、本文「次のことについて話し合いましょう」というリンクの構築 四半期目標」、cc「manager@example.com」は完全なエンコードを示します。被験者には、%20 のようなスペース、%28 および %29 のような括弧が必要です。機関には次のものが必要です: 「議論しましょう:」はほとんど変更されていません (スペースは %20)、改行は %0D%0A で、「四半期目標」はほとんど変更されていません。 cc フィールドにはエンコードは必要ありません。
結果の mailto: は次のようになります: mailto:contact@example.com?subject=Meeting%20agenda%20%28Sept%29&body=Let%20us%20discuss%3A%0D%0AQuarterly%20goals&cc=manager@example.com。ブラウザでテストすると、メール クライアントの解釈が異なることが明らかになります。 Gmail では、正しい件名、2 行の本文、CC が表示された作成ウィンドウが開きます。 Outlook でも同様の結果が示されています。 Apple Mail には権限が必要です。年配のクライアントは体のサポートが不足すると失敗します。
ここで + が間違っている理由 — mailto: はフォーム エンコーディングではなく RFC 3986 に従っているため、+ はプラスのままです
プラス記号が間違っている理由 — mailto: は RFC 3986 に従っており、フォーム エンコーディングではないため、プラスはリテラルのままです — は重要な違いを明確にしています。 HTML フォームのエンコードでは、クエリ文字列内のスペースにプラスを使用します。 RFC 3986 と RFC 6068 はどちらもスペースに %20 を指定しています。 mailto: と subject="Meeting+Agenda" では、スペースではなくリテラルのプラス記号を含む件名が作成されます。この間違いは、フォーム エンコーディング ロジックを mailto: 生成にコピーすると発生します。プラスはスペースではなくプラスを意味します。
これが重要な理由: 開発者はフォーム GET 送信ロジックを mailto: 世代解除リンクにコピーします。件名「会議の議題」は、フォームでは「会議+議題」になります。 mailto: リンクでは、リテラルのプラスが付いた "Meeting+Agenda" が作成されます。ユーザーは件名を手動で修正します。 mailto: リンクをテストするには、フォーム ルールを分析するのではなく、リンクをクリックするか、生成されたリンクを調べる必要があります。
よくある間違い — href 内の & 区切り文字を HTML エスケープし忘れたり、アドレス内の @ をパーセントエンコードしたりすること
mailto: 構築の一般的な間違いには、href 属性での HTML アンパサンド エスケープを忘れることが含まれます。 HTML では、有効な XHTML の場合、属性内のアンパサンドは & である必要があります。 href="mailto:address?subject=Test&body=Test" は無効な HTML です。 href="mailto:address?subject=Test&body=Test" である必要があります。これは、URL エンコーディングとは異なるエンコーディングを表します。 HTML パーサーは、ブラウザーが URL を処理する前に & を & として解釈します。
これらの間違いをテストするには、HTML ソースとブラウザー コンソールを調べる必要があります。右クリックして「要素の検査」を選択すると、実際の href 値が表示されます。 href 値をコピーしてアドレス バーに貼り付け (mailto: プレフィックスを付けて)、メール クライアントを確認します。電子メール リンクの中には、特定のブラウザでは機能するものもありますが、他のブラウザでは機能しないものもあります。 mailto: には外部クライアントが関与しており、手動による検証が一般的であるため、自動テストは困難です。
この内容ではカバーされていないもの — メール クライアントのサポートの違いと複数の受信者の詳細
これには、メール クライアントのサポートの違いや複数の受信者が含まれません。すべてのクライアントが RFC 6068 パラメーターを同等にサポートしているわけではありません。 body パラメータは幅広くサポートされていますが、一部の古いクライアントはそれを無視します。 cc および bcc パラメータには変数がサポートされています。複数の受信者にはカンマ区切りの電子メール アドレスが必要で、複雑なアドレスの場合はカンマを %2C としてエンコードします。ロケールが異なると、表示のために適切な UTF-8 エンコードが必要になります。
メール クライアントの進化は、プラットフォーム間の mailto: の動作に影響を与えます。最新の Web メール クライアント (Gmail、Outlook.com) は、古いデスクトップ クライアントよりも優れた RFC 6068 準拠を備えています。モバイル クライアントでは、より厳密な解析が行われる場合があります。リッチ テキストをサポートするものもありますが、プレーン テキストのみをサポートするものもあります。開発者は、視聴者が実際に使用するメール クライアントを使用してテストする必要があります。実際の実装は、RFC 6068 仕様にかかわらず異なります。
要点: 各値をエンコードし、構造を維持 — URL エンコーダーとデコーダーの単一値モードがエンコードされた件名と本文を貼り付ける方法
要点: 各値をエンコードし、構造を維持します。URL エンコーダーおよびデコーダーの単一値モードでは、リンクに貼り付ける準備ができているエンコードされた件名と本文が生成されます。このツールは、「会議の議題 (9 月)」などのエンコードされていない値を受け入れ、「Meeting%20agenda%20%28Sept%29」を生成します。出力を mailto: href 属性に直接コピーします。複数行の本文の場合は、改行を含むプレーンテキスト バージョンを貼り付け、%0D%0A でエンコードされたバージョンを取得します。
ベスト プラクティスでは、手動で構築するのではなく、エンコードされた部分から mailto: リンクをアセンブルします。 JavaScript またはテンプレートで HTML を動的に構築する場合は、& 区切り文字で連結する前に各パラメーターを個別にエンコードします。静的 HTML の場合、URL エンコーダとデコーダは手書きの前にエンコードを確実にテストします。ドキュメントのエンコード処理はコード コメントで行われます。結果の mailto: リンクを、展開前に実際のメール クライアントでクリックしてテストします。