เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ · URL ตัวเข้ารหัสและตัวถอดรหัส
ช่องว่างในลิงก์ดาวน์โหลดไฟล์: ทำไม %20, + และพื้นที่ดิบไม่เหมือนกัน
· เหตุใดจึงสำคัญ
การเข้ารหัส URL http นักพัฒนาเวิร์กโฟลว์
ไฟล์ชื่อ 'รายงานไตรมาส 3 (ฉบับสุดท้าย).pdf' สามารถเชื่อมโยงได้ 3 วิธี และมีเพียงวิธีเดียวเท่านั้นที่ถูกต้อง โพสต์นี้จะอธิบายว่าทำไมชื่อไฟล์จึงทำให้ลิงก์ดาวน์โหลดเสียหาย และวิธีการเข้ารหัสเพื่อให้ลูกค้าทุกคนเห็นด้วย
การดาวน์โหลดที่ล้มเหลวสำหรับผู้ใช้บางรายและใช้ได้กับผู้อื่น — ชื่อไฟล์ที่มีการเว้นวรรคและเครื่องหมายบวก
ไฟล์เช่น "Q3 report.pdf" ทำงานได้ดีเมื่อจัดเก็บไว้ในเครื่อง แต่ล้มเหลวผ่านลิงก์ดาวน์โหลดสำหรับผู้ใช้บางราย ในขณะที่ผู้อื่นทำได้สำเร็จโดยไม่มีปัญหา ช่องว่างไม่ถูกต้องใน URL ตามข้อกำหนด RFC 3986 เบราว์เซอร์ยอมรับสิ่งเหล่านี้ในแถบที่อยู่ แต่ไคลเอนต์ HTTP ปฏิเสธอย่างเข้มงวด การทำความเข้าใจ %20 รวมถึงเครื่องหมายบวก และพื้นที่ดิบถือเป็นสิ่งสำคัญอย่างยิ่งสำหรับการจัดจำหน่ายที่เชื่อถือได้ ความแตกต่างระหว่างวิธีการเข้ารหัสส่งผลโดยตรงต่ออัตราความสำเร็จในการดาวน์โหลดบนแพลตฟอร์มต่างๆ เครื่องมืออัตโนมัติต่างๆ และการใช้งานไคลเอ็นต์ HTTP ทั่วโลก นักพัฒนาจะต้องเข้าใจความแตกต่างนี้เมื่อสร้างระบบดาวน์โหลด บริบทมีความสำคัญสำหรับตัวเลือกการเข้ารหัสและความเข้ากันได้ของระบบ
นักพัฒนาจะต้องเลือกระหว่างช่องว่าง %20 หรือเครื่องหมายบวกเมื่อสร้างลิงก์ดาวน์โหลด การทดสอบด้วย curl, wget และ Python เผยให้เห็นว่าไคลเอนต์ใดบังคับใช้การปฏิบัติตาม RFC การดาวน์โหลดเบราว์เซอร์สำเร็จเนื่องจากการกู้คืนข้อผิดพลาด แต่การรวม API ล้มเหลวเมื่อพบช่องว่างที่ไม่ได้เข้ารหัส
เหตุใดพื้นที่ดิบจึงไม่ถูกต้องใน URL — และเหตุใดเบราว์เซอร์จึงยอมรับพื้นที่ดังกล่าวในแถบที่อยู่ แต่ไคลเอ็นต์ HTTP ไม่ยอมรับ
ช่องว่างใน URL มีรากฐานทางประวัติศาสตร์ในการออกแบบโปรโตคอล ระบบสำรวจ URL ที่ใช้ช่องว่างเป็นตัวคั่นระหว่างโทเค็น ช่องว่างใน URL อาจถูกตีความผิดว่าเป็นตัวสิ้นสุด ไคลเอนต์ HTTP ที่อ่านจากบรรทัดคำสั่งจะถูกตัดทอนที่ช่องว่างแรก การออกแบบพื้นฐานนี้ยังคงอยู่ในการใช้งานโปรโตคอลและไม่น่าจะเปลี่ยนแปลง
เบราว์เซอร์ยอมรับพื้นที่ดิบผ่านการแปลงแบบไม่มีการโต้ตอบเป็น %20 ก่อนที่จะส่งคำขอ HTTP พฤติกรรมที่เป็นมิตรต่อผู้ใช้นี้จะซ่อนข้อกำหนดของโปรโตคอลไม่ให้ผู้ใช้ปลายทางวาง URL ลงในแถบที่อยู่ ระบบอัตโนมัติไม่มีชั้นการกู้คืนนี้ สคริปต์ล้มเหลวใน URL ที่มีช่องว่าง ไคลเอนต์อีเมลพบความล้มเหลวในการเปิดลิงก์ดังกล่าว
%20 เทียบกับ + ในส่วนของเส้นทาง - แบบแผนการเข้ารหัสแบบฟอร์มที่ใช้ไม่ได้กับเส้นทาง
%20 กับเครื่องหมายบวกแสดงถึงความแตกต่างพื้นฐานในบริบทการเข้ารหัส URL ในส่วนของเส้นทาง การเว้นวรรคต้องเข้ารหัสเป็น %20 ต่อ RFC 3986 เครื่องหมายบวกไม่ใช่การเข้ารหัสช่องว่างในเส้นทาง แบบแผนนี้มีต้นกำเนิดในการเข้ารหัสแบบฟอร์ม HTML โดยทำหน้าที่เป็นการเข้ารหัสช่องว่างในสตริงการสืบค้น นักพัฒนามักจะนำกฎของแบบฟอร์มไปใช้กับเส้นทางอย่างไม่ถูกต้อง
แบบแผนการเข้ารหัสแบบฟอร์มที่อนุญาตให้มีเครื่องหมายบวกไม่สามารถใช้กับเส้นทางที่มีข้อกำหนดทางโครงสร้างที่แตกต่างกัน ในสตริงแบบสอบถาม พารามิเตอร์เครื่องหมายและเท่ากับตัวคั่น การใช้เครื่องหมายบวกเพื่อเว้นวรรคในค่าการสืบค้นจะไม่ทำให้เกิดความคลุมเครือ เนื่องจากเครื่องหมายบวกไม่ใช่ตัวคั่น ในเส้นทาง บวก ไม่มีความหมายพิเศษ การผสมผสานแบบแผนทำให้เกิดลิงก์ดาวน์โหลดที่เสียหาย
ชื่อไฟล์ที่ไม่ใช่ ASCII — UTF-8 การเข้ารหัสเปอร์เซ็นต์และคีย์การจัดเก็บอ็อบเจ็กต์ที่เก็บชื่อดิบ
ชื่อไฟล์ที่ไม่ใช่ ASCII ต้องมีการเข้ารหัส UTF-8 เปอร์เซ็นต์ก่อนที่จะส่งผ่าน URL อย่างปลอดภัย ชื่อไฟล์เช่น "Über report.pdf" มี "Ü" (U+00DC) อยู่นอกช่วง ASCII UTF-8 การเข้ารหัสแปลงสิ่งนี้เป็นไบต์ C3 9C ไบต์เหล่านี้เข้ารหัสเปอร์เซ็นต์เป็น %C3%9C ใน URL แต่ละ UTF-8 ไบต์จะได้รับแฝดของตัวเอง ทำให้มีชื่อไฟล์ที่เข้ารหัสยาวขึ้น
บริการพื้นที่จัดเก็บอ็อบเจ็กต์ เช่น Amazon S3 นำเสนอกรณีที่น่าสนใจสำหรับชื่อไฟล์ที่ไม่ใช่ ASCII บางระบบอนุญาตให้มีไบต์ UTF-8 แบบดิบในคีย์ ในขณะที่บางระบบจำเป็นต้องมีการเข้ารหัสเปอร์เซ็นต์ กลยุทธ์การเข้ารหัสขึ้นอยู่กับผู้ให้บริการพื้นที่เก็บข้อมูลและการใช้งาน URL การเข้าถึงแบบ URL ต้องใช้การเข้ารหัสเปอร์เซ็นต์ UTF-8 นักพัฒนาจะต้องประสานพื้นที่เก็บข้อมูลและเลเยอร์การสร้าง URL
ตัวอย่างการทำงาน: การเข้ารหัส 'Über Q3 report (final)+notes.pdf' สำหรับพาธ — เอาต์พุตที่แน่นอนและเหตุใด + จึงต้องกลายเป็น %2B
ตัวอย่างการทำงาน: การเข้ารหัส "Über report (final)+notes.pdf" แสดงให้เห็นถึงการเข้ารหัสที่สมบูรณ์ ชื่อไฟล์มีการเว้นวรรค อักขระที่ไม่ใช่ ASCII และเครื่องหมายบวกตามตัวอักษร UTF-8 การเข้ารหัสของ "Ü" จะสร้าง %C3%9C ในการเข้ารหัสเส้นทาง ช่องว่างจะกลายเป็น %20 (ไม่เหมือนกับการเข้ารหัสแบบฟอร์มโดยใช้เครื่องหมายบวก) เครื่องหมายบวกกลายเป็น %2B วงเล็บเข้ารหัสเป็น %28 และ %29 ผลลัพธ์: %C3%9CberQ3%20รายงาน%20%28สุดท้าย%29%2Bnotes.pdf
การทดสอบด้วยตัวเข้ารหัสและตัวถอดรหัส URL แสดงการเปลี่ยนแปลงที่แน่นอน การวางชื่อไฟล์ลงในโหมดค่าเดียวจะสร้างส่วนที่เข้ารหัสเป็นเปอร์เซ็นต์ที่ถูกต้องโดยใช้กฎเส้นทาง เครื่องมือจะรักษาตัวคั่นเส้นทางในขณะที่เข้ารหัสเฉพาะส่วนประกอบชื่อไฟล์ การเปรียบเทียบอินพุตและเอาต์พุตด้วยภาพทำให้กฎมีความชัดเจนและตรวจสอบได้ก่อนการผลิต เปรียบเทียบสิ่งนี้กับโหมดแบบฟอร์มเพื่อดูความแตกต่างของบริบท
พารามิเตอร์ Content-Disposition และ filename* — การเข้ารหัสแยกต่างหากสำหรับพร้อมท์การดาวน์โหลด ซึ่งกล่าวถึงเพื่อความสมบูรณ์
พารามิเตอร์การจัดการเนื้อหาและชื่อไฟล์* แสดงถึงเลเยอร์การเข้ารหัสทางเลือกสำหรับพร้อมท์การดาวน์โหลด เซิร์ฟเวอร์รวมส่วนหัวการจัดการเนื้อหาที่ระบุชื่อไฟล์สำหรับกล่องโต้ตอบการดาวน์โหลด พารามิเตอร์ชื่อไฟล์ใช้การเข้ารหัส RFC 2183 ในขณะที่ชื่อไฟล์* ใช้ RFC 5987 พร้อมการเข้ารหัสเปอร์เซ็นต์ เบราว์เซอร์จะตีความส่วนหัวเหล่านี้เพื่อตัดสินใจชื่อไฟล์บันทึก ชื่อไฟล์เดียวกันเข้ารหัสสองครั้งด้วยรูปแบบที่แตกต่างกัน
การเข้ารหัสสองชั้นสร้างโอกาสในการเกิดข้อผิดพลาดในการแปลงรหัส URL ชื่อไฟล์ที่เข้ารหัสและเข้ารหัสส่วนหัวอาจไม่ไปกลับอย่างถูกต้องหากเซิร์ฟเวอร์และไคลเอนต์ไม่เห็นด้วย เพื่อความเข้ากันได้สูงสุด นักพัฒนาควรเข้ารหัสชื่อไฟล์ในเส้นทาง URL โดยใช้การเข้ารหัส %20 และ UTF-8 เปอร์เซ็นต์ และตั้งค่าส่วนหัวการจัดการเนื้อหาด้วยชื่อไฟล์ที่ถอดรหัสแล้ว ซึ่งจะทำให้ไคลเอ็นต์และเบราว์เซอร์ HTTP ทั้งหมดทำงานได้อย่างถูกต้อง
สิ่งนี้ไม่ครอบคลุม — ชื่อไฟล์ที่สงวนไว้บนระบบปฏิบัติการเฉพาะและลักษณะเฉพาะของผู้ให้บริการจัดเก็บข้อมูล
ชื่อไฟล์ที่สงวนไว้บนระบบปฏิบัติการเฉพาะจะเพิ่มความซับซ้อนให้กับการเข้ารหัส URL Windows สงวนชื่อเช่น CON, PRN และ AUX สำหรับอุปกรณ์ ไฟล์ชื่อ "CON.pdf" ตามตัวอักษรไม่สามารถมีอยู่ใน NTFS macOS มีรูปแบบการตั้งชื่อและกฎคุณลักษณะเพิ่มเติม Linux คำนึงถึงขนาดตัวพิมพ์ ชื่อไฟล์ที่เข้ารหัส URL ที่ถูกต้องอาจไม่ถูกต้องสำหรับการจัดเก็บในบางระบบ
นิสัยใจคอของผู้ให้บริการพื้นที่จัดเก็บข้อมูลเพิ่มความซับซ้อนให้กับการกระจายข้ามแพลตฟอร์ม Amazon S3 ยอมรับคีย์ UTF-8 และคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ Google Cloud Storage มีพฤติกรรมคล้ายกันโดยมีข้อจำกัดเพิ่มเติม Azure Blob Storage มีกฎอักขระที่แตกต่างกัน ชื่อไฟล์ที่ทำงานบน S3 อาจล้มเหลวบน Azure สถาปนิกจะต้องตรวจสอบเอกสารของผู้ให้บริการและทดสอบด้วยชื่อไฟล์ที่ไม่ใช่ ASCII จริง
ประเด็นสำคัญ: เข้ารหัสส่วน ไม่ใช่ URL — วิธีการที่โหมดค่าเดียวของตัวเข้ารหัสและตัวถอดรหัสของ URL สร้างชื่อไฟล์ที่ปลอดภัยต่อเส้นทาง
ประเด็นสำคัญ: เข้ารหัสส่วน ไม่ใช่ URL—โหมดค่าเดียวของตัวเข้ารหัสและตัวถอดรหัส URL จะสร้างชื่อไฟล์ที่ปลอดภัยต่อเส้นทาง เครื่องมือนี้ยอมรับชื่อไฟล์ดิบและสร้างส่วนที่เข้ารหัสเป็นเปอร์เซ็นต์ ซึ่งจะป้องกันการเข้ารหัสซ้ำและการผสมบริบท การใช้โหมดค่าเดียวจะหลีกเลี่ยงเส้นทางที่สมดุล การสืบค้น และกฎการเข้ารหัสส่วนย่อย กลุ่มที่สร้างขึ้นสามารถแทรกลงใน URL ได้อย่างปลอดภัย
แนวทางปฏิบัติที่ดีที่สุดคือการเข้ารหัสชื่อไฟล์โดยที่เข้าสู่โครงสร้าง URL อย่าถือว่าเบราว์เซอร์แก้ไขปัญหาการเข้ารหัส ทดสอบกับไคลเอนต์ HTTP จริงที่ใช้โดยผู้ใช้เป้าหมาย: curl, wget, Python, Java httplib และ API การดึงข้อมูลของเบราว์เซอร์ ตรวจสอบชื่อไฟล์ที่รอดจากการสะดุดทั่วทั้งระบบ URL ตัวเข้ารหัสและตัวถอดรหัสเป็นจุดเริ่มต้นที่รับประกันความถูกต้อง