URL ควรคำนึงถึงตัวพิมพ์เล็กหรือไม่

284

ฉันสังเกตว่า

HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK

และ

http://stackoverflow.com/questions/ask

ทั้งสองทำงานได้ดี - อันที่จริงก่อนหน้านี้ถูกแปลงเป็นตัวพิมพ์เล็ก

ฉันคิดว่ามันสมเหตุสมผลสำหรับผู้ใช้

ถ้าฉันดู Google แล้ว URL นี้ใช้ได้ดี:

http://www.google.com/intl/en/about/corporate/index.html

แต่อันนี้ด้วย "ABOUT" ไม่ทำงาน:

http://www.google.com/intl/en/ABOUT/corporate/index.html

URL ควรตรงตามตัวพิมพ์ใหญ่หรือไม่

url case-sensitive

— Imageree
แหล่งที่มา

13

IMHO, URL ไม่ควรตรงตามตัวพิมพ์เล็กและใหญ่ซึ่งทำให้ชีวิตยากขึ้นสำหรับผู้ที่จะใช้งาน

— มูฮัมหมัดอูเมอ

16

คำถาม "URL ควรคำนึงถึงตัวอักษรตัวเล็กหรือไม่" เป็นคำถามที่ไม่ดีเพราะมันก่อให้เกิดความคิดเห็น ค่อนข้างเป็นคำถามที่ดีกว่าว่า "ทำไม (หรือทำไมไม่) URL เป็นกรณี ๆ ไป?" หรือ "ทำไม URL บางกรณีจึงมีความละเอียดอ่อนในขณะที่คนอื่นไม่ได้?"

— chharvey

แต่สำหรับคำตอบที่เป็นไปได้หนึ่งตรวจสอบWHATWG URL ของมาตรฐานใหม่ซึ่งได้รับการรับรองโดยNode.js

— chharvey

ในความคิดของฉันพวกเขาไม่ควรจะเป็น

— Andrew

หากเบราว์เซอร์ไม่เคารพในกรณีนี้ที่อยู่ ipfs จะไม่ทำงาน แต่ก็ไม่ได้รับการแก้ไข

— Beeno Tung

281

ตาม " HTML และ URL " ของ W3 พวกเขาควรจะ:

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

— jldupont
แหล่งที่มา

95

ฉันเดาว่า "มีอิสระในสิ่งที่คุณยอมรับและระมัดระวังในสิ่งที่คุณส่ง" (IETF พูด) จะเป็นแนวทางของฉัน

— jldupont

9

แนวทางของ W3 นั้นสมเหตุสมผล เพียงระบุว่าไม่ควรทำการสันนิษฐานว่าเซิร์ฟเวอร์จัดการกับ URL ที่คุณส่งอย่างไร ขึ้นอยู่กับเซิร์ฟเวอร์ว่าจะจัดการ URL ที่ขอได้อย่างไร เว็บเซิร์ฟเวอร์ส่วนใหญ่เป็นยูนิกซ์ / ลินุกซ์และนั่นหมายความว่าเว็บเซิร์ฟเวอร์ส่วนใหญ่จะคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่

— oᴉɹǝɥɔ

37

W3 กล่าวว่า USERS ควรถือว่าเซิร์ฟเวอร์เป็นกรณี ๆ ไป แต่ไม่ได้ให้คำแนะนำสำหรับเซิร์ฟเวอร์

— trysis

3

เพื่อความยืดหยุ่นโปรแกรมที่แปลความหมาย URL ควรปฏิบัติต่อตัวอักษรตัวพิมพ์ใหญ่เทียบเท่ากับตัวพิมพ์เล็กในชื่อแบบแผน (เช่นอนุญาต "HTTP" และ "http") ที่มา

— realPK

3

@PK_ ทราบว่านี้ถือเป็นเพียง แต่สำหรับโครงการส่วนหนึ่งของ URL RFC1738 ไม่ได้หารือว่าส่วนอื่น ๆ ของ URL ควรตีความว่าเป็นตัวพิมพ์เล็กหรือใหญ่

— dthrasher

126

ทั้งหมด " insensitive " s เป็นตัวหนาสำหรับการอ่าน

ชื่อโดเมนไม่ตรงตามตัวพิมพ์ใหญ่และตัวพิมพ์เล็กตามRFC 43434343 ส่วนที่เหลือของ URL จะถูกส่งไปยังเซิร์ฟเวอร์ผ่านวิธีการ GET นี่อาจเป็นตัวพิมพ์เล็กหรือใหญ่

