Als je vreemde tekens ziet, dan komt dat door je encoding. Blijkbaar sta je die nu met holbewonertactieken stuk voor stuk recht te breien in plaats van dat je netjes de boel laat converteren.
Hoe converteer je dat dan? Converteren is wat anders dan een crapload aan replacements uitvoeren. Misschien is het nu niet meer goed te converteren omdat je teveel hebt zitten te rommelen. Dus ik hoop dat je een back-up hebt.
Het is wel van belang dat je weet wat de waardes van de settings: character-set-server en collation-server zijn. Deze kan je in phpMyAdmin vinden, zodra je inlogt.
Wat ik doe is heel basic in Phpmyadmin de kolom bewerken door de bewuste kolom van via bewerken "Collatie" van latin1_swedish_ci naar utf8_general_c om te zetten.
PHPmyadmin gaat aan de slag, maar komt dan met de fout <code> "fout in query #1366- incorrect string value: \\xEB|rij...'for column....ad row2.</code>
Die links ga ik straks even lezen alvast bedankt!
\
Als je een kolom hebt met het naam "duits" en daarin staan teksten in het Duits
en je verandert de naam in Frans.
dan worden de teksten niet vertaald.
Evenzo met de collatie. (die trouwens meer zegt over de bijkomende zaken als sorteren, en je zou eigenlijk de character set van de kolom willen aanpassen).
Waarschijnlijk is je foutmelding een gevolg van "de kolom bevat nu waarden die niet te verwerken zijn met de nieuwe collatie"/
Vergelijk met het hernoemen van de kolom van Duits naar Frans.
Je hebt nu ineens tekens als ö en ß in je tekst die in het Frans niet voorkomen.
Betere werkwijze:
nieuwe kolom met de gewenste settings aanmaken en de inhoud van de oude geconverteerd naar deze nieuwe kolom brengen.
Als ik een kolom verander van latin1_swedish_ci naar utf8_general_c dan wordt deze automatiche vertaald.
Het gaat niet om ö of ñ of welke letter dan ook. Zoals ik in eerste instantie als schreef, Er zitten ONZICHTBARE!!! gegevens in die tabel. Daarom krijg ik een error.
De tabel heb ik al als CSV geëxporteerd. Op geschoond wat betreft zichtbare karakters.
Daarna weer geïmporteerd.
daarna kreeg toch weer de melding : "fout in query #1366- incorrect string value: \\xEB|rij...'for column....ad row2.
Als ik <code> SELECT * FROM `newsitems` WHERE `NewsItem_Intro` REGEXP '\\xEBl' </code> doe dan krijg ik als resultaat 222 records. In die records is niet te zien qua karakters wat daar niet hoort.
ik hoopte op een combinatie script dat de code wel kan vinden en die kan replacen met een leeg waarde
zoiets dus:
<code> UPDATE newsitems SET NewsItem_Intro = REPLACE(NewsItem_Intro, 'REGEXP '\\xEBl'' ''); </code>
Check mijn gedeelde script eens, en lees ook eens wat Ivo zegt.
Backup terug, en probeer dat script.
?
Onbekende gebruiker
14-07-2024 22:06
gewijzigd op 14-07-2024 22:08
Het converteren van de ene naar de ander encoding heet transcoding, en latin1 past helemaal in UTF8, dus dat kan het probleem niet zijn.
Het is gewoon vreemd dat er vreemde tekens in staan waar MySQL (ik neem aan dat je dat gebruikt?) geen raad weet. Misschien een bug, wie zal het zeggen.
Dat zou je met een query moeten kunnen verhelpen. Het enige is dat je dat op zo'n manier moet zien te communiceren naar MySQL dat-ie het snapt. Misschien dat dit helpt:
UPDATE newsitems SET NewsItem_Intro = REPLACE(NewsItem_Intro, UNHEX('EB', '')); </code>
Ik heb het voorbeeld hier vandaan gehaald. (Zelf ben ik meer van PostgreSQL)
Zelf ben ik geen fan van phpMyAdmin. Vroeger was het een drama, en ik weet niet of dat nog steeds zo is. Bij het exporteren was het altijd hoop houden dat de export goed ging. Maar tegenwoordig gebruik ik voornamelijk HeidiSQL, en als ik op de server onderhoud moet plegen, dan doe ik dat met mysql op de server. Dan heb je bovendien geen lompe limieten...