ทำไมต้องเป็นตัวพิมพ์เล็ก - ใหญ่ URL

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

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

ตัวอย่างเช่น Wikipedia เป็นเว็บไซต์ที่ละเอียดอ่อนต่อตัวอักษร (ยกเว้นตัวอักษรตัวแรก):

https://en.wikipedia.org/wiki/St ck_Exchangeคือกรมวิชาการเกษตร

ทำไม URL จะไม่ตรงตามตัวพิมพ์ใหญ่ - เล็ก

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

มีเว็บเซิร์ฟเวอร์มากมายหลายแบบที่เปิดตัว Microsoft ได้เปิดตัว IIS พร้อมกับระบบปฏิบัติการ Windows Server (และอื่น ๆ รวมถึง Windows XP Professional) Unix มีรุ่นใหญ่อย่าง nginx และ Apache ไม่ต้องพูดถึงข้อเสนอเล็ก ๆ เช่น httpd ภายในของ OpenBSD หรือ thttpd หรือ lighttpd นอกจากนี้อุปกรณ์ที่รองรับเครือข่ายจำนวนมากได้สร้างขึ้นในเว็บเซิร์ฟเวอร์ที่สามารถใช้เพื่อกำหนดค่าอุปกรณ์รวมถึงอุปกรณ์ที่มีจุดประสงค์เฉพาะกับเครือข่ายเช่นเราเตอร์ (รวมถึงจุดเชื่อมต่อ Wi-Fi จำนวนมากและโมเด็ม DSL) และอุปกรณ์อื่น ๆ เช่นเครื่องพิมพ์หรือ UPS (หน่วยจ่ายไฟสำรองที่สำรองแบตเตอรี่) ซึ่งอาจมีการเชื่อมต่อเครือข่าย

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

เหตุผลสำคัญสำหรับพฤติกรรมที่แตกต่างกันระหว่างเว็บเซิร์ฟเวอร์ที่แตกต่างกันอาจทำให้เกิดความยุ่งยาก วิธีง่ายๆในการสร้างเว็บเซิร์ฟเวอร์คือการทำสิ่งต่าง ๆ เช่นเดียวกับที่ระบบปฏิบัติการของคอมพิวเตอร์ / อุปกรณ์ค้นหาไฟล์ หลายครั้งที่เว็บเซิร์ฟเวอร์ค้นหาไฟล์เพื่อให้ตอบกลับ Unix ได้รับการออกแบบให้ใช้งานกับคอมพิวเตอร์ระดับสูงได้ดังนั้น Unix จึงมีฟังก์ชั่นที่ต้องการในการใช้ตัวอักษรตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก Unix ตัดสินใจที่จะปฏิบัติต่อตัวพิมพ์ใหญ่และตัวพิมพ์เล็กเพราะแตกต่างกันเพราะมันต่างกัน นั่นคือสิ่งที่ตรงไปตรงมาและเป็นธรรมชาติที่ต้องทำ Windows มีประวัติว่าเป็นตัวพิมพ์เล็กและตัวพิมพ์ใหญ่เนื่องจากต้องการสนับสนุนซอฟต์แวร์ที่สร้างขึ้นมาแล้วและประวัตินี้กลับไปที่ DOS ซึ่งไม่รองรับตัวอักษรตัวพิมพ์เล็ก อาจเป็นไปได้ในความพยายามที่จะลดความซับซ้อนของสิ่งต่าง ๆ ด้วยคอมพิวเตอร์ที่มีประสิทธิภาพน้อยกว่าที่ใช้หน่วยความจำน้อยลง เนื่องจากระบบปฏิบัติการเหล่านี้มีความแตกต่างกันผลลัพธ์คือเว็บเซิร์ฟเวอร์ที่ได้รับการออกแบบอย่างเรียบง่าย (เวอร์ชั่นก่อนหน้า) จะมีความแตกต่างกัน

ตอนนี้ด้วยพื้นหลังทั้งหมดต่อไปนี้เป็นคำตอบเฉพาะของคำถามเฉพาะ:

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

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

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

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

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

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

อย่างไรก็ตามในหลายกรณีไม่มีประโยชน์ที่น่าสนใจอย่างยิ่งต่อความไวของตัวพิมพ์เล็กซึ่งพิสูจน์ได้จากข้อเท็จจริงที่ว่า IIS มักไม่สนใจมัน

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

