Adatbázis kódolás megváltoztatása

Adatbázis: SQL, XML DB

Üdv!

Egy nagyon régi problémámhoz hasonló jött most elő, és sajnos ehhez egyáltalán nem értek.

Adott egy python + django applikáció, ami mögött egy mysql szerver található. Az adatbázisban semmilyen kódolás nem lett beállítva, default szinte teljesen.

Az őűŐŰ karakterek helyett mindenhol kérdőjelek jelennek meg, és ezt szeretném orvosolni.

Nagyjából 4- 5 tábláról van szó, de ha az adatbázis egészére meg lehet oldani, az még jobb.

Amit eddig próbáltam: 

ALTER TABLE tablanev CONVERT TO CHARACTER SET utf8 COLLATE utf8_hungarian_ci

. Ez megoldja a problémát az újonnan felvitt rekordokhoz, de a régiek helyén kérdőjelek maradnak. Ha ráfrissitek a rekordra, szintén kérdőjelek maradnak. Igazából nem tudom, hogy ezek milyen típusú kérdőjelek (mármint tényleg kérdőjelek (#63), avagy még megvan az eredeti karakter (őúŐÚ, stb), csak rosszul jelennek meg). 

select mezo from table

hatasara is kerdojelnek tunnek.

-----

Debian: 8.9
Mysql: 5.5.57
Python: 2.7.9
Django: 1.11.4 


mysql> show session variables like 'char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

Koszonom a valaszokat, hozzaszolasokat.

( bandy | 2018. 08. 29., sze – 13:09 )

Tábla karakterkódolás mellett az egyes (text/string)mezők és az adatbázis karakterkódolása is utf8_* ?

( Fisher v | 2018. 08. 29., sze – 13:21 )

Esetleg tudsz listázni karakterkódokat: 


mysql> select type from ports where id=13315;
+------+
| type |
+------+
| USB  |
+------+
1 row in set (0.00 sec)

mysql> select hex(type) from ports where id=13315;
+-----------+
| hex(type) |
+-----------+
| 555342    |
+-----------+
1 row in set (0.00 sec)

( gabrielakos v | 2018. 08. 29., sze – 13:26 )

Csinálnék egy dumpot, abban megnézném hogy milyenek a karakterek.
Ha nem jók akkor lehet sed-el a replace-t megcsinálni.
Van persze olyan szitu amikor sajnos újra be kell vinni az adatokat mert ha nem bírta tárolni akkor nem bírta tárolni...

Aztán a dumpot egy helyesen (kódolással) megcsinált adatbázisba vissza lehet rakni, tesztelni, kész.
--
Gábriel Ákos

Ha user által felvitt tartalom (azaz nem a rendszer által kontrollált adat), akkor nem feltétlenül van benne csak magyar ékezet.
Az ilyen könnyelmű hozzáállások, miszerint "beállít, kipróbál, go", ahelyett, hogy átgondolná, és rendesen csinálná az ember (ami ugyanannyi beállítás, csak előtte van egy 10 perces "átgondol" fázis is) vezetnek oda, hogy igénytelenek a szoftverek, és az üzemeltetési környezetek.

mondjuk ilyen szempontból a MySQL egy förtelmes szoftver, mert az átgondolnál az ilyen apróságait elég alaposan kell ismerni.

Múltkor egy napot olvastam utána, hogyan kezelünk rendesen UTF-8-at MySQL alatt - és sikerült szmájlikat beszúrnom, meg ilyenek, de még mindig nem vagyok benne biztos, hogy minden korrekt...

Bocs, de ha mar hozzanyul, akkor miert ne csinalna meg rendesen? (Valamint az is erdekes feltetelezes, hogy orokke csak magyar nevu ugyfelek lesznek.)
Kb pont az ilyenekbol lesznek a kodban a provizorikus kodreszletek, meg kesobb a techdebt sprintek.
Nyilvan nem lehet mindenhol a tokeletessegre torekedni (nincs ra ido, nem eri meg, etc), de itt most szo szerint harom plusz betuvel meg lehet elozni kesobbi gondokat...