ตัวเข้ารหัส URL

ตัวเข้ารหัส URL เป็นเครื่องมือฟรีที่แปลงสตริงให้อยู่ในรูปแบบการเข้ารหัสฟอร์ม ซึ่งใช้กับพารามิเตอร์การค้นหาของ URL และข้อมูลเว็บแบบข้อความประเภทอื่นๆ

การเข้ารหัส URL คืออะไร และใช้ทำไม?

การเข้ารหัส URL จะแทนที่อักขระที่มีความหมายพิเศษใน URL ด้วยเครื่องหมายเปอร์เซ็นต์ตามด้วยเลขฐานสิบหก วิธีนี้ช่วยให้ส่งข้อความผ่านระบบที่รองรับอักขระเพียงบางชุดได้

ตัวอย่างเช่น เครื่องหมายแอมเพอร์แซนด์ใช้คั่นพารามิเตอร์การค้นหา ดังนั้นหากเครื่องหมายนี้เป็นส่วนหนึ่งของค่า จะต้องเข้ารหัสเป็น %26 ส่วนช่องว่างก็ต้องจัดการเป็นพิเศษเช่นกัน เครื่องมือนี้ใช้ฟังก์ชัน urlencode ของ PHP ซึ่งจะแปลงช่องว่างเป็นเครื่องหมายบวก

ก่อนเข้ารหัส: tea and cake

หลังเข้ารหัส: tea+and+cake

คุณอาจพบข้อความที่เข้ารหัส URL อยู่ใน:

• สตริงการค้นหาที่ส่งมาจากเว็บฟอร์ม
• URI ข้อมูลที่มีข้อความซึ่งไม่สามารถใส่ลงไปตรงๆ ได้
• ลิงก์ในข้อความอีเมล
• ค่า URL ที่จัดเก็บอยู่ในเพย์โหลด JSON
• พารามิเตอร์การเปลี่ยนเส้นทางและพารามิเตอร์ callback ที่เว็บแอปพลิเคชันใช้
• URL ที่เชื่อมโยงกับชื่อโดเมนสากล แม้ว่าตัวชื่อโดเมนเองอาจต้องใช้ Punycode แทนการเข้ารหัสแบบเปอร์เซ็นต์

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

ใช้ตัวเข้ารหัส URL อย่างไร?

ป้อนสตริงที่ต้องการเข้ารหัส เรียกใช้เครื่องมือ แล้วดูค่าที่แปลงแล้วในช่องผลลัพธ์ เข้ารหัส URL ให้เข้ารหัสเฉพาะค่านั้น ไม่ต้องรวมเครื่องหมายอัญประกาศหรือข้อความอธิบายที่อยู่รอบๆ

การประมวลผลเกิดขึ้นบนเซิร์ฟเวอร์ ข้อมูลที่คุณป้อนจะส่งไปยังเซิร์ฟเวอร์ผ่าน HTTPS และไม่มีการจัดเก็บไว้ ถึงอย่างนั้นก็ไม่ควรใส่รหัสผ่าน โทเค็นเซสชัน หรือข้อมูลส่วนบุคคลที่เป็นความลับลงใน URL เพราะที่อยู่เว็บอาจปรากฏในประวัติของเบราว์เซอร์ ระบบวิเคราะห์ข้อมูล และบันทึกของเซิร์ฟเวอร์

หากต้องการย้อนกระบวนการ ให้ใช้ตัวถอดรหัส URL ค่าที่ถอดรหัสอย่างถูกต้องควรตรงกับข้อความต้นฉบับ ตราบใดที่ทั้งสองขั้นตอนใช้การเข้ารหัสอักขระและกฎการเข้ารหัสฟอร์มแบบเดียวกัน

ควรเข้ารหัส URL ทั้งหมดหรือเฉพาะค่าพารามิเตอร์?

โดยทั่วไปควรเข้ารหัสค่าของพารามิเตอร์แต่ละตัว ไม่ใช่ URL ทั้งหมด เพราะการเข้ารหัสที่อยู่ทั้งชุดจะแทนที่อักขระที่กำหนดโครงสร้างด้วย เช่น เครื่องหมายทวิภาค เครื่องหมายทับ เครื่องหมายคำถาม และเครื่องหมายเท่ากับ

