[SQL] Hoe juist importeren?

[TommyGun]

Hallo allen, bij deze een kort vraagje over het importeren van een SQL (MySQL, type MyISAM) database. Ik draai op mijn server Linux, en importeer een database altijd op de volgende manier in SSH omdat deze te groot is om via PHPMyAdmin te importeren; mysql dbnaam -u root -p < dbfile.sql

Helaas zorgt dit er wel voor dat woorden zoals "didn't" veranderen in "did´nt". Eigenlijk alles met " ' á etc worden allemaal van zulke tekens. Lastig dus als je wat aan het spelen bent en je een zojuist gemaakte backup terug wilt zetten, en je ziet vervolgens dat nicknames/posts/signatures noem het maar op niet meer kloppen.

Misschien dat er een manier is om dit in de toekomst te vermijden? Het zou mooi zijn als dit nog aangepast zou kunnen worden achteraf via een query of wat dan ook maar dat lijkt me niet helaas.

Ik heb helaas niet de mogelijkheid om een nieuwe import uit te voeren, aangezien dit al enkele weken zo draait en de backups die gemaakt worden van de database dus ook deze tekens bevatten. Ik edit zelf wel wat hier en daar maar dat is natuurlijk niet te doen steeds.

Iemand suggesties of tips? Bedankt

[TeeDee]

De encoding van de doel database goed zetten?

[TommyGun]

TeeDee schreef op maandag 02 april 2007 @ 22:46:
De encoding van de doel database goed zetten?

Daar dacht ik ook aan, maar ik zie zo eigenlijk niet (in PHPMyAdmin) welke encoding er gebruikt wordt. Je bedoeld niet het 'tekenset' neem ik aan of wel? (Deze staat op UTF-8). De collatie staat ingesteld op latin1_swedish_ci .

[ Voor 6% gewijzigd door TommyGun op 02-04-2007 22:50 ]

[Reinier]

TommyGun schreef op maandag 02 april 2007 @ 22:49:
De collatie staat ingesteld op latin1_swedish_ci .

Daar zit je probleem als je het mij vraagt.

[TeeDee]

UTF-8 zou goed moeten zijn.

Edit: Die collation is inderdaad een vreemde keuze

[ Voor 51% gewijzigd door TeeDee op 02-04-2007 22:55 ]

[TommyGun]

Hm wat zou die collatie dan moeten zijn? utf8_general_ci ofzo?

[RobIII]

TommyGun schreef op maandag 02 april 2007 @ 23:14:
Hm wat zou die collatie dan moeten zijn? utf8_general_ci ofzo?

Waarschijnlijk, maar je zou je ook effe kunnen verdiepen in het hele gebeuren in plaats van in het wilde weg te gaan proberen. Zo zou je bijvoorbeeld leren dat _ci staat voor Case Insensitive (en dus niet hoofdlettergevoelig bij zoeken/sorteren).

[ Voor 7% gewijzigd door RobIII op 03-04-2007 00:08 ]

[TommyGun]

Oke bedankt, ik ga iig ff een topic starten op het support board voor deze forum software, kijken wat nu de standaard hiervoor is of wat anderen personen hebben.

[ Voor 21% gewijzigd door TommyGun op 03-04-2007 00:15 ]

[TeeDee]

Ik denk dat je dat beter meteen had kunnen doen.

ipv mij een dm te sturen om nog even een blik op je topic te werpen.Ik zie dat heus wel als er iemand na mij gereageerd heeft.

[TommyGun]

TeeDee schreef op dinsdag 03 april 2007 @ 08:10:
Ik denk dat je dat beter meteen had kunnen doen.

ipv mij een dm te sturen om nog even een blik op je topic te werpen.Ik zie dat heus wel als er iemand na mij gereageerd heeft.

De antwoorden spreken voor zich; http://forums.invisionize.com/index.php?showtopic=122951

Mja dan maar zo laten. Helaas. Doe maar rustig hoor...

[Confusion]

TommyGun schreef op maandag 02 april 2007 @ 22:49:
Daar dacht ik ook aan, maar ik zie zo eigenlijk niet (in PHPMyAdmin) welke encoding er gebruikt wordt. Je bedoeld niet het 'tekenset' neem ik aan of wel? (Deze staat op UTF-8). De collatie staat ingesteld op latin1_swedish_ci .

