Napraw polskie znaki w MySQL i phpMyAdmin

phpMyAdmin, zrzut SQL lub Twoja aplikacja pokazują Ä… zamiast ą albo ? zamiast ę? Zwykle tabela, połączenie i import używają różnych kodowań. Mojibuster naprawia eksport w przeglądarce – potem ustawisz MySQL raz a dobrze.

Działa z tekstem i plikami:

  • CSV
  • TXT
  • JSON
  • XML
  • SRT
  • VTT
  • SMI
  • TSV
  • MD
  • HTML
  • SQL
  • LOG

Na przykład eksporty z Excela, zrzuty baz danych, napisy do filmów lub kod stron.

Napraw

  1. Przeciągnij plik lub wklej tekst
  2. Naprawa następuje automatycznie
  3. Skopiuj lub pobierz
albo po prostu przeciągnij plik tutaj

Trzy miejsca, w których MySQL potrzebuje kodowania

  • Kolumna lub tabela: zestaw znaków, w którym zapisane są dane, np. utf8mb4, latin2 lub cp1250.
  • Połączenie: zestaw znaków, w którym klient i serwer ze sobą rozmawiają – ustawiasz go przez SET NAMES utf8mb4 albo w ustawieniach połączenia.
  • Plik: kodowanie, w którym czytany jest import lub zapisywany eksport – w phpMyAdmin w polu Zestaw znaków pliku.

Jeśli te trzy ustawienia się nie zgadzają, polskie litery się psują. Najczęstszy przypadek: tekst w UTF-8 zapisany przez połączenie latin1 do kolumny latin1. W aplikacji wszystko wygląda dobrze, ale phpMyAdmin i eksport pokazują Ä… i Ĺ‚.

Wiersz z eksportu CSV z phpMyAdmin

Przed

"1","Zbigniew Wójcik","ul. Gdańska 12","Kraków"

Po

"1","Zbigniew Wójcik","ul. Gdańska 12","Kraków"

Sprawdź zestawy znaków

  • SHOW VARIABLES LIKE 'character_set%'; pokazuje ustawienia serwera i połączenia.
  • SHOW CREATE TABLE klienci; pokazuje zestaw znaków tabeli i jej kolumn.
  • SELECT nazwisko, HEX(nazwisko) FROM klienci LIMIT 5; pokazuje prawdziwe bajty: w kolumnie utf8mb4 C3B3 to ó, a C383C2B3 to już zepsute ó.

Napraw eksport lub zrzut bazy

  1. Wyeksportuj tabelę w phpMyAdmin jako SQL lub CSV – albo poleceniem mysqldump --default-character-set=utf8mb4.
  2. Przeciągnij plik do pola powyżej. Mojibuster naprawia tylko zepsute miejsca, poprawne znaki zostają bez zmian.
  3. Sprawdź naprawione miejsca w sekcji Co zostało zmienione? i pobierz plik.
  4. Zaimportuj go do tabeli z utf8mb4 i w oknie importu wybierz zestaw znaków utf-8.
  5. Najpierw przetestuj to na kopii, zanim podmienisz prawdziwą tabelę.

Eksport nigdy nie opuszcza Twojego komputera – a przy danych klientów to ma znaczenie. Jeśli teksty w bazie są zepsute w kilku warstwach naraz, zajrzyj na stronę co to jest mojibake.

Usuń przyczynę

  • Nowe tabele twórz z DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci. Do polskiego sortowania możesz użyć też utf8mb4_polish_ci.
  • Ustaw w aplikacji połączenie utf8mb4, w PHP np. przez charset=utf8mb4 w DSN dla PDO.
  • Jeśli bajty UTF-8 leżą w kolumnie latin1, nie konwertuj jej wprost przez CONVERT TO – zakodujesz je drugi raz i powstanie tekst zakodowany podwójnie. Bezpieczna droga prowadzi przez typ binarny: najpierw MODIFY nazwisko VARBINARY(255), potem MODIFY nazwisko VARCHAR(255) CHARACTER SET utf8mb4.
  • Jeśli MySQL zamienia litery na ?, kolumna lub połączenie nie potrafią ich zapisać. To, co tak już zapisano, jest utracone – więcej w artykule co to jest mojibake.

Najczęstsze pytania

Dlaczego w aplikacji wszystko wygląda dobrze, a w phpMyAdmin nie?

Bo aplikacja i baza robią ten sam błąd dwa razy: aplikacja zapisuje UTF-8 przez połączenie latin1 i tak samo je odczytuje. phpMyAdmin łączy się poprawnie, więc pokazuje to, co naprawdę jest w bazie.

Jakiego porównywania (collation) użyć?

utf8mb4_unicode_ci pasuje do większości aplikacji, a od MySQL 8 domyślne jest utf8mb4_0900_ai_ci. Ważniejszy jest zestaw znaków utf8mb4 – nie utf8, który w MySQL nie zapisze emoji.

Czy to działa także z MariaDB?

Tak. MariaDB obsługuje zestawy znaków jak MySQL, a polecenia są takie same.

Jak duży może być zrzut bazy?

Do 100 MB na plik. Większe bazy eksportuj tabela po tabeli.

Więcej poradników