SPECS: coppermine-gallery.spec - upgrade to 1.4.14 (sec fixes!), -...

[Tomasz Pala]

On Tue, Nov 13, 2007 at 18:03:48 +0100, Patryk Zawadzki wrote:

> Ustaw sobie charset dla klientów na utf-8 - tak ma domyślnie pgsql.

Ale domyślnie dla mysql jest latin1. Cudnie - przestawić nie mogę, bo
baza jest w użytku, a klienci nie trzymają pod ręką webmasterów, żeby im
poprawili niedorobiony kod. Zresztą nonsensem jest przestawianie
jakiegokolwiek parametru domyślnego całego serwera dla jakiejś
niedorobionej aplikacji.

> > A jak mam bazę latin2 i domyślne połączenia latin1, to skąd w bazie
> > biorą się unikodowe znaczki?
> 
> Wysyłasz unikod, twierdzisz, że to latin1 i każesz zapisać w latin2.
> Czego się spodziewasz?

Na pewno nie unikodu! Mysql ma taką paskudną cechę, że wstawia '?' w
miejsce nieznanych znaków - tego bym się spodziewał.

Ale sprawdziłem sobie tcpdumpem, co leci pomiędzy CPG a MySQL - otóż jak
można było się spodziewać, CPG wysyła unikod nie dbając w ogóle o
ustalenie z MySQL-em, po jakiemu rozmawiają. Wystarczy dopisać to set
names, tak jak zresztą sugerują tutaj:
http://coppermine-gallery.net/forum/index.php?topic=24129.msg152210
żeby zawartość bazy zgadzała się z deklarowanymi charsetami. Dla
przypomnienia w CPG cały czas wyświetlało się dobrze, mimo że w bazie
było źle - dwukrotne (od)unikodowywanie po prostu robił.

Przy okazji w powyższym widać myślenie twórców CPG - mysql nie powinien
robić w ogóle żadnej konwersji, bo można stracić informacje, zapisujmy
więc 'jak leci, bajt po bajcie'. Szkoda, że bez powiadamiania o tym
fakcie MySQL, bo w latin1 to on tych bajtów nie zapisze.
Pomijając już fakt, że skoro generowana strona przedstawia się charsetem
UTF-8, to nie ma żadnego sensu w podejściu 'bajt po bajcie' - należałoby
po prostu wymusić wszędzie unikod.

Żeby pozostać na devel - to jak ktoś ma ochotę, sugeruję uzupełnienie
cpg_mysql_connect o odpowiednie sety.

-- 
Tomasz Pala <gotar w pld-linux.org>