9 odpowiedzi na ten temat

[Davred]

Witajcie. jak powinien wyglądać prawidłowy my.cnf na moim vps:

aktualnie zawartość tego pliku u mnie to:

[mysqld]
local-infile=0

konfiguracja sprzętu:

 Serwery VPS 
 
 
 
 Pojemność HDD-25 GB

 Transfer miesięczny-5000 GB
 
 Gwarantowana pamięć RAM-1024 MB
 
 Pamięć BURST-2048 MB
 
 Czas Pracy Procesora~3 GHz
 
 Ilość Adresów IP-1
 
 
 

na serwerze gł będzie stało forum na skrypcie vB aktualnie jakieś 3 k odsłon / 24h ten współczynnik będzie rósł.

może ktoś ma już gotową zawartość pliku która by pasowała dla mnie, ważne jest tez aby było pod kodowanie Latin2_general_ci

[Davred]

ale właśnie myslełem że poprawna konfiguracja pliku naprawie kodowanie forum które się popsuło po przeniesieniu na nowy serwer z zawartościa pliku podana wyżej...

[guziec]

Davred, o 28 marzec 2010 - 18:14, powiedział:

Witajcie. jak powinien wyglądać prawidłowy my.cnf na moim vps:

aktualnie zawartość tego pliku u mnie to:

[mysqld]
local-infile=0

konfiguracja sprzętu:

 Serwery VPS 
 
 
 
 Pojemność HDD-25 GB

 Transfer miesięczny-5000 GB
 
 Gwarantowana pamięć RAM-1024 MB
 
 Pamięć BURST-2048 MB
 
 Czas Pracy Procesora~3 GHz
 
 Ilość Adresów IP-1
 
 
 

na serwerze gł będzie stało forum na skrypcie vB aktualnie jakieś 3 k odsłon / 24h ten współczynnik będzie rósł.

może ktoś ma już gotową zawartość pliku która by pasowała dla mnie, ważne jest tez aby było pod kodowanie Latin2_general_ci

Ale po co? Zamiast kombinować z latinami przejdź na utf-a jak biały człowiek.

w sekcji [mysqld] ustaw:

default-character-set=utf8
default-collation=utf8_polish_ci
character-set-server=utf8
collation-server=utf8_polish_ci

plus ewentualnie:

skip-character-set-client-handshake

I jeszcze dodatkowo w [mysql] i w [mysqldump]

default-character-set = utf8

Zrzuć dumpa ze starej bazy w trybie utf-8 a jeśli już go zrzuciłeś w innym charsecie, to przekonwertuj na utf-8 (np iconv-em) i po zaimportowaniu będziesz miał polskie litery i spokój już na zawsze bez ustawiania "SET NAMES" i tym podobnych protez.

[regdos]

guziec, o 29 marzec 2010 - 00:06, powiedział:

Zrzuć dumpa ze starej bazy w trybie utf-8 a jeśli już go zrzuciłeś w innym charsecie, to przekonwertuj na utf-8 (np iconv-em) i po zaimportowaniu będziesz miał polskie litery i spokój już na zawsze bez ustawiania "SET NAMES" i tym podobnych protez.

Masz świadomość, że jeżeli jest cokolwiek serializowane i zapisywane w bazie danych i zawiera jakiekolwiek dwubajtowe znaki to przy wykorzystaniu iconv-a po prostu będzie nie do odczytania ponownie ?

"SET NAMES" nie jest jakąś protezą tylko normalną rzeczą, którą się stosuje, bo nie każdy musi używać UTF-a.
Przy mysql-u trzeba rozróżnić kilka rzeczy - kodowanie danych w bazie, kodowanie danych jako dane użytkownika, kodowanie danych podczas przesyłu danych pomiędzy aplikacjami (mysql-php) i kodowanie danych przy imporcie/eksporcie.
Import/eksport zawsze przez utf-a należy robić (co jest domyślne w np. phpmyadminie) przez co mamy pewność, że nic nie zgubimy podczas przenoszenia danych, to kodowanie nie ma wpływu na kodowanie danych.
Jeżeli jest to shared to posiłkujemy się SET NAMES, które odpowiada kodowaniu naszych danych, jeżeli mamy dostęp do my.cnf możemy sobie globalnie ustawić w tym pliku SET NAMES.
Jeżeli faktycznie robimy coś od samego początku to najwygodniej będzie tak jak napisał guziec od razu wszędzie zrobić UTF i mamy spokój.

