Rare tekens na verhuizing forum

[David]

• Adres van je forum: http://www.timefc.net/forum
  Event. modificaties op je forum:
  Wanneer ontstond het probleem? Probleem is bij mij gemeld 22-september-2012 mogelijk ontstaan na de verhuizing die gisteren 21-september-2012 heeft plaatst gevonden zo rond het middag uur.
  phpBB versie: 3.0.11
  
  
  Heb je onlangs iets veranderd aan je forum?
  Wat is het probleem?

Gisteren heb ik voor het eerst twee forums verhuisd naar een andere host, dit verliep goed... ik dacht dat er zich geen problemen hadden voor gedaan. Maar helaas melde de eigenaar van het forum vandaag rare tekens te hebben: http://www.timefc.net/forum/viewtopic.php?f=9&t=4257

Uiteraard heb ik zelf al eens eventjes gezocht en vond een aantal topics met ongeveer het zelfde probleem! Het heeft als ik het goed begrijp iets te maken heeft met UTF-8 maar als ik de back-ups bekijk zie ik daar ook UTF-8 staan! Ik heb de databases ingelezen met bigdump ik zelf denk dat daar iets mis is gegaan. Aan de hand van wat ik in andere topic heb gelezen zie ik nu dat ik de utf8 ook in bigdump had moeten aangeven... tenminste als ik het goed begrijp!

Kan iemand mij wat wijzer maken en uitleggen wat ik nu verkeerd heb gedaan, wat is precies het probleem alleen die rare tekens? Is er een herstel tool of script om de leestekens te herstellen? De verhuizing is meer dan 24 uur geleden dus opnieuw met back-ups goochelen zie ik niet zo zitten.

Ik dacht dat ik me goed had voorbereid had zelfs de verhuizing geoefend, maar de leestekens helaas niet opgemerkt anders had ik niet zo snel definitief verhuisd natuurlijk. Dus hoop dat ik het zonder verlies van gegevens recht kan zetten.

[Pola]

Het heeft te maken met de character set (collation) van de database.

De enige manier die ik zo snel kan bedenken is door middel van SQL queries de foute karakters door goede te vervangen:

Code: Selecteer alles

update phpbb_posts set post_text = replace(post_text, 'old_character', 'new_character')

Een aantal foute en goede karakters kun je in deze tabel vinden.

[David]

Het resultaat van die query is:

Uw SQL-query is succesvol uitgevoerd. (Query duurde 0.9686 sec)

Helaas zijn de characters uit het voorbeeld niet hersteld of vervangen


Wat ik me nog steeds afvraag wat houd dit foutje/probleem precies in, en hoe voorkom ik het de volgende keer als ik een back-up verplaats of terug zet? Als ik nu bijvoorbeeld speciale tekens post zoals Reëel of reünie dan worden ze wel goed herkent/geplaatst. Ik wil even zeker weten of het geen verdere gevolgen heeft. De posts en onderwerp titels zou je dan bewijze van spreken ook zelf kunnen wijzigingen/herstellen toch?

[Pola]

Ik ben geen specialist op dat gebied.
Wat ik er van begrijp is dat wanneer de character set ongewijzigd blijft, je geen probleem zou moeten hebben. Wanneer de oorspronkelijke database en de nieuwe database een verschillende character set heeft, of als je de export met een andere character set forceert, dan kan het zijn dat bepaalde speciale karkaters anders geconverteerd worden. Bepaalde karakters bestaan wel in de ene set en niet in de andere.

Wat is de query die je uitgevoerd hebt? Je moet old_character en new_character in de query steeds vervangen door de foute code en het goede karakter.

Als je de berichten wijzigt en de karakters zelf in het bericht corrigeert, kun je het inderdaad ook herstellen. Belangrijk is dat de database utf8_bin heeft als character set.

[David]

Domme ik, ik heb alleen dit uitgevoerd

update phpbb_posts set post_text = replace(post_text, 'old_character', 'new_character')

Had even niet door dat ik de speciale tekens daar moest invoeren met de gewone tekens. Daar zal ik me deze week dan eventjes mee bezig gaan houden

phpbb_post heeft als collatie inderdaad utf8_bin

Maar als ik kijk naar de structuur:

post_subject collatie: utf8_unicode_ci
post_text collatie: utf8_unicode_ci

Misschien dat dat niet klopt?

[Pola]

Die collaties kloppen wel.
Als je de Fulltext mysql zoekindex creeert, wordt volgens mij de collatie van post_text veranderd van utf8_bin naar utf8_unicode_ci. Dat mag geen probleem zijn.

[David]

De SQL-query werkt nu wel gewoon nu ik hem gebruik zoals ik hem moet gebruiken

Ik heb ook meteen uitgezocht wat ik nu verkeerd heb gedaan, ik kwam er namelijk achter dat de characters in de back-up al verkeerd staan wat zou betekenen dat ik iets verkeerd doe bij het maken van de back-up.

Bij data dump opties heb je de optie: Syntax om te gebruiken bij het toevoegen van data

Optie die al geselecteerd is:

Code: Selecteer alles

Beide van bovenstaande
Voorbeeld: INSERT INTO tbl_naam (kol_A,kol_B) VALUES (1,2,3), (4,5,6), (7,8,9)

Een tijdje geleden had ik het probleem dat bigdump te lange query's niet aankan, dit had iets te maken met "semicolon" of zoiets dergelijks. Zo breek je de langere query's en verdeel je ze in kleine stukje tenminste dat is wat ik eruit begreep Daarom vink ik onderstaande optie aan:

Optie die ikzelf selecteer:

Code: Selecteer alles

neem kolom namen op in elke INSERT opdracht
Voorbeeld: INSERT INTO tbl_naam (kol_A,kol_B,kol_C) VALUES (1,2,3)

Bron die ik toen heb gebruikt: https://forum.antagonist.nl/viewtopic.php?f=7&t=10964

Ik heb het voor mezelf eventjes getest de optie die ik kies zorgt ervoor dat die leestekens/characters verminkt worden. De optie die standaard geselecteerd staat doet dat niet!

Dat is mijn conclusie

Alleen is mijn vraag nu, hoe voorkom ik dat query's te lang worden? Zonder dat de characters ervan kapot gaan?

[Pola]

Ik vind het raar dat met die optie de karakters gewijzigd worden. Dat zou ik niet verwachten en heb dat zelf ook niet meegemaakt.
Een alternatief zou ik zo snel niet weten.

[marian0810]

Als ik me goed herinner (en je goed begrijp) heb ik dat indertijd opgelost door in bigdump.php

Code: Selecteer alles

define ('MAX_QUERY_LINES',300);

te veranderen in

Code: Selecteer alles

define ('MAX_QUERY_LINES',30000);

en

Code: Selecteer alles

$db_connection_charset = '';

in

Code: Selecteer alles

$db_connection_charset = 'utf8';

[David]

Ik vind het raar dat met die optie de karakters gewijzigd worden. Dat zou ik niet verwachten en heb dat zelf ook niet meegemaakt.
Een alternatief zou ik zo snel niet weten.

Vreemd, dus eigenlijk zeg je dat het normaal gezien niet zou moeten gebeuren? Vind het ook maar vreemd eerlijk gezegd maar goed het probleem is opgelost de meeste characters heb ik kunnen herstellen gelukkig

Bedankt voor je reactie marian0810 ik ga dat zeker eens proberen

Ik ga mezelf er nog wat meer in proberen te verdiepen via een andere weg, anders wijken we teveel af van phpBB en dat is ook weer niet de bedoeling. Bedankt voor jullie antwoorden en reacties.