ไทย

เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ · URL ตัวเข้ารหัสและตัวถอดรหัส

วิธีเข้ารหัส Mailto: ลิงก์กับหัวเรื่อง ตัวแบ่งบรรทัดเนื้อหา และเครื่องหมายและ

· เหตุใดจึงสำคัญ

เมลโต้ การเข้ารหัส URL html

โครงสร้างลิงก์ Mailto พร้อมหัวเรื่องและเนื้อหาที่เข้ารหัส
ภาพประกอบเวกเตอร์ต้นฉบับ ToolAcre

mailto: ลิงก์ที่มีหัวเรื่องและเนื้อหาเป็น URL ดังนั้นการเว้นวรรค การขึ้นบรรทัดใหม่ และ & จะต้องเข้ารหัสเป็นเปอร์เซ็นต์ โพสต์นี้จะแสดงสิ่งที่ขาดหายไปและวิธีสร้างลิงก์ที่เปิดอย่างถูกต้องในโปรแกรมรับส่งเมล

ลิงก์ผู้ติดต่อที่มีหัวเรื่องหยุดอยู่ที่ช่องว่างแรก — mailto ที่เสียหายอย่างเป็นรูปธรรม: และสิ่งที่โปรแกรมรับส่งเมลได้รับ

ลิงก์ติดต่อ เช่น <a href="mailto:test@example.com?subject=Support Inquiry">Send</a> ใช้งานไม่ได้เนื่องจากการเว้นวรรคใน "ข้อซักถามเกี่ยวกับการสนับสนุน" จะยุติลิงก์ในโปรแกรมรับส่งเมล ลูกค้าหลายรายได้รับเฉพาะ "การสนับสนุน" ตามหัวข้อเท่านั้น สิ่งนี้เกิดขึ้นเนื่องจากลิงก์ mailto: ตาม RFC 6068 โดยระบุว่าช่องว่างและอักขระพิเศษจำเป็นต้องมีการเข้ารหัสเปอร์เซ็นต์ในพารามิเตอร์การสืบค้น เครื่องหมายและต้องมีการเข้ารหัส %26 เพื่อหลีกเลี่ยงการเป็นตัวคั่นพารามิเตอร์

mailto ที่เสียหาย: ลิงก์แสดงให้เห็นถึงปัญหาอย่างชัดเจน ลิงก์ที่สร้างขึ้น เช่น <a href="mailto:test@example.com?subject=Support Inquiry&body=Reply">Contact</a> จะให้ผลลัพธ์เป็นข้อความที่มีหัวเรื่อง "การสนับสนุน" เท่านั้น การทดสอบในโปรแกรมรับส่งเมลที่แตกต่างกันเผยให้เห็นความทนทานที่แตกต่างกัน: Apple Mail จัดการลิงก์บางส่วน, Gmail แสดงเฉพาะ "การสนับสนุน", Outlook ล้มเหลวโดยสิ้นเชิง

mailto: เป็นรูปแบบ URL — RFC 6068 โดยย่อ และส่วนใดเป็นสตริงการสืบค้น

RFC 6068 กำหนด mailto: URL รูปแบบที่มีกฎการเข้ารหัสเฉพาะส่วนประกอบ ไม่เหมือนกับ URL ทั่วไป mailto: มีกฎเฉพาะสำหรับแต่ละองค์ประกอบ ส่วนที่อยู่ (test@example.com) ยังคงไม่มีการเข้ารหัส @ และโดเมนมีโครงสร้าง พารามิเตอร์การค้นหา (หัวเรื่อง, เนื้อหา, สำเนาลับ, สำเนาลับ) จำเป็นต้องมีการเข้ารหัส RFC 6068 อ้างอิง RFC 3986 สำหรับกฎ กำหนดให้มีการเข้ารหัสเปอร์เซ็นต์สำหรับการเว้นวรรคและอักขระพิเศษ เครื่องหมายและภายในค่าจะกลายเป็น %26 เมื่อปรากฏเป็นข้อมูล ไม่ใช่ตัวคั่น

