Skocz do zawartości
"Idzie nowe..." - o zmianach i nie tylko ×
Przeniesienie zakupów z IPS Marketplace / Moving bought items from IPS Marketplace ×

ROZWIĄZANY: latin2 (ISO-8859-2) na UTF8


maxx

Rekomendowane odpowiedzi

Wiem, wiem - na forum zatrzęsienie tematów o krzakach na forum, znakach "?", konwersji różnymi metodami.

Dwa dni siedziałem, czytałem to wszystko pilnie i robiłem testy. Niby problemu nie ma, ale wątpliwości pozostają.

Baza od środka wygląda tak;

post-293-1267206821,1299_thumb.jpg

post-293-1267206881,2895_thumb.jpg

post-293-1267206918,4878_thumb.jpg

post-293-1267206971,4708_thumb.jpg

Zawartość tabeli ibf_post PRZED konwersją wygląda tak:

post-293-1267206988,9407_thumb.jpg

Konwertuję gżegżółką ustawioną w poniższy sposób:

post-293-1267207113,4495_thumb.jpg

i otrzymuję taki wynik w bazie:

post-293-1267207391,7784_thumb.jpg

Robię konwersję do UTF-8 (na próbę tylko ibf_forums i ibf_topic), przestawiam forum na UTF-8 i:

post-293-1267207675,0642_thumb.jpg

jest ok, ale... Zastanawiam się, czy wszystko jest tak jak być powinno, bo tabele dalej mają opis [Metoda porównywania napisów latin2_general_ci]

Nie chciałbym czegoś skopać (>300k postów) więc stąd moje wątpliwości i pytania:

1. czy tak jak jest jest dobrze (w bazie), czy mam coś zmienić?

2. czy gżegżółka jest dobrze ustawiona i czy "daje radę" plikom >200MB?

3. czy bigdump może "zepsuć" kodowanie przy imporcie?

Edytowane przez maxx
Odnośnik do komentarza
Udostępnij na innych stronach

  • Manager

1. czy tak jak jest jest dobrze (w bazie), czy mam coś zmienić?

2. czy gżegżółka jest dobrze ustawiona i czy "daje radę" plikom >200MB?

Ja bym to zrobił tak:

post-1-1267276291,6273_thumb.png

3. czy bigdump może "zepsuć" kodowanie przy imporcie?

Jeśli ustawisz identyczne kodowanie, jak jest kodowany plik ( znaki ) to nie.

intermedia - profesjonalne rozwiązania Invision Power Board

---

Chcesz uzyskać szybko i sprawnie pomoc? Uzupełnij wersję i adres w profilu.

Odnośnik do komentarza
Udostępnij na innych stronach

  • Manager

Z tym, że ja tutaj więcej, jak -> skonwertuj polskie ogonki gżegżółką do uft8 encji i wgraj bigdumpem z kodowaniem utf8 nie mogę napisać bo to serio tylko tyle. :-)

intermedia - profesjonalne rozwiązania Invision Power Board

---

Chcesz uzyskać szybko i sprawnie pomoc? Uzupełnij wersję i adres w profilu.

Odnośnik do komentarza
Udostępnij na innych stronach

Nie jest tak różowo, ale 3 dni testów na localhoście i na serwerze, trochę literatury i gugiel dały pożądany efekt końcowy i nadzieję, że wiem jak to zrobić.

Metoda którą zastosowałem:

0. Czyszczenie bazy:

a. usunięcie logów botów, trackera i innych niepotrzebnych śmieci

b. optymalizacja i sprawdzenie bazy

1. Instalacja mysqldumper'a i backup całej bazy (w ustawieniach UTF8 bez względu na kodowanie backupowanej bazy (!) włączona kompresja *.gz)

2. Download backupu i rozpakowanie bazy na PC (totalcmd)

3. Zmiana kodowania gżegżółką:

a. odhaczone wszystkie opcje w zakładce konwersja)

b. konwersja z ISO-8859-2 na UTF8 (encje w każdej konfiguracji dawały "krzaki")

c. plik miał prawie 700MB - poszło bez problemu

4. Spakowanie skonwertowanej bazy do *.gz (totalcmd)

5. Upload pliku do katalogu mysqldumpera i odtworzenie bazy z tego pliku

6. Próba wejścia na forum i... cannot ... czyli wysypka.

7. Przywrócenie z backupu tabel, które moim zdaniem nie zawierały żadnych polskich znaków (~47 tabel, niektóre, puste zostawiłem)

8. F5 na klawiaturze i jest - wszystko ładnie, z ogonkami i bez żadnych krzaków (nie wiem ja PW - nie robiłem konwersji z 2.3.x do 3.0.5)

Wnioski:

1. Bigdump nie nadaje się wbrew nazwie do ładowania dużych baz, bo:

a. przy dużych tabelach (jak np. ibf_post) producent każe wyłączyć "rozszerzone dodania" przy eksporcie - daje to taki efekt, że plik potraja swoją objętość - eksport z włączoną opcją "rozszerzonych dodań" krzaczy forum w każdej próbie, a zrobiłem ich sporo :a:

b. potrafi "zabić" dedyka, mimo ostrożnego ustawienia (1000 lini, 100ms delay'a) - i za każdym razem albo sam się wieszał, albo dramatycznie podnosił load serwera po mniej więcej 3/4 przywracania - load dochodził do 300(!)

c. backup trzeba sobie phpmyadminem zrobić - nie każdy serwer to udźwignie (no chyba, że się ma dostęp do shella i możliwość uruchomienia mysqldump'a - nie próbowałem)

2. Gżegżółka konwertuje nawet spore pliki

3. Nobla temu kto napisze gżegżółkę pod linuxa :) - najwięcej czasu zajmuje robienie backupu, download/upload i restore bazy (w moim przypadku łącznie prawie 3h, a łącze mam szybkie, serwer też)

4. Trzeba by sporządzić listę tabel, które powinno się skonwertować. Backup byłby mniejszy i stresów mniej.

5. Metoda kodowania napisów w poszczególnych tabelach nie ma znaczenia (screen 3-ci z pierwszego posta ( przestawianie przed i po konwersji nic nie zmienia)

6. Zastanawiam się, czy przy upgrade chodzącego forum (a nie kopii testowej) konwersję ISO/UTF lepiej robić przed czy po upgrade (?)

To tyle na szybko.

Nie twierdzę, że powyższa metoda da każdemu dobry wynik - w moim przypadku dała :)

Odnośnik do komentarza
Udostępnij na innych stronach

  • Manager

Problem ROZWIĄZANY. Jeśli są jakiekolwiek wątpliwości, pytania proszę o założenie nowego tematu.

Wszelkie uzasadnione reklamacje/pretensje/sugestie/rady przyjmuje ekipa forum.

intermedia - profesjonalne rozwiązania Invision Power Board

---

Chcesz uzyskać szybko i sprawnie pomoc? Uzupełnij wersję i adres w profilu.

Odnośnik do komentarza
Udostępnij na innych stronach

Gość
Ten temat został zamknięty. Brak możliwości dodania odpowiedzi.
  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Umieściliśmy na Twoim urządzeniu pliki cookie, aby pomóc Ci usprawnić przeglądanie strony. Możesz dostosować ustawienia plików cookie, w przeciwnym wypadku zakładamy, że wyrażasz na to zgodę.