Có nên cộng mã hóa trong mailto: hyperlinks?

Khi đặt một địa chỉ email bằng thẻ địa chỉ (còn gọi là địa chỉ phụ) trong một siêu liên kết mailto

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

Nên cộng điểm trong email có được mã hóa URL không?

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

Tôi không thể tìm ra điều này, và tài liệu này là xung đột. Các thử nghiệm trong thế giới thực của chúng tôi cũng đã tạo ra kết quả hỗn hợp, làm cho nó thậm chí còn khó hiểu hơn.

Dấu cộng được sử dụng để mã hóa khoảng trắng trong URL, không phải bằng HTML và không phải là SMTP (RFC2821). Tuy nhiên, vì mailto:address@server.comlà một URI (nó có một giao thức, dấu phân cách giao thức và địa chỉ giao thức) nên nó phải được coi là một URI và nó phải được mã hóa phần trăm .

Do đó, tùy thuộc vào ứng dụng khách để giải quyết chính xác biểu diễn được mã hóa và giải mã nó theo mức độ phù hợp. Đây là chính thức của Microsoft về vấn đề này .

Bạn nên áp dụng mã hóa URL trên mailto: URL được nhúng trong HTML nếu các ký tự trong địa chỉ email được bảo lưu URI. Điều này đảm bảo rằng bạn đang làm đúng. Tùy thuộc vào ứng dụng khách để giải mã URI một cách thích hợp từ khi nhận được. Vâng, this+address@gmail.comlà một email rất hợp lệ; vâng this%2Baddress@gmail.comcũng hợp lệ. Có, hai cái đó khác nhau, nhưng liệu chúng có được đối xử khác nhau hay không là tùy thuộc vào khách hàng ...

Như bạn đã lưu ý trước đây, không phải tất cả các máy khách đều hiển thị chính xác. Tôi khuyên bạn nên tìm ứng dụng khách có khả năng nhất (gmail? Máy khách dựa trên trình duyệt? Outlook?) Mà người dùng của bạn sẽ sử dụng và thực hiện những gì khách hàng đó làm. Bạn nói bạn đã thử nghiệm trên GMail? Làm thế nào bạn kiểm tra nó? Với "trình duyệt mailto: client (chẳng hạn như tiện ích bổ sung cho firefox và gmail), URI rất có thể không được giải mã (như vậy).

Bạn CÓ THỂ mã hóa +, nhưng bạn không phải làm thế.

Đầu tiên, chúng ta cần đồng ý rằng đó mailtolà một ví dụ về URI chung, được chỉ định bởi RFC 2396 . (Đây là những gì XHTML và HTML 4 sử dụng).

Bây giờ chúng ta hãy tìm hiểu danh sách các nhân vật dành riêng trong RFC 2396.

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

URI chia thành tuyệt đối và tương đối:

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

Và bởi vì lược đồ mailto:được chỉ định nên đây là một URI tuyệt đối:

absoluteURI   = scheme ":" ( hier_part | opaque_part )

Và vì cả hai mẫu để hier_partbắt đầu /, mailtolà một phần mờ đục.

opaque_part   = uric_no_slash *uric

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

uric          = reserved | unreserved | escaped

Vì vậy, hạn chế là bạn phải thoát /nếu nói đến ký tự đầu tiên, nhưng sau đó bạn có thể đặt các ký tự dành riêng bao gồm +và @.

Đây là một RFC khác để hỗ trợ này. Trong các RFC mới nhất của sơ đồ mailto được xuất bản năm 2010 được gọi là RFC 6068 , nó nói:

Phần mềm tạo 'mailto'URI tương tự phải cẩn thận để mã hóa bất kỳ ký tự dành riêng nào được sử dụng. Các biểu mẫu HTML là một loại phần mềm tạo 'mailto'URI. Các triển khai hiện tại mã hóa một không gian như '+', nhưng điều này tạo ra các vấn đề bởi vì '+'không thể phân biệt được chỗ đứng như vậy đối với không gian thực '+'trong 'mailto' URI. Khi tạo 'mailto'URI, tất cả các khoảng trắng NÊN được mã hóa thành %20và các '+'ký tự CÓ THỂ được mã hóa thành %2B. Xin lưu ý rằng các '+' ký tự thường được sử dụng như một phần của địa chỉ email để chỉ ra một phần phụ, ví dụ như trong <bill+ietf@example.org>.