URL ไม่คำนึงถึงตัวอักษรพิมพ์เล็ก - ใหญ่มีเพียงบางส่วนเท่านั้น
ยกตัวอย่างเช่นไม่มีอะไรที่เป็นกรณี ๆ ไปใน URL https://google.com,

โดยอ้างอิงถึงRFC 3986 - Uniform Resource Identifier (URI): ไวยากรณ์ทั่วไป

ก่อนอื่นจากWikipedia URL จะมีลักษณะดังนี้:

 scheme:[//host[:port]][/]path[?query][#fragment]

(ฉันลบuser:passwordส่วนนี้ออกเพราะไม่น่าสนใจและไม่ค่อยได้ใช้)

• scheme:

แบบแผนไม่ตรงตามตัวพิมพ์เล็กและตัวพิมพ์ใหญ่

• host:

คอมโพเนนต์ย่อยของโฮสต์ไม่คำนึงถึงขนาดตัวพิมพ์

• path:

องค์ประกอบเส้นทางมีข้อมูล ...

• query:

องค์ประกอบการสืบค้นมีข้อมูลที่ไม่ใช่ลำดับชั้น ...

• fragment:

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

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

ทำไมต้องตรงตามตัวpathพิมพ์ใหญ่ - เล็ก

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

 scheme:[//host[:port]][/]path[?query][#fragment]
 \____________________/\________________________/
        Location                 Data

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

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

มันมีประโยชน์หรือไม่

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

• Base64ซึ่งจะใช้ในข้อมูลยูริ
• ไซต์สามารถเข้ารหัสข้อมูล Base64 ใน url ตัวอย่างเช่น: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgAgAgAgAgAgAgAgAgAgQaAgQaAgQaAgQaAgQZAgAgAzAgQAAAQQAGQA
• เครื่องมือย่อ URL ใช้ตัวพิมพ์เล็กและตัวพิมพ์ใหญ่: /a5Bอาจแตกต่างจาก/a5b
• ตามที่คุณพูดถึงวิกิพีเดียสามารถแยก "เอดส์" ออกจาก "เอดส์"

ง่าย ระบบปฏิบัติการเป็นกรณี ๆ ไป โดยทั่วไปแล้วเว็บเซิร์ฟเวอร์จะไม่สนใจจนกว่าพวกเขาจะต้องตีระบบไฟล์ในบางจุด นี่คือที่ Linux และระบบปฏิบัติการที่ใช้ Unix อื่น ๆ บังคับใช้กฎของระบบไฟล์ในกรณีที่ความไวเป็นส่วนสำคัญ นี่คือสาเหตุที่IISไม่คำนึงถึงขนาดตัวพิมพ์ เพราะ Windows ไม่คำนึงถึงขนาดตัวพิมพ์

[Update]

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

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

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

โปรดจำไว้ว่าเว็บเซิร์ฟเวอร์ยุคแรก ๆ วิ่งบนคอมพิวเตอร์ราคาแพงเช่นเซิร์ฟเวอร์ DEC VAX / VMS และ Unix ของวัน (Berkeley และ Ultrix รวมถึงอื่น ๆ ) บนคอมพิวเตอร์เฟรมหลักหรือเฟรมกลางหลังจากนั้นไม่นาน คอมพิวเตอร์ที่มีน้ำหนักเบาเช่นพีซีและ Windows 3.1 เมื่อเครื่องมือค้นหาที่ทันสมัยมากขึ้นเริ่มปรากฏเช่น Google ในปี 1997/8 Windows ได้ย้ายเข้าสู่ Windows NT และระบบปฏิบัติการอื่น ๆ เช่น Novell และ Linux ก็เริ่มเรียกใช้เว็บเซิร์ฟเวอร์ Apache เป็นเว็บเซิร์ฟเวอร์ที่โดดเด่นแม้ว่าจะมีเว็บไซต์อื่น ๆ เช่น IIS และ O'Reilly ซึ่งเป็นที่นิยมเช่นกัน ไม่มีของพวกเขาในเวลาข้ามบริการระบบปฏิบัติการ มีโอกาสที่เว็บเซิร์ฟเวอร์จะไม่ทำเลยแม้แต่วันนี้

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

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

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

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

เป็นคนง่าย ๆ จริงๆ มันไม่ใช่วิทยาศาสตร์จรวด มีความสัมพันธ์แบบสัมบูรณ์ระหว่างส่วนพา ธ / ไฟล์ของ URL และระบบไฟล์

1. URL ที่อ้างว่าเป็น UNIFORM Resource locator และสามารถชี้ไปยังแหล่งข้อมูลที่นำหน้าเว็บได้ สิ่งเหล่านี้บางตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ (เช่นเซิร์ฟเวอร์ ftp จำนวนมาก) และ URL ต้องสามารถแสดงทรัพยากรเหล่านี้ในรูปแบบที่ใช้งานง่าย

2. การคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ต้องใช้งานได้มากกว่าเมื่อค้นหาคู่ที่ตรงกัน (ทั้งใน OS หรือสูงกว่า)

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

4. กรณีที่ไม่รู้สึกอาจจะไม่น่ารำคาญในบริบทระหว่างประเทศ: https://en.wikipedia.org/wiki/Dotted_and_dotless_I RFC1738 ยังอนุญาตให้ใช้อักขระนอกช่วง ASCII หากมีการเข้ารหัส แต่ไม่ได้ระบุชุดอักขระ สิ่งนี้ค่อนข้างสำคัญสำหรับบางสิ่งที่เรียกตัวเองว่าเป็นเวิลด์ไวด์เว็บ การกำหนด URL โดยไม่คำนึงถึงขนาดตัวพิมพ์จะทำให้ขอบเขตของข้อบกพร่องมากขึ้น

5. หากคุณพยายามที่จะแพ็คข้อมูลจำนวนมากลงใน URI (เช่นData URI ) คุณสามารถแพ็คเพิ่มเติมได้ในกรณีที่ตัวพิมพ์ใหญ่และตัวพิมพ์เล็กแตกต่างกัน

ฉันขโมยสิ่งเก่าสิ่งใหม่มาจากบล็อกของการเข้าใกล้คำถามของแบบฟอร์ม "ทำไมมันถึงเป็นอย่างนั้นล่ะ?" ด้วยคำถามตอบโต้ "โลกจะเป็นอย่างไรถ้าไม่ใช่ในกรณีนี้?"

ว่าฉันตั้งค่าเว็บเซิร์ฟเวอร์เพื่อให้บริการไฟล์เอกสารของตัวเองจากโฟลเดอร์เพื่อให้ฉันสามารถอ่านพวกเขาบนโทรศัพท์เมื่อฉันออกจากสำนักงาน ตอนนี้ในโฟลเดอร์เอกสารของฉันฉันมีสามไฟล์todo.txt, ToDo.txtและTODO.TXT(ฉันรู้ แต่มันทำให้ความรู้สึกกับฉันเมื่อฉันทำไฟล์)

ฉันต้องการใช้ URL ใดในการเข้าถึงไฟล์เหล่านี้ http://www.example.com/docs/filenameฉันต้องการที่จะเข้าถึงพวกเขาในทางที่ใช้งานง่ายโดยใช้

ว่าฉันมีสคริปต์ที่ให้ฉันเพิ่มผู้ติดต่อในสมุดรายชื่อของฉันซึ่งฉันสามารถทำผ่านเว็บ วิธีที่ใช้พารามิเตอร์ของมัน? http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reillyดีฉันต้องการที่จะใช้มันเหมือน: แต่ถ้าไม่มีวิธีให้ฉันระบุชื่อเป็นกรณี ๆ ไปฉันจะทำยังไงดี?

ฉันจะแยกหน้า wiki สำหรับ Cat และ CAT, Text and TEXT, latex และ LaTeX ได้อย่างไร Disambig Pages ฉันเดา แต่ฉันชอบที่จะได้สิ่งที่ฉันขอ

แต่ทั้งหมดที่ให้ความรู้สึกเหมือนกำลังตอบคำถามผิดอยู่ดี

คำถามที่ฉันคิดว่าคุณถามจริง ๆ คือ "ทำไมเว็บเซิร์ฟเวอร์ 404 ถึงคุณต่างกันแค่กรณีเมื่อคอมพิวเตอร์เป็นคอมพิวเตอร์ที่ออกแบบมาเพื่อทำให้ชีวิตง่ายขึ้น URL ที่ฉันพิมพ์จะใช้งานได้หรือไม่ "

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

แม้ว่าคำตอบข้างต้นนั้นถูกต้อง & ดี ฉันต้องการเพิ่มคะแนน

เพื่อความเข้าใจที่ดีขึ้นเราควรเข้าใจความแตกต่างพื้นฐานระหว่างเซิร์ฟเวอร์ Unix (Linux) Vs Windows Unix คำนึงถึงขนาดตัวพิมพ์ & Windows ไม่คำนึงถึงขนาดตัวพิมพ์

โปรโตคอล HTTP ได้รับการพัฒนาหรือเริ่มนำไปใช้งานในปี 1990 โปรโตคอล HTTP ได้รับการออกแบบโดยวิศวกรที่ทำงานที่สถาบัน CERN ซึ่งส่วนใหญ่นักวิทยาศาสตร์ใช้เครื่อง Unix ไม่ใช่ Windows

นักวิทยาศาสตร์ส่วนใหญ่คุ้นเคยกับ Unix ดังนั้นพวกเขาอาจได้รับอิทธิพลจากระบบไฟล์สไตล์ Unix

เซิร์ฟเวอร์ Windows ได้เปิดตัวหลังจากปี 2000 มากก่อนที่เซิร์ฟเวอร์ Windows จะกลายเป็นโปรโตคอล HTTP ที่ได้รับความนิยมนั้นได้รับการพัฒนาอย่างเต็มที่

นี่อาจเป็นเหตุผล

เราควรอ่าน "ทำไมจึงออกแบบวิธีนี้" คำถาม? คุณกำลังขอบัญชีที่ถูกต้องในอดีตเกี่ยวกับกระบวนการตัดสินใจหรือคุณกำลังถามว่า "ทำไมทุกคนจะออกแบบด้วยวิธีนี้?"

เป็นไปได้ยากมากที่จะได้รับบัญชีที่มีความแม่นยำ บางครั้งเมื่อมีการตัดสินใจในคณะกรรมการมาตรฐานมีหลักฐานทางว่าการอภิปรายเกิดขึ้นได้อย่างไร แต่ในช่วงแรก ๆ ของการตัดสินใจทางเว็บถูกเร่งรีบโดยบุคคลบางคน - ในกรณีนี้อาจโดย TimBL ตัวเอง - และเหตุผลที่ไม่น่าเป็นไปได้ ที่จะได้รับการเขียนลง แต่ TimBL ยอมรับว่าเขาทำผิดพลาดในการออกแบบ URL - ดูhttp://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address -mistake.html

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

สิ่งนี้ไม่เกี่ยวกับตำแหน่งที่คุณซื้อโดเมน DNS ไม่คำนึงถึงขนาดตัวพิมพ์ แต่ระบบไฟล์บนเซิร์ฟเวอร์ที่คุณใช้สำหรับโฮสต์นั้น

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

Closetnoc นั้นถูกต้องเกี่ยวกับระบบปฏิบัติการ ระบบไฟล์บางระบบใช้ชื่อเดียวกันกับตัวเครื่องที่ต่างกัน

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

ใช่. เพื่อหลีกเลี่ยงปัญหาเนื้อหาที่ซ้ำกัน

หากคุณมีตัวอย่าง URL ต่อไปนี้:

http://example.com/page-1
http://example.com/Page-1
http://example.com/paGe-1
http://example.com/PAGE-1
http://example.com/pAGE-1

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

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

ความไวตัวพิมพ์เล็ก - ใหญ่มีค่า

หากมี 26 ตัวอักษรแต่ละตัวมีความสามารถในการตัวพิมพ์ใหญ่นั่นคือ 52 ตัวอักษร

4 ตัวอักษรมีความเป็นไปได้รวมกัน 52 * 52 * 52 * 52 ซึ่งเท่ากับ 7311616 ชุด

หากคุณไม่สามารถใช้อักษรตัวพิมพ์ใหญ่ได้จำนวนชุดค่าผสมคือ 26 * 26 * 26 * 26 = 456976

ชุดค่าผสมมีความยาวรวมกันมากกว่า 14 เท่าสำหรับ 52 ตัวอักษรมากกว่าที่มีอยู่ 26 ตัวดังนั้นสำหรับการจัดเก็บข้อมูล URL อาจสั้นลงและสามารถส่งผ่านข้อมูลได้มากกว่าผ่านเครือข่ายที่มีการถ่ายโอนข้อมูลน้อยลง

นี่คือเหตุผลที่คุณเห็น youtube โดยใช้ URL เช่นhttps://www.youtube.com/watch?v=xXxxXxxX