สมมติว่าค่าที่ใช้ค้นหาคือ green tea & coffee รูปแบบที่เข้ารหัสแล้วคือ green+tea+%26+coffee ซึ่งนำไปวางต่อท้ายชื่อพารามิเตอร์ได้ หากเข้ารหัสที่อยู่ทั้งหมด ตัวคั่นที่เบราว์เซอร์ต้องใช้เพื่อแยกโปรโตคอล โฮสต์ พาธ และสตริงการค้นหาจะถูกบดบังไปด้วย

เครื่องมือนี้ใช้ urlencode จึงเหมาะกับพารามิเตอร์การค้นหาแบบฟอร์ม HTML อย่างไรก็ตาม API และส่วนพาธบางระบบใช้หลักเกณฑ์ของ RFC 3986 ซึ่งเขียนช่องว่างเป็น %20 แทน + ควรตรวจสอบว่าระบบปลายทางต้องการการเข้ารหัสฟอร์มที่ใช้ + หรือรูปแบบ RFC 3986 ที่ใช้ %20

ตัวอย่างการเข้ารหัส URL

ตัวอักษร ASCII และตัวเลขยังคงอ่านได้ตามเดิม ช่องว่างจะกลายเป็นเครื่องหมายบวก ส่วนเครื่องหมายวรรคตอนที่สงวนไว้และข้อความที่ไม่ใช่ ASCII จะแสดงเป็นไบต์ที่เข้ารหัสแล้ว

• hello world จะกลายเป็น hello+world
• tea & cake จะกลายเป็น tea+%26+cake
• email=test@example.com จะกลายเป็น email%3Dtest%40example.com
• 100% ready จะกลายเป็น 100%25+ready
• café จะกลายเป็น caf%C3%A9 เมื่อข้อความต้นฉบับใช้ UTF-8

ตัวอักษรที่มีเครื่องหมายกำกับและอักษรที่ไม่ใช่ละตินจะถูกแปลงเป็นไบต์ด้วยการเข้ารหัสอักขระก่อน ซึ่งบนเว็บมักใช้ UTF-8 จากนั้นแต่ละไบต์ที่อยู่นอกชุดที่อนุญาตจะถูกแทนด้วยรหัสเปอร์เซ็นต์ของตัวเอง ด้วยเหตุนี้ อักขระที่มองเห็นเพียงหนึ่งตัวจึงอาจกลายเป็นหลายกลุ่มที่ขึ้นต้นด้วย %

ตัวเลขไม่ต้องจัดการเป็นพิเศษ หากข้อมูลนำเข้าว่างเปล่า ผลลัพธ์ก็จะไม่มีเนื้อหาที่เข้ารหัส ข้อมูลนำเข้าที่ยาวมากอาจมีขนาดเพิ่มขึ้นมาก เพราะไบต์ที่เข้ารหัสแต่ละไบต์ใช้พื้นที่สามอักขระ

ทำไมถอดรหัส URL ไม่ได้หรือได้ข้อความอ่านไม่รู้เรื่อง?

สาเหตุที่พบบ่อยคือข้อมูลนำเข้าถูกเข้ารหัสด้วยกฎคนละแบบ ถูกเข้ารหัสซ้ำมากกว่าหนึ่งครั้ง หรือไม่ได้แทนข้อความด้วยชุดอักขระที่ระบบคาดไว้