ทำความเข้าใจกับโครงสร้าง mailto: ช่วยป้องกันข้อผิดพลาดในการเข้ารหัส แบบฟอร์มคือ: mailto:address?parameter1=value1&parameter2=value2 เครื่องหมายคำถามแนะนำส่วนข้อความค้นหา พารามิเตอร์การแยกเครื่องหมายและยังคงไม่มีการเข้ารหัส เฉพาะเครื่องหมายและภายในค่าที่เข้ารหัสเป็น %26 หากหัวเรื่องมีคำว่า "Tom & Jerry" ให้เข้ารหัสเป็น Tom%20%26%20Jerry เครื่องหมายแอมเปอร์แซนด์ระหว่างหัวเรื่องและเนื้อหายังคงไม่มีการเข้ารหัส การเข้ารหัสแบบซ้อนนี้เกิดข้อผิดพลาดได้ง่าย

การเข้ารหัสหัวเรื่องและเนื้อหา — ช่องว่างเป็น %20 ตัวแบ่งบรรทัดเป็น %0D%0A และ & เป็น %26 ค่าภายใน

การเข้ารหัสหัวเรื่องและเนื้อหาต้องมีการจัดการช่องว่างและอักขระพิเศษอย่างระมัดระวัง ช่องว่างกลายเป็น %20 ใน mailto: ลิงก์ ไม่ใช่เครื่องหมายบวกซึ่งต่างจากแบบฟอร์ม HTML ความแตกต่างที่สำคัญนี้ทำให้นักพัฒนาคุ้นเคยกับแบบฟอร์มบนเว็บ ตัวแบ่งบรรทัดเข้ารหัสเป็น %0D%0A (CRLF ลงท้ายบรรทัดในอีเมล) เครื่องหมายแอมเพอร์แซนด์กลายเป็น %26 เครื่องหมายเปอร์เซ็นต์กลายเป็น %25 โดยทั่วไปหัวเรื่องจะมีการเว้นวรรค การเน้นเสียง และวงเล็บ เนื้อหาประกอบด้วยช่องว่าง การเน้นเสียง และการแบ่งบรรทัด

การเข้ารหัสทั่วไปในลิงก์ mailto: ประกอบด้วย: ช่องว่างเป็น %20, ขึ้นบรรทัดใหม่เป็น %0D%0A, เครื่องหมายและเป็น %26, เปอร์เซ็นต์เป็น %25, แฮชเป็น %23, คำถามเป็น %3F สำเนียงที่ไม่ใช่ ASCII ชอบจะแปลงเป็น UTF-8 ไบต์ก่อน จากนั้นจึงเข้ารหัสเปอร์เซ็นต์ "รายงาน Über" กลายเป็น %C3%9ber%20รายงาน "สวัสดี! ลาก่อน" กลายเป็น สวัสดี%21%0D%0Aลาก่อน เข้ารหัสเฉพาะค่า ไม่ใช่โครงสร้าง ? และ & ตัวอักษร

ตัวอย่างการทำงาน: การสร้างลิงก์ที่มีหัวเรื่อง เนื้อหาสองบรรทัด และ cc — ผลลัพธ์ที่เข้ารหัสและลักษณะที่ปรากฏในเมลไคลเอ็นต์

ตัวอย่างการทำงาน: การสร้างลิงก์กับหัวเรื่อง "วาระการประชุม (กันยายน)", เนื้อหา "ให้เราหารือกัน: เป้าหมายรายไตรมาส" และ 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 เปิดหน้าต่างเขียนพร้อมหัวเรื่องที่ถูกต้อง เนื้อหาสองบรรทัด และสำเนา Outlook แสดงผลลัพธ์ที่คล้ายกัน Apple Mail ต้องการการอนุญาต ลูกค้าเก่าล้มเหลวในการขาดการสนับสนุนทางร่างกาย

