Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã URL
Cách mã hóa mailto: liên kết với chủ đề, ngắt dòng nội dung và ký hiệu
· Tại sao nó quan trọng
gửi thư url-encoding html
Liên kết mailto: có chủ đề và nội dung là URL, vì vậy dấu cách, dấu ngắt dòng và & phải được mã hóa theo phần trăm. Bài đăng này hiển thị những gì bị hỏng khi chúng không hoạt động và cách tạo liên kết mở chính xác trong ứng dụng thư khách.
Liên kết liên hệ có chủ đề dừng ở khoảng trống đầu tiên - một thư gửi bị hỏng cụ thể: và những gì ứng dụng thư khách nhận được
Các liên kết liên hệ như <a href="mailto:test@example.com?subject=Support Inquiry">Send</a> bị hỏng vì các khoảng trống trong "Yêu cầu hỗ trợ" chấm dứt các liên kết trong ứng dụng thư khách. Nhiều khách hàng chỉ nhận được chủ đề "Hỗ trợ". Điều này xảy ra do các liên kết mailto: đi theo RFC 6068, chỉ định rằng khoảng trắng và ký tự đặc biệt yêu cầu mã hóa phần trăm trong tham số truy vấn. Ký hiệu và cần mã hóa %26 để tránh bị phân tách tham số.
Các liên kết mailto: bị hỏng thể hiện vấn đề một cách rõ ràng. Các liên kết được tạo như <a href="mailto:test@example.com?subject=Support Inquiry&body=Reply">Liên hệ</a> chỉ dẫn đến các thông báo có chủ đề "Hỗ trợ". Thử nghiệm trong các ứng dụng thư khác nhau cho thấy dung sai khác nhau: Apple Mail xử lý một phần các liên kết, Gmail chỉ hiển thị "Hỗ trợ", Outlook thất bại hoàn toàn.
mailto: là một lược đồ URL — tóm tắt là RFC 6068 và phần nào là chuỗi truy vấn
RFC 6068 xác định các lược đồ mailto: URL với các quy tắc mã hóa dành riêng cho thành phần. Không giống như các URL thông thường, mailto: có các quy tắc cụ thể cho mỗi thành phần. Các phần địa chỉ (test@example.com) vẫn chưa được mã hóa; @ và tên miền có cấu trúc. Các tham số truy vấn (chủ đề, nội dung, cc, bcc) cần mã hóa. RFC 6068 tham chiếu RFC 3986 cho các quy tắc, bắt buộc mã hóa phần trăm cho dấu cách và ký tự đặc biệt. Ký hiệu trong các giá trị trở thành %26 khi xuất hiện dưới dạng dữ liệu chứ không phải dấu phân cách.
Hiểu cấu trúc lược đồ mailto: ngăn ngừa lỗi mã hóa. Biểu mẫu là: mailto:address?parameter1=value1¶meter2=value2. Dấu hỏi giới thiệu phần truy vấn. Các tham số phân tách ký hiệu vẫn không được mã hóa; chỉ các ký hiệu và bên trong các giá trị mới mã hóa thành %26. Nếu chủ đề chứa "Tom & Jerry", hãy mã hóa thành Tom%20%26%20Jerry. Ký hiệu giữa chủ đề và nội dung vẫn không được mã hóa. Mã hóa lồng nhau này dễ bị lỗi.
Mã hóa chủ đề và nội dung — dấu cách dưới dạng %20, ngắt dòng dưới dạng %0D%0A và & dưới dạng %26 bên trong các giá trị
Việc mã hóa chủ thể và nội dung yêu cầu xử lý cẩn thận các khoảng trắng và ký tự đặc biệt. Dấu cách trở thành %20 trong liên kết mailto: chứ không phải dấu cộng không giống như biểu mẫu HTML. Sự khác biệt quan trọng này khiến các nhà phát triển quen thuộc với biểu mẫu web gặp khó khăn. Ngắt dòng mã hóa dưới dạng %0D%0A (CRLF kết thúc dòng trong email). Ký hiệu trở thành %26. Dấu phần trăm trở thành %25. Chủ đề thường chứa dấu cách, dấu và dấu ngoặc đơn. Nội dung chứa dấu cách, dấu, ngắt dòng.
Các mã hóa phổ biến trong các liên kết mailto: bao gồm: dấu cách là %20, dòng mới là %0D%0A, ký hiệu và dấu hiệu là %26, phần trăm là %25, hàm băm là %23, câu hỏi là %3F. Các dấu không giống ASCII trước tiên sẽ chuyển đổi thành UTF-8 byte sau đó mã hóa phần trăm. "Báo cáo Über" trở thành báo cáo %C3%9ber%20. "Xin chào! Tạm biệt" trở thành Hello%21%0D%0ATạm biệt. Chỉ mã hóa các giá trị chứ không phải cấu trúc? và & ký tự.
Ví dụ đã hoạt động: xây dựng một liên kết có chủ đề, nội dung hai dòng và cc — kết quả được mã hóa và cách nó xuất hiện trong ứng dụng thư
Ví dụ hoạt động: xây dựng liên kết với chủ đề "Chương trình họp (tháng 9)", nội dung "Chúng ta hãy thảo luận: Mục tiêu hàng quý" và cc "manager@example.com" thể hiện quá trình mã hóa hoàn chỉnh. Chủ đề cần: dấu cách là %20, dấu ngoặc đơn là %28 và %29. Nội dung cần: "Chúng ta hãy thảo luận:" hầu như không thay đổi (dấu cách là %20), ngắt dòng là %0D%0A, "Mục tiêu hàng quý" hầu như không thay đổi. Trường cc không yêu cầu mã hóa.
Kết quả mailto: là: mailto:contact@example.com?subject=Meeting%20agenda%20%28Sept%29&body=Let%20us%20discuss%3A%0D%0AQuarterly%20goals&cc=manager@example.com. Thử nghiệm trong trình duyệt cho thấy các cách hiểu khác nhau về ứng dụng thư khách. Gmail mở cửa sổ soạn thảo với chủ đề chính xác, nội dung hai dòng và cc. Outlook cho thấy kết quả tương tự. Apple Mail yêu cầu quyền. Những khách hàng lớn tuổi không thành công vì thiếu sự hỗ trợ cơ thể.
Tại sao + sai ở đây — mailto: theo sau RFC 3986, không phải mã hóa biểu mẫu, vì vậy + vẫn là điểm cộng
Tại sao dấu cộng sai—mailto: theo sau RFC 3986, không phải mã hóa biểu mẫu, vì vậy dấu cộng vẫn giữ nguyên nghĩa đen—làm rõ những khác biệt quan trọng. Mã hóa biểu mẫu HTML sử dụng dấu cộng cho khoảng trắng trong chuỗi truy vấn. RFC 3986 và RFC 6068 đều chỉ định %20 cho khoảng trắng. Một mailto: với chủ đề="Cuộc họp+Chương trình nghị sự" tạo chủ đề bằng các dấu cộng theo nghĩa đen chứ không phải dấu cách. Lỗi này xảy ra khi sao chép logic mã hóa biểu mẫu sang mailto: Generation. Plus có nghĩa là cộng, không phải khoảng trắng.
Tại sao điều này lại quan trọng: nhà phát triển sao chép logic gửi biểu mẫu GET sang mailto: tạo liên kết ngắt. Chủ đề "Chương trình cuộc họp" trở thành "Cuộc họp+Chương trình nghị sự" trong biểu mẫu. Trong các liên kết mailto:, nó tạo ra "Cuộc họp+Chương trình nghị sự" với các điểm cộng theo nghĩa đen. Người dùng tự sửa dòng chủ đề. Việc kiểm tra các liên kết mailto: yêu cầu nhấp vào chúng hoặc kiểm tra các liên kết được tạo chứ không phải phân tích các quy tắc biểu mẫu.
Các lỗi phổ biến — quên HTML-thoát dấu & dấu phân cách trong href và mã hóa phần trăm @ trong địa chỉ
Các lỗi xây dựng mailto: phổ biến bao gồm quên ký hiệu HTML và thoát trong thuộc tính href. Trong HTML, ký hiệu và trong thuộc tính phải là & cho XHTML hợp lệ. href="mailto:address?subject=Test&body=Test" không hợp lệ HTML; nó phải là href="mailto:address?subject=Test&body=Test". Điều này thể hiện cách mã hóa khác với mã hóa URL. Trình phân tích cú pháp HTML diễn giải & trước khi trình duyệt xử lý URL.
Việc kiểm tra những lỗi này yêu cầu kiểm tra HTML bảng điều khiển nguồn và trình duyệt. Nhấp chuột phải và chọn "Kiểm tra phần tử" để xem giá trị href thực tế. Sao chép-dán các giá trị href vào thanh địa chỉ (có tiền tố mailto:) và kiểm tra ứng dụng thư khách. Một số liên kết email hoạt động trong một số trình duyệt nhất định nhưng không hoạt động trong các trình duyệt khác. Kiểm tra tự động khó khăn vì mailto: liên quan đến các khách hàng bên ngoài, khiến việc xác minh thủ công trở nên phổ biến.
Điều này không bao gồm những gì - sự khác biệt về hỗ trợ ứng dụng thư khách và chiều sâu của nhiều người nhận
Điều này không bao gồm những khác biệt về hỗ trợ ứng dụng thư và nhiều người nhận. Không phải tất cả ứng dụng khách đều hỗ trợ thông số RFC 6068 như nhau. Tham số body được hỗ trợ rộng rãi nhưng một số khách hàng cũ bỏ qua nó. Các tham số cc và bcc có hỗ trợ thay đổi. Nhiều người nhận yêu cầu địa chỉ email được phân tách bằng dấu phẩy, mã hóa dấu phẩy dưới dạng %2C cho các địa chỉ phức tạp. Các ngôn ngữ khác nhau yêu cầu mã hóa UTF-8 thích hợp để hiển thị.
Sự phát triển của ứng dụng thư khách ảnh hưởng đến hành vi mailto: trên các nền tảng. Ứng dụng thư trên web hiện đại (Gmail, Outlook.com) có mức độ tuân thủ RFC 6068 tốt hơn so với ứng dụng khách trên máy tính để bàn cũ. Ứng dụng khách di động đôi khi có khả năng phân tích cú pháp chặt chẽ hơn. Một số hỗ trợ văn bản có định dạng trong khi một số khác chỉ hỗ trợ văn bản thuần túy. Các nhà phát triển nên thử nghiệm với ứng dụng thư khách mà khán giả của họ thực sự sử dụng. Việc triển khai thực tế khác nhau bất chấp thông số kỹ thuật RFC 6068.
Bài học rút ra: mã hóa từng giá trị, giữ nguyên cấu trúc - cách chế độ một giá trị của bộ mã hóa & giải mã URL cung cấp cho bạn chủ đề và nội dung được mã hóa để dán
Bài học rút ra: mã hóa từng giá trị, giữ nguyên cấu trúc—chế độ một giá trị duy nhất của bộ mã hóa và giải mã URL tạo ra các chủ thể và nội dung được mã hóa sẵn sàng để dán vào các liên kết. Công cụ này chấp nhận các giá trị chưa được mã hóa như "Chương trình cuộc họp (Tháng 9)" và tạo ra "Cuộc họp%20agenda%20%28Sept%29". Sao chép đầu ra trực tiếp vào thuộc tính mailto: href. Đối với nội dung nhiều dòng, hãy dán các phiên bản văn bản gốc có ngắt dòng, nhận các phiên bản được mã hóa %0D%0A.
Cách thực hành tốt nhất là tập hợp các liên kết mailto: từ các phần được mã hóa thay vì xây dựng thủ công. Khi xây dựng HTML một cách linh hoạt trong JavaScript hoặc các mẫu, hãy mã hóa từng thông số riêng biệt trước khi nối bằng & dấu phân cách. Đối với bộ mã hóa và giải mã HTML, URL tĩnh sẽ kiểm tra mã hóa một cách đáng tin cậy trước khi viết tay. Quy trình mã hóa tài liệu trong nhận xét mã. Kiểm tra các liên kết mailto: kết quả bằng cách nhấp vào chúng bằng ứng dụng thư khách thực tế trước khi triển khai.