latin1_swedish_ci Is geen geldige collation voor een kolom of tabel die UTF-8 als encoding heeft. Als het goed is kan je dat niet zetten en wordt er een foreign key constraint violation exception gegooid als je het probeert. Ik denk dat je die 'UTF-8' niet van de goede plek haalt.

[ Voor 4% gewijzigd door Confusion op 03-04-2007 21:01 ]

[TommyGun]

Confusion schreef op dinsdag 03 april 2007 @ 21:00:
[...]

latin1_swedish_ci Is geen geldige collation voor een kolom of tabel die UTF-8 als encoding heeft. Als het goed is kan je dat niet zetten en wordt er een foreign key constraint violation exception gegooid als je het probeert. Ik denk dat je die 'UTF-8' niet van de goede plek haalt.

UTF-8 is gewoon het tekenset wat ik heb aangegeven in de .htaccess en die wordt ook door de browser gebruikt als ik onder Beeld -> Tekenset op mijn forum kijk. Deze heb ik altijd al gebruikt, en werkt perfect, dit probleem wat ik nu heb zal wel gewoon van het exporteren of importeren komen.

[twiekert]

Dat is nou juist het probleem. Alles tussen de bron van de data (database) en de client (browser) moet met UTF-8 werken.

Je tabellen moeten dus ook de UTF-8 character set gebruiken. In PHP zal je UTF-8 compatible functies moeten gebruiken, je webserver zal het document als UTF-8 moeten serveren, en je cliënt zal dit ook als UTF-8 moeten interpreteren.

Bijv: je zal ook rekening moeten houden met de mysql connection library die in PHP zit dat die ook gebruik maakt van UTF-8 encoding. als er iets in 1 van deze lagen niet goed gaat met de encoding levert dat alleen maar garbage op voor speciale characters.

[ Voor 26% gewijzigd door twiekert op 03-04-2007 22:22 ]

[Confusion]

TommyGun schreef op dinsdag 03 april 2007 @ 21:03:
UTF-8 is gewoon het tekenset

UTF-8 is geen tekenset. Unicode is de tekenset. UTF-8 is een encoding. En inderdaad, in bijvoorbeeld PHP en MySQL hebben diverse variabelen gewoon een verkeerde naam.

wat ik heb aangegeven in de .htaccess

De .htaccess heeft niets met de database te maken.

Deze heb ik altijd al gebruikt, en werkt perfect, dit probleem wat ik nu heb zal wel gewoon van het exporteren of importeren komen.

Wat je altijd al hebt gebruikt werkte toevallig, bijvoorbeeld omdat de latin-1 en utf-8 encodings gelijk zijn voor de eerste 127 tekens (die ook weer precies gelijk zijn aan de oorspronkelijke ASCII set). Zodra je bijvoorbeeld met het euro teken te maken krijgt (die niet in latin1/ ISO-8859-1 zit), kom je hele vervelende problemen tegen. Want waarom wordt iets verkeerd weergegeven? Staat het verkeerd in de database? Wordt het door de database connectie verkeerd vertaald? Wordt het in de PHP een keer verkeerd gebruikt omdat een string manipulatie methode een bepaalde encoding verwacht? Of staat er een HTTP header verkeerd, waardoor de browser iets anders weergeeft dan je 'in werkelijkheid' hebt? Zodra je ruzie met encodings hebt, heb je twee mogelijkheden: heel goed nadenken en stap voor stap nagaan welke encodings de onderdelen die de data passeert er op nahouden of gewoon links en rechts wat encodings proberen te veranderen tot het werkt

In het geval van MySQL moet je bijvoorbeeld zorgen dat iedere connectie alle data als UTF-8 behandelt. Het eerste commando dat in een open connectie moet worden gegeven is 'SET NAMES utf-8'. Dat ervanuitgaande dat de server encoding ook al op utf-8 staat en je tables een utf-8 encoding hebben.

[ Voor 3% gewijzigd door Confusion op 04-04-2007 20:19 . Reden: Zin vergeten af te maken ]

[TommyGun]

Confusion; bedankt voor je post. Je kunt wel zien dat ik aardig beginner ben op database gebied en zo. Het spreekt echter wel een beetje tegen met de posts in het topic van de link hierboven ergens, maar als ik je goed begrijp dan komt het erop neer dat ik de database om moet toveren naar utf-8? Wat informatie;

