![]() |
![]() ![]() |
![]() |
![]()
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: 3 Pomógł: 0 Dołączył: 12.07.2003 Ostrzeżenie: (0%) ![]() ![]() |
W dokumentacji php znalazłem już informację że WDDX domyślnie koduje
znaki w ISO-8859-1 i to było przyczyną tego błędu. Można to kodowanie zmienić za pomocą funkcji setlocale() - jednak nie mogę za jej poomocą ustawić kodowania UTF-8. Czy jest to wogóle możliwe? Nie dzialają np. wywolania (zwracają FALSE): [php:1:ceeaf3c716] setlocale (LC_ALL, 'UTF-8'); [/php:1:ceeaf3c716] albo [php:1:ceeaf3c716] setlocale(LC_ALL, 'pl_PL.UTF-8'); [/php:1:ceeaf3c716] Czy ktoś próbować serializować dane w UTF-8 do pakietów WDDX i czy się to udało? I czy da się za pomocą setlocale ustawić kodowanie UTF-8 ? |
|
|
![]()
Post
#3
|
|
![]() Grupa: Przyjaciele php.pl Postów: 398 Pomógł: 0 Dołączył: -- Skąd: Poznań Ostrzeżenie: (0%) ![]() ![]() |
Może lepiej ustaw setlocal normalnie (pl_PL), natomiast rozwiązania problemu szukaj w iconv?
-------------------- cease this long, long rest / wake and risk a foul weakness to live / when it all comes down / watch the smoke and bury the past again / sit and think what will come / raise your fears and cast them all away
|
|
|
![]()
Post
#4
|
|
Grupa: Zarejestrowani Postów: 3 Pomógł: 0 Dołączył: 12.07.2003 Ostrzeżenie: (0%) ![]() ![]() |
Problem w tym że korzystanie z iconv byoby o tyle utrudnione że w bazie będę miał dane zapisane w różnych językach - np. po rosyjsku, czesku, niemiecku itd... Odczytując dane z bazy nie wiem w jakim języku są one zapisane - muszę je bez żadnych zmian przekazać aplikacji "klienta" który oczekuje tych danych zapisanych w UTF-8.
Jeśli postapiłbym w taki sposób że: po odczytaniu danych z bazy konwertuję je z UTF-8 na np. ISO-8859-2, następnie serializuję je do pakietów WDDX i otrzymany pakiet WDDX konwertuję na UTF-8 i wtedy dopiero wysyłam pakiet do klienta, to straciłbym najprawdopodbniej różne znaki. Problem powodowałoby m.in.to że serializer WDDX zamienia rózne znaki narodowe na znacznki <CHAR code='XXXXXXXX'/> i wtedy powtórna konwersja pakietu WDDX na UTF-8 za pomocą iconv nic nie da ponieważ te znaczniki nie zostaną zamienione na znak w UTF-8. Jesli wiedziałbym że ograniczę się tylko do polskich znaków mógłbym sam zamieniać te znaczniki na znak za pomocą np. ereg_replace() ale wetdy nie mialoby sensu kodowanie danych w UTF. |
|
|
![]()
Post
#5
|
|
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. |
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 24.07.2025 - 20:17 |