รับหน้านี้ตัวอย่างเช่น stackoverflow.com รับ GET string / คำถาม / 7996919 / should-url-be-case-sensitive , ส่งเอกสาร HTML ไปยังเบราว์เซอร์ของคุณ Stackoverflow.com เป็นกรณีตายเพราะมันก่อให้เกิดผลเช่นเดียวกันสำหรับ/ คำถาม / 7996919 / น่า URL จะเป็นกรณีที่มีความอ่อนไหว

ในทางกลับกัน Wikipedia จะต้องคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ยกเว้นตัวอักษรตัวแรกของชื่อ URL https://en.wikipedia.org/wiki/Case_sensitivityและhttps://en.wikipedia.org/wiki/case_sensitivityนำไปสู่บทความเดียวกัน แต่https://en.wikipedia.org/wiki/CASE_SENSITIVITYส่งคืน 404

— jdh8
แหล่งที่มา

7

วิกิพีเดียมีการให้อภัยในกรณีที่ผู้ใช้อาจคิดว่าคำควรจะเป็นหนึ่งในกรณีหรืออื่น ๆ แต่นี้เป็นเพราะ OCD ... ขออภัยธรรมชาติของบรรณาธิการ แม้ว่า URL ของมันจะใช้ตัวพิมพ์เล็กและตัวพิมพ์ใหญ่

— trysis

14

นั่นเป็นเพราะความหมายเป็นส่วนหนึ่งที่สามารถอ่านได้จาก URL ของคำถามใน StackOverflow 7996919ไม่ได้ระบุว่ามันก็ระบุ ส่วนความหมายของ URL นั้นมีไว้เพื่อการทำ SEO เท่านั้น

— user3367701

4

จริง ๆ แล้วยัง/programming/7996919/should-BLABLA-be-or-NOT-to-be ใช้งานได้ นี่เป็นเพราะเซิร์ฟเวอร์ของ stackoverflow.com ใช้ ID ของคำถามเพื่อระบุและส่งคืน URL และหน้า HTML ที่ถูกต้อง

— Bozzy

72

ขึ้นอยู่กับระบบปฏิบัติการโฮสติ้ง ไซต์ที่โฮสต์บน Windows มักจะเป็นแบบตัวพิมพ์เล็กและตัวพิมพ์ใหญ่เนื่องจากระบบไฟล์ต้นแบบนั้นไม่ตรงตามตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก ไซต์ที่โฮสต์บนระบบชนิด Unix มีแนวโน้มว่าจะต้องตรงตามตัวพิมพ์ใหญ่และตัวพิมพ์เล็กเนื่องจากระบบไฟล์ของพวกมันจะต้องตรงตามตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก ส่วนชื่อโฮสต์ของ URL นั้นจะไม่ตรงตามตัวพิมพ์ใหญ่ - เล็กเป็นส่วนที่เหลือของเส้นทางที่แตกต่างกันไป

— จิมณัฏฐ์
แหล่งที่มา

1

ใช่เพราะสิ่งนี้ค้นพบอย่างเจ็บปวดในคำขอ HTTP ไปยังไฟล์บนเซิร์ฟเวอร์ Unix ftp

— ลอรีสเติร์น

1

การพูดว่า 'ขึ้นอยู่กับเซิร์ฟเวอร์' นั้นแม่นยำกว่าเพราะการแสดงไฟล์ไม่ใช่วิธีเดียวที่จะตอบคำขอ HTTP

— Valentin Waeselynck

31

ส่วนชื่อโดเมนของ URL ไม่ตรงตามตัวพิมพ์ใหญ่ - เล็กเนื่องจาก DNS ไม่สนใจขนาดตัวพิมพ์: http://en.example.org/และHTTP://EN.EXAMPLE.ORG/ทั้งคู่เปิดหน้าเดียวกัน

พา ธ ใช้เพื่อระบุและอาจค้นหาทรัพยากรที่ร้องขอ เป็นแบบตรงตามตัวพิมพ์ใหญ่ - เล็กแม้ว่าอาจใช้เป็นตัวพิมพ์เล็กและตัวพิมพ์เล็กโดยเฉพาะเซิร์ฟเวอร์ที่ใช้ Microsoft Windows

หากเซิร์ฟเวอร์คำนึงถึงขนาดตัวพิมพ์และhttp://en.example.org/wiki/URLถูกต้องแล้วhttp://en.example.org/WIKI/URLหรือhttp://en.example.org/wiki/urlจะแสดงหน้าข้อผิดพลาด HTTP 404 ยกเว้นว่า URL เหล่านี้ชี้ไปยังแหล่งข้อมูลที่ถูกต้อง

