Door
Guus Wiegerinck
op 15-10-2024 12:15
gewijzigd op 15-10-2024 12:18
7.002 views
Sinds ik een nieuwe WAMP heb geïnstalleerd, worden letters als ä, bijv in Märklin, weergegeven als een zwart ruitje met vraagteken. In de tabel staat echter gewoon een ä. Is dit een collatieprobleem en hoe los ik dit op?
Volgens mij zal dat met andere letters met accenten ook wel zo zijn, moet het alleen nog zien.
De tabel staat in utf8_general_ci, de (nieuwe) database in utf8mb4_unicode-ci.
Als ik daar utf8_general_ci van maak, verandert er aan de weergave niets: de ä blijft een zwart ruitje met vraagteken.
Na afsluiten en mySqlAdmin weer openen, staat er als collatie weer utf8mb4_unicode-ci. Wat doe ik niet goed?
Mysql: 3306 staat helemaal bovenin scherm.
Kan ik in dit forum afbeeldingen toevoegen aan mijn reactie? Een plaatje toont meer dan een praatje.
Ik heb namelijk een schermafbeelding gemaakt van wat ik krijg na inloggen bij phpMyAdmin.
Die kan ik echter niet plakken in een reactie met
[size=xsmall]Toevoeging op 16/10/2024 17:03:00:[/size]
Ik kan nu niet meer bij phpMyAdmin. Firefox kan geen verbinding krijgen met Localhost. Een hardnekkig terugkerend probleem. Zie ook mijn draadje op Tweakers.
[size=xsmall]Toevoeging op 16/10/2024 17:08:15:[/size]
Overigens, wat die zwarte ruitjes betreft.
Wat ik wwou uitzoeken of het een collatieprobleem is (wat levert de database aan? ä of een zwart ruitje?) Maar dat kan ik Hu niet, ik kan er niet bij.
het kan ook zijn dat het een html-probleem is. In dat geval moet ik alle letters met accenten op een slimme manier omzetten in html-code. Óf ... in de tabellen de html-code gaan gebruiken i.o.v. de gewone schrijfwijze.
We hebben hier geen uploadsysteem voor afbeeldingen. Je kan ze bijv. uploaden op www.imgbb.com.
Zonder code, en al je settings is het lastig uit te zoeken. Maar mogelijk kan een mysqli_set_charset() wel helpen, maar dit is wel uitzoeken of dat wel het probleem is. De serverinstelling is altijd leidend, en met mysqli_set_charset() kan je het aanpassen.
We hebben hier geen uploadsysteem voor afbeeldingen. Je kan ze bijv. uploaden op www.imgbb.com.
Kijk op imgbb voor screenshot phpMyAdmin
[size=xsmall]Toevoeging op 18/10/2024 17:51:51:[/size]
Ik heb intussen de karakterset omgezet in utf_general_ci.
Ik heb gekeken wat SQL ervan maakt. In een query wordt Märklin weergegeven als Märklin. Dus daar worden letters niet veranderd in zwarte ruitjes met een vraagteken.
Dus doet html dat, concludeer ik. Of is dat te kort door de bocht?
[size=xsmall]Toevoeging op 18/10/2024 17:53:32:[/size]
O ja, ik kan intussen weer bij mijn phpMyAdmin. Heb je waarschijnlijk al gemerkt.
Als alles in phpMyAdmin goed staat zonder die 'geruite wybertjes' of andere rare encodingfratsen die de speciale tekens onleesbaar maken, dan gaat er in jouw PHP-script iets niet goed. Afhankleijk van de collatie-instellingen van je database moet je mogelijk mysqli_set_charset() gebruiken met de juiste collatie. Dit heeft verder niks met HTML te maken.
Maar zonder de screenshot is het nog steeds gissen. Je zult echt die link moeten delen ;-)
Is er een script waarmee ik de inhoud van een variabele kan zien zonder dat dat via html gaat?
Toelichting:
Nu worden letters met leestekens, zoals ä of ó, door html weergegeven als zwart ruitje met een vraagteken erin. Terwijl die in de database gewoon als ä of ó zijn getypt en in een sql ook zo worden weergegeven. En staat dat ook precies zo in de variabele, totdat html zegt: "ä? Ken ik niet. Dat is onbekend."
Het is niet zo dat "er staat in pma een ä, dus het is daar goed".
Dat is net zo iets als een Nederlander laten kijken of een tekst goed is, en vervolgens deze tekst aanbieden aan een franstalige.
Tekens worden op verschillende manier opgeslagen.
Bijvoorbeeld simpelweg met de ascii code. Ontwikkeld in de tijd dat er vooral Engelstalige teksten op een letters-only scherm kwamen (zo'n zwart scherm met groene letters).
Toen was 255 tekens meer dan genoeg.
Fast Forward via tekensets per taal naar unicode. Daarin zitten duizenden tekens en is 1 byte niet genoeg om ze allemaal een nummer te geven.
Nu wordt het extra belangrijk om aan te geven in welke tekenset (taal om de NL/FR vergelijking in stand te houden) je iets hebt opgeslagen.
Jij zegt dat het unicode/utf8 is.
Maar ergens tussen het lezen uit de database en het tonen op het scherm zit een element dat uitgaat van een andere tekenset.
Vaak zie je dat een niet weer te geven teken veranderd wordt in 2 rare tekens.
Dat is als een 2bytes tekens voor een 1bytes tekenset wordt aangezien.
Vergelijk: teken 6432 wordt dan gezien als teken(64) gevolgd door teken(32)
Jij lijkt het omgekeerde te hebben: jouw tekens in maar 1 blokje/vraagteken.
Waar kan zo iets misgaan:
Je hebt de tekst ergens ingevoerd.
Was dat in een html-pagina met de juiste tekenset?
Was de verbinding naar de database daarmee in overeenstemming?
DB: die tekenset noem je al.
Uitlezen:
is de verbinding met de database in de goede tekenset gesteld?
Als op het scherm geplaatst: wordt daarbij aangegeven dat de browser de tekesn als unicode moet zien?
Zitten er onderweg nog tekstbewerkende functies bij? Iets als substr() die niet per se multibyte compatibel zijn.
vandaar bijvoorbeeld https://www.php.net/mb_substr
Heb je eventueel iets aan een programma als HeidiSQL om in je database te kijken? Dat scheelt in elk geval een hoop gedoe met de settings van de browser etc.
En als zulke letters toch moeten worden omgezet naat html-code, is daar dan een script voor?
Zoiets als:
als in woord ä staat, zet ä om in bijv. ä
