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

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

สามารถทำการปรับให้เป็นมาตรฐานได้หลายประเภท บางประเภทจะรักษาความหมายดั้งเดิมไว้เสมอ ในขณะที่บางประเภทอาจไม่เป็นเช่นนั้น

การทำให้เป็นมาตรฐานต่อไปนี้ได้รับการอธิบายไว้ใน RFC 3986 ^{[ 1 ]}เพื่อให้ได้ URI ที่เทียบเท่ากัน:

• การแปลงสามตัวเลขที่เข้ารหัสด้วยเปอร์เซ็นต์ให้เป็นตัวพิมพ์ใหญ่ตัวเลขฐานสิบหกภายใน สามตัวเลข ที่เข้ารหัสด้วยเปอร์เซ็นต์ของ URI (เช่น%3aเทียบกับ%3A) ไม่คำนึงถึงตัวพิมพ์ใหญ่-เล็ก ดังนั้นจึงควรทำให้เป็นมาตรฐานโดยใช้ตัวอักษรพิมพ์ใหญ่สำหรับตัวเลข AF ^{[ 2 ]}ตัวอย่าง:

http://example.com/foo%2a→http://example.com/foo%2A

• แปลงรูปแบบและโฮสต์เป็นตัวพิมพ์เล็ก ส่วนประกอบ รูปแบบและโฮสต์ของ URI ไม่คำนึงถึงตัวพิมพ์ใหญ่เล็ก ดังนั้นจึงควรแปลงเป็นตัวพิมพ์เล็ก^{[ 3 ]}ตัวอย่าง:

HTTP://[email protected]/Foo→http://[email protected]/Foo

• การถอดรหัสชุดอักขระสามตัวที่เข้ารหัสด้วยเปอร์เซ็นต์ของอักขระที่ไม่สงวนไว้ ชุดอักขระสามตัวที่เข้ารหัสด้วยเปอร์เซ็นต์ของ URI ในช่วงของตัวอักษร ( %41– %5Aและ%61– %7A), ตัวเลข ( %30– %39), เครื่องหมาย%2Dขีดกลาง ( ) , จุด ( %2E), เครื่องหมายขีดล่าง ( %5F) หรือเครื่องหมายตัวหนอน ( %7E) ไม่จำเป็นต้องเข้ารหัสด้วยเปอร์เซ็นต์และควรถอดรหัสเป็นอักขระที่ไม่สงวนไว้ที่สอดคล้องกัน^{[ 4 ]}ตัวอย่าง:

http://example.com/%7Efoo→http://example.com/~foo

• การลบส่วนดอท ส่วนดอ.ท..ในส่วนประกอบเส้นทางของ URI ควรถูกลบออกโดยใช้อัลกอริธึม remove_dot_segments ^{[ 5 ]}กับเส้นทางที่อธิบายไว้ใน RFC 3986 ^{[ 6 ]}ตัวอย่าง:

http://example.com/foo/./bar/baz/../qux→http://example.com/foo/bar/qux

• การแปลงเส้นทางว่างให้เป็นเส้นทาง "/"ในกรณีที่มีส่วนประกอบของหน่วยงาน เส้นทางว่างควรได้รับการทำให้เป็นมาตรฐานเป็นส่วนประกอบของเส้นทาง "/" ^{[ 7 ]}ตัวอย่าง:

http://example.com→http://example.com/

• การลบพอร์ตเริ่มต้น ส่วนประกอบพอร์ต ว่างหรือพอร์ตเริ่มต้นของ URI (พอร์ต 80 สำหรับhttpรูปแบบ) พร้อมตัว คั่น ":" ควรถูกลบออก^{[ 7 ]}ตัวอย่าง:

http://example.com:80/→http://example.com/

สำหรับ URI ของ HTTP และ HTTPS การแปลงค่ามาตรฐานต่อไปนี้ที่ระบุไว้ใน RFC 3986 อาจส่งผลให้ได้ URI ที่เทียบเท่ากัน แต่ไม่รับประกันว่าจะเป็นเช่นนั้นตามมาตรฐาน:

• เพิ่มเครื่องหมาย "/" ต่อท้ายเส้นทางที่ไม่ว่างเปล่าไดเร็กทอรี (โฟลเดอร์) จะระบุด้วยเครื่องหมายทับต่อท้ายและควรใส่ไว้ใน URI ด้วย ตัวอย่าง:

http://example.com/foo→http://example.com/foo/

อย่างไรก็ตาม ไม่มีวิธีใดที่จะทราบได้ว่าส่วนประกอบของพาธ URI นั้นแสดงถึงไดเร็กทอรีหรือไม่ RFC 3986 ระบุว่า หาก URI แรกเปลี่ยนเส้นทางไปยัง URI หลัง นั่นแสดงว่า URI ทั้งสองนั้นเทียบเท่ากัน

การใช้รูปแบบการปรับมาตรฐานต่อไปนี้จะส่งผลให้ URI มีความหมายแตกต่างกัน แม้ว่าจะอ้างอิงถึงทรัพยากรเดียวกันก็ตาม:

• การลบดัชนีไดเร็กทอรี โดยทั่วไปแล้ว ดัชนีไดเร็กทอรีเริ่มต้นไม่จำเป็นใน URI ตัวอย่างเช่น:

http://example.com/a/index.html→http://example.com/a/

http://example.com/default.asp→http://example.com/

• การลบ ส่วนท้ายของ URI ส่วนท้ายนี้เซิร์ฟเวอร์จะไม่เห็น และบางครั้งสามารถลบออกได้ ตัวอย่าง:

http://example.com/bar.html#section1→http://example.com/bar.html