— ภวินชาห์
แหล่งที่มา

3

คำตอบนี้มีเพียงถ้อยคำที่ถูกต้อง "มันเป็นกรณี ๆ ไป คำตอบที่ถูกต้องเท่านั้น

— Daniel W.

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

— โกเมน

2

@garnet จากRFC3986 6.2.2.1 การทำให้เป็นมาตรฐานกรณีและปัญหา : เมื่อ URI ใช้ส่วนประกอบของไวยากรณ์ทั่วไปกฎความเท่าเทียมกันขององค์ประกอบไวยากรณ์จะมีผลใช้เสมอ กล่าวคือโครงร่างและโฮสต์เป็นแบบตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ดังนั้นจึงควรทำให้เป็นมาตรฐานเป็นตัวพิมพ์เล็ก ตัวอย่างเช่น URI HTTP://www.EXAMPLE.com/นั้นเทียบเท่ากับhttp://www.example.com/เทียบเท่ากับ ส่วนประกอบไวยากรณ์ทั่วไปอื่น ๆ จะถือว่าเป็นแบบตรงตามตัวพิมพ์ใหญ่ - เล็กเว้นแต่จะกำหนดไว้เป็นอย่างอื่นโดยโครงการ "

— Daniel W.

2

@garnet และจากHTTP RFC : "เมื่อเปรียบเทียบ URIs สองรายการเพื่อตัดสินใจว่าตรงกันหรือไม่ไคลเอ็นต์ควรใช้การเปรียบเทียบทั้งตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ตามตัวพิมพ์ใหญ่ของทั้ง URIs [... ] " (ยกเว้นโครงการ และโฮสต์เอง)

— Daniel W.

15

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

@Bhavin Shah คำตอบระบุว่าส่วนโดเมนของ URL ไม่ตรงตามตัวพิมพ์ใหญ่ - เล็กดังนั้น

http://google.com

และ

http://GOOGLE.COM

และ

http://GoOgLe.CoM

เหมือนกันทุกอย่าง แต่ทุกอย่างหลังจากส่วนชื่อโดเมนถือว่าเป็นตัวพิมพ์เล็กและตัวพิมพ์ใหญ่

ดังนั้น...

http://GOOGLE.COM/ABOUT

และ

http://GOOGLE.COM/about

แตกต่าง.

หมายเหตุ: ฉันกำลังพูดถึง "ทางเทคนิค" และไม่ใช่ "ตัวอักษร" ในกรณีส่วนใหญ่ที่จริงแล้วเซิร์ฟเวอร์กำลังตั้งค่าเพื่อจัดการรายการเหล่านี้เหมือนกัน แต่เป็นไปได้ที่จะตั้งค่าเพื่อไม่ให้จัดการเหมือนกัน

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

ดังนั้นเพื่อตอบคำถาม "ควร" เซิร์ฟเวอร์คำนึงถึงตัวพิมพ์เล็กและตัวใหญ่ในการจับข้อมูลนี้คำตอบคือ "ใช่แน่นอนที่สุด"

แน่นอนว่าไม่ใช่ทุกอย่างจะต้องตรงตามตัวพิมพ์ใหญ่ - เล็ก แต่เซิร์ฟเวอร์ควรระวังสิ่งที่เป็นและวิธีจัดการกับกรณีเหล่านั้น

@Hart Simha ความเห็นของโดยทั่วไปกล่าวในสิ่งเดียวกัน ฉันพลาดก่อนที่จะโพสต์ดังนั้นฉันจึงต้องการให้เครดิตในกรณีที่เครดิตครบกำหนด

— Kenneth Garza
แหล่งที่มา

7

ดูข้อกำหนดได้ที่นี่: ส่วน 2.7.3 http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19

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

— Nitin
แหล่งที่มา

3

พิจารณาสิ่งต่อไปนี้:

https://www.example.com/createuser.php?name=Paul%20McCartney

ในตัวอย่างสมมุตินี้รูปแบบ HTML - โดยใช้วิธีการ GET - ส่งพารามิเตอร์ "ชื่อ" ไปยังสคริปต์ PHP ที่สร้างบัญชีผู้ใช้ใหม่