• จัดการช่องว่างต่างกัน ตัวถอดรหัสฟอร์มจะตีความ + เป็นช่องว่าง แต่ตัวถอดรหัสเปอร์เซ็นต์แบบเคร่งครัดอาจคงไว้เป็นเครื่องหมายบวก
• เข้ารหัสซ้ำ เครื่องหมายเปอร์เซ็นต์ใน %26 สามารถถูกเข้ารหัสเป็น %25 ได้ จึงกลายเป็น %2526 เมื่อถอดรหัสหนึ่งรอบ ผลลัพธ์จะเป็น %26 แทนเครื่องหมายแอมเพอร์แซนด์เดิม
• ใช้การเข้ารหัสอักขระผิด หากถอดรหัสไบต์ UTF-8 ด้วยชุดอักขระอื่น อาจได้สัญลักษณ์ทดแทนหรือตัวอักษรที่ผิดเพี้ยน
• ข้อมูลเป็นไบนารี ไม่ใช่ข้อความ ไบต์ที่ถอดรหัสแล้วอาจเป็นรูปภาพ ไฟล์บีบอัด หรือไฟล์ชนิดอื่น เมื่อนำมาแสดงเป็นข้อความจึงอ่านไม่รู้เรื่อง
• ใช้รูปแบบหรือชุดอักขระผิด Base64 แบบปลอดภัยสำหรับ URL, Base64 มาตรฐาน และการเข้ารหัสแบบเปอร์เซ็นต์เป็นคนละรูปแบบกัน การใช้ตัวถอดรหัส URL กับข้อความ Base64 จะไม่คืนค่าที่ต้องการ

การเข้ารหัส URL ไม่มีอักขระสำหรับเติมเต็มข้อมูล หากตัวถอดรหัสแจ้งว่าไม่มี padding ข้อมูลนำเข้านั้นน่าจะเป็น Base64 หรือรูปแบบอื่นที่ใช้ padding ไม่ใช่ข้อความที่เข้ารหัสแบบเปอร์เซ็นต์

คำถามที่พบบ่อย

รหัสเปอร์เซ็นต์ที่ใช้ตัวพิมพ์ใหญ่กับตัวพิมพ์เล็กเหมือนกันไหม?

เหมือนกัน ตัวอักษรฐานสิบหกในรหัสเปอร์เซ็นต์ไม่แยกตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก ดังนั้นทั้ง %2F และ %2f จึงแทนเครื่องหมายทับเหมือนกัน อย่างไรก็ตาม แนะนำให้ใช้เลขฐานสิบหกแบบตัวพิมพ์ใหญ่เพื่อให้รูปแบบสม่ำเสมอ

ใช้การเข้ารหัส URL แปลงชื่อโดเมนสากลได้ไหม?

ไม่ได้ ป้ายกำกับโดเมน เช่น ชื่อที่มี é โดยทั่วไปต้องผ่านการประมวลผลชื่อโดเมนสากล และแปลงเป็น Punycode ในรูปแบบ ASCII ที่ขึ้นต้นด้วย xn-- การเข้ารหัสแบบเปอร์เซ็นต์ใช้กับส่วนอื่นของ URL และไม่ควรนำมาใช้แทนการแปลงดังกล่าว

ตัวแบ่งบรรทัดกับแท็บจะถูกแปลงเป็นอะไร?

ไบต์ของแท็บและตัวแบ่งบรรทัดจะถูกเข้ารหัสแบบเปอร์เซ็นต์ เพราะไม่สามารถใส่ลงในค่า URL ทั่วไปได้โดยตรง โดยทั่วไปแท็บจะแสดงเป็น %09 ส่วนอักขระจบบรรทัดจะขึ้นอยู่กับว่าต้นฉบับใช้ LF หรือ CRLF

ทำไมวาง URL ที่เข้ารหัสแล้วลงในแอป แต่ยังใช้งานไม่ได้?

แอปพลิเคชันอาจต้องการค่าดิบและทำการเข้ารหัสเอง จึงทำให้เกิดการเข้ารหัสซ้ำ นอกจากนี้ยังอาจปฏิเสธ URL เพราะที่อยู่มีความยาวเกินขีดจำกัดโดยรวม หรือเพราะอักขระสงวนในส่วนที่กำหนดโครงสร้างของที่อยู่ถูกเข้ารหัส ตรวจสอบก่อนว่าแอปพลิเคชันขอส่วนประกอบใดโดยเฉพาะ แล้วจึงเข้ารหัสส่วนนั้น

แชร์ข้อมูลสตริงการค้นหาที่เข้ารหัสแล้วได้อย่างปลอดภัยไหม?

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