อย่างไรก็ตาม แอปพลิเคชัน AJAXมักใช้ค่าในส่วนของข้อมูล (fragment)

• แทนที่ที่อยู่ IP ด้วยชื่อโดเมนตรวจสอบว่าที่อยู่ IP นั้น ตรงกับชื่อโดเมนหรือไม่ ตัวอย่าง:

http://208.77.188.166/→http://example.com/

การแทนที่แบบย้อนกลับนั้นแทบจะไม่ปลอดภัยเลย เนื่องจากเซิร์ฟเวอร์เว็บเสมือน

• การจำกัดโปรโตคอลการจำกัด โปรโตคอล ระดับแอปพลิ เคชันที่แตกต่างกัน ตัวอย่างเช่น รูปแบบ “https” อาจถูกแทนที่ด้วย “http” ตัวอย่าง:

https://example.com/→http://example.com/

• การลบเครื่องหมายทับที่ซ้ำกันเส้นทางที่มีเครื่องหมายทับสองตัวติดกันสามารถแปลงให้เหลือเพียงเครื่องหมายทับเดียวได้ ตัวอย่าง:

http://example.com/foo//bar.html→http://example.com/foo/bar.html

• การลบหรือเพิ่ม “www” เป็นป้ายกำกับโดเมนแรกบางเว็บไซต์ทำงานเหมือนกันในสองโดเมนอินเทอร์เน็ต: โดเมนหนึ่งมีป้ายกำกับที่สำคัญน้อยที่สุดคือ “www” และอีกโดเมนหนึ่งมีชื่อเป็นผลมาจากการละเว้นป้ายกำกับที่สำคัญน้อยที่สุดจากชื่อของโดเมนแรก ซึ่งโดเมนหลังนี้เรียกว่าโดเมนเปลือยตัวอย่างเช่นhttp://www.example.com/และhttp://example.com/อาจเข้าถึงเว็บไซต์เดียวกันได้ เว็บไซต์หลายแห่งเปลี่ยนเส้นทางผู้ใช้จากที่ อยู่ wwwไปยังที่อยู่ที่ไม่ใช่ www หรือในทางกลับกัน ตัวปรับมาตรฐานอาจตรวจสอบว่า URI หนึ่งเปลี่ยนเส้นทางไปยังอีก URI หนึ่งหรือไม่ และปรับมาตรฐาน URI ทั้งหมดอย่างเหมาะสม ตัวอย่าง:

http://www.example.com/→http://example.com/

• การเรียงลำดับพารามิเตอร์ในคำค้นหา เว็บเพจบางเว็บใช้ พารามิเตอร์มากกว่าหนึ่งตัวใน URI ตัวปรับมาตรฐานสามารถเรียงลำดับพารามิเตอร์ตามลำดับตัวอักษร (พร้อมค่าของพารามิเตอร์) และประกอบ URI ใหม่ได้ ตัวอย่าง:

http://example.com/display?lang=en&article=fred→http://example.com/display?article=fred&lang=en

อย่างไรก็ตาม ลำดับของพารามิเตอร์ใน URI อาจมีความสำคัญ (ซึ่งไม่ได้กำหนดไว้ในมาตรฐาน) และเว็บเซิร์ฟเวอร์อาจอนุญาตให้ตัวแปรเดียวกันปรากฏได้หลายครั้ง^{[ 8 ]}

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

http://example.com/display?id=123&fakefoo=fakebar→http://example.com/display?id=123

โปรดทราบว่าพารามิเตอร์ที่ไม่มีค่าไม่ได้หมายความว่าเป็นพารามิเตอร์ที่ไม่ได้ใช้งานเสมอไป

• การลบพารามิเตอร์การค้นหาเริ่มต้นค่าเริ่มต้นในสตริงการค้นหาอาจแสดงผลเหมือนกันไม่ว่าจะมีอยู่หรือไม่ก็ตาม ตัวอย่าง:

http://example.com/display?id=&sort=ascending→http://example.com/display

• ลบเครื่องหมาย "?" เมื่อแบบสอบถามว่างเปล่าในกรณีที่แบบสอบถามว่างเปล่า อาจไม่จำเป็นต้องมีเครื่องหมาย "?" ตัวอย่าง:

http://example.com/display?→http://example.com/display

อาจมีการกำหนดกฎเกณฑ์การปรับมาตรฐานสำหรับเว็บไซต์เฉพาะโดยการตรวจสอบรายการ URI ที่ได้จากการรวบรวมข้อมูลครั้งก่อนหรือบันทึกของเว็บเซิร์ฟเวอร์ ตัวอย่างเช่น หาก URI

http://example.com/story?id=xyz

ปรากฏในบันทึกการรวบรวมข้อมูลหลายครั้งพร้อมกับ

http://example.com/story_xyz

เราอาจสันนิษฐานได้ว่า URI ทั้งสองนั้นเทียบเท่ากันและสามารถปรับให้เป็นรูปแบบ URI รูปแบบใดรูปแบบหนึ่งได้

Schonfeld et al. (2006) นำเสนอฮิวริสติกที่เรียกว่า DustBuster สำหรับการตรวจจับกฎ DUST (URI ที่แตกต่างกันแต่มีข้อความคล้ายกัน) ซึ่งสามารถนำไปใช้กับรายการ URI ได้ พวกเขาแสดงให้เห็นว่าเมื่อพบกฎ DUST ที่ถูกต้องและนำไปใช้กับอัลกอริธึมการทำให้เป็นมาตรฐานแล้ว พวกเขาสามารถค้นหา URI ที่ซ้ำซ้อนในรายการ URI ได้มากถึง 68%

• URL (Uniform Resource Locator)
• ส่วนย่อยของ URI
• เว็บครอว์เลอร์