และประเด็นที่ฉันทำกับตัวอย่างนี้คือพารามิเตอร์ GET นี้ต้องคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่เพื่อรักษาตัวพิมพ์ใหญ่ของ "McCartney" (หรือเป็นอีกตัวอย่างหนึ่งในการรักษา "Walter d'Isney" เนื่องจากมีวิธีอื่น ๆ สำหรับชื่อที่จะทำลายกฎการใช้อักษรตัวพิมพ์ใหญ่ตามปกติ)

เป็นกรณีเช่นนี้ซึ่งเป็นแนวทางในการแนะนำ W3C ว่าแบบแผนและโฮสต์ไม่คำนึงถึงขนาดตัวพิมพ์ แต่ทุกอย่างหลังจากนั้นอาจเป็นแบบตรงตามตัวพิมพ์เล็ก - ใหญ่และวางไว้บนเซิร์ฟเวอร์ การบังคับใช้ insensitivity case ตามมาตรฐานจะทำให้ตัวอย่างข้างต้นไม่สามารถรักษา case ของอินพุตของผู้ใช้ที่ส่งผ่านเป็นพารามิเตอร์เคียวรี GET

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

(เช่นชื่อผู้ใช้บัญชีอาจถูกบังคับให้ต้องคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ - เช่น "User123" และ "user123" การมีบัญชีที่แตกต่างกันอาจทำให้เกิดความสับสน - แม้ว่าชื่อจริงของพวกเขาดังกล่าวข้างต้น

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

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

— ผมบ๊อบ
แหล่งที่มา

สตริงข้อความค้นหาถือว่าเป็นส่วนหนึ่งของตำแหน่งหรือไม่ ฉันเชื่อว่าพวกเขาถือว่าเป็นเอนทิตีที่แยกต่างหากและไม่ได้ใช้สำหรับการแก้ปัญหาตำแหน่ง

— jpmc26

สตริงการค้นหาจะแยกจากตำแหน่งใช่ แต่หลักการเดียวกันกับที่ฉันแสดงไว้ที่นั่นพร้อมกับพารามิเตอร์การสืบค้นสามารถใช้กับส่วนอื่น ๆ ของ URL ได้ ตัวอย่าง CMSes บางตัวอาจเขียน "/user.php?id=3756" เป็น "/ users / PaulMcCartney" โดยมีจุดประสงค์เพื่อให้ URL ที่มนุษย์อ่านง่ายและเป็นมิตรกับ SEO (เช่น Wordpress ทำเช่นนี้) ประเด็นก็คือว่ามาตรฐานจงใจถอยออกมาจากใบสั่งยามากกว่าสิ่งที่ขึ้นอยู่กับบริบท มันถูกทิ้งไว้ที่เซิร์ฟเวอร์เพื่อตัดสินใจเนื่องจากเซิร์ฟเวอร์เข้าใจบริบทที่ไม่สามารถใช้มาตรฐานสากลได้

— Bob

2

URL ไม่ควรตรงตามตัวพิมพ์เล็กและตัวพิมพ์ใหญ่เว้นแต่จะมีเหตุผลที่ดีว่าทำไมจึงไม่ควรเป็นเช่นนั้น

สิ่งนี้ไม่ได้บังคับ (ไม่ใช่ส่วนใดส่วนหนึ่งของ RFC) แต่มันทำให้การสื่อสารและการจัดเก็บของ URL มีความน่าเชื่อถือมากขึ้น

ถ้าฉันมีสองหน้าในเว็บไซต์:

http://stackoverflow.com/ABOUT.html

และ

http://stackoverflow.com/about.html

พวกเขาควรจะแตกต่างกันอย่างไร อาจจะมีคนเขียนว่า 'รูปแบบการตะโกน' (ตัวพิมพ์ใหญ่) - แต่จากมุมมองของ IA ความแตกต่างไม่ควรถูกเปลี่ยนแปลงโดยในกรณีของ URL

ยิ่งกว่านั้นมันง่ายที่จะใช้สิ่งนี้ใน Apache - เพียงแค่ใช้CheckSpelling Onจาก mod_Speling

— Konchog
แหล่งที่มา

0

คำถามเก่า แต่ฉันสะดุดที่นี่ดังนั้นทำไมไม่ลองยิงมันเพราะคำถามคือการมองมุมมองที่หลากหลายและไม่ใช่คำตอบที่ชัดเจน

W3C อาจมีข้อแนะนำ - ที่ฉันสนใจมาก - แต่ต้องการที่จะคิดใหม่ตั้งแต่คำถามคือที่นี่

ทำไม w3c ถึงพิจารณาว่าชื่อโดเมนนั้นเป็นตัวพิมพ์เล็กและใหญ่

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

เครื่องสามารถจัดการกับความรู้สึกตัวพิมพ์เล็กและตัวพิมพ์เล็กกว่ามนุษย์ (ไม่ใช่แบบทางเทคนิค :))

