URL có nên phân biệt chữ hoa chữ thường?

Tôi nhận thấy rằng

HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK

và

http://stackoverflow.com/questions/ask

cả hai đều hoạt động tốt - thực sự cái trước được chuyển thành chữ thường.

Tôi nghĩ rằng điều này có ý nghĩa cho người dùng.

Nếu tôi nhìn vào Google thì URL này hoạt động tốt:

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

nhưng cái này với "GIỚI THIỆU" không hoạt động:

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

URL có nên phân biệt chữ hoa chữ thường?

Theo " HTML và URL " của W3, họ nên:

Có thể có URL hoặc một phần của URL, trong trường hợp không quan trọng, nhưng việc xác định chúng có thể không dễ dàng. Người dùng phải luôn luôn xem xét rằng URL là phân biệt chữ hoa chữ thường.

Tất cả các khu vực không nhạy cảm của sê-ri được in đậm để dễ đọc.

Tên miền không phân biệt chữ hoa chữ thường theo RFC 4343 . Phần còn lại của URL được gửi đến máy chủ thông qua phương thức GET. Điều này có thể là trường hợp nhạy cảm hoặc không.

Lấy trang này làm ví dụ, stackoverflow.com nhận chuỗi GET / câu hỏi / 7996919 / nên phân biệt chữ hoa chữ thường , gửi tài liệu HTML đến trình duyệt của bạn. Stackoverflow.com không phân biệt chữ hoa chữ thường vì nó tạo ra kết quả tương tự cho / QUEStions / 7996919 / Nên-url-be-case-nhạy cảm .

Mặt khác, Wikipedia là trường hợp nhạy cảm ngoại trừ ký tự đầu tiên của tiêu đề. Các URL https://en.wikipedia.org/wiki/Case_sens nhạy và https://en.wikipedia.org/wiki/case_sens nhạy dẫn đến cùng một bài viết, nhưng https://en.wikipedia.org/wiki/CASE_SENSITIVITY trả về 404.

Phụ thuộc vào hệ điều hành lưu trữ. Các trang web được lưu trữ trên Windows có xu hướng không phân biệt chữ hoa chữ thường vì hệ thống tệp cơ bản không phân biệt chữ hoa chữ thường. Các trang web được lưu trữ trên các hệ thống loại Unix có xu hướng phân biệt chữ hoa chữ thường vì các hệ thống tệp cơ bản của chúng thường phân biệt chữ hoa chữ thường. Phần tên máy chủ của URL luôn không phân biệt chữ hoa chữ thường, đó là phần còn lại của đường dẫn khác nhau.

Phần tên miền của URL không phân biệt chữ hoa chữ thường vì DNS bỏ qua trường hợp: http://en.example.org/và HTTP://EN.EXAMPLE.ORG/cả hai đều mở cùng một trang.

Đường dẫn được sử dụng để chỉ định và có thể tìm thấy tài nguyên được yêu cầu. Nó phân biệt chữ hoa chữ thường, mặc dù nó có thể được coi là không phân biệt chữ hoa chữ thường bởi một số máy chủ, đặc biệt là các máy chủ dựa trên Microsoft Windows.

Nếu máy chủ phân biệt chữ hoa chữ thường và http://en.example.org/wiki/URLđúng, thì http://en.example.org/WIKI/URLhoặc http://en.example.org/wiki/urlsẽ hiển thị trang lỗi HTTP 404, trừ khi các URL này trỏ đến chính các tài nguyên hợp lệ.

Tôi không phải là một fan hâm mộ của các bài báo cũ nhưng vì đây là một trong những phản hồi đầu tiên cho vấn đề đặc biệt này, tôi cảm thấy cần phải làm rõ điều gì đó.

Vì câu trả lời @Bhavin Shah nói rằng phần tên miền của url không phân biệt chữ hoa chữ thường, vì vậy

http://google.com 

và

http://GOOGLE.COM 

và

http://GoOgLe.CoM 

đều giống nhau nhưng mọi thứ sau phần tên miền được coi là phân biệt chữ hoa chữ thường.

vì thế...

http://GOOGLE.COM/ABOUT

và

http://GOOGLE.COM/about

là khác nhau

Lưu ý: Tôi đang nói "về mặt kỹ thuật" chứ không phải "theo nghĩa đen" trong nhiều trường hợp, thực tế, các máy chủ được thiết lập để xử lý các mục này giống nhau, nhưng có thể thiết lập chúng để chúng KHÔNG bị xử lý như nhau.

