การเข้ารหัสแบบเปอร์เซ็นต์หรือที่เรียกว่าการเข้ารหัส URLเป็นวิธีการเข้ารหัสข้อมูลใดๆ ในตัวระบุทรัพยากรสากล (URI) โดยใช้เฉพาะ อักขระ US-ASCIIที่ถูกต้องภายใน URI เท่านั้น การเข้ารหัสแบบเปอร์เซ็นต์ใช้เพื่อให้แน่ใจว่าอักขระพิเศษจะไม่รบกวนโครงสร้างและการตีความของ URI อักขระพิเศษจะถูกแทนที่ด้วยเครื่องหมายเปอร์เซ็นต์ (%) ตามด้วยตัวเลขฐานสิบหกสองหลักที่แสดงค่าไบต์ของอักขระนั้น ตัวอย่างเช่น ช่องว่างมักจะถูกเข้ารหัสเป็น%20:

• ต้นฉบับ:http://example.com/my file.txt
• เข้ารหัส:http://example.com/my%20file.txt

แม้ว่าจะรู้จักกันในชื่อการเข้ารหัส URLแต่ก็ยังใช้กันโดยทั่วไปภายใน ชุด Uniform Resource Identifier (URI) หลัก ซึ่งประกอบด้วยทั้งUniform Resource Locator (URL) และUniform Resource Name (URN) ดังนั้นจึงใช้ในการเตรียมข้อมูลของapplication/x-www-form-urlencodedประเภทสื่อเช่นเดียวกับที่มักใช้ในการส่ง ข้อมูล แบบฟอร์ม HTML ใน คำขอ HTTPการเข้ารหัสแบบเปอร์เซ็นต์ไม่คำนึงถึงตัวพิมพ์ใหญ่เล็ก

อักขระที่อนุญาตให้ใช้ใน URI นั้นมีทั้งอักขระสงวนและ อักขระ ไม่สงวน (หรืออักขระเปอร์เซ็นต์ซึ่งเป็นส่วนหนึ่งของการเข้ารหัสแบบเปอร์เซ็นต์) อักขระ สงวนคืออักขระที่มีความหมายพิเศษในบางครั้ง ตัวอย่างเช่น อักขระ สแลชใช้เพื่อแยกส่วนต่างๆ ของ URL (หรือโดยทั่วไปคือ URI) อักขระ ไม่สงวนไม่มีความหมายเช่นนั้น การใช้การเข้ารหัสแบบเปอร์เซ็นต์ อักขระสงวนจะถูกแทนด้วยลำดับอักขระพิเศษ ชุดของอักขระสงวนและไม่สงวน รวมถึงสถานการณ์ที่อักขระสงวนบางตัวมีความหมายพิเศษนั้นมีการเปลี่ยนแปลงเล็กน้อยในการแก้ไขข้อกำหนดที่ควบคุม URI และรูปแบบ URI แต่ละครั้ง

อักขระอื่นๆ ใน URI จะต้องเข้ารหัสด้วยเปอร์เซ็นต์

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

อักขระสงวน/เช่น `\n` หากใช้ในส่วนประกอบ "path" ของURIจะมีความหมายพิเศษคือเป็นตัวคั่นระหว่างส่วนของเส้นทาง หากตามรูปแบบ URI ที่กำหนด `\n` /จำเป็นต้องมีอยู่ในส่วนของเส้นทาง จะต้องใช้อักขระสามตัว `\n` %2Fหรือ%2f`\n` ในส่วนนั้นแทนที่จะใช้ `\n` แบบ/ดั้งเดิม

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

ในส่วน " query " ของ URI (ส่วนที่อยู่หลัง?อักขระ) ตัวอย่างเช่น/อักขระ ยังคงถือว่าเป็นอักขระสงวน แต่โดยปกติแล้วจะไม่มีวัตถุประสงค์ที่สงวนไว้ เว้นแต่ว่ารูปแบบ URI เฉพาะจะระบุไว้เป็นอย่างอื่น อักขระนั้นไม่จำเป็นต้องเข้ารหัสด้วยเปอร์เซ็นต์เมื่อไม่มีวัตถุประสงค์ที่สงวนไว้