แต่คำถามก็เพราะเครื่องสามารถจัดการกับสิ่งที่ควรจะทำอย่างนั้น?

ฉันหมายถึงประโยชน์ของการตั้งชื่อและการเข้าถึงทรัพยากรที่hereIsTheResourceเทียบกับhereistheresourceอะไร

ด้านข้างไม่สามารถอ่านได้มากกว่าตัวเคสอูฐซึ่งอ่านได้ง่ายกว่า สามารถอ่านได้กับมนุษย์ (รวมถึงประเภททางเทคนิค)

ดังนั้นนี่คือคะแนนของฉัน: -

เส้นทางของทรัพยากรอยู่ตรงกลางของโครงสร้างการเขียนโปรแกรมและอยู่ใกล้กับผู้ใช้หลังเบราว์เซอร์ในบางครั้ง

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

URL ของคุณ (ไม่รวมชื่อโดเมน) ควรคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่หากผู้ใช้ของคุณจะไม่พิมพ์ด้วยมือ

ข้อสรุป

พา ธ ควรคำนึงถึงขนาดตัวพิมพ์ คะแนนของฉันกำลังชั่งน้ำหนักไปยังเส้นทางที่เล็กและใหญ่

— bhantol
แหล่งที่มา

0

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

— แขก
แหล่งที่มา

นี่เป็นสิ่งที่น่าสนใจ อักขระ ASCII ปกติ (ซึ่งมีตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก) ไม่แปลงจริงใช่ไหม? เป็นเพียงช่องว่างและอักขระส่วนขยายที่หลบหนีใน url อักขระที่ขยายเพิ่มมีตัวปรับขนาดตัวพิมพ์เล็ก / ใหญ่หรือไม่

— TygerKrash

0

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

— rspring1975
แหล่งที่มา

เพื่อความเป็นธรรมคำถามใด ๆ ที่ถามว่า "SHOULD" นั้นอิงตามความคิดเห็นโดยธรรมชาติและสามารถลบออกจาก StackOverflow (เพิ่มเติม: stackoverflow.blog/2010/09/29/good-subjective-bad-subjective )

— chharvey

0

การอนุรักษ์กรณี

URL จะรักษาขนาดตัวพิมพ์ระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ แต่บางส่วนของ URL อาจเป็นแบบตัวพิมพ์เล็กหรือตัวพิมพ์ใหญ่ขึ้นอยู่กับเซิร์ฟเวอร์ด้วยเหตุผลหลายประการ

ความไวของเคส

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

http: // www example.com /abc/def.ghi?jkl=mno#pqr

ผู้ใช้ @ example.com

หลักการและเหตุผล

การพิจารณาตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ใน URL สามารถใช้งานได้หลายอย่าง ส่วนใหญ่:

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

ในฐานะนักพัฒนาซอฟต์แวร์ฉันเชื่อว่าสิ่งที่กล่าวมาข้างต้นสามารถได้รับการจัดการในวิธีที่ดีกว่า แต่ฉันก็เข้าใจเช่นกันว่ามีบางกรณีที่สถานการณ์อาจไม่อนุญาต

ตัวอย่างเช่นลองนึกภาพผลิตภัณฑ์ที่มีอยู่ที่ต้องใช้ข้อมูลจำนวนมากใน URL "GET" แต่จะต้องเข้ากันได้กับความยาว URL สูงสุดของเซิร์ฟเวอร์หลักเบราว์เซอร์และกลไกการแคช / พร็อกซี / พร็อกซี เพื่อให้พอดีกับสตริงคำสั่งที่มีความยาวปานกลาง (ต่ำกว่า 1,024 อักขระสำหรับเบราว์เซอร์รุ่นเก่าบางรุ่น) คุณจะต้องใช้อักขระที่ปลอดภัยต่อ URL ที่ไม่ซ้ำกันทุกตัวที่คุณสามารถทำได้

ในโลกอุดมคติ

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