Các máy chủ khác nhau xử lý việc này khác nhau và trong một số trường hợp, chúng phải phân biệt chữ hoa chữ thường. Trong nhiều trường hợp, các giá trị chuỗi truy vấn được mã hóa (chẳng hạn như Id phiên hoặc dữ liệu được mã hóa Base64 được truyền dưới dạng giá trị chuỗi truy vấn) Các mục này có phân biệt chữ hoa chữ thường nên máy chủ phải phân biệt chữ hoa chữ thường để xử lý chúng.

Vì vậy, để trả lời câu hỏi, "máy chủ" có nên phân biệt chữ hoa chữ thường trong việc lấy dữ liệu này không, câu trả lời là "có, chắc chắn nhất".

Tất nhiên không phải mọi thứ đều cần phân biệt chữ hoa chữ thường nhưng máy chủ nên nhận thức được đó là gì và cách xử lý các trường hợp đó.

Nhận xét của @Hart Simha nói về điều tương tự. Tôi đã bỏ lỡ nó trước khi tôi đăng vì vậy tôi muốn cung cấp tín dụng khi tín dụng đáo hạn.

Xem thông số kỹ thuật tại đây: phần 2.7.3 http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19

Đề án và máy chủ lưu trữ không phân biệt chữ hoa chữ thường và thường được cung cấp bằng chữ thường; tất cả các thành phần khác được so sánh theo cách phân biệt chữ hoa chữ thường.

Hãy xem xét những điều sau đây:

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

Trong ví dụ giả thuyết này, một biểu mẫu HTML - sử dụng phương thức GET - sẽ gửi tham số "tên" tới tập lệnh PHP tạo tài khoản người dùng mới.

Và điểm tôi đưa ra với ví dụ này là tham số GET này cần phân biệt chữ hoa chữ thường để bảo toàn chữ viết hoa của "McCartney" (hoặc, như một ví dụ khác, để bảo toàn "Walter d'Isney", vì có nhiều cách khác cho tên để phá vỡ các quy tắc viết hoa thông thường).

Các trường hợp như thế này hướng dẫn khuyến nghị của W3C rằng lược đồ và máy chủ không phân biệt chữ hoa chữ thường, nhưng mọi thứ sau đó đều có khả năng phân biệt chữ hoa chữ thường - và được để lại cho máy chủ. Buộc không nhạy cảm trường hợp theo tiêu chuẩn sẽ làm cho ví dụ trên không có khả năng bảo toàn trường hợp đầu vào của người dùng được truyền dưới dạng tham số truy vấn GET.

Nhưng điều tôi muốn nói là mặc dù đây nhất thiết phải là lá thư của luật để giải quyết những trường hợp như vậy, nhưng tinh thần của luật là ở chỗ, trường hợp không liên quan, hãy hành xử theo cách không nhạy cảm. Mặc dù vậy, các tiêu chuẩn không thể cho bạn biết trường hợp nào không liên quan bởi vì, giống như các ví dụ tôi đã đưa ra, đó là một điều phụ thuộc vào ngữ cảnh.

(ví dụ: tên người dùng tài khoản có thể bị buộc là không nhạy cảm với trường hợp - vì "User123" và "user123" là các tài khoản khác nhau có thể gây nhầm lẫn - ngay cả khi tên thật của họ, như trên, là trường hợp nhạy cảm nhất.

Đôi khi nó có liên quan, hầu hết các lần nó không. Nhưng nó phải được để lại cho nhà phát triển máy chủ / web quyết định những điều này - và không thể được quy định theo tiêu chuẩn - vì chỉ ở mức đó mới có thể biết được bối cảnh.

Đề án và máy chủ lưu trữ không phân biệt chữ hoa chữ thường (cho thấy ưu tiên của tiêu chuẩn đối với độ nhạy cảm của trường hợp, trong đó nó có thể được quy định chung). Phần còn lại tùy thuộc vào bạn để quyết định, vì bạn hiểu bối cảnh tốt hơn. Nhưng, như đã được thảo luận, có lẽ, theo tinh thần của luật pháp, mặc định là không nhạy cảm với trường hợp trừ khi bạn có lý do chính đáng để không.

Các URL nên không phân biệt chữ hoa chữ thường trừ khi có lý do chính đáng tại sao chúng không nên.

Điều này không bắt buộc (nó không phải là một phần của RFC) nhưng nó làm cho việc liên lạc và lưu trữ URL đáng tin cậy hơn nhiều.

Nếu tôi có hai trang trên một trang web:

http://stackoverflow.com/ABOUT.html

và

http://stackoverflow.com/about.html

Chúng nên khác nhau như thế nào? Có thể một người được viết 'phong cách la hét' (mũ) - nhưng theo quan điểm của IA, không bao giờ nên phân biệt bằng cách thay đổi trong trường hợp của URL.

Hơn nữa, thật dễ dàng để thực hiện điều này trong Apache - chỉ cần sử dụng CheckSpelling Ontừ mod_Speling.

Câu hỏi cũ nhưng tôi đã vấp ngã ở đây vì vậy tại sao không chụp nó vì câu hỏi đang tìm kiếm quan điểm khác nhau và không phải là một câu trả lời dứt khoát.

w3c có thể có các đề xuất của nó - điều mà tôi quan tâm rất nhiều - nhưng muốn suy nghĩ lại vì câu hỏi ở đây.

Tại sao w3c coi tên miền không phân biệt chữ hoa chữ thường và để lại bất cứ thứ gì sau đó không phân biệt chữ hoa chữ thường?

Tôi nghĩ rằng lý do là phần tên miền của URL được nhập bởi người dùng. Mọi thứ sau khi được siêu văn bản sẽ được máy giải quyết (trình duyệt và máy chủ ở phía sau).

Máy móc có thể xử lý trường hợp không nhạy cảm tốt hơn con người (không phải loại kỹ thuật :)).

