Dlaczego większość (wszystkich?) Witryn obsługuje tylko nazwy użytkowników w ASCII? Czy są jakieś względy bezpieczeństwa, jeśli administrator zdecyduje się rozpocząć akceptowanie nazw użytkownika Unicode?Czy w nazwach użytkowników dozwolony jest kod Unicode?
Powiedziałbym, że ważnym powodem jest brak obsługi standardu Unicode w większości instalacji PHP. Nie jest łatwo z nim pracować, więc po co pozwalać, gdy możliwości w ASCII są wystarczające, aby pokryć całą twoją bazę użytkowników?
Pytanie nie dotyczy PHP, więc ułomność tego języka nie powinna być argumentem. – Crozin
@Crozin: Wiele aplikacji internetowych jest napisanych w PHP, więc może być dla nich argumentem. Ten konkretny język ma długą, smutną historię najbardziej fałszywego wsparcia dla Unicode obok samego LaTeXa. – Joey
@[email protected] Johannes_Rössel: Podążając za tym argumentem, sieć powinna zawierać tylko znaki łacińskie? Aby śledzić odpowiedzi, nawet jeśli twierdzisz, że PHP nie obsługuje kodu Unicode, możesz znaleźć wiele witryn z treścią w formacie Unicode ** z wyjątkiem **, gdy zmuszają one swoich użytkowników do wybierania nazw użytkowników i haseł ASCII. – banx
Zwykły ASCII jest rzadki, powiedziałbym. Często po prostu nikt o tym nie myśli, ponieważ w zachodniej Europie wystarczy łacińska 1, a także w USA. Niektóre bazy danych rozróżniają tekst w starszych zestawach znaków i Unicode (varchar vs. nvarchar) lub w innych bazach danych należy ustawić specjalny zestaw znaków.
Zwłaszcza w USA wiele osób nawet nie zauważa, że ASCII nie wystarczy. Niektórzy próbują znaleźć wymówki z »Użytkownicy muszą to zrobić« lub podobne, które są w większości sfałszowane.
Wątpię, czy istnieją względy bezpieczeństwa, z wyjątkiem możliwości fałszowania nazwisk innych osób za pomocą różnych skryptów (a i wyglądają identycznie, ale jedna to łacina, jedna jest cyrylicą - wcześniej zrobiono to za pomocą adresów URL) . Generalnie uważam to za niedopatrzenie twórców, którzy prawdopodobnie powinni wiedzieć lepiej.
Ataki homoglifów. Użytkownik "cat" i "сat" to różne ciągi znaków Unicode, chociaż wyglądają tak samo. Pierwszą literą w drugim "сat" jest rosyjski "с" - "CYRILLIC SMALL LETTER ES", aby być dokładnym. System nie może łatwo stwierdzić, że podszywasz się pod nazwę innego użytkownika - na komputer są one różne.
Edycja: zapobieganie mieszanym skryptom nie rozwiązuje problemu. Na przykład "сосо" jest czystym Cyrylemicznym i może być użyty do podrabiania ascii "coco".
Także nadpisanie od lewej do prawej (i znajomych). Pozostaw je nieautoryzowane i zepsuć całą stronę.
Cóż, * może * łatwo stwierdzić, czy miksujesz skrypty, i czy ich nie akceptujesz. Przeglądarki internetowe stosują podobną zasadę, aby przywrócić wyświetlanie IDN do ekranu Punycode. – Joey
Nie zawsze trzeba mieszać * skrypty. Niektóre słowa ascii można odtworzyć za pomocą cyrylicy, na przykład "coco". Więc musisz sobie z tym poradzić. –
Ataki homoglifów są również możliwe w ASCII; "0" i "O" są nie do odróżnienia w wielu czcionkach, podobnie jak "|", "I", "l" i "1"; ".com", ".corn" między innymi. –
Uwierzytelnianie HTTP? Mogą wystąpić problemy z wysyłaniem nazwy użytkownika (i/lub hasła) Unicode do istniejących protokołów. Jeden przypadek, w którym wcześniej uczestniczyłem, jest z uwierzytelnianiem podstawowym. Nie ma dobrze zdefiniowanego sposobu obsługi wysyłania tych nazw/haseł Unicode w podstawowych nagłówkach autoryzacji.
[UTF-7] (http://en.wikipedia.org/wiki/UTF-7) umożliwia przesyłanie kodów Unicode jako ASCII. – dreamlax
Ale z utf-7 lub jakimkolwiek innym kodowaniem, musisz posiadać klienta i kod serwera, aby upewnić się, że poprawnie zdekodują dane. – Mike
To była dla mnie najlepsza odpowiedź, ponieważ szukałem przyczyny, która nadal obowiązywała, nawet jeśli administrator przydzielił wszystkie nazwy użytkowników w kontrolowany sposób. Wciąż używamy BASIC auth ... Wydaje mi się, że daje nam to powód do odrzucenia go w przyszłości. – Trejkaz
Można zezwolić na unikod, jednak niektóre nazwy użytkowników nie będą działać zgodnie z oczekiwaniami, ponieważ różne kultury stosują różne reguły do tych samych znaków.
Rozważmy podstawowe argumenty za łamanie case sensivitity: W turecki, nazwy użytkowników „ID1” oraz „ID1” różnią (w turecki istnieją dwa różne jest jedną z kropką i jeden bez, otrzymując 2 Captial i 2 małe litery, które nie pasują do tych samych reguł captialization co angielski). Tak więc, chociaż każda osoba z Turcji może wpisać swoje imię w swoim własnym języku, program nie będzie traktował ich nazwiska zgodnie z oczekiwaniami - zamiast tego zostanie poddany dziwnej transformacji w zmutowany angielski.
Specjalne znaki łacińskie w językach europejskich mają podobne nakładanie się, co sprawia, że wydaje się, że są one losowe, do jakiego języka są wprowadzane. Inne regiony świata mają podobne wspólne postacie, w których reguły użycia są różne - w niektórych przypadkach krajowe i kulturowe. Nienawiść do nienawiści może spowodować, że niektóre osoby tworzące swoją nazwę będą traktowane tak, jakby były napisane w języku znienawidzonego wroga (z uwagi na to, że są to domyślne ustawienia systemów operacyjnych dla obcych znaków).
Potrzebujemy zatem PSP (programowanie wrażliwe na politykę). Wstydź się konsorcjum Unicode za to, że nie posortowaliśmy dla nas wszystkiego. ☺ –
Twoja obserwacja nie zawsze jest prawdą.A wybór ASCII jest w dużej mierze czynnikiem ludzkim, a nie technicznym lub bezpieczeństwa.
W większości przypadków chodzi tylko o łatwość programowania. Programista nigdy nie wie, że całe oprogramowanie, biblioteki, narzędzia na stronie internetowej ulegną zerwaniu z niektórymi znakami. Dlaczego ryzykujesz rozwój strony, a ASCII działa dobrze? Ponadto niektóre pakiety oprogramowania sieci Web utrudniałyby używanie Unicode w nazwie użytkownika. Przyczynia się to do tego, że wiele witryn obsługuje tylko nazwy użytkowników w ASCII.
Teoretycznie wszystkie obecne oprogramowanie może dobrze obsługiwać 8-bitowe dane. Obecnie nie ma problemu z przechowywaniem lub przesyłaniem. Nawet jeśli niektóre protokoły nie, mogą tłumaczyć w UTF-7 lub w innych schematach transformacji.
Występują pewne problemy z Unicode. Jest bardziej po stronie przetwarzania danych. Może to być wyświetlanie, czcionki, gotowość oprogramowania i bibliotek oprogramowania dla znaków innych niż BMP, zestawianie, porównywanie, metody wprowadzania, wskazówki dotyczące pisania. Administratorzy mogą nie mieć wystarczającej wiedzy, aby sobie z nimi poradzić. W zależności od charakteru strony może to być problem, ale w większości nie.
Do celów administracyjnych nie jest łatwo wpisać pewne egzotyczne znaki. Utrudnia adminowi wyszukiwanie użytkowników. Administratorowi trudno jest także powstrzymać ofensywne nazwy użytkowników w językach obcych poza witryną.
Jednak nie jest niczym niezwykłym, że chińskie nazwy użytkownika są używane w chińskiej witrynie. Może nie zawsze w ASCII. Podobnie jak inne kultury i języki. Niektóre projekty globalne akceptują niemal wszystkie rodzaje znaków Unicode. Wikipedia jest przykładem.
Albo możemy po prostu przestać okazywać, jak wygląda nazwa użytkownika, i czy MY możemy wypowiedzieć/zapamiętać. To powinno dotyczyć USERS. Jeśli nikt cię nie pamięta, to twoja strata. Jeśli chodzi o spoofowanie nazw, jest to prawie nieuniknione. A jednak rzadko słyszysz o podróbkach nazw użytkowników.
Wyobraź sobie forum, wyobraź sobie, że ktoś publikuje konto, które wygląda identycznie jak Twoje. Masz kłopoty, powiedz, że tego nie zrobiłeś, opublikuj link do swojej historii, zobacz, że nie ma tam postu. Kliknij profil faceta, który FAKTYCZNIE zamieścił go, a bam, masz jego profil. On jest banny.
Posiadanie tej samej nazwy nie oznacza, że masz te same dane użytkownika. Każda aplikacja, która nie ułatwi odróżnienia dwóch podobnych użytkowników, jest tak czy inaczej wadliwa i musi zostać przepisana.
To nie odpowiada na pytanie. Byłoby lepiej jako komentarz pod jedną z pozostałych odpowiedzi. –
Chociaż wątpliwe jest, dlaczego powinna istnieć nazwa użytkownika, a nie tylko "hasło" do identyfikacji użytkownika, myślę, że nie ma powodu, aby uniemożliwić nazwy użytkownika w Unicode.
Co ważniejsze, jest to hasło, które ma być sprawdzone jako niezastosowanie języka: powinno traktować klawisze bez względu na ustawienia klawiatury użytkownika. Oznacza to, że "שלום" i "akuo" będą tym samym hasłem. Jest to ważne, ponieważ użytkownik często nie widzi znaków hasła, które wpisuje, a oni stają się poważnie wkurzeni, jeśli CAPSLOCK jest włączony.
To brzmi całkiem nieźle, ale chciałbym zobaczyć system, który może niezawodnie to zrobić ... powiedz, czy twój IME to taki, który potrafi konwertować rzeczy w nieodwracalny sposób. Na przykład: 缶 用 で シ プ ェ r て ぃ s? – Trejkaz
Głosuję, że to powinno być wiki społeczności. Wygląda na to, że zaczynają się dobre dyskusje. – jtbandes
Jeśli zależy ci na bezpieczeństwie twojego kodu, nie powinieneś pozwalać na używanie unicodu w dowolnym miejscu (chyba że jesteś masochistą ** i ** ekspertem od unicode ** i ** jesteś jedynym, który kiedykolwiek będzie musiał kod) –
@ L̳o̳̳n̳̳g̳̳p̳o̳̳k̳̳e̳̳, W rzeczywistości ostatni punkt powinien brzmieć "** i ** opiekunowie również kwalifikują się (1) i (2)." – Pacerier