diakritische tekens als ? weergegeven
Wederom een nieuw onderwerp. Diakritische tekens. Hoe weer te geven?
Mijn <b>collatie</b> instelling:
database en alle tabellen staan op utf8_general_ci ingesteld.
In mijn hearder.php staat als allereerste de code, die ik overigens include:
en in mijn head section de code:
Code (php)
1
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Maar bij mij blijven de diakritische tekens als ? weergegeven worden. Als je op het forum zoekt gaat het alle kanten uit en wordt het allemaal heel verwarrend. Er is enorm veel over te lezen maar ik lees tussen de regels ook door dat een oplossing niet zo 1,2,3 voor handen is.
Er is geen man over boord of zo hoor maar zou mooi zijn als de tekst op mooie manier wordt weergegeven.
Draai op een normale Windows laptop mijn localhost op een Wampserver
@Thoma, wat is het verschil?
Geef je ook na je connectie mee welke collatie je gebruikt?
Even wezen googlen leverde onderstaande code op
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
$connection = mysqli_connect("xxxxxxxxx", "xxxxxx", "xxxxxxx");
mysqli->set_charset('utf8');
mysqli->query("SET collation_connection = utf8_general_ci");
if(!$connection){
echo "Er kan geen connectie met de server worden gemaakt" . die(mysqli_error($connection));;
}
$dbselect = mysqli_select_db($connection, "xxxxxxxx");
if(!$dbselect){
echo "Er kan geen connectie met de database worden gemaakt" . die(mysqli_error($connection));
}
?>
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
$connection = mysqli_connect("xxxxxxxxx", "xxxxxx", "xxxxxxx");
mysqli->set_charset('utf8');
mysqli->query("SET collation_connection = utf8_general_ci");
if(!$connection){
echo "Er kan geen connectie met de server worden gemaakt" . die(mysqli_error($connection));;
}
$dbselect = mysqli_select_db($connection, "xxxxxxxx");
if(!$dbselect){
echo "Er kan geen connectie met de database worden gemaakt" . die(mysqli_error($connection));
}
?>
Maar dat lever de volgende foutmelding op:
<b> Parse error: syntax error, unexpected '->' (T_OBJECT_OPERATOR) in ...... on line 5
</b>
maar weet niet wat ik daar mee aan moet.
Verder raad ik aan om geen mengeling met procedureel (functies zoals mysqli_xxx()) en objectgeorienteerd
$conn->query(...) te gebruiken. Liever in objectgeoriënteerde code...
Het kán wel, maar het geeft verwarring door inconsistente syntax.
Gewijzigd op 14/07/2019 20:21:30 door - Ariën -
Snap d'r geen z*k van....
Die oplossing heb ik al gegeven en zelfs onderstreept ;-)
Maar als jij iets ingewikkeld vindt, dan heb ik het idee dat je ergens kennis van mist.
Anyway, je mist een $ van een variabele.
Als je een helder overzicht wilt hebben van object-oriënted en procedural:
Kijk eens hier: https://php.net/mysqli_query
In twee codeblokken zie je de verschillen. Ik raad altijd object-georienteerd aan.
Gewijzigd op 14/07/2019 21:16:47 door - Ariën -
Maar het enige wat ik onderstreept zie is jouw naam in een melding van het systeem doordat je bericht hebt aangepast.
maar ik zal de plank wel totaal misslaan maar ik zie het niet ..... morgen maar de opticiën.
maar misschien ook een tip... niet iedereen zit op topniveau zoals jullie :-) en zijn still learning
Hier mist een $ omdat het een variabele is, maar dan moet je wel de variabele van je connectie gebruiken. Dat dollarteken heb ik tevens onderstreept in mijn vorige bericht ;-)
Gewijzigd op 14/07/2019 21:35:23 door - Ariën -
probeer het over 'n tijdje als ik hopelijk wat meer kennis opgedaan heb nog wel eens een keer.. maar voor beginnelingen is dit niet te doen.... moet het ook maar 'n beetje van het freubelen hebben.. niks geen opleiding in deze gehad ...
Toch bedankt Ari?n :-)
Gewijzigd op 14/07/2019 21:44:07 door - Ariën -
blijft ingewikkelde kost hoor.... maar afijn bedankt voor al die handvatten...
'ns kijken of we dat kunnen tackelen
Simpele oplossing: Code even kopiëren naar Notepad/kladblok, en opnieuw opslaan als UTF-8. Of anders met je editor opslaan zonder BOM (Byte Order mark).
Zie ook: https://en.wikipedia.org/wiki/Byte_order_mark
Character encoding (en ook wel character set of charset)
Dit identificeert de wijze waarop tekst op byteniveau staat opgeslagen, of opgeslagen zou moeten zijn. De encodering bepaalt tevens hoe deze bytes (elk karakter omvat een of meer bytes, de zogenaamde multibyte karakters) geïnterpreteerd dienen te worden als ze weer omgezet moeten worden in leesbare karakters op je scherm.
Als deze dus op een bepaalde wijze staan opgeslagen (zeg character encoding A) en je probeert deze vervolgens te serveren met een andere encoding (zeg encoding B), en er wordt geen (handmatige of automatische) omzetting uitgevoerd van A naar B, dan heb je dus stront op je scherm. Voor een computer hebben deze letters verder geen betekenis. Deze geeft ze enkel weer op de voorgeschreven wijze.
Ook kan het voorkomen dat teksten zijn opgeslagen met een verkeerde encodering, bijvoorbeeld omdat je voorheen vergat om set_charset('utf8') toe te voegen na het maken van een connectie. Op het moment dat je dit dus repareert (je een set_charset() aanroep toevoegt) wordt het pas evident dat de data in je database min of meer corrupt is.
MySQL kent verschillende multibyte encoderingen: utf8, utf8mb, utf16 et cetera. Dit zijn alle subsets van wat UTF-8 omvat. De subset bepaalt de maximum lengte (aantal bytes) van de toegestane symbolen. De ondersteunde charsets zou je kunnen opvragen met:
Code (php)
1
SHOW CHARACTER SET WHERE Charset LIKE 'utf%';
Hier (interne link) vind je nogmaals een uitleg, zij het op een wat andere manier, wat character encoderingen zijn en hoe je een en ander in goede banen kunt leiden.
Collations
Een collation bepaalt hoe karakters worden vergeleken (wanneer zijn symbolen equivalent) en gesorteerd
(welke symbolenreeks komt alfabetisch voor een andere symbolenreeks bij het sorteren op een tabelkolom). Dit zegt dus niets over hoe deze symbolen zijn geëncodeerd (in het geheugen staan opgeslagen).
Dat gezegd hebbende komt het mij nogal vreemd over dat je een collation instelt na het maken van een connectie. Als het goed is is deze namelijk al in je database-, tabel- en/of kolom-definitie opgenomen. En als deze op een bepaalde plek afwijkt van de default dan kun je in je query met behulp van COLLATE zelf aangeven hoe je tekst wenst te vergelijken of te sorteren.
Maar als je vraagtekens, of als je heel erg je best hebt gedaan van die wiebertjes, op je pagina hebt dan wil dat zeggen dat er dingen inhoudelijk mis zijn qua codering van je teksten. Ik neem aan dat alle tabeldefinities ook echt als utf8 of equivalent zijn aangemaakt?
Zonder details wordt dit nogal lastig om op te lossen omdat je eerst een analyse (debugging :p) moet maken van wat er aan de hand is, daarna kun je pas een remedie opstellen.
- Ariën - op 14/07/2019 21:43:17:
Met een ? vermoed ik dat je collatie niet klopt, en dat je een teken gebruikt die deze collatie niet kent. Gebruik eens: utf8mb4_general_ci
Nee, er is echt ergens iets mis met de data zelf, of hoe je deze benadert, of allebei. Dit heeft niets met collation te maken.
Gewijzigd op 14/07/2019 23:19:46 door Thomas van den Heuvel
heeft op moment niet mijn hoogste focus.... maar de tekentjes vallen op :-)... ze horen er per slot van rekening niet
- Ariën - op 14/07/2019 23:18:52:
gekloot met je coding
Dit is waarschijnlijk de voornaamste
Als je niet weet wat er misgaat, hoe kun je dan inschatten wat het effect van een verandering is? Wat ben je dan precies aan het repareren?
Gewijzigd op 14/07/2019 23:28:23 door Thomas van den Heuvel