Nhưng câu hỏi chỉ là vì các máy CÓ THỂ xử lý được mà nên làm theo cách đó?

Ý tôi là những lợi ích của việc đặt tên và truy cập tài nguyên ở hereIsTheResourcevshereistheresource gì?

Phần bên rất khó đọc hơn trường hợp lạc đà dễ đọc hơn. Có thể đọc được cho Con người (bao gồm các loại kỹ thuật.)

Vì vậy, đây là điểm của tôi: -

Đường dẫn tài nguyên rơi vào một nơi nào đó ở giữa cấu trúc lập trình và đôi khi gần với người dùng cuối đằng sau trình duyệt.

URL của bạn (không bao gồm tên miền) không phân biệt chữ hoa chữ thường nếu người dùng của bạn sẽ chạm vào nó hoặc gõ nó, v.v. Bạn nên phát triển ứng dụng của mình để AVOID yêu cầu người dùng nhập đường dẫn càng nhiều càng tốt.

URL của bạn (không bao gồm tên miền) phải phân biệt chữ hoa chữ thường nếu người dùng của bạn sẽ không bao giờ gõ nó bằng tay.

Phần kết luận

Đường dẫn phải là trường hợp nhạy cảm. Điểm của tôi đang cân nhắc đối với các trường hợp nhạy cảm trường hợp.

Các ký tự URL được chuyển đổi thành mã hex (nếu bạn đã nhận thấy khoảng trắng trong URL được hiển thị là% 20, v.v.) và vì chữ thường và chữ hoa có các giá trị hex khác nhau, điều đó có nghĩa hoàn hảo rằng URL rất nhạy cảm với trường hợp. Tuy nhiên, tinh thần của câu hỏi dường như NÊN là tiêu chuẩn và tôi nói không, nhưng chúng là như vậy. Tùy thuộc vào nhà phát triển / nhà cung cấp để giải thích điều này trong mã của họ nếu họ muốn nó hoạt động bất kể người dùng cuối.

Tôi nghĩ rằng điều này và nhiều câu trả lời xung quanh những gì thông số kỹ thuật không hoặc không nói là thiếu điểm của câu hỏi. Họ có nên nhạy cảm trường hợp? Đó thực sự là một câu hỏi được tải. Từ quan điểm của người dùng, độ nhạy trường hợp là một điểm đau, không phải ai cũng biết tạo nên sự khác biệt. Câu hỏi về việc URI nên hay không nên, tùy thuộc vào ngữ cảnh của câu hỏi. Đối với linh hoạt kỹ thuật, có, họ nên được. Đối với khả năng sử dụng, không, họ không nên.

Bảo quản trường hợp

URL được bảo quản trường hợp , giữa máy khách và máy chủ. Nhưng các phần của URL có thể hoặc không phân biệt chữ hoa chữ thường , tùy thuộc vào máy chủ, vì một vài lý do.

Độ nhạy trường hợp

Các phần in đậm sau đây của URL có thể phân biệt chữ hoa chữ thường, tùy thuộc vào cấu hình trang web và / hoặc máy chủ.

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

    người sử dụng @ example.com

Cơ sở lý luận

Phân biệt chữ hoa chữ thường trong URL có thể có một số cách sử dụng. Chủ yếu:

