collatieprobleem?
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.
Gewijzigd op 15/10/2024 12:18:01 door Guus Wiegerinck
Ik heb namelijk een schermafbeelding gemaakt van wat ik krijg na inloggen bij phpMyAdmin.
Die kan ik echter niet plakken in een reactie met
Toevoeging op 16/10/2024 17:03:00:
Ik kan nu niet meer bij phpMyAdmin. Firefox kan geen verbinding krijgen met Localhost. Een hardnekkig terugkerend probleem. Zie ook mijn draadje op Tweakers.
Toevoeging op 16/10/2024 17:08:15:
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.
Gewijzigd op 15/10/2024 23:08:55 door Guus Wiegerinck
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.
Gewijzigd op 17/10/2024 00:58:22 door - Ariën -
- Ariën - op 17/10/2024 00:52:31:
We hebben hier geen uploadsysteem voor afbeeldingen. Je kan ze bijv. uploaden op www.imgbb.com.
Kijk op imgbb voor screenshot phpMyAdmin
Toevoeging op 18/10/2024 17:51:51:
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?
Toevoeging op 18/10/2024 17:53:32:
O ja, ik kan intussen weer bij mijn phpMyAdmin. Heb je waarschijnlijk al gemerkt.
Maar zonder de screenshot is het nog steeds gissen. Je zult echt die link moeten delen ;-)
Gewijzigd op 18/10/2024 18:01:47 door - Ariën -
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.
Zoiets als:
als in woord ä staat, zet ä om in bijv. ä
Als deze in een vorige MySQL/MariaDB installatie afwijkt, dan heb je kans dat je inderdaad verkeerde tekens zal zien.
Verder steun ik Ivo P zijn reactie door ook HeidiSQL aan te raden. Dit is een los programma wat een connectie maakt met MySQL of MariaDB, zonder tussenkomst van PHP of een webserver. Ik gebruik bijna zelden nog phpMyAdmin. Voornamelijk om even snel wat installatiesettings uit te lezen, of het beheer van MySQL/MariaDB zelf op mijn testserver.
Je kan met htmlentities() bepaalde karakters omzetten naar HTML-entities, zoals > wat dan > is.
Maar waarom zou je dit willen? Dit wil je enkel als je HTML-tags onschadelijk wilt maken als je bijvoorbeeld een script wilt bouwen waarmee je wilt dat <strong>vet</strong> niet letterlijk vet wordt gemaakt.
Met de encoding en collations gaat er een wereld voor je open om alle tekens te gebruiken. De functie htmlentities() moet je niet als lapmiddel zien. Vooral omdat dit je tekst verminkt.
Gewijzigd op 18/10/2024 18:17:07 door - Ariën -
Je kunt nog kijken of je https://www.php.net/manual/en/book.iconv.php kunt gebruiken om de tekenset te achterhalen.
En evt te converteren.
Vervelende van & in je database zetten, is dat je dat bij het bewerken van je tekst ook weer op moet nemen. En als je er een pdf van maakt je ineens Märklin in je tekst ziet.
Toevoeging op 18/10/2024 18:15:20:
Ivo P op 18/10/2024 18:14:10:
maar dat script zal dan ook moeten snappen dat het een ä is....
(reactie op het zoeken naar script om om te zetten naar ä)
Je kunt nog kijken of je https://www.php.net/manual/en/book.iconv.php kunt gebruiken om de tekenset te achterhalen.
En evt te converteren.
Vervelende van & in je database zetten, is dat je dat bij het bewerken van je tekst ook weer op moet nemen. En als je er een pdf van maakt je ineens Märklin in je tekst ziet.
(reactie op het zoeken naar script om om te zetten naar ä)
Je kunt nog kijken of je https://www.php.net/manual/en/book.iconv.php kunt gebruiken om de tekenset te achterhalen.
En evt te converteren.
Vervelende van & in je database zetten, is dat je dat bij het bewerken van je tekst ook weer op moet nemen. En als je er een pdf van maakt je ineens Märklin in je tekst ziet.
Waar heb ik de tekst/speciale tekens ingevoerd? --> in phpMyAdmin de tabellen gevuld. De tabellen hadden collatie utf8_general_ci.
Een html-pagina in juiste tekenset ... weet ik niks van. Sinds in begin jaren 2000 me verdiept heb in html, heb ik me nooit vergewist van tekensets. Bijzondere tekens zoals & of paste ik toe wanneer resultaat afweek van de letter die het moest worden. Krijg nu idee dat ik een tijdmachine vooruit gelanceerd ben. Fred Flinstone in de digitale wereld.
Gewijzigd op 18/10/2024 18:22:14 door Guus Wiegerinck
Guus Wiegerinck op 18/10/2024 18:16:11:
Snel reageren is lastig, want ik kan niet citeren. Daarom een nieuwe reactie.
Waar heb ik de tekst/speciale tekens ingevoerd? --> in phpMyAdmin de tabellen gevuld. De tabellen hadden collatie utf8_general_ci.
Waar heb ik de tekst/speciale tekens ingevoerd? --> in phpMyAdmin de tabellen gevuld. De tabellen hadden collatie utf8_general_ci.
En welke tekenset gebruikte phpmyadmin?
Nu hebben de tabellen en serververbinding dezelfde collatie, nl utf8_general_ci.
Maar nu heeft de server weer een ander karakterset: w.european (latin1). Hmmm. Maakt het wel ingewikkeld.
Gewijzigd op 18/10/2024 18:29:14 door Guus Wiegerinck
Gewijzigd op 18/10/2024 18:29:40 door - Ariën -
"als $merk == M?rklin dan $merk = Märklin;"
of
"als $merk == Märklin dan $merk = Märklin;"
Want hoe komt het binnen, ik zie alleen wat er uit komt.
Toevoeging op 18/10/2024 18:34:46:
- Ariën - op 18/10/2024 18:29:19:
Dan is het raadzaam om mijn tip op te volgen, en utf8mb4 te gebruiken in je PHP-script.
En alle tabellen de collatie utf8mb4 te geven, toch?
Toevoeging op 18/10/2024 18:38:02:
Guus Wiegerinck op 18/10/2024 18:33:43:
Ik kan natuurlijk een if-else-je maken:
"als $merk == M?rklin dan $merk = Märklin;"
of
"als $merk == Märklin dan $merk = Märklin;"
Want hoe komt het binnen, ik zie alleen wat er uit komt.
"als $merk == M?rklin dan $merk = Märklin;"
of
"als $merk == Märklin dan $merk = Märklin;"
Want hoe komt het binnen, ik zie alleen wat er uit komt.
Niet zo handig bij nader inzien. Werkt alleen als inhoud van $merk één woord is. In zinnen moet je eerste zoeken of er een woord is dat ... Toch niet zo simpel
Maak wel altijd backups!!
Daarnaast is het zinloos om te controleren op ?, want dat van alles zijn. Verder is het ook onzinnig om HTML-entities te gebruiken omdat je problemen met UTF-8 hebt. Zorg gewoon voor een goede oplossing i.p.v. pleisters plakken waarbij je later daar restanten van zal zien, en je code vervolgens slechter onderhoudbaar wordt.
Gewijzigd op 18/10/2024 18:44:40 door - Ariën -
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
<?php
[code]$SQL_host = 'localhost';
$SQL_user = 'username';
$SQL_password = 'password';
$SQL_database = 'database';
$db = new MySQLi( $SQL_host, $SQL_user, $SQL_password, $SQL_database );
$db->set_charset("utf8mb4");
$db->query("SET NAMES utf8mb4 COLLATE utf8mb4_general_ci");
?>
[code]$SQL_host = 'localhost';
$SQL_user = 'username';
$SQL_password = 'password';
$SQL_database = 'database';
$db = new MySQLi( $SQL_host, $SQL_user, $SQL_password, $SQL_database );
$db->set_charset("utf8mb4");
$db->query("SET NAMES utf8mb4 COLLATE utf8mb4_general_ci");
?>
en dit in de <head> van een html pagina
Code (php)
1
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
daarmee kan je alle codes uit de unicodetabel gebruiken
https://en.wikipedia.org/wiki/List_of_Unicode_characters
Verder heb ik er nooit echt bij stilgestaan. Het staat in menige handleiding of tutorial. Of je verzint het zelf.