Một bài đọc nghiêm ngặt của RFC có liên quan nói rằng "+" nên được mã hóa.

Mục 2, đầu trang 2 trên http://tools.ietf.org/html/rfc2368 nói:

"Lưu ý rằng tất cả các ký tự dành riêng URL trong" đến "phải được mã hóa: cụ thể là dấu ngoặc đơn, dấu phẩy và dấu phần trăm ("% "), thường xảy ra trong cú pháp" hộp thư "."

RFC cho URI (http://tools.ietf.org/html/rfc3986#section-2.2) liệt kê "+" dưới dạng ký tự dành riêng.

Điều đó nói rằng, "chính xác" không nhất thiết là những gì sẽ hoạt động trong tất cả các trình duyệt. Một số trình duyệt rõ ràng sẽ luôn xử lý những thứ chính xác như thể chúng sai và không chính xác như thể chúng đúng.

Chỉnh sửa: Đối với RFC6068 và "CÓ THỂ", tôi sẽ đọc đó là phụ thuộc vào ngữ cảnh. Nếu bạn đang viết URL để đọc văn bản thì "+" sẽ có ý nghĩa hơn, tuy nhiên nếu bạn viết nó bằng HTML thì cách giải thích chặt chẽ hơn của RFC3986 sẽ phù hợp hơn với các ý tưởng "HTML hợp lệ" và vì vậy mọi thứ sử dụng giá trị nên mong đợi nó được mã hóa

Mỗi RFC mới http://tools.ietf.org/html/rfc6068#section-5

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

Vì vậy, tôi đoán câu trả lời là không, nhưng có lẽ?

Tôi nghĩ rằng mã hóa nó hay không, sẽ không tạo ra sự khác biệt thực sự. Vấn đề là các khách hàng thư. Đối với bài kiểm tra, Yahoo Mail chỉ sử dụng dấu gạch nối cho địa chỉ phụ trong khi gMail sử dụng dấu cộng.

Đó là 2 xu của tôi ...

EDIT: Phản hồi dưới đây có một điểm vững chắc.

các RFC1738

3.5. MAILTO

Lược đồ URL mailto được sử dụng để chỉ định địa chỉ gửi thư Internet của một cá nhân hoặc dịch vụ. Không có thông tin bổ sung nào ngoài địa chỉ gửi thư Internet có mặt hoặc ngụ ý.

URL mailto có dạng:

    mailto:<rfc822-addr-spec>

trong đó (mã hóa của một) addr-spec, như được chỉ định trong RFC 822 . Trong URL mailto, không có ký tự dành riêng.

Lưu ý rằng dấu phần trăm ("%") thường được sử dụng trong các địa chỉ RFC 822 và phải được mã hóa.

Không giống như nhiều URL, lược đồ mailto không đại diện cho một đối tượng dữ liệu được truy cập trực tiếp; không có ý nghĩa trong đó nó chỉ định một đối tượng. Nó có cách sử dụng khác với loại tin nhắn / cơ thể bên ngoài trong MIME.

Vì không có ký tự dành riêng nên nó được mã hóa.

Theo RFC 6068 như được đề cập trong câu trả lời, bạn CÓ THỂ mã hóa dấu cộng dưới dạng %2B.

Lý do có sự nhầm lẫn là việc chuyển đổi một khoảng trắng thành dấu cộng thực sự không phải là một phần của mã hóa URL tiêu chuẩn, đó là một phần của mã hóa tham số biểu mẫu (nghĩa là application/x-www-form-urlencoded)

Nó giống như sự khác biệt giữa PHP rawurlencode()và urlencode().

Vì vậy, điều mà RFC 6068 đang nói là một mailto:URL nên sử dụng mã hóa URL tiêu chuẩn "thô" (theo RFC 3986 ) và một dấu cộng xuất hiện trong URL phải luôn được coi là dấu cộng, và không phải là khoảng trắng có được mã hóa dưới dạng.

Nếu máy khách cục bộ chuyển đổi dấu cộng thành khoảng trắng thì nó bị hỏng.