MySQL Karakterset: UTF-8 Unicode (utf8)
MySQL verbindingscollatie: utf8_general_ci

Als ik dus in de database van het forum kijk dan staat er overal bij "Collatie" latin1_swedish_ci (Zweeds, hoofdletter ongevoelig).

[TommyGun]

Kleine bump dan maar

[TommyGun]

Helemaal niemand? Op dat andere board kunnen ze me ook niet verder helpen....

Het is geen ramp, maar zou leuk zijn als ik dit kan voorkomen in de toekomst, of nog beter; nu nog kan aanpassen.

[twiekert]

je tabellen staan waarschijnlijk nog op de latin1 character set. hier kun je alles vinden over de mysql character sets: http://dev.mysql.com/doc/refman/5.0/en/charset.html

Dit is echter niet 123 op te lossen voor bestaande tabellen. het converteren van een latin1 tabel naar utf8 kan met een ALTER TABLE statement, maar dat wil nog niet zeggen dat de data in de tabel ook goed staat. dat hangt er helemaal vanaf in wat voor encoding de data nu staat. het is mogelijk dat de huidige data als UTF8 encoding in een latin1 tabel worden opgeslagen, en dan zal je data goed verkloot worden als je een ALTER TABLE doet.

de meest makkelijke manier is de tabellen dumpen en de encoding veranderen naar UTF8 in de CREATE TABLE statements in de sql dump. Denk er wel aan hier een UTF8 compatible editor voor te gebruiken.

Wat meer info:

http://www.oreillynet.com...sql_data_in_latin1_t.html

of hier: http://www.mostrey.be/drupal_character_encoding_mysql

en anders even googlen als het niet werkt

[TommyGun]

twiekert; Bedankt voor je reactie.

de meest makkelijke manier is de tabellen dumpen en de encoding veranderen naar UTF8 in de CREATE TABLE statements in de sql dump. Denk er wel aan hier een UTF8 compatible editor voor te gebruiken.

Ik heb hier EditPad Pro 6 en daarmee eens een dump geopend, maar er veranderd helaas helemaal niks als ik daar Text Encoding kies en dan UTF8. Ik zie wel idd dat alles op latin1_swedish_ci staat. (CHARSET=latin1 bij de tabellen).



Edit; ik heb in bovenstaande menu natuurlijk wel de 2e optie gekozen, alleen bij t maken van de screen vergeten.

[ Voor 82% gewijzigd door TommyGun op 21-04-2007 01:17 ]

[twiekert]

Die CHARSET moet je dan omgooien naar CHARSET=utf8. Is de encoding van het dumpbestand ook al default UTF-8? Als dat zo is, en de non-ascii characters worden in de dump goed getoond dan is er niks aan de hand.

Mocht je dumpbestand in latin1 encoding staan dan zal je deze moeten converteren naar UTF8 via de Text Encoding optie. Afhankelijk van de huidige tabellen moet je één van die opties in het text encoding venster hebben ('Interpret the original data as being encoded with another character set...' of 'Encode the original data with another character set').

Dat is gewoon een kwestie van proberen. Zolang je de data op het scherm in editpad goed kan lezen op UTF-8 encoding is het in orde.

Welke mysql versie is dit trouwens en van welke mysql versie komt die dump? als dat 4.0 of lager is en de data was als UTF-8 opgeslagen in latin1 ge-encode tabellen dan zou je deze link nog kunnen lezen waar het zelfde probleem voorkwam: http://www.mostrey.be/drupal_character_encoding_mysql

[TommyGun]

Mijn MySQL versie is 4.1.12. Ik heb 2 verschillende dumps waar ik mee aan het testen ben;
1 via PHPMyAdmin en 1 via een cronjob. In die cronjob staat;

code:

backup2spot="`date +%Y-%m-%d`-2spot.sql"
mysqldump --password=blaat --databases 2spot >> $basedir/$backup2spot

Bij de tabellen in de PHPMyAdmin dump staat:

code:

ENGINE=MyISAM DEFAULT CHARSET=latin1

In de dump gemaakt door de cronjob staat wat meer;

code:

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

