Tại sao hầu hết các trang web (tất cả?) Chỉ hỗ trợ tên người dùng trong ASCII? Có bất kỳ cân nhắc bảo mật nào nếu quản trị viên quyết định bắt đầu chấp nhận tên người dùng Unicode không?Có nên cho phép Unicode trong tên người dùng không?
Tôi sẽ nói lý do chính là thiếu hỗ trợ cho unicode trong hầu hết các cài đặt PHP. Nó không phải là dễ dàng để làm việc với, vậy tại sao cho phép nó khi các khả năng trong ASCII là đủ để trang trải toàn bộ cơ sở người dùng của bạn?
Câu hỏi không phải là về PHP nên sự khinh bỉ của ngôn ngữ đó không nên là một đối số. – Crozin
@Crozin: Nhiều ứng dụng web được viết bằng PHP, vì vậy nó có thể là một đối số cho những ứng dụng đó. Ngôn ngữ cụ thể đó có một lịch sử dài, buồn về sự hỗ trợ crappiest cho Unicode bên cạnh LaTeX. – Joey
@[email protected] Johannes_Rössel: Theo lập luận này, web chỉ nên được phổ biến với các ký tự latin? Để theo dõi câu trả lời của bạn, mặc dù bạn nói PHP thiếu hỗ trợ unicode, bạn tìm thấy nhiều trang web có nội dung unicode, ** ngoại trừ ** khi họ buộc người dùng của họ chọn ascii tên người dùng và mật khẩu. – banx
Đồng bằng ASCII là hiếm, tôi muốn nói. Thường thì không có ai nghĩ về nó vì ở Tây Âu Latin 1 cũng đủ và cho cả Mỹ nữa. Một số cơ sở dữ liệu phân biệt giữa văn bản trong bộ ký tự cũ và Unicode (varchar so với nvarchar) hoặc cho các cơ sở dữ liệu khác phải đặt một bộ ký tự đặc biệt.
Đặc biệt ở Mỹ, nhiều người thậm chí không bao giờ nhận thấy rằng ASCII sẽ không đủ. Một số cố gắng tìm lý do với »Người dùng phải nhập nó« hoặc tương tự mà chủ yếu là không có thật, mặc dù.
Để trả lời câu hỏi của bạn, tôi nghi ngờ có những cân nhắc bảo mật, ngoại trừ có thể giả mạo tên của người khác bằng cách sử dụng các tập lệnh khác nhau (và trông giống hệt, nhưng một là tiếng La tinh, một là Cyrillic - điều này đã được thực hiện với URL trước đó) . Nói chung tôi thấy nó như một sự giám sát của các nhà phát triển có lẽ nên biết rõ hơn.
Cuộc tấn công đồng luân. Người dùng 'mèo' và 'сat' là các chuỗi unicode khác nhau mặc dù chúng trông giống nhau. Chữ cái đầu tiên trong 'сat' thứ hai là tiếng Nga 'с' - "CYRILLIC SMALL LETTER ES" là chính xác. Hệ thống không thể dễ dàng nói rằng bạn đang giả mạo tên của người dùng khác - với máy tính, các nick khác nhau.
Chỉnh sửa: Ngăn chặn tập lệnh hỗn hợp không giải quyết được sự cố. Ví dụ 'сосо' là Cyryllic thuần túy và có thể được sử dụng để giả mạo ascii 'coco'.
Ngoài ra, ghi đè từ trái sang phải (và bạn bè.) Để chúng không được an toàn và chúng sẽ làm hỏng toàn bộ trang của bạn.
Vâng, nó * có thể * dễ dàng biết nếu bạn đang trộn các script và không cho phép chúng. Trình duyệt web tuân thủ quy tắc tương tự để hoàn nguyên IDN về hiển thị Punycode. – Joey
Bạn không phải lúc nào cũng cần * trộn * tập lệnh. Một số từ ascii tất cả có thể được tái tạo bằng cách sử dụng chỉ cyrillic, ví dụ 'coco'. Vì vậy, bạn cần phải đối phó với điều đó quá. –
Các cuộc tấn công homoglyph cũng có thể có trong ASCII; "0" và "O" không thể phân biệt được trong nhiều phông chữ, như là "|", "I", "l" và "1"; ".com", ".corn" trong số những người khác. –
Xác thực HTTP? Có thể có một số vấn đề khi gửi tên người dùng unicode (và/hoặc mật khẩu) qua các giao thức hiện có. Một trường hợp mà tôi đã gặp phải trước đó là xác thực cơ bản. Không có cách nào được xác định rõ ràng để xử lý việc gửi các tên người dùng/mật khẩu unicode này trong các tiêu đề auth cơ bản.
[UTF-7] (http://en.wikipedia.org/wiki/UTF-7) cho phép bạn truyền mã Unicode như ASCII. – dreamlax
Nhưng với utf-7 hoặc bất kỳ mã hóa nào khác, bạn cần sở hữu máy khách và mã máy chủ để đảm bảo rằng chúng sẽ giải mã dữ liệu đúng cách. – Mike
Đây là câu trả lời hay nhất trên trang vì tôi đang tìm kiếm lý do vẫn được áp dụng ngay cả khi quản trị viên phân bổ tất cả tên người dùng theo cách được kiểm soát. Chúng tôi thực sự vẫn đang sử dụng BASIC auth ... Tôi đoán điều này cho chúng ta một lý do để thả nó trong tương lai. – Trejkaz
Mặc dù bạn có thể tiếp tục và cho phép unicode, hiểu rằng một số tên người dùng sẽ không hoạt động như mong đợi nhờ các nền văn hóa khác nhau áp dụng các quy tắc khác nhau cho cùng một ký tự.
Hãy xem xét các trường hợp cơ bản vì vi phạm trường hợp sensivitity: Trong Thổ Nhĩ Kỳ, các tên người dùng "ID1" và "id1" là khác nhau (ở Thổ Nhĩ Kỳ có hai khác nhau là, một với một dấu chấm và một không có, dẫn đến 2 gọn Visitor Map và 2 chữ cái nhỏ không khớp với các quy tắc tương tự như tiếng Anh). Vì vậy, trong khi bất kỳ người Thổ Nhĩ Kỳ nào có thể nhập tên của họ bằng ngôn ngữ riêng của họ, chương trình sẽ không đối xử với tên của họ như họ mong đợi - thay vào đó nó sẽ trải qua một sự biến đổi kỳ lạ thành tiếng Anh đột biến.
Ký tự Latinh đặc biệt trong ngôn ngữ châu Âu có chồng chéo tương tự, làm cho nó dường như ngẫu nhiên như ngôn ngữ mà chúng đang được nhập. Các khu vực khác trên thế giới có các ký tự sử dụng khác nhau - trong một số trường hợp quốc gia và văn hóa sự thù hận có thể dẫn đến một số người dân giận dữ rất khi các nhân vật tạo tên người dùng của họ được coi như được viết bằng ngôn ngữ của kẻ thù bị ghét (do đó là cài đặt mặc định của hệ điều hành cho các ký tự nước ngoài đó).
Vì vậy, chúng ta cần PSP (lập trình nhạy cảm chính trị). Xấu hổ trong tập đoàn Unicode vì không phân loại tất cả những gì cho chúng tôi. ☺ –
Quan sát của bạn không phải lúc nào cũng đúng.Và, sự lựa chọn ASCII phần lớn là yếu tố con người hơn là các vấn đề kỹ thuật hoặc an ninh.
Đối với hầu hết các trường hợp, nó chỉ là để dễ lập trình. Một lập trình viên không bao giờ biết rằng tất cả các phần mềm, thư viện, tiện ích trong trang web sẽ phá vỡ hay không với một số ký tự. Tại sao rủi ro phát triển trang web trong khi ASCII hoạt động tốt? Ngoài ra, một số phần mềm web đóng gói sẽ cản trở việc sử dụng Unicode trong tên người dùng. Điều này góp phần vào vấn đề nhiều trang web chỉ hỗ trợ tên người dùng trong ASCII.
Về mặt lý thuyết, tất cả phần mềm hiện tại đều có thể xử lý dữ liệu 8 bit tốt. Không có vấn đề trong lưu trữ hoặc truyền ngày nay. Ngay cả khi một số giao thức không, chúng có thể dịch trong UTF-7 hoặc với các chương trình chuyển đổi khác.
Có một số vấn đề với Unicode. Nó là nhiều hơn ở phía bên của xử lý dữ liệu. Nó có thể là hiển thị, phông chữ, sự sẵn sàng của phần mềm và thư viện phần mềm cho các ký tự không phải BMP, đối chiếu, so sánh, phương thức nhập liệu, chỉ đường viết. Quản trị viên có thể không đủ hiểu biết để xử lý chúng. Tùy thuộc vào bản chất của trang web, nó có thể là một vấn đề, nhưng chủ yếu là không.
Vì mục đích quản trị, không dễ để nhập một số ký tự lạ. Nó làm cho quản trị viên khó tìm kiếm người dùng. Quản trị viên cũng khó để giữ tên người dùng xúc phạm bằng ngôn ngữ nước ngoài ngoài trang web.
Tuy nhiên, không phải là hiếm khi tên người dùng Trung Quốc được sử dụng trang web Trung Quốc. Nó có thể không phải lúc nào cũng trong ASCII. Vì vậy, làm các nền văn hóa và ngôn ngữ khác. Một số dự án toàn cầu chấp nhận gần như tất cả các loại ký tự Unicode. Wikipedia là một ví dụ.
Hoặc, chúng tôi chỉ có thể ngừng cung cấp thông tin về tên người dùng và liệu chúng tôi có thể phát âm/ghi nhớ nó hay không. Đó nên là mối quan tâm của USERS. Nếu không ai nhớ bạn, đó là mất mát của bạn. Và, đối với giả mạo tên, điều đó gần như không thể tránh khỏi trong mọi trường hợp. Tuy nhiên, hiếm khi bạn nghe về giả mạo tên người dùng.
Hãy tưởng tượng một diễn đàn, hãy tưởng tượng một người nào đó đăng bài bằng tài khoản LOOKS giống với của bạn. Bạn gặp rắc rối, nói rằng bạn đã không làm điều đó, đăng một liên kết đến lịch sử của bạn, xem bài viết không có ở đó. Nhấp vào hồ sơ của anh chàng HOẠT ĐỘNG đăng nó, và bam, bạn có hồ sơ của mình. Anh ta bây giờ là bannable.
Có cùng tên không có nghĩa là bạn có cùng dữ liệu người dùng. Bất kỳ ứng dụng nào không giúp bạn dễ dàng phân biệt hai người dùng tương tự đều là người nghèo khổ và cần được viết lại.
Điều này không trả lời được câu hỏi. Nó sẽ là tốt hơn như một bình luận theo một trong những câu trả lời khác. –
Trong khi tất cả có vấn đề tại sao phải có tên người dùng và không chỉ là 'mật khẩu' để xác định người dùng, tôi nghĩ không có lý do gì để không cho phép tên người dùng unicode.
Điều quan trọng hơn, là mật khẩu được xác thực là lanuguage-thuyết bất khả tri: nó sẽ xử lý keystokes bất kể cài đặt bàn phím của người dùng. Điều này có nghĩa là "שלום" và "akuo" sẽ là cùng một mật khẩu. Điều này là quan trọng, bởi vì người dùng thường không nhìn thấy các ký tự mật khẩu anh ta gõ, và họ đang nhận được pissed nghiêm trọng nếu CAPSLOCK là trên.
Điều này nghe có vẻ khá tuyệt vời nhưng tôi muốn thấy một hệ thống mà đáng tin cậy có thể làm điều này ... nói nếu IME của bạn là một trong đó có thể chuyển đổi mọi thứ trong một thời trang không thể đảo ngược. Ví dụ, 缶 用 で シ プ ェ て て？ s？ – Trejkaz
Tôi bỏ phiếu này nên là cộng đồng wiki. Âm thanh như một số cuộc thảo luận tốt đang bắt đầu. – jtbandes
nếu bạn quan tâm đến bảo mật mã của bạn, bạn không nên cho phép unicode ở bất kỳ đâu (trừ khi bạn là masochist ** và ** unicode expert ** và ** bạn là người duy nhất sẽ phải duy trì code) –
@ L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳, Trên thực tế điểm cuối cùng nên được "** và ** duy trì cũng đủ điều kiện (1) và (2)." – Pacerier