ดูเหมือนว่าหลายคนจะเห็นด้วยกับข้อเท็จจริงที่ว่า URL ที่ไม่ต้องสนใจตัวพิมพ์เล็กและใหญ่เปิดใช้งานสำหรับไซต์และบริการยอดนิยมจำนวนมากเพื่อเพิ่มการใช้งาน ตัวอย่างที่เด่นชัดที่สุดคือส่วนชื่อผู้ใช้ของที่อยู่อีเมล ผู้ให้บริการอีเมลส่วนใหญ่จะไม่สนใจขนาดตัวพิมพ์และบางครั้งอาจเป็นจุดและสัญลักษณ์อื่น ๆ (เช่น "j.smith@example.com" จะเหมือนกับ "JSMITH@example.com") แม้ว่าชื่อผู้ใช้อีเมลจะเป็นกรณี ๆ ไปตามค่าเริ่มต้นตามข้อมูลจำเพาะ

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

ปฏิบัติที่ดีที่สุด

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

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

— Beejor
แหล่งที่มา

-1

คำถามคือควรเป็นกรณี ๆ ไป?

ฉันไม่เห็นประโยชน์หรือแนวปฏิบัติที่ดีที่อยู่เบื้องหลังการพิจารณาตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ของ URL มันโง่ดูดและควรหลีกเลี่ยงตลอดเวลา

เพื่อสำรองความคิดเห็นของฉันเมื่อมีคนถามว่า URL ใดคุณจะอธิบายตัวอักษรของ URL ว่าเป็นตัวพิมพ์ใหญ่หรือตัวพิมพ์เล็กได้อย่างไร นั่นเป็นเรื่องไร้สาระและไม่ควรมีใครบอกคุณเป็นอย่างอื่น

— HenriKoppen
แหล่งที่มา

32

มีข้อดีอย่างหนึ่งต่อ URL ที่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ ในบางเว็บไซต์ที่วัตถุที่มีการเข้ารหัสด้วยรหัสที่ไม่ซ้ำที่สามารถเรียกผ่านทาง URL ที่เข้ารหัสสามารถเป็นสิ่งที่ชอบ base64 แทนbase36 นี้จะช่วยให้คุณสามารถเข้ารหัสวัตถุชี้แจงที่ไม่ซ้ำกันมากขึ้นในจำนวนที่เท่ากันของตัวละคร URL ตัวอย่างเช่น foo.com/000 - foo.com/zzz (ตัวพิมพ์เล็กและตัวพิมพ์เล็ก) อาจอ้างถึงวัตถุที่ไม่ซ้ำกัน 36 ^ 3 โดยที่ foo.com/000 - foo.com/ZZZ (คำนึงถึงตัวพิมพ์เล็กและใหญ่หมายถึง foo.com/zzz และ foo.com/ZZZ เป็นเส้นทางที่แตกต่างกัน) จะอ้างถึงวัตถุ 62 ^ 3

— Hart Simha

6

นี่ไม่ใช่คำตอบมันเป็นความเห็นที่ถูกวิจารณ์

— ชายดีบุก

1

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

— HenriKoppen

1

@theTinMan มันเป็นคำตอบของคำถามแสดงความคิดเห็นความรู้สึก

— chharvey

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

— jaybro

-3

สำหรับเว็บไซต์เจ้าภาพในเซิร์ฟเวอร์ Linux URL ที่เป็นกรณีที่สำคัญ http://www.google.co.th/aboutและhttp://www.google.co.th/Aboutจะถูกเปลี่ยนเส้นทางไปยังสถานที่ต่างๆ ในขณะที่อยู่ใน Windows Server URL จะเป็นแบบตัวพิมพ์เล็กและตัวพิมพ์ใหญ่เช่นเดียวกับการตั้งชื่อ FOLDER และจะถูกเปลี่ยนเส้นทางไปยังตำแหน่งเดียวกัน

— พระนารายณ์
แหล่งที่มา

-6

เป็นไปได้ที่จะทำให้ URL ที่ไม่สำคัญเป็นตัวพิมพ์เล็ก

RewriteEngine on
rewritemap lowercase int:tolower
RewriteCond $1 [A-Z]
RewriteRule ^/(.*)$ /${lowercase:$1} [R=301,L]

ทำให้ Google.com..GOOGLE.com เป็นต้นไปที่ google.com โดยตรง

— Renjith Gopi
แหล่งที่มา

สิ่งนี้ไม่ตอบคำถาม

— monokrome

3

คำถามคือ: "URL ควรมีตัวพิมพ์เล็กหรือใหญ่" คำตอบของคุณคือ: "วิธีทำ URL ที่ไม่ต้องพิมพ์เล็กและใหญ่"

— realPK