Lista znaków Unicode, które powinny być filtrowane na wyjściu?

Question

Niedawno trafiłem na błąd z powodu jakości danych z obsługą przeglądarki i szukam bezpiecznej reguły dla stosowania ucieczki ciągu bez podwójnego rozmiaru, chyba że jest to wymagane.

Sekwencja bajtów UTF-8 "E2-80-A8" (U + 2028, SEPARATOR LINIOWY), doskonale działająca postać w bazie danych Unicode. Jednak ta sekwencja reprezentuje separator liniowy (Tak, inny niż "0A").

Niestety, wiele przeglądarek (w tym Chrome, Firefox i Safari, nie przetestowałem innych), nie udało się przetworzyć wywołania zwrotnego JSONP, które zawiera ciąg znaków, który zawiera znak Unicode. JSONP został dołączony przez kod HTML inny niż Unicode, którego nie miałem żadnej kontroli.

Przeglądarki po prostu zgłosiły NIEPRAWIDŁOWY KOD/błąd składni na takim kodzie JavaScript, który wygląda poprawnie na narzędziach do debugowania i wszystkich edytorach tekstu. Sądzę, że może spróbować przekonwertować "E2-80-A8" na BIG-5 i złamać składnię JS.

Powyższe jest tylko przykładem tego, w jaki sposób Unicode może spowodować nieoczekiwane złamanie systemu. O ile wiem, niektórzy hakerzy mogą używać RTL i innych znaków kontrolnych dla ich dobra. I jest wiele "cytatów", "spacji", "symboli" i "kontroli" w specyfikacji Unicode.

PYTANIE:

Czy istnieje lista znaków Unicode za każdy programista wiedzieć o ukrytych funkcji (i błędów), które nie chcą im skuteczne w naszej aplikacji. (na przykład Windows wyłącza RTL w nazwie pliku).

EDIT:

Nie pytam dla JSON ani JavaScript. Proszę o ogólną najlepszą praktykę przekazywania Unicode we wszystkich programach.

Answer 1

Jest to baza danych właściwości znaków i raport opisujący to, UNICODE CHARACTER DATABASE, który daje dobry pogląd na to, jak przeglądarki "powinny" traktować punkt kodowy. Uwielbiam to słowo, "powinienem". Najbezpieczniejsza będzie biała lista, prawdopodobnie możesz wybrać L | M | N | S, Letter lub Mark lub Numer lub Symbol.

Wystarczy popatrzeć na ICU project dla biblioteki

Answer 2

Łamie JavaScript ponieważ łańcuchy nie mogą mieć nowe linie w nich:

var myString = " 

"; 

//SyntaxError: Unexpected token ILLEGAL 

Teraz UTF-8 sekwencja "E2-80-A8" dekoduje na punkt kodowy Unicode U+2028, która traktowana jest podobny do znaku nowej linii w javascript:

var myString = "
"; 

//Syntax Error 

jest jednak bezpiecznie pisać

var myString = "\u2028"; 
//you can now log myString in console and get real representation of this character 

, który jest prawidłowo zakodowany przez JSON. Zajmę się prawidłowym kodowaniem JSON zamiast utrzymywania czarnej listy niebezpiecznych postaci. (które są U + 2028 i U + 2029 AFAIK).

w PHP:

echo json_encode(chr(0xe2). chr(0x80).chr(0xA8)); 
//"\u2028" 

Answer 3

A-Z, A-Z i 0-9 są ogólnie bezpieczne. Poza tymi 62 znakami możesz napotkać problemy z niektórymi systemami. Nie ma innej odpowiedzi, którą każdy może ci dać.

Na przykład wspominasz nazwy domen. Jedynym sposobem na obsługę nazw w standardzie Unicode jest śledzenie RFC 3454 i RFC 5890-5893 i przetwarzanie danych w ten sposób i tylko w ten sposób. Nazwy plików na większości systemów plików Unix są arbitralnymi ciągami bajtów, które nie zawierają/lub \ 0. Funkcjonalne traktowanie nazwy pliku w systemie Unix jako ciąg znaków Unicode bez niszczenia czegokolwiek jest kwestią samą w sobie. Zauważ, że nazwy plików systemu Windows nie są bezpieczne dla A-Z; rzeczy takie jak NUL i PRN są zastrzeżonymi nazwami. Każda domena ma swoje własne małe problemy i dziwactwa, a żadne proste streszczenie nie wystarczy wszędzie.

Answer 4

Spójrz na wykresy Unicode. Jest lista niedrukowalnych znaków. To są potencjalni wichrzyciele. Twój przyjaciel U + 2028 ma wielu przyjaciół: http://www.unicode.org/charts/PDF/U2000.pdf I to nie tylko w serii 2000.

Można było albo nuke je wszystkie, lub je rozdzielić na różne kategorie (zwęgla SEP typu U + 2028 staje \ n lub ucieczce prawidłowo) itd

HTH