[guziec]

regdos, o 29 marzec 2010 - 07:23, powiedział:

Masz świadomość, że jeżeli jest cokolwiek serializowane i zapisywane w bazie danych i zawiera jakiekolwiek dwubajtowe znaki to przy wykorzystaniu iconv-a po prostu będzie nie do odczytania ponownie ?

Tu zgoda, chociaż z doświadczenia wiem że do 90 procent baz mysql nie ładuje się danych binarnych, bo to niezbyt wydajne. W takim przypadku można przekonwertować za pomocą importu do lokalnej bazy na swoim komputerze i następnie zrzutu już w utf-ie.

Cytuj

"SET NAMES" nie jest jakąś protezą tylko normalną rzeczą, którą się stosuje, bo nie każdy musi używać UTF-a.

Ale jak jest powód do nieużywania UTF-a na swoim VPS-ie? SET NAMES to polecenie SQL służące do przestawienia zwracanych wyników na naszą stronę kodową. Po co ustawiać na serwerze bazy danych inne kodowanie a potem po każdym połączeniu do niej przestawiać na właściwe, jak można wszystko od razu zrobić w tym samym?

Cytuj

Przy mysql-u trzeba rozróżnić kilka rzeczy - kodowanie danych w bazie, kodowanie danych jako dane użytkownika, kodowanie danych podczas przesyłu danych pomiędzy aplikacjami (mysql-php) i kodowanie danych przy imporcie/eksporcie.
Import/eksport zawsze przez utf-a należy robić (co jest domyślne w np. phpmyadminie) przez co mamy pewność, że nic nie zgubimy podczas przenoszenia danych, to kodowanie nie ma wpływu na kodowanie danych.
Jeżeli jest to shared to posiłkujemy się SET NAMES, które odpowiada kodowaniu naszych danych, jeżeli mamy dostęp do my.cnf możemy sobie globalnie ustawić w tym pliku SET NAMES.

Jeśli mamy dostęp do my.cnf to sobie ustawiamy obsługę wszystkich baz na utf-8 i nie potrzebujemy przestawiania na jakieś starożytne pseudo-standardy. Mamy już rok 2010.

[regdos]

guziec, o 29 marzec 2010 - 10:29, powiedział:

Tu zgoda, chociaż z doświadczenia wiem że do 90 procent baz mysql nie ładuje się danych binarnych, bo to niezbyt wydajne. W takim przypadku można przekonwertować za pomocą importu do lokalnej bazy na swoim komputerze i następnie zrzutu już w utf-ie.

Mam na myśli przechowywanie w bazie danych tablic lub obiektów z php, które właśnie się serializuje żeby była możliwość ich zapisu do bazy. (dla przypomnienia dane serializowane są w formacie tekstowym a nie binarnym) Większość skryptów forów w ten sposób przechowuje jakieś dane.

Moim zamiarem było wskazanie, że skorzystanie z iconv-a jest bardzo złym pomysłem ponieważ może doprowadzić do zniszczenia danych. Niestety import do lokalnej bazy a potem zrzut do utf-a nie rozwiązuje problemu, bo import/export nie zmienia w żaden sposób danych, na których operuje.

SET NAMES nie przestawia zwracanych wyników na naszą stronę kodową tylko ustala sposób kodowania pomiędzy aplikacją (php) a bazą danych a dokładnie ustawia 3 zmienne mysql-a dla danego połącznie: character_set_client, character_set_results, character_set_connection

Masz rację z poziomu my.cnf ustawiamy sobie jak maja być dane przechowywane w plikach bazy danych jednak nic nie stoi na przeszkodzie żeby kodowanie tych danych było inne niż utf-8 np. iso-5589-2 czy to iso-5589-1, które nadal są obowiązującymi standardami.

[BlueMan]

iso-8859-2 jak już nie iso-5589-2

[regdos]

Oczywiście myślałem tak jak npisałeś a źle klikałem w klawisze.