โดยปกติแล้ว URI ที่แตกต่างกันเพียงแค่ว่าอักขระสงวนนั้นถูกเข้ารหัสด้วยเปอร์เซ็นต์หรือปรากฏตามตัวอักษร จะถือว่าไม่เทียบเท่ากัน (หมายถึงทรัพยากรเดียวกัน) เว้นแต่จะสามารถระบุได้ว่าอักขระสงวนดังกล่าวไม่มีวัตถุประสงค์ที่สงวนไว้ การพิจารณานี้ขึ้นอยู่กับกฎที่กำหนดไว้สำหรับอักขระสงวนโดยแต่ละรูปแบบ URI

ตัวอักษรจากชุดที่ไม่สงวนไว้ไม่จำเป็นต้องเข้ารหัสเป็นเปอร์เซ็นต์

ตามนิยามแล้ว URI ที่แตกต่างกันเพียงแค่ว่าอักขระที่ไม่สงวนไว้ถูกเข้ารหัสด้วยเปอร์เซ็นต์หรือปรากฏตามตัวอักษรนั้น ถือว่าเทียบเท่ากัน แต่ในทางปฏิบัติ ตัวประมวลผล URI อาจไม่ยอมรับความเทียบเท่านี้เสมอไป ตัวอย่างเช่น ผู้ใช้งาน URI ไม่ควรปฏิบัติ%41ต่อ แตกต่างจากAหรือ%7Eแตกต่างจาก~แต่บางโปรแกรมก็ทำเช่นนั้น เพื่อให้สามารถทำงานร่วมกันได้อย่างสูงสุด ผู้ผลิต URI จึงไม่ควรเข้ารหัสอักขระที่ไม่สงวนไว้ด้วยเปอร์เซ็นต์

เนื่องจากอักขระเปอร์เซ็นต์ ( %) ใช้เพื่อระบุไบต์ที่เข้ารหัสด้วยเปอร์เซ็นต์ ดังนั้นตัวอักขระเปอร์เซ็นต์เองจึงต้องถูกเข้ารหัสด้วยเปอร์เซ็นต์ด้วยจึง%25จะสามารถใช้เป็นข้อมูลภายใน URI ได้

รูปแบบ URI ส่วนใหญ่เกี่ยวข้องกับการแสดงข้อมูลที่ไม่จำเพาะเจาะจง เช่นที่อยู่ IPหรือ เส้นทาง ของระบบไฟล์เป็นส่วนประกอบของ URI ข้อกำหนดของรูปแบบ URI ควรให้การจับคู่ที่ชัดเจนระหว่างอักขระ URI กับค่าข้อมูลที่เป็นไปได้ทั้งหมดที่แสดงโดยอักขระเหล่านั้น แต่บ่อยครั้งที่ไม่ได้ทำเช่นนั้น

นับตั้งแต่มีการเผยแพร่ RFC 1738 ในปี 1994 ได้มีการกำหนดรูปแบบที่อนุญาตให้แสดงข้อมูลไบนารีใน URI ว่าต้องแบ่งข้อมูลออกเป็นไบต์ 8 บิตและเข้ารหัสเปอร์เซ็นต์ของแต่ละไบต์ในลักษณะเดียวกับข้างต้น^{[ 1 ] [ 2 ] [ 3 ]}ตัวอย่างเช่น ค่าไบต์ 0x0F ควรแสดงด้วย%0Fแต่ค่าไบต์ 0x41 สามารถแสดงด้วยAหรือ%41การใช้ตัวอักษรที่ไม่เข้ารหัสสำหรับตัวอักษรและตัวเลขและอักขระอื่นๆ ที่ไม่ได้สงวนไว้มักเป็นที่นิยมมากกว่า เนื่องจากทำให้ URL สั้นลง

