Handling Kodowanie znaków w URI na Tomcat

Question

Na stronie staram się pomóc, użytkownik może wpisać adres URL w przeglądarce, jak następujących znaków chińskich,

http://localhost:8080?a=测试 

Na serwerze, otrzymujemy

GET /a=%E6%B5%8B%E8%AF%95 HTTP/1.1 

Jak widać, jest kodowany w UTF-8, a następnie zakodowany w adresie URL. Możemy obsłużyć to poprawnie, ustawiając kodowanie na UTF-8 w Tomcat.

Jednak czasami mamy kodowania latin1 na niektórych przeglądarkach,

http://localhost:8080?a=ß 

zamienia

GET /a=%DF HTTP/1.1 

Czy mimo to poprawnie obsłużyć w Tomcat? Wygląda na to, że serwer musi dokonać inteligentnego zgadywania. Nie spodziewamy się obsługiwać Latin1 poprawnie 100%, ale wszystko jest lepsze niż to, co teraz robimy, zakładając, że wszystko jest w UTF-8.

Serwer to Tomcat 5.5. Obsługiwane przeglądarki to IE 6+, Firefox 2+ i Safari na iPhonie.

Answer 1

Niestety, kodowanie UTF-8 jest "powinno" w URI specification, które wydaje się zakładać, że serwer źródłowy wygeneruje wszystkie adresy URL w taki sposób, że będą one znaczące dla serwera docelowego.

Istnieje kilka technik, które bym rozważył; wszystkie wymagają samodzielnego parsowania ciągu zapytania (chociaż możesz znać lepiej niż I, czy ustawienie kodowania żądań wpływa na ciąg zapytania na mapowanie parametrów lub tylko na treść).

Najpierw sprawdź ciąg zapytania dla pojedynczego "wysokiego bajtu": poprawna sekwencja UTF-8 musi mieć dwa lub więcej bajtów (Wikipedia entry ma ładną tabelę ważnych i nieprawidłowych bajtów).

Mniej wiarygodne byłoby wybranie nagłówka "Accept-Charset" w żądaniu. Nie sądzę, aby ten nagłówek był wymagany (nie sprawdzałem specyfikacji HTTP do weryfikacji) i wiem, że przynajmniej Firefox wyśle ​​całą listę akceptowanych wartości. Wybór pierwszej wartości na liście może zadziałać, lub może nie.

Czy dokonałeś analizy logów, aby sprawdzić, czy dany klient użytkownika konsekwentnie używa tego kodowania?