ทำไม + ผิดที่นี่ — mailto: ติดตาม RFC 3986 ไม่ใช่การเข้ารหัสรูปแบบ ดังนั้น + จึงเป็นข้อดี

เหตุใดเครื่องหมายบวกจึงผิด — mailto: ติดตาม RFC 3986 ไม่ใช่การเข้ารหัสรูปแบบ ดังนั้น plus ยังคงเป็นตัวอักษร—ทำให้ความแตกต่างที่สำคัญชัดเจนขึ้น HTML การเข้ารหัสแบบฟอร์มใช้เครื่องหมายบวกสำหรับการเว้นวรรคในสตริงการสืบค้น RFC 3986 และ RFC 6068 ทั้งคู่ระบุ %20 สำหรับการเว้นวรรค mailto: with subject="Meeting+Agenda" จะสร้างหัวเรื่องที่มีเครื่องหมายบวกตามตัวอักษร ไม่ใช่การเว้นวรรค ข้อผิดพลาดนี้เกิดขึ้นขณะคัดลอกตรรกะการเข้ารหัสแบบฟอร์มไปยัง mailto: รุ่น บวกหมายถึงบวก ไม่ใช่ช่องว่าง

เหตุใดจึงสำคัญ: นักพัฒนาคัดลอกแบบฟอร์ม GET ตรรกะการส่งไปยัง mailto: ลิงก์ตัวหยุดการสร้าง หัวข้อ "วาระการประชุม" จะกลายเป็น "การประชุม+วาระการประชุม" ในรูปแบบ ในลิงก์ mailto: จะสร้าง "การประชุม+วาระ" พร้อมข้อดีที่แท้จริง ผู้ใช้แก้ไขหัวเรื่องด้วยตนเอง การทดสอบ mailto: ลิงก์จำเป็นต้องคลิกหรือตรวจสอบลิงก์ที่สร้างขึ้น ไม่ใช่การวิเคราะห์กฎของแบบฟอร์ม

ข้อผิดพลาดทั่วไป — ลืม HTML- หลีกเลี่ยงตัวคั่น & ใน href และเข้ารหัสเปอร์เซ็นต์ @ ในที่อยู่

mailto ทั่วไป: ข้อผิดพลาดในการสร้างรวมถึงการลืม HTML เครื่องหมายและ Escape ในแอตทริบิวต์ href ใน HTML เครื่องหมายและในแอตทริบิวต์ควรเป็น &amp; สำหรับ XHTML ที่ถูกต้อง href="mailto:address?subject=Test&body=Test" ไม่ถูกต้อง HTML; ควรเป็น href="mailto:address?subject=Test&amp;body=Test" นี่แสดงถึงการเข้ารหัสที่แตกต่างจากการเข้ารหัส URL HTML parsers ตีความ &amp; เป็น & ก่อนที่เบราว์เซอร์จะประมวลผล URL

การทดสอบข้อผิดพลาดเหล่านี้จำเป็นต้องตรวจสอบแหล่งที่มา HTML และคอนโซลของเบราว์เซอร์ คลิกขวาและเลือก "ตรวจสอบองค์ประกอบ" เพื่อดูค่า href จริง คัดลอกและวางค่า href ลงในแถบที่อยู่ (โดยมี mailto: นำหน้า) และตรวจสอบโปรแกรมรับส่งเมล ลิงก์อีเมลบางรายการใช้งานได้ในบางเบราว์เซอร์ แต่ไม่ใช่ในเบราว์เซอร์อื่น การทดสอบอัตโนมัติเป็นเรื่องยากเนื่องจาก Mailto: เกี่ยวข้องกับไคลเอนต์ภายนอก ทำให้การตรวจสอบด้วยตนเองเป็นเรื่องธรรมดา

สิ่งนี้ไม่ครอบคลุมถึงความแตกต่างในการสนับสนุนเมลไคลเอ็นต์และผู้รับหลายรายในเชิงลึก

