osCommerce – Zmiana kodowania znaków ISO-8859-2 na UTF-8

Każdy kto prowadzi sklep na osCommerce i integrował z nim zewnętrzne systemy, spotkał się z problemem kodowania znaków przy wymianie informacji pomiędzy nimi.
Polska wersja językowa osCommerce powstała w czasie, gdy kodowanie UTF-8 nie było jeszcze powszechnie przyjętym standardem. Od kilku lat UTF jest normą i dzięki temu mamy znacznie ułatwioną komunikację pomiędzy systemami w różnych językach ze znakami diakrytycznymi. Każdy programista pracujący na OSC przy integrowaniu zewnętrznych modułów musiał użyć funkcji konwertujących iconv lub mb_convert_encoding itp. Następnie nie zawsze to musiało działać jak należy i czekało tłumaczenie klientowi co się wydarzyło, o co dokładnie chodzi, co to w ogóle jest kodowanie znaków, skąd te krzaki na stronie itd… Jednym słowem łańcuch problemów :/
Aby tego uniknąć, opiszę jak krok po kroku w bezpieczny sposób przekonwertować pliki sklepu oraz jego bazę danych.

Zmiana kodowania w osCommerce – krok po kroku:

1. Backup wszystkich plików sklepu z serwera i pobranie ich na dysk lokalny.
   Zamiast TotalCommander, najlepiej do tego użyć FileZilla, która posiada funkcję rozbudowanego kolejkowania plików wraz automatycznym odnawianiem zerwanego połączenia.
2. Przekonwertowanie wszystkich plików sklepu na serwerze z ISO na UTF.
   Najlepiej do tego użyć rodzimego programu Gżegżółka. Zanim cokolwiek zrobimy dobrze jest zrobić kopię zapasową tego co pobraliśmy z serwera na dysk, w przypadku, gdy coś pójdzie nie tak przy konwertowaniu.

   Następnie ładujemy pliki i wybieramy poniższe opcje:
   

3. Zmiana configu CHARSET w pliku polish.php.
   Fragment
   define('CHARSET', 'iso-8859-2');
   zamień na
   define('CHARSET', 'utf-8');
4. Przeszukanie wszystkich plików w katalogu sklepu na serwerze szukając ciągu znaków iso-, następnie zamiana na utf-8.
   Jest to bardzo istotne. Jeżeli przed nami w danym sklepie grzebał inny programista mógł nie używać stałej CHARSET i wpisywał na sztywno iso-8859-2. Tak, są tacy ludzie :)
5. Przeszukać pliki ciągiem znaków iconv lub mb_convert_encoding.
   Te funkcje najczęściej są używane przy konwertowaniu znaków przy wymianie danych pomiędzy systemami. Należy sprawdzić czy są jeszcze potrzebne lub zmodyfikować je, jeżeli istnieje taka potrzeba.
6. Blokada sklepu w godzinach nocnych.
   Wówczas jest najmniej zamówień (chociaż to zależy od strefy czasowej klientów).
   Ważne, aby zablokować sklep przed dumpem bazy danych. Dzięki temu unikniemy desynchornizacji bazy danych (np. zamówienia, sesje użytkowników itd…).

   Możesz to zrobić wpisując na początku pliku
   ../includes/application_top.php
   fragment kodu

   PHP

   1 2 3 4

   header("HTTP/1.1 503 Service Temporarily Unavailable"); // info dla Google header("Status: 503 Service Temporarily Unavailable"); header('Retry-After: 10800'); // czas liczony w sekundach die('Chwilowa przerwa techniczna. Przepraszamy.');

   .

7. Backup bazy danych. Zrzut do pliku całej bazy danych na dysk lokalny.
   Możesz do tego użyć standardowo phpMyAdmin lub HeidiSQL.
   O tym jakie opcje wybrać używając pierwszego z nich znajdziesz tutaj w akapicie Przeniesienie bazy danych.
8. Ponowne załadowanie / upload przekonwertowanych plików na serwer.
9. Przekonwertowanie w/w pliku bazy z ISO na UTF.
   Ponownie użyj Gżegżółki :). Przed tym sprawdź czy na pewno jest kodowanie ISO-8859-2. Możesz to zrobić używając opcji Rozpoznanie.
10. Zmiana parametrów tabel z latin2 na utf8_polish_ci.
    Poniżej przykład poprawnie przygotowanej tabeli do importu.
    Przykład poprawnie przygotowanej tabeli MySQL (składnia)

    MySQL

    1 2 3 4 5 6 7 8 9

    DROP TABLE IF EXISTS `zones`;   CREATE TABLE IF NOT EXISTS `zones` (   `zone_id` int(11) NOT NULL AUTO_INCREMENT,   `zone_country_id` int(11) NOT NULL DEFAULT '0',   `zone_code` varchar(32) CHARACTER SET utf8 COLLATE utf8_polish_ci NOT NULL DEFAULT '',   `zone_name` varchar(32) CHARACTER SET utf8 COLLATE utf8_polish_ci NOT NULL DEFAULT '',   PRIMARY KEY (`zone_id`) ) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

    Należy zwrócić uwagę na:
    CHARACTER SET utf8 COLLATE utf8_polish_ci
    oraz
    DEFAULT CHARSET=utf8

    Ważne, aby było to polish_ci a nie general_ci. Na general_ci MySQL przy użyciu funkcji sortującej wyniki nie będzie brał pod uwagę polskich liter. Potraktuje je jako litery zwykłe (bez ogonków) lub wyrzuci je na koniec listy.

11. Ponowne załadowanie pliku zrzutu bazy danych na serwer.
12. Przetestowanie/przeklikanie sklepu.
13. Ewentualna zmiana kodowania przy połączeniu z bazą danych SET NAMES UTF8.
    Jeżeli opisy produktów mają krzaki, wówczas spróbuj ustawić kodowanie znaków przy pobieraniu danych z bazy.
    W pliku ../includes/functions/database.php (oraz to samo w katalogu admin)
    po fragmencie
    mysql_select_db($database);
    wstaw
    mysql_query('SET NAMES UTF8');.
14. Sprawdzenie poprawności polskich liter w wysyłanych mailach.
15. Ewentualne poprawki w przypadku błędnego wyświetlania polskich liter.
16. Odblokowanie sklepu.