วิธีการเข้ารหัสข้อมูลไบนารีแบบเปอร์เซ็นต์มักถูกนำไปประยุกต์ใช้กับข้อมูลอักขระ ซึ่งบางครั้งอาจไม่เหมาะสมหรือไม่ได้รับการระบุอย่างครบถ้วน ใน ช่วงเริ่มต้นของ เวิลด์ไวด์เว็บเมื่อใช้ข้อมูลอักขระในชุด ASCII และใช้ไบต์ที่สอดคล้องกันใน ASCII เป็นพื้นฐานในการกำหนดลำดับการเข้ารหัสแบบเปอร์เซ็นต์ วิธีการนี้ค่อนข้างไม่มีอันตราย เพราะโดยทั่วไปแล้วจะถือว่าอักขระและไบต์จับคู่กันแบบหนึ่งต่อหนึ่งและสามารถใช้แทนกันได้ อย่างไรก็ตาม ความต้องการในการแสดงอักขระนอกช่วง ASCII เพิ่มขึ้นอย่างรวดเร็ว และรูปแบบและโปรโตคอล URI มักไม่สามารถกำหนดกฎมาตรฐานสำหรับการเตรียมข้อมูลอักขระเพื่อรวมไว้ใน URI ได้ ส่งผลให้แอปพลิเคชันเว็บเริ่มใช้การเข้ารหัสแบบหลายไบต์ แบบมีสถานะและการเข้ารหัสที่ไม่เข้ากันกับ ASCII อื่นๆ เป็นพื้นฐานสำหรับการเข้ารหัสแบบเปอร์เซ็นต์ ซึ่งนำไปสู่ความกำกวมและความยากลำบากในการตีความ URI อย่างน่าเชื่อถือ

ตัวอย่างเช่น รูปแบบและโปรโตคอล URI จำนวนมากที่อิงตาม RFC 1738 และ 2396 สันนิษฐานว่าอักขระข้อมูลจะถูกแปลงเป็นไบต์ตามการเข้ารหัสอักขระ ที่ไม่ระบุ ก่อนที่จะแสดงใน URI ด้วยอักขระที่ไม่ได้สงวนไว้หรือไบต์ที่เข้ารหัสแบบเปอร์เซ็นต์ หากรูปแบบไม่อนุญาตให้ URI ให้คำแนะนำเกี่ยวกับการเข้ารหัสที่ใช้ หรือหากการเข้ารหัสขัดแย้งกับการใช้ ASCII ในการเข้ารหัสแบบเปอร์เซ็นต์สำหรับอักขระที่สงวนไว้และไม่ได้สงวนไว้ URI ก็จะไม่สามารถตีความได้อย่างน่าเชื่อถือ บางรูปแบบล้มเหลวในการคำนึงถึงการเข้ารหัสเลย และแนะนำเพียงว่าอักขระข้อมูลจะแมปโดยตรงกับอักขระ URI ซึ่งปล่อยให้การใช้งานเป็นผู้ตัดสินใจว่าจะเข้ารหัสแบบเปอร์เซ็นต์สำหรับอักขระข้อมูลที่ไม่ได้อยู่ในชุดที่สงวนไว้หรือไม่ได้สงวนไว้หรือไม่ และอย่างไร

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

ไวยากรณ์ URI ทั่วไปแนะนำว่า รูปแบบ URI ใหม่ที่รองรับการแสดงข้อมูลอักขระใน URI ควรแสดงอักขระจากชุดอักขระที่ไม่ได้สงวนไว้โดยไม่ต้องแปลง และควรแปลงอักขระอื่นๆ ทั้งหมดเป็นไบต์ตามมาตรฐานUTF-8จากนั้นจึงเข้ารหัสค่าเหล่านั้นด้วยเปอร์เซ็นต์ ข้อเสนอแนะนี้ได้รับการนำเสนอในเดือนมกราคม 2548 พร้อมกับการเผยแพร่ RFC 3986 รูปแบบ URI ที่ได้รับการนำเสนอก่อนหน้านี้จะไม่ได้รับผลกระทบ

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

มีการเข้ารหัสที่ไม่เป็นมาตรฐานสำหรับอักขระ Unicode: โดยที่xxxxคือ หน่วยรหัส UTF-16 ที่แสดงเป็นตัวเลขฐานสิบหกสี่หลัก ตัวอย่างเช่น ECMA-262ฉบับที่ 13 มีฟังก์ชันที่ใช้ไวยากรณ์นี้^{[ 4 ]}อย่างไรก็ตาม พฤติกรรมนี้ไม่ได้ระบุไว้ใน RFC ใดๆ และถูกปฏิเสธโดย W3C ^{[ 5 ]}%uxxxxescape

