ตัวเข้ารหัส URL
แปลงข้อความเป็นรูปแบบที่ปลอดภัยสำหรับ URL โดยการเข้ารหัสอักขระพิเศษ
ป้อนข้อความที่จะเข้ารหัส:
วิธีใช้ URL Encoder / Decoder
- 1
ป้อนข้อความหรือ URL ของคุณ
วางข้อความที่ต้องการ encode หรือสตริงที่ encode แบบ URL ที่ต้องการ decode ลงในช่องป้อนข้อมูล
- 2
เลือก encode หรือ decode
เลือก Encode เพื่อแปลงข้อความเป็นรูปแบบที่ปลอดภัยสำหรับ URL หรือ Decode เพื่อเปลี่ยนข้อความที่ encode แบบเปอร์เซ็นต์กลับเป็นปกติ
- 3
รันการแปลง
ประมวลผลข้อมูลที่ป้อนเพื่อแปลงในทิศทางที่เลือกทันที
- 4
คัดลอกผลลัพธ์
คัดลอกผลลัพธ์ที่ encode หรือ decode เพื่อใช้ในลิงก์ query string หรือคำขอ API
อธิบายการเข้ารหัส URL และการเข้ารหัสแบบเปอร์เซ็นต์
การเข้ารหัส URL คืออะไร
การเข้ารหัส URL หรือที่เรียกให้ตรงกว่าว่าการเข้ารหัสแบบเปอร์เซ็นต์ (percent-encoding) คือกลไกที่ทำให้ URL สามารถพกพาอักขระที่ปกติแล้วมันแสดงไม่ได้ URL ถูกจำกัดให้ใช้อักขระ ASCII เพียงชุดเล็ก ๆ และอักขระบางตัวในชุดนั้นก็มีความหมายเชิงโครงสร้างเป็นพิเศษ การเข้ารหัสแบบเปอร์เซ็นต์จะแทนอักขระที่เป็นปัญหาด้วยเครื่องหมายเปอร์เซ็นต์ ตามด้วยเลขฐานสิบหกสองหลักของค่าไบต์ของอักขระนั้น ดังนั้นช่องว่างจึงกลายเป็น %20 และเครื่องหมายแฮชจึงกลายเป็น %23
กฎเกณฑ์ต่าง ๆ ถูกกำหนดไว้ใน RFC 3986 ซึ่งเป็นมาตรฐานที่ควบคุมไวยากรณ์ของ URI เป้าหมายนั้นเรียบง่าย คือทำให้แน่ใจว่าค่าที่ใส่ไว้ภายใน URL ถูกส่งผ่านและแยกวิเคราะห์ได้ตรงตามเจตนาทุกประการ โดยไม่มีอักขระแปลกปลอมตัวใดถูกเข้าใจผิดว่าเป็นตัวคั่น หรือถูกซอฟต์แวร์ระหว่างทางตัดทิ้งไป
อักขระสงวนกับอักขระไม่สงวน
RFC 3986 แบ่งอักขระออกเป็นกลุ่ม ๆ ชุดอักขระไม่สงวน (unreserved) นั้นปลอดภัยเสมอและจะไม่ถูกเข้ารหัส ได้แก่ ตัวอักษร A-Z และ a-z, ตัวเลข 0-9 และเครื่องหมายอีกสี่ตัวคือ ยัติภังค์ (-), จุด (.), ขีดล่าง (_) และทิลเดอ (~) อักขระเหล่านี้ผ่านไปได้โดยไม่ถูกแตะต้อง เพราะไม่มีความหมายเชิงโครงสร้างใด ๆ และใช้ได้อย่างถูกต้องในทุกตำแหน่งของ URL
ส่วนชุดอักขระสงวน (reserved) คือเครื่องหมายวรรคตอนที่ใช้คั่นแต่ละส่วนของ URL ได้แก่ ตัวคั่นทั่วไป : / ? # [ ] @ และตัวคั่นย่อย ! $ และ & ' ( ) * + , ; = อักขระเหล่านี้ใช้เป็นตัวคั่นได้อย่างถูกต้อง แต่เมื่อมันปรากฏอยู่ภายในค่าหนึ่ง ๆ แทนที่จะทำหน้าที่เป็นตัวคั่น มันจะต้องถูกเข้ารหัสแบบเปอร์เซ็นต์เพื่อให้ตัวแยกวิเคราะห์ไม่อ่านผิด ตัวอย่างเช่น เครื่องหมายแอมเปอร์แซนด์ที่อยู่ภายในค่าของ query จะต้องกลายเป็น %26 มิฉะนั้นมันจะถูกอ่านว่าเป็นจุดเริ่มต้นของพารามิเตอร์ตัวใหม่
พื้นฐานบนไบต์ของ UTF-8
การเข้ารหัสแบบเปอร์เซ็นต์ทำงานกับไบต์ ไม่ใช่กับอักขระโดยตรง และ URL สมัยใหม่ใช้ UTF-8 เป็นแหล่งของไบต์ อักขระ ASCII หนึ่งตัวคือหนึ่งไบต์ ดังนั้นอักขระ ASCII ที่เข้ารหัสแล้วจึงเป็นเอสเคปแบบเปอร์เซ็นต์หนึ่งชุด ส่วนอักขระที่อยู่นอกเหนือ ASCII จะถูกแสดงเป็นลำดับไบต์ UTF-8 ก่อน จากนั้นแต่ละไบต์จึงถูกเข้ารหัสแบบเปอร์เซ็นต์แยกกัน ทำให้เกิดเอสเคปหนึ่งชุดต่อหนึ่งไบต์
ตัวอักษรที่มีเครื่องหมายกำกับเสียงอย่าง é คือตัวอย่างมาตรฐานที่ใช้อธิบาย ใน UTF-8 มันคือสองไบต์ 0xC3 และ 0xA9 ดังนั้นมันจึงเข้ารหัสแบบเปอร์เซ็นต์เป็น %C3%A9 นั่นคือสองเอสเคปสำหรับอักขระที่มองเห็นเพียงตัวเดียว ส่วนเครื่องหมายยูโรซึ่งเป็นสามไบต์ใน UTF-8 ก็กลายเป็น %E2%82%AC นี่คือเหตุผลว่าทำไมข้อความที่ไม่ใช่อักษรละตินจึงขยายขนาดขึ้นมากเมื่อถูกเข้ารหัส เพราะอักขระแต่ละตัวอาจกลายเป็นเอสเคปแบบเปอร์เซ็นต์สอง สาม หรือสี่ชุด ขึ้นอยู่กับความยาวของมันใน UTF-8
ตัวอย่างจริง: การเข้ารหัสค่าสำหรับการค้นหา
สมมติว่าคุณต้องการใส่วลี "Q&A: cats + dogs" ลงใน query string ตัวอักษร ตัวเลข และข้อความรอบ ๆ เครื่องหมายโคลอนจะคงอยู่เป็นคำตามเดิม แต่อักขระที่ไม่ปลอดภัยและอักขระสงวนจะถูก escape ช่องว่างจะกลายเป็น %20, แอมเปอร์แซนด์จะกลายเป็น %26, โคลอนจะกลายเป็น %3A และเครื่องหมายบวกจะกลายเป็น %2B เพราะถ้าปล่อยให้เป็นเครื่องหมายบวกตามตัวอักษร มันจะถูกอ่านว่าเป็นช่องว่างในข้อมูลแบบฟอร์ม
ผลลัพธ์ที่ได้คือ Q%26A%3A%20cats%20%2B%20dogs เมื่อนำไปใส่ในลิงก์เป็น ?q=Q%26A%3A%20cats%20%2B%20dogs เซิร์ฟเวอร์จะถอดรหัสมันกลับไปเป็นวลีต้นฉบับเดิมได้อย่างเป๊ะ ๆ สังเกตว่าอักขระสงวนทุกตัวที่ตั้งใจให้เป็นข้อมูล ไม่ใช่ตัวคั่น จะต้องถูกเข้ารหัสเพื่อให้รอดพ้นการเดินทางครั้งนี้ไปได้
ช่องว่าง: %20 กับเครื่องหมายบวก
ช่องว่างมีความพิลึกที่โด่งดังอยู่อย่างหนึ่ง ในส่วน path และในเกือบทุกส่วนของ URL ช่องว่างจะถูกเข้ารหัสเป็น %20 แต่ในรูปแบบ application/x-www-form-urlencoded ที่ใช้กับการส่งฟอร์ม HTML และ query string จำนวนมาก ช่องว่างกลับถูกเข้ารหัสเป็นเครื่องหมายบวก (+) ตามธรรมเนียมดั้งเดิม ทั้งสองธรรมเนียมยังถูกใช้งานอยู่จริง ซึ่งเป็นต้นเหตุของความสับสนอยู่บ่อยครั้ง
ผลที่ตามมาในทางปฏิบัติคือ เครื่องหมายบวกตามตัวอักษรในข้อมูลแบบฟอร์มจะต้องถูกเข้ารหัสเป็น %2B เพื่อไม่ให้ถูกเข้าใจผิดว่าเป็นช่องว่าง เมื่อคุณถอดรหัส คุณต้องรู้ว่าธรรมเนียมใดเป็นตัวสร้างสตริงนั้นขึ้นมา เครื่องหมายบวกในค่าของฟอร์มหมายถึงช่องว่าง ขณะที่เครื่องหมายบวกในที่อื่น ๆ มักหมายถึงเครื่องหมายบวกตามตัวอักษร เครื่องมือนี้จัดการการเข้ารหัสแบบเปอร์เซ็นต์มาตรฐาน เพื่อให้ค่าของคุณวนกลับไปกลับมาได้อย่างหมดจด
การเข้ารหัส URL ทั้งอันกับการเข้ารหัสค่าเดี่ยว
JavaScript เปิดให้ใช้ฟังก์ชันสองตัวที่ตรงกับงานสองแบบที่ต่างกัน และการเลือกผิดตัวก็คือบั๊กคลาสสิก encodeURI มีไว้สำหรับ URL ทั้งอัน มันจะปล่อยอักขระเชิงโครงสร้าง : / ? # & = ไว้เหมือนเดิมเพื่อให้ URL ยังทำงานได้ โดยเข้ารหัสเฉพาะอักขระที่ผิดกฎอย่างชัดเจน เช่น ช่องว่าง ส่วน encodeURIComponent มีไว้สำหรับข้อมูลชิ้นเดียว เช่น ค่าของ query หนึ่งค่า หรือส่วนหนึ่งของ path มันจะ escape ตัวคั่นที่เป็นอักขระสงวนด้วย ดังนั้นเครื่องหมายทับหรือแอมเปอร์แซนด์ที่ฝังอยู่ภายในจึงไม่สามารถทำให้ URL ที่ห่อหุ้มอยู่เสียได้
เครื่องมือนี้ทำการเข้ารหัสแบบ component คือพฤติกรรมของ encodeURIComponent ซึ่งเป็นค่าเริ่มต้นที่ปลอดภัยสำหรับการแทรกค่าที่เชื่อถือไม่ได้เข้าไประหว่างตัวคั่นที่คุณควบคุมเอง มันจะ escape ตัวคั่นที่เป็นอักขระสงวนด้วย ดังนั้นเครื่องหมายทับหรือแอมเปอร์แซนด์ที่ฝังอยู่ภายในจึงไม่สามารถทำให้ URL ที่ห่อหุ้มอยู่เสียได้ ข้อแลกเปลี่ยนก็คือคุณไม่ควรวางที่อยู่แบบเต็มลงที่นี่ เพราะมันจะ escape อักขระเชิงโครงสร้าง : / ? # & = ด้วย และทำให้ลิงก์พังเสียหาย หากต้องการเข้ารหัส URL ทั้งอัน ให้เข้ารหัสแต่ละค่าหรือแต่ละส่วนของ path ทีละชิ้น แล้วจึงประกอบเป็นที่อยู่ที่สมบูรณ์ด้วยตัวคุณเอง
ความผิดพลาดจากการเข้ารหัสซ้ำซ้อน
การเข้ารหัสซ้ำซ้อน (double-encoding) คือบั๊กของการเข้ารหัสแบบเปอร์เซ็นต์ที่พบบ่อยที่สุด มันเกิดขึ้นเมื่อข้อความที่เข้ารหัสไปแล้วถูกเข้ารหัสเป็นครั้งที่สอง ตัวกระตุ้นก็คือเครื่องหมายเปอร์เซ็นต์เอง เพราะเปอร์เซ็นต์เป็นอักขระสงวน การเข้ารหัสมันจึงเปลี่ยน %20 ให้กลายเป็น %2520 เนื่องจากเครื่องหมาย % ที่นำหน้ากลายเป็น %25 ส่วนเลข 20 ยังคงอยู่เหมือนเดิม ค่าที่ถูกเข้ารหัสซ้ำสองครั้งจะแสดงลำดับเอสเคปตามตัวอักษรอย่าง %2520 ให้ผู้ใช้ปลายทางเห็น แทนที่จะเป็นช่องว่างตามที่ตั้งใจไว้
หลีกเลี่ยงปัญหานี้ด้วยการเข้ารหัสเพียงครั้งเดียวเป๊ะ ๆ ในจังหวะที่คุณสร้าง URL และอย่านำสตริงที่มีเอสเคปแบบเปอร์เซ็นต์อยู่แล้วไปผ่านตัวเข้ารหัสซ้ำอีก หากคุณเห็น %25 ตามด้วยสิ่งที่ดูเหมือนเป็นอีกเอสเคปหนึ่ง แทบจะแน่นอนว่าคุณกำลังมองข้อมูลที่ถูกเข้ารหัสซ้ำซ้อน และวิธีแก้คือถอดรหัสมันเพิ่มอีกหนึ่งครั้ง หรือกำจัดขั้นตอนการเข้ารหัสที่ซ้ำซ้อนออกจากโค้ดของคุณ
คุณจะได้ใช้มันที่ไหนบ้าง
การเข้ารหัสแบบเปอร์เซ็นต์มีอยู่ทุกที่ที่ค่าเดินทางอยู่ภายใน URL ไม่ว่าจะเป็นการสร้าง query string สำหรับการค้นหาและการกรอง การประกอบลิงก์ที่มีข้อความที่ผู้ใช้ป้อนเข้ามา การส่งพารามิเตอร์ไปยัง REST API การฝังปลายทางของการเปลี่ยนเส้นทางไว้ในพารามิเตอร์ return_url และการลงนามคำขอที่ต้องตรงกันแบบไบต์ต่อไบต์ ทั้งหมดนี้ล้วนขึ้นอยู่กับการเข้ารหัสที่ถูกต้อง เว็บเซิร์ฟเวอร์และเฟรมเวิร์กจะถอดรหัส URL ที่เข้ามาโดยอัตโนมัติ ดังนั้นรูปแบบที่เข้ารหัสแล้วจึงมักเป็นสิ่งที่คุณสร้างขึ้นมากกว่าจะเป็นสิ่งที่คุณอ่าน
นิสัยที่ดีอย่างหนึ่งคือการเข้ารหัสข้อมูลแบบไดนามิกทีละชิ้นในขณะที่คุณประกอบ URL ขึ้นมา แทนที่จะเข้ารหัสสตริงที่สมบูรณ์แล้วทั้งหมดในครั้งเดียว วิธีนี้จะรักษาตัวคั่นของคุณให้คงสภาพอยู่ พร้อมกับทำให้ทุกค่าปลอดภัย และยังเลี่ยงทั้งการเข้ารหัสไม่เพียงพอที่ทำให้ลิงก์พัง และการเข้ารหัสซ้ำซ้อนที่ทำให้ลิงก์เสียหายได้ในคราวเดียวกัน
คำถามที่พบบ่อย
URL encoding ทำอะไรกันแน่
เครื่องมือนี้ทั้ง encode และ decode ได้ไหม
มันรองรับอักขระพิเศษและภาษาอื่น ๆ ไหม
การ encode URL ทั้งอันกับค่าเดี่ยวต่างกันอย่างไร
ข้อมูลของฉันเป็นส่วนตัวและเครื่องมือนี้ฟรีไหม
เครื่องมือที่เกี่ยวข้อง
ทำงานต่อด้วยเครื่องมือที่มีประโยชน์เหล่านี้