2010-03-29 9 views
5

Właśnie stworzył swój pierwszy funkcji ajax z jQuery, która faktycznie działa, ale niestety kodowanie znaków (dla znaków takich jak A, O, U, SS, C, C, A , ø) to koszmar.jQuery: AJAX umlauty i znaki specjalne bałagan

Moje pliki i moja baza danych to wszystkie UTF-8. Próbowałem wielu opcji w funkcji ajax i funkcji PHP, z których żadna nie była zadowalająca.

To mój ajax

var dataString = { 
'name': name, 
'mail': mail 
// other stuff 
} 


    $.ajax({ 
type: "POST", 
url: "/post.php", 
data: dataString, 
contentType: "application/x-www-form-urlencoded;charset=UTF-8", 
cache: false, 
success: function(html){ 
// do stuff 
} 

Próbowałem go bez contentType: "application/x-www-form-urlencoded; charset = UTF-8" i starałem się zawinąć dane zaatakowaną w encodeURIComponent(), z których żaden nie działał.

Gdy używam że AJAX z htmlentities() w moim php, moi umlauty wyglądać w postaci zwykłego tekstu: UE A, AE A, œ, UE ¼, ae, oe å¤ o

i tak w bazie: UE & Atilde; OE AE & Atilde; „, OE & Atilde ;, ue & Atilde; & frac14 ;, ae & Atilde; & curren ;, oe o

Jeśli nie używam htmlentities() ale mysql_real_escape_string() zamiast (lub nie), wyglądają dobrze w zwykłym tekście, ale wyglądają tak w bazie danych: AE à ", OE Ã-, UE Ãœ, ae ¤ oe ¶ ue ¼

Próbuję mnóstwo opcji już od wielu godzin, ale nie mogę znaleźć rozwiązania, które działa. Jak dotąd jedyną opcją, którą wydaje mi się, jest to, że wyglądają jak totalny bałagan w bazie danych, ale byłoby to bardzo kontraproduktywne, gdyby te zbiory danych wymagały edycji.

+1

Czy Twoja ostatnia obserwacja nie sugeruje, że problem leży prawdopodobnie w bazie danych (a może w PHP), a nie w jQuery i AJAX? –

+0

Próbowałem zmienić kodowanie bazy danych na latin1, ale nie było żadnej różnicy. – rayne

Odpowiedz

6

Próbowałem zawinąć dane dotknięta encodeURIComponent()

Nah, jeśli jesteś przejazdem w {} obiektu jQuery zajmie UTF-8 i kodowania URL-go dla Ciebie.

Gdy używam że AJAX z htmlentities() w moim php, moi umlauty wyglądać w postaci zwykłego tekstu: UE A, AE A, OE A, ue ¼ AE å¤, oe o

Jeśli trzeba użyć htmlentities(), trzeba powiedzieć, że Twój kodowanie jest UTF-8 w opcjonalnym $charset argumentu, bo inaczej (głupio) domyślnie traktowanie wszystkich bajtów jako ISO-8859-1 i koduje je do nieodpowiednie odwołania do encji, po jednym dla każdego bajtu.

Zamiast tego lepiej jest użyć htmlspecialchars(), ponieważ nie próbuje on stosować niepotrzebnego kodowania do znaków innych niż kilka znaków ASCII, które naprawdę tego potrzebują.

I jak to w bazie danych: UE AoE, AE A „, OE A-, ue ¼ AE å¤, oe o

Jak się stwierdzając, że? Czy narzędzie, którego używasz do pobierania danych z bazy danych, wie o Unicode? (Jeśli jest to podejrzany interfejs webowy PHP, może nie, PHP nie jest świetny w Unicode.)

Możliwe, że w bazie danych przechowywane są właściwe bajty UTF-8, ale w tabelach oznaczonych jako Zestawianie Latin-1.To zadziała, o ile dostaniesz te same bajty, co włożysz, ale jeśli MySQL nie wie, że są bajtami UTF-8, wtedy rozróżnianie wielkości liter poza ASCII nie będzie działało poprawnie , więc szukanie Ä nie będzie pasować do ä. To może lub nie ma znaczenia dla Ciebie.

Jeśli nie używam htmlentities(), ale mysql_real_escape_string() zamiast

Whoah, ostrożny. Wykreślanie HTML jest dla etapu wyjściowego do strony. SQL-string-literal-escaping występuje podczas tworzenia zapytania SQL. Potrzebujesz ich obu, ale nie mieszaj ich ani nie próbuj robić ich na tym samym etapie, albo będziesz miał różne rodzaje dziwnych ucieczek, które przeszły na niewłaściwe i potencjalne luki w zabezpieczeniach.

+0

Kiedy używam htmlspecialchars(), postacie wyglądają dobrze na stronie, ale tak jak w bazie danych: ü (niezależnie, czy db to UTF-8 lub latin1). Używam SQLyog do dostępu do bazy danych, nie mam interfejsu WWW jak phpmyadmin. Wyglądają też niechlujnie, kiedy używam mojego niestandardowego interfejsu administratora, aby je edytować. – rayne

+0

OK, SQLyog * twierdzi, * że obsługuje Unicode, więc mam nadzieję, że powinno to być poprawne. Jeśli ważne jest, aby dane wyglądały dokładnie w interfejsie administratora, musisz użyć 'CREATE TABLE ... CHARACTER SET utf8', aby utworzyć tabele i wywołać' mysql_set_charset ('utf8') 'z PHP przed użyciem bazy danych połączenie. – bobince

3

Wygląda na to, że problem występuje podczas wstawiania danych do bazy danych. Czy używasz MySQL? Po podłączeniu do serwera bazy danych numerze zapytania:

SET NAMES utf8; 

Dzięki temu dowiesz serwer bazy danych, że połączenie klient chce wysłać dane w UTF-8 i interpretować je jako takie.

Również podczas wysyłania tych danych do przeglądarki upewnij się, aby ustawić nagłówek ContentType

header('Content-type: text/html; charset=utf-8'); 

Będzie to powiedzieć, że przeglądarka interpretuje dane jako UTF-8.

1

użycie spróbować tej funkcji zamiast htmlentities

htmlspecialchars()

0

I w końcu znaleźć rozwiązanie, które działa na mnie; I usunięto z contentType: "application/x-www-form-urlencoded;charset=UTF-8" z mojego jQuery ajax, używam tylko htmlentities($value, ENT_NOQUOTES, 'UTF-8'); do przetwarzania danych z SQL i moja baza danych jest ustawiona na UTF8 Unicode.

Znaki są wyświetlane poprawnie i są zapisywane jako ä dla ä i tak dalej w bazie danych.

+0

Proszę nie przechowywać danych zakodowanych w HTML w bazie danych! Wyłuszanie kodu HTML jest problemem, który powinien wystąpić zawsze i tylko na etapie strona-wynik. Nie należy do warstwy dostępu do danych. Jeśli umieścisz zakodowane w HTML dane w bazie danych, nie będziesz mógł wyszukiwać takich jak 'LIKE '% uml%'' (nie będzie w stanie odróżnić zakodowanego umlauta od tekstu "uml") każda operacja "SUBSTRING" (w tym ukryte przycinanie ze względu na ograniczenia długości pola) może spowodować złamanie odwołania do jednostki i wygenerowanie uszkodzonego kodu HTML, a to zepsułoby wszelkie inne dane niż dane w formacie HTML, takie jak wysyłanie wiadomości. – bobince

+0

Och, naprawdę?Nie wiedziałem o tym, ale generalnie jestem złym programistą;) Po usunięciu htmlentities() z mojego skryptu, moje specjalne znaki znów wyglądają tak samo w bazie danych: ü Dziwnie, kiedy wysyłam dane tylko poprzez PHP (przy dezaktywacji javascript) wyglądają dobrze w bazie danych (ä). Tak więc problem najprawdopodobniej jest spowodowany przez ajax jQuery. – rayne