เมื่อข้อมูลที่ป้อนลงในแบบฟอร์ม HTML ถูกส่ง ข้อมูลชื่อฟิลด์และค่าของแบบฟอร์มจะถูกเข้ารหัสและส่งไปยังเซิร์ฟเวอร์ในข้อความคำขอ HTTP โดยใช้วิธีGETหรือPOSTหรือในอดีตผ่านทางอีเมล[ ^{nb 1 ]}การเข้ารหัสที่ใช้โดยค่าเริ่มต้นจะอิงตามกฎการเข้ารหัสเปอร์เซ็นต์ URI ทั่วไปเวอร์ชันแรก^{[ 6 ]}โดยมีการปรับเปลี่ยนหลายอย่าง เช่น การทำให้ขึ้นบรรทัด ใหม่เป็นมาตรฐานและการแทนที่ช่องว่างด้วย+แทนที่จะเป็นประเภทสื่อ%20ของข้อมูลที่เข้ารหัสด้วยวิธีนี้คือและปัจจุบันมีการกำหนดไว้ในข้อกำหนด HTML และXFormsนอกจากนี้ ข้อกำหนด CGIยังมีกฎสำหรับวิธีที่เว็บเซิร์ฟเวอร์ถอดรหัสข้อมูลประเภทนี้และทำให้พร้อมใช้งานสำหรับแอปพลิเคชัน application/x-www-form-urlencoded

เมื่อส่งข้อมูลฟอร์ม HTML ในคำขอ HTTP GET ข้อมูลนั้นจะถูกรวมอยู่ในส่วนคำถามของ URI คำขอโดยใช้ไวยากรณ์เดียวกันกับที่อธิบายไว้ข้างต้น เมื่อส่งในคำขอ HTTP POSTหรือทางอีเมล ข้อมูลจะถูกวางไว้ในส่วนเนื้อหาของข้อความ และapplication/x-www-form-urlencodedรวมอยู่ในส่วนหัว Content-Type ของข้อความนั้น

Wikifunctionsมีฟังก์ชันเข้ารหัสเปอร์เซ็นต์ของ URI

Wikifunctionsมีฟังก์ชันถอดรหัสเปอร์เซ็นต์ของ URI

• Base64  – การเข้ารหัสลำดับของค่าไบต์โดยใช้ตัวอักขระที่พิมพ์ได้ 64 ตัว
• การเข้ารหัสไบนารีเป็นข้อความ  – การแปลงข้อมูลไบนารีให้เป็นข้อความ
• ตัวระบุทรัพยากรสากล (Internationalized Resource Identifier)  ​​– ชุดอักขระที่ขยายเพิ่มเติมในโปรโตคอล URI
• Punycode  – การเข้ารหัสสำหรับชื่อโดเมนแบบ Unicode
• เชลล์โค้ด  – โค้ดที่ออกแบบมาเพื่อใช้เป็นเพย์โหลดในการโจมตีช่องโหว่ของซอฟต์แวร์

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

• RFC  3986 / STD STD 66 . IETF .(พร้อมแก้ไขข้อผิดพลาด ) ข้อกำหนดไวยากรณ์ URI ทั่วไปฉบับปัจจุบัน
• RFC  2396 (ล้าสมัย พร้อมข้อแก้ไข เพิ่มเติม ) และRFC  2732 (พร้อมข้อแก้ไข เพิ่มเติม ) รวมกันเป็นเวอร์ชันก่อนหน้าของข้อกำหนดไวยากรณ์ URI ทั่วไป
• RFC  1738 (ส่วนใหญ่ล้าสมัยแล้ว) และRFC  1808 (ล้าสมัยแล้ว) ซึ่งกำหนดURLไว้
• RFC  1630 (ล้าสมัย) ข้อกำหนดไวยากรณ์ URI ทั่วไปฉบับแรก
• "การตั้งชื่อและการกำหนดที่อยู่: URI, URL, ..." W3C สืบค้นเมื่อ 17 กันยายน 2025(แนวทาง)
• "โปรแกรมเข้ารหัส URI" . W3C . สืบค้นเมื่อ 17 กันยายน 2025 .(คำอธิบายของ W3C เกี่ยวกับ UTF-8 ใน URI หน้าเว็บดังกล่าวไม่ได้มีการบำรุงรักษาอีกต่อไปแล้ว และข้อมูลอาจไม่ถูกต้อง)
• "แบบฟอร์ม" . W3C . สืบค้นเมื่อ 17 กันยายน 2025 .(ประเภทเนื้อหาแบบฟอร์ม HTML ของ W3C)