1. Khả năng tương thích với các hệ thống tập tin phân biệt chữ hoa chữ thường.
2. Mã hóa dữ liệu nhỏ gọn hơn trong các URL, chẳng hạn như để tuần tự hóa, băm, ID, permalinks và rút ngắn URL.

Là một nhà phát triển, tôi tin rằng những điều trên thường có thể được xử lý theo những cách tốt hơn, nhưng tôi cũng hiểu có những trường hợp tình huống có thể không cho phép điều này.

Ví dụ: hãy tưởng tượng một sản phẩm hiện có yêu cầu nhiều dữ liệu được đặt trong URL "NHẬN", nhưng nó phải tương thích với độ dài URL tối đa của tất cả các máy chủ, trình duyệt và cơ chế bộ đệm / proxy chính. Để phù hợp với một chuỗi lệnh có độ dài vừa phải (dưới 1.024 ký tự cho một số trình duyệt cũ hơn), bạn cần sử dụng mọi ký tự an toàn URL duy nhất bạn có thể (về cơ bản là mã hóa base64url).

Trong một thế giới lý tưởng

Hay không URL nên được trường hợp nhạy cảm là gây tranh cãi. Cá nhân tôi tin rằng họ không nên đơn giản (mặc dù có thể tạo các URL dài hơn, chúng tôi có phần trăm thoát để dễ dàng xử lý các trường hợp chúng tôi phải đảm bảo giữ nguyên các ký tự chính xác và có nhiều cách để truyền dữ liệu ngoài quyền trong URL) .

Nhiều người dường như đồng ý dựa trên thực tế là các URL không phân biệt chữ hoa chữ thường được kích hoạt rõ ràng cho nhiều trang web và dịch vụ phổ biến, nhằm tăng khả năng sử dụng. Ví dụ nổi bật nhất là phần tên người dùng của địa chỉ email. Hầu hết các nhà cung cấp email sẽ bỏ qua trường hợp và đôi khi cả các dấu chấm và các ký hiệu khác (như "j.smith@example.com" giống như "JSMITH@example.com"). Mặc dù tên người dùng email được phân biệt chữ hoa chữ thường theo mặc định, theo thông số kỹ thuật.

Tuy nhiên, thực tế là bất chấp những gì tôi hoặc người khác có thể muốn, đây là trạng thái của mọi thứ hiện đang hoạt động. Và mặc dù việc chuyển đổi trên toàn thế giới thành một tiêu chuẩn URL không phân biệt chữ hoa là điều chắc chắn có thể xảy ra, có thể sẽ mất khá nhiều thời gian vì độ nhạy trường hợp hiện đang được sử dụng rộng rãi trên web cho các mục đích khác nhau.

Thực hành tốt nhất

Theo như các thực tiễn tốt nhất, với tư cách là một người dùng, bạn có thể sử dụng hợp lý chữ thường trong hầu hết các tình huống và mong muốn mọi thứ hoạt động. Các ngoại lệ chính sẽ là các URL sử dụng đường dẫn tài liệu hoặc mã hóa dựa trên trường hợp với các tương đương hệ thống tệp trực tiếp. Tuy nhiên, các URL phức tạp như vậy thường được sao chép (hoặc nhấp đơn giản) thay vì nhập thủ công.

Là một nhà phát triển web, bạn nên xem xét việc giữ các URL không phân biệt chữ hoa chữ thường nhất có thể. Mặc dù rõ ràng có một số tình huống khó tránh, tùy thuộc vào bối cảnh, như đã lưu ý ở trên.

Câu hỏi là url có nên phân biệt chữ hoa chữ thường không?

Tôi thấy không sử dụng hoặc thực hành tốt đằng sau trường hợp URL nhạy cảm. Nó ngu ngốc, nó hút và nên tránh mọi lúc.

Chỉ cần sao lưu ý kiến ​​của tôi, khi ai đó hỏi URL nào, làm thế nào bạn có thể giải thích các ký tự của URL là chữ hoa hoặc chữ thường? Điều đó thật vô nghĩa và không ai có thể nói với bạn điều gì khác.

Đối với các trang web được lưu trữ trong máy chủ Linux, URL phân biệt chữ hoa chữ thường. http://www.google.com/about và http://www.google.com/ About sẽ được chuyển hướng đến các địa điểm khác nhau. Mặc dù trong Windows Server, URL không phân biệt chữ hoa chữ thường, như khi đặt tên một FOLDER và sẽ được chuyển hướng đến cùng một vị trí.

Có thể tạo các URL không nhạy cảm

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

Làm cho Google.com..GOOGLE.com vv trực tiếp vào google.com