Haruskah ditambah dikodekan dalam mailto: hyperlink?

Saat menempatkan alamat email dengan tag alamat (alias sub-pengalamatan) dalam hyperlink mailto ...

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

... haruskah nilai tambah dalam email dikodekan URL?

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

Saya tidak bisa mengetahuinya, dan dokumentasinya saling bertentangan. Tes dunia nyata kami telah menghasilkan hasil yang beragam juga, membuatnya lebih membingungkan.

Nilai tambah digunakan untuk menyandikan spasi dalam URL, bukan dalam HTML dan bukan pada SMTP (RFC2821). Namun, karena mailto:address@server.comURI (memiliki protokol, pemisah protokol, dan alamat protokol) maka harus diperlakukan sebagai URI dan harus persen dikodekan .

Oleh karena itu, tergantung pada klien untuk menyelesaikan secara akurat representasi yang disandikan dan mendekodekannya sejauh yang diperlukan. Ini adalah keputusan resmi Microsoft untuk masalah ini .

Anda harus menerapkan penyandian URL pada mailto: URL yang disematkan dalam HTML jika karakter dalam alamat email dilindungi undang-undang. Ini memastikan bahwa Anda melakukan hal yang benar. Terserah klien untuk memecahkan kode URI dari mana ia diterima. Ya, this+address@gmail.comemail yang sangat valid; ya this%2Baddress@gmail.comjuga valid. Ya keduanya berbeda, tetapi apakah mereka akan diperlakukan berbeda terserah klien ...

Seperti yang Anda catat sebelumnya, tidak semua klien memberikan ini dengan benar. Saya sarankan mencari klien yang paling mungkin (gmail? Klien berbasis browser? Outlook?) Yang akan digunakan pengguna Anda dan melakukan apa yang klien lakukan. Anda bilang Anda diuji di GMail? Bagaimana Anda mengujinya? Dengan "mailto: client berbasis browser (seperti add-on untuk firefox dan penawaran gmail), URI kemungkinan besar tidak sedang diterjemahkan (sebagaimana seharusnya).

Anda MUNGKIN mengkodekan +, tetapi Anda tidak harus melakukannya.

Pertama, kita perlu setuju bahwa mailtoini adalah contoh dari URI generik, yang ditentukan oleh RFC 2396 . (Inilah yang digunakan XHTML dan HTML 4).

Sekarang mari kita cari tahu daftar karakter yang dipesan di RFC 2396.

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

URI terbagi menjadi absolut dan relatif:

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

Dan karena skema mailto:ditentukan ini adalah URI absolut:

absoluteURI   = scheme ":" ( hier_part | opaque_part )

Dan karena kedua pola untuk hier_partmemulai /, mailtoadalah bagian buram.

opaque_part   = uric_no_slash *uric

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

uric          = reserved | unreserved | escaped

Jadi batasannya adalah bahwa Anda harus melarikan diri /jika menyangkut karakter pertama, tetapi setelah itu Anda dapat memasukkan karakter yang termasuk termasuk +dan @.

Inilah RFC lain untuk mendukung ini. Dalam skema RFC terbaru dari mailto yang diterbitkan pada 2010 yang disebut RFC 6068 , disebutkan:

Perangkat lunak yang membuat 'mailto'URI juga harus berhati-hati untuk menyandikan karakter apa saja yang digunakan. Bentuk HTML adalah salah satu jenis perangkat lunak yang menciptakan 'mailto'URI. Implementasi saat ini menyandikan ruang sebagai '+', tetapi ini menciptakan masalah karena '+'berdiri untuk ruang seperti itu tidak dapat dibedakan dari nyata '+'dalam 'mailto' URI. Saat memproduksi 'mailto'URI, semua ruang HARUS dikodekan sebagai %20, dan '+'karakter DAPAT dikodekan sebagai %2B. Harap perhatikan bahwa '+' karakter sering digunakan sebagai bagian dari alamat email untuk menunjukkan subaddress, seperti misalnya dalam <bill+ietf@example.org>.

Pembacaan ketat RFC yang relevan mengatakan bahwa "+" harus dikodekan.

Bagian 2, bagian atas halaman 2 di http://tools.ietf.org/html/rfc2368 mengatakan:

"Perhatikan bahwa semua karakter yang dilindungi URL di" ke "harus dikodekan: khususnya, tanda kurung, koma, dan tanda persen ("% "), yang biasanya terjadi dalam sintaks" kotak surat "."

RFC untuk URI (http://tools.ietf.org/html/rfc3986#section-2.2) mencantumkan "+" sebagai karakter yang dipesan.

Yang mengatakan, apa yang "benar" belum tentu apa yang akan berfungsi di semua browser. Beberapa browser jelas akan selalu menangani hal-hal yang benar seolah-olah mereka salah dan salah seolah-olah mereka benar.

Sunting: Mengenai RFC6068 dan "MEI", saya akan membacanya sebagai tergantung konteks. Jika Anda menulis URL untuk membaca teks maka "+" akan lebih masuk akal, namun jika Anda menulisnya dalam HTML maka interpretasi yang lebih ketat dari RFC3986 akan lebih sejalan dengan ide "HTML yang valid" dan segala hal yang menggunakan nilai harus berharap itu akan dikodekan.

Per RFC baru http://tools.ietf.org/html/rfc6068#section-5

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

Jadi saya kira jawabannya tidak, tapi mungkin?

Saya pikir penyandian itu atau tidak, tidak akan membuat perbedaan nyata. Masalahnya adalah klien email. Sebagai contoh, Yahoo Mail hanya menggunakan tanda hubung untuk sub alamat sedangkan gMail menggunakan plus.

Itu 2 sen saya ...

EDIT: Respons di bawah ini memiliki poin yang kuat.

The RFC1738

3.5. MAILTO

Skema URL mailto digunakan untuk menunjuk alamat surat menyurat Internet dari seseorang atau layanan. Tidak ada informasi tambahan selain alamat surat menyurat yang ada atau tersirat.

URL mailto mengambil bentuk:

    mailto:<rfc822-addr-spec>

di mana (encoding dari) addr-spec, seperti yang ditentukan dalam RFC 822 . Dalam URL mailto, tidak ada karakter yang dipesan.

Perhatikan bahwa tanda persen ("%") biasanya digunakan dalam alamat RFC 822 dan harus dikodekan.

Tidak seperti banyak URL, skema mailto tidak mewakili objek data untuk diakses secara langsung; tidak ada gunanya menunjuk objek. Ini memiliki penggunaan yang berbeda dari jenis pesan / eksternal-tubuh di MIME.

Karena tidak ada karakter yang dipesan, itu harus dikodekan.

Per RFC 6068 sebagaimana disebutkan dalam jawaban, Anda DAPAT menyandikan tanda tambah sebagai%2B .

Alasan ada kebingungan adalah bahwa mengubah spasi menjadi plus sebenarnya bukan bagian dari pengkodean URL standar, itu bagian dari pengkodean parameter bentuk (yaituapplication/x-www-form-urlencoded )

Ini seperti perbedaan antara PHP rawurlencode()danurlencode() .

Jadi yang dikatakan RFC 6068 adalah bahwa mailto:URL harus menggunakan pengkodean URL standar "mentah" (per RFC 3986 ), dan tanda plus yang muncul di URL harus selalu diperlakukan sebagai tanda plus literal, dan bukan sebagai ruang yang memiliki formulir telah dikodekan.

Jika klien lokal mengubah nilai tambah menjadi spasi, itu rusak.