สิ่งที่ไม่ครอบคลุมถึงความแตกต่างในการสนับสนุนเมลไคลเอ็นต์และผู้รับหลายราย ไคลเอ็นต์ไม่ทั้งหมดสนับสนุนพารามิเตอร์ RFC 6068 เท่าๆ กัน พารามิเตอร์ body ได้รับการรองรับในวงกว้าง แต่ไคลเอนต์รุ่นเก่าบางรายเพิกเฉยต่อมัน พารามิเตอร์ cc และ bcc มีการรองรับตัวแปร ผู้รับหลายคนกำหนดให้ที่อยู่อีเมลคั่นด้วยเครื่องหมายจุลภาค โดยเข้ารหัสเครื่องหมายจุลภาคเป็น %2C สำหรับที่อยู่ที่ซับซ้อน สถานที่ที่แตกต่างกันต้องมีการเข้ารหัส UTF-8 ที่เหมาะสมสำหรับการแสดงผล

วิวัฒนาการของไคลเอ็นต์เมลส่งผลต่อ Mailto: พฤติกรรมข้ามแพลตฟอร์ม ไคลเอ็นต์เว็บเมลสมัยใหม่ (Gmail, Outlook.com) มีการปฏิบัติตามข้อกำหนด RFC 6068 ได้ดีกว่าไคลเอ็นต์เดสก์ท็อปรุ่นเก่า บางครั้งไคลเอนต์มือถือก็มีการแยกวิเคราะห์ที่เข้มงวดกว่า บางตัวรองรับ Rich Text ในขณะที่บางตัวรองรับเฉพาะข้อความธรรมดาเท่านั้น นักพัฒนาซอฟต์แวร์ควรทดสอบกับโปรแกรมรับส่งเมลที่ผู้ชมใช้จริง การใช้งานจริงจะแตกต่างกันไปแม้จะมีข้อกำหนด RFC 6068 ก็ตาม

ประเด็นสำคัญ: เข้ารหัสแต่ละค่า เก็บโครงสร้างไว้ — วิธีที่โหมดค่าเดียวของตัวเข้ารหัสและตัวถอดรหัส URL ให้คุณใส่หัวเรื่องและเนื้อหาที่เข้ารหัสเพื่อวาง

ประเด็นสำคัญ: เข้ารหัสแต่ละค่า เก็บโครงสร้างไว้ โหมดตัวเข้ารหัสและตัวถอดรหัสค่าเดียว URL จะสร้างหัวเรื่องและเนื้อหาที่เข้ารหัสพร้อมที่จะวางลงในลิงก์ เครื่องมือยอมรับค่าที่ไม่ได้เข้ารหัส เช่น "วาระการประชุม (กันยายน)" และสร้าง "Meeting%20agenda%20%28Sept%29" คัดลอกเอาต์พุตโดยตรงไปยังแอตทริบิวต์ mailto: href สำหรับเนื้อหาที่มีหลายบรรทัด ให้วางเวอร์ชันข้อความธรรมดาที่มีการขึ้นบรรทัดใหม่ เพื่อรับเวอร์ชันที่เข้ารหัส %0D%0A

แนวทางปฏิบัติที่ดีที่สุดคือการรวบรวม mailto: ลิงก์จากส่วนที่เข้ารหัสแทนที่จะสร้างด้วยตนเอง เมื่อสร้าง HTML แบบไดนามิกใน JavaScript หรือเทมเพลต ให้เข้ารหัสแต่ละพารามิเตอร์แยกกันก่อนที่จะเชื่อมต่อกับ & ตัวคั่น สำหรับ HTML แบบคงที่ ตัวเข้ารหัสและตัวถอดรหัส URL จะทดสอบการเข้ารหัสก่อนเขียนด้วยลายมืออย่างน่าเชื่อถือ กระบวนการเข้ารหัสเอกสารในความคิดเห็นของโค้ด ทดสอบลิงก์ mailto: ผลลัพธ์โดยการคลิกลิงก์เหล่านั้นกับโปรแกรมรับส่งเมลจริงก่อนใช้งาน