code:

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `2spot` /*!40100 DEFAULT CHARACTER SET latin1 */;

code:

ENGINE=MyISAM DEFAULT CHARSET=latin1;

Ga vanavond eens verder prutsen met EditPad. Bedankt voor je moeite!

[ Voor 121% gewijzigd door TommyGun op 21-04-2007 13:25 ]

[Verwijderd]

Het ziet er naar uit dat ik het zelfde probleem heb, alleen ik heb er nog minder verstand van heb als TG.
Ik draai mybb forum en heb eerst een testforum gemaakt zodat ik het officieel pas online kon zetten zodra ik wist dat alles 100% werkte. Op het testforum heb ik allemaal hoofdtopics aangemaakt en ben toen vanuit het Mybb cpadmin menu een backup gaan maken en alles overgaan zetten naar een nieuw domein.

Waarschijnlijk heeft dit nog niets te maken met de characterset, maar ik ben ook gaan kijken in phpmijn admin en trof daar dit aan.

MySQL Karakterset: UTF-8 Unicode (utf8)
MySQL verbindingscollatie: Collatie UTF8 Unicode

Ik ben vervolgens gaan kijn ook in phpmyadmin wat er staat bij database

Database Collatie
deb_forumikf latin1_swedish_ci

Dus ik heb ook een latin collatie.

Waarom deze vraag?
Het komt regelmatig voor dat sommige vreemde letters veranderen in �.

Neem nu een van mijn laatste users meld zich aan onder de naam Brejl�-k, wat moet zijn Breljik.
De i die ik hier echter niet kan namaken (heb die toets niet) is een i met het puntje schuin.
Deze problemen kunnen grote gevolgen hebben: je kunt niet repyen op een brecht dat als titel deze � heeft.

Nu de vragen
1. kan ik deze latin1_swedish_ci via myphpadmin op een een of andere manier veranderen
2. zal dit het probleem in te toekomst op kunnen lossen
3. als ik het kan aanpassen wat zijn de gevolgen voor de al gemaakte 10.000 teksten

[Megamind]

1. Als je nou eens goed zoekt in phpmyadmin kan je gewoon de coalitie veranderen, van je tabel van je DB en van velden apart.

2. Als je niet elke keer van set wisselt dan is er niks aan de hand

3. Waarschijnlijk is het overhoop, als je teminste niet al data hebt zitten invoeren onder een latin1 set...

[ Voor 43% gewijzigd door Megamind op 05-05-2007 09:55 ]

[Verwijderd]

Wat bedoel je met de laatste opmerking??

Zal dit mijn omschreven probleem kunnen verhelpen??


Kijk ik in de php file van mybb forum dan staat er

// Sets the lang in the <html> on all pages
$langinfo['htmllang'] = "en";

// Sets the character set, blank uses the default.
$langinfo['charset'] = "UTF-8";

Vandaar dat ik hoop dat deze twee verschillen het probleem kunnen verhelpen.
En natuurlijk als ik het in myphpadmin verander dit geen problemen op levert.

Zolang het forum online is heb ik geen veranderingen gemaakt met betrekking tot deze character codes.

[TommyGun]

Nou ik heb eens mijn database gecloned enzo, en vervolgens voor enkele tabellen dit gedaan;

code:

ALTER TABLE ibf_posts CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

Vervolgens staat de collatie dan netjes op utf8_general_ci maar helaas veranderd er niks aan de posts zelf.

Gek word ik er van, nu niet echt een probleem maar stel dat ik dalijk weer eens moet importen dan is alles weer verneukt . Hoewel; volgens mij gaat het echt fout bij het exporten, niet bij het inporten, maar het maakt niet uit of dat nou via PHPMyAdmin of via SSH gebeurd. Of komt dat gewoon om de database als collatie latin1_swedish_ci heeft?

[ Voor 36% gewijzigd door TommyGun op 05-05-2007 16:28 ]

[Megamind]

Nee logisch, de tekst zal ook niks veranderen aangezien die opgeslagen is in een andere set. Het enigste is wat je kan doen is met PHPP de tekst uitlezen, omzetten naar de juiste character set en weer opslaan in de juiste character set in een nieuwe tabel.

Het is een helwerk weet ik uit ervaring, er zijn genoeg dingen te vinden op google hierover.