![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 3 Pomógł: 0 Dołączył: 12.07.2003 Ostrzeżenie: (0%) ![]() ![]() |
Witam. Napotkałem następujacy problem:
Serializuje dane (pobierane z bazy MySQL) do pakietów WDDX przy pomocy funkcji wddx_serialize_value() lub np. wddx_add_vars(). Serializowane dane są zakodowane w UTF-8 i problem polega na tym ze po serializacji dwa polskie znaki 'ą' i 'ć' są zastępowane znacznikami <char code='FFFFFF85'/> <char code='FFFFFF87'/>, ktore raczej nie sa kodami tych znakow w UTF-8. W wyniku tego po przeslaniu danych do klienta, dane sa niepoprawnie wyswietlane (a konkretnie zle sa wyswietlane te dwa znaki). Czy problem moze wynikac stad ze binaria php pod Windows moga miec niektore biblioteki skompilowane domyslnie np dla ISO-8859-1? Testowalem to w srodowisku Windows i nie sprawdzilem jeszcze jak dziala serializacja danych w unikodzie pod Linuxem. Będę wdzięczny za wszelkie podpowiedzi |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 53 Pomógł: 1 Dołączył: 28.09.2007 Skąd: Gdynia Ostrzeżenie: (0%) ![]() ![]() |
i co? problem nierozwiązywalny w php?
z mojego researcha wynika, że w php setlocale działa prawidłowo jedynie w przypadku właściwej konfiguracji serwera i php na serwerze, co na większości hostingów jest po prostu niebywałą rzadkością. prawdę mówiąc, jeszcze się nie spotkałem, żeby to kiedykolwiek działało, ale zgodnie z dokumentacją php to jest możliwe i powinno działać. z drugiej strony, locale powinno się wbijać z ręki, bez zależności po stronie serwera. cała przewaga php nad nowocześniejszymi językami programowania www polega na tym, że ma małe zależności serwerowe i praktycznie nie wymaga posiadania shella. a tutaj zonk. kolejny zonk wyjdzie, kiedy ktoś będzie używał funkcji mysql(i)_real_escape_string - to jest zależne od locale, czyli założę się, że albo może popsuć string utf-8, albo wprost przeciwnie, nic nie zepsuje, tylko wpuści injecta używającego hacków utf. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 7.10.2025 - 16:52 |