Vreemde tekens op website

[YoshiBignose]

Sinds een aantal maanden (volgens mij sinds een PHP update van de webhost) worden tekens als é en ö en € aangepast naar: �

Vroeger heb ik dit eens gehad en dat lag aan de charset. Ik veranderde dan de meta in de html code van de site:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

Soms was het ISO en soms UTF. Maar nu maakt het niet uit wat ik daar invul, ik blijf de vreemde tekens houden. De webhost zei dat het niet met PHP te maken kan hebben want ze hadden de website teruggezet naar oude PHP en toen was het er ook nog. Maar ik zou toch zweren dat ik het kreeg sinds die update.

Iemand enig idee wat het probleem kan zijn en hoe ik het oplos? Alles handmatig veranderen naar html codes gaat niet werken trouwens.

[bvk]

Ik kan er helemaal naast zitten, maar heeft dit er niet meer mee te maken dat je systeem ineens geen extended ASCII meer begrijpt?

[b2vjfvj75gjx7]

code:

é
ö
€

[Boelie-Boelie]

Ik heb ook wel eens problemen gehad met vreemde tekens gehad en het was een gigantisch karwei om het op te lossen. In mijn geval had WordPress besloten de charset te veranderen van de data die ze naar de database sturen. Dat was zinvol, maar databases die allang WP draaiden, stonden nog op de oude charset ingesteld, dus de data werd verkeerd opgeslagen, wat leidde tot vreemde tekens.

Indien het een databaseprobleem is, zou het volgende aan de hand kunnen zijn: de data kan in een verkeerde charset naar de database worden verstuurd, de database kan ingesteld zijn op een verkeerde charset, de tabellen kunnen staan ingesteld zijn op een verkeerde charset, de kolommen ook. Het is niet onwaarschijnlijk dat je combinaties van alles hierboven hebt.

In mijn geval heb ik met heel veel test-runs een script kunnen maken waarmee de kolommen en tabellen werden omgezet naar de juiste charset, vreemde kakakters zoveel mogelijk werden omgezet naar een UTF-8-kakakter, daarna de inhoud omgezet naar 'blobs', om ze daarna te converteren naar de gewenste charset. Ook het cms geconfigureerd naar de juiste charset. Uiteraard eerst op een test-database gedaan.

Ik volgde dit proces:
https://codex.wordpress.o...g_Database_Character_Sets
En deze zoekquery's: https://stackoverflow.com...-database-table-column-is

[YoshiBignose]

Boelie-Boelie schreef op donderdag 29 december 2016 @ 19:19:
Ik heb ook wel eens problemen gehad met vreemde tekens gehad en het was een gigantisch karwei om het op te lossen. In mijn geval had WordPress besloten de charset te veranderen van de data die ze naar de database sturen. Dat was zinvol, maar databases die allang WP draaiden, stonden nog op de oude charset ingesteld, dus de data werd verkeerd opgeslagen, wat leidde tot vreemde tekens.

Indien het een databaseprobleem is, zou het volgende aan de hand kunnen zijn: de data kan in een verkeerde charset naar de database worden verstuurd, de database kan ingesteld zijn op een verkeerde charset, de tabellen kunnen staan ingesteld zijn op een verkeerde charset, de kolommen ook. Het is niet onwaarschijnlijk dat je combinaties van alles hierboven hebt.

In mijn geval heb ik met heel veel test-runs een script kunnen maken waarmee de kolommen en tabellen werden omgezet naar de juiste charset, vreemde kakakters zoveel mogelijk werden omgezet naar een UTF-8-kakakter, daarna de inhoud omgezet naar 'blobs', om ze daarna te converteren naar de gewenste charset. Ook het cms geconfigureerd naar de juiste charset. Uiteraard eerst op een test-database gedaan.

Ik volgde dit proces:
https://codex.wordpress.o...g_Database_Character_Sets
En deze zoekquery's: https://stackoverflow.com...-database-table-column-is

Het zijn eigenlijk vrij eenvoudige html/php sites. Geen WP/Joomla en dus ook geen mysql.

bvk schreef op donderdag 29 december 2016 @ 18:49:
Ik kan er helemaal naast zitten, maar heeft dit er niet meer mee te maken dat je systeem ineens geen extended ASCII meer begrijpt?

Wat wil dat zeggen?

b2vjfvj75gjx7 schreef op donderdag 29 december 2016 @ 18:51:

code:

é
ö
€

Nogmaals handmatig veranderen is teveel werk. En dit zou ook niet hoeven...

[ Voor 6% gewijzigd door YoshiBignose op 29-12-2016 19:27 ]

[bvk]

YoshiBignose schreef op donderdag 29 december 2016 @ 19:27:
[...]


Wat wil dat zeggen?

Leesvoer....

Wikipedia: Extended ASCII

http://www.ascii-code.com/

[TommyboyNL]

YoshiBignose schreef op donderdag 29 december 2016 @ 19:27:
Nogmaals handmatig veranderen is teveel werk. En dit zou ook niet hoeven...

Dan beun je een script in elkaar dat dat voor je doet?

[YoshiBignose]

TommyboyNL schreef op donderdag 29 december 2016 @ 19:38:
[...]

Dan beun je een script in elkaar dat dat voor je doet?

Zucht echt waar dat is je antwoord? Ik heb zat sites waarbij het gewoon werkt en ik kan me niet voorstellen dat mensen constant é gaan typen in hun verhalen. Het moet gewoon kunnen, dus liever dat iemand met verstand ervan reageert dan dit soort advies.

[TommyboyNL]

YoshiBignose schreef op donderdag 29 december 2016 @ 19:50:
Ik heb zat sites waarbij het gewoon werkt en ik kan me niet voorstellen dat mensen constant é gaan typen in hun verhalen.

Dan configureer je je niet-werkende site toch het zelfde als je wel-werkende sites? Probleem opgelost.

[Cartman!]

Nee, nee, nee...wat een antwoorden tot nu toe

https://www.joelonsoftwar...haracter-sets-no-excuses/

Je moet simpelweg zorgen dat elke verbinding/script ingesteld is dat het UTF-8 is.

[ Voor 9% gewijzigd door Cartman! op 29-12-2016 22:28 ]

[RobIII]

Cartman! schreef op donderdag 29 december 2016 @ 22:19:
Nee, nee, nee...wat een antwoorden tot nu toe

https://www.joelonsoftwar...haracter-sets-no-excuses/

Ik kwam precies hetzelfde zeggen. De antwoorden tot dusver zitten er aardig naast.

Controleer de charset van je php/html bestanden, de charset in je http headers, de charset van je DB connectie én de collation van je DB. Dat zijn de 4 meest voorkomende fouten en pas een miljoenmiljard keer hier eerder behandeld (gebruik de search eens...).

Maar éérst die link lezen!

[ Voor 24% gewijzigd door RobIII op 29-12-2016 22:48 ]

[NMe]

YoshiBignose schreef op donderdag 29 december 2016 @ 19:50:
[...]


Zucht echt waar dat is je antwoord? Ik heb zat sites waarbij het gewoon werkt en ik kan me niet voorstellen dat mensen constant é gaan typen in hun verhalen. Het moet gewoon kunnen, dus liever dat iemand met verstand ervan reageert dan dit soort advies.

Even los van wat de twee heren boven mij terecht zeggen: is dit nou serieus de houding die je jezelf wil aanmeten tegenover mensen die proberen je te helpen? Doe eens even normaal...

Sowieso heeft ook hij gelijk, als er nu een é in je code staat zonder &eacute; dan is dat aardig fout en heb jij in je PHP-code de fout gemaakt om HTML-entities niet te vertalen...

[RobIII]

NMe schreef op vrijdag 30 december 2016 @ 11:39:
[...]
dan is dat aardig fout en heb jij in je PHP-code de fout gemaakt om HTML-entities niet te vertalen...

Nou ja "fout"... met de juiste encoding/charset overal heb je die entities niet écht nodig natuurlijk (maar het kan geen kwaad en is natuurlijk altijd handig als éxtra maatregel). (Los van escaping uiteraard!)

[DJMaze]

De unicode 🛅 (Emoji Left luggage) wordt op deze website ook opgeslagen als &#128709;
En dat ligt aan de charset (charset=ISO-8859-15)

Daarnaast kan MySQL "utf8" maar 3 bytes aan! Je hebt utf8mb4 charset nodig.

[Caelorum]

RobIII schreef op vrijdag 30 december 2016 @ 11:52:
[...]

Nou ja "fout"... met de juiste encoding/charset overal heb je die entities niet écht nodig natuurlijk (maar het kan geen kwaad en is natuurlijk altijd handig als éxtra maatregel). (Los van escaping uiteraard!)

Achja, fout is zo gemaakt natuurlijk. Hoe vaak ik wel niet een batch-operatie heb gedaan waardoor alle bestanden een andere encoding kregen. Vervolgens niet doorhebben en collega's later vloeken. Uiteindelijk zagen ze toch maar het licht door ze html-encoded op te slaan in de diverse bestanden (in de database ging overigens alles wel goed).
Het was wat werk om al die websites af te lopen, maar het probleem kan zich iig niet meer voordoen.

[Cartman!]

Caelorum schreef op vrijdag 30 december 2016 @ 17:09:
[...]
Uiteindelijk zagen ze toch maar het licht door ze html-encoded op te slaan in de diverse bestanden (in de database ging overigens alles wel goed).

Het is slechts symptoonbestrijding, als je denkt dat omzetten naar entities "het licht zien" is dan raad ik je aan het artikel wat ik hierboven gelinkt even te lezen.

[Compizfox]

Als je gewoon overal UTF-8 gebruikt, dus:

• Als daadwerkelijke character set van je bestanden
• In de meta tag
• In je database

Dan zou het goed moeten gaan. Mijn vermoeden is dus dat in één van bovenstaande punten je een andere charset gebruikt. Je bestanden zijn bijvoorbeeld niet in UTF-8 terwijl je de browser wel vertelt dat ze UTF-8 zijn.

De correcte meta tag in HTML5 is trouwens:

HTML:

<meta charset="utf-8">

---

NMe schreef op vrijdag 30 december 2016 @ 11:39:
[...]

Sowieso heeft ook hij gelijk, als er nu een é in je code staat zonder &eacute; dan is dat aardig fout en heb jij in je PHP-code de fout gemaakt om HTML-entities niet te vertalen...

Dat is helemaal niet fout. Je hoeft niet per se alles naar htmlentities om te zetten. We leven bijna in 2017, het is tegenwoordig gewoon mogelijk om Unicode in HTML te gebruiken hoor...

Het is alleen verplicht als je character in je tekst hebt die een speciale betekenis hebben in HTML, zoals &, <, >, ", enz. Die moet je wel verplicht omzetten naar HTML entities.

Maar een é kun je prima als UTF-8 in je code hebben staan.

[ Voor 59% gewijzigd door Compizfox op 30-12-2016 19:02 ]

[Caelorum]

Cartman! schreef op vrijdag 30 december 2016 @ 18:50:
[...]

Het is slechts symptoonbestrijding, als je denkt dat omzetten naar entities "het licht zien" is dan raad ik je aan het artikel wat ik hierboven gelinkt even te lezen.

Mwoah, als je denkt dat we geen charset opgeven dan wel ja. Als je denkt dat we nooit alles opslaan in de database als UTF-8 wel. Het ging hier echt op de file encoding mis en nou zouden we uiteraard een precommit hook kunnen aanmaken in onze vcs, maar of je daar zo blij van wordt. Dan limiteer je meteen je ontwikkelaar in de tooling die ze kunnen gebruiken + de encoding van het bestand zou gewoon simpelweg niet moeten uitmaken voor wat er uiteindelijk aan de client wordt geserveerd. Al sla ik het op in een eigengemaakte encoding, zolang de webserver het kan lezen en kan outputten in de goede encoding is alles ok.
Het ging hier overigens nog niet eens over obscure editors die alles op zijn plaat lieten gaan. Eigenlijk alles dat niet UTF-8 met BOM ondersteunt maakt alles kapot, daar vallen een hoop populaire editors onder.

[Compizfox]

Caelorum schreef op vrijdag 30 december 2016 @ 19:26:
[...]

Mwoah, als je denkt dat we geen charset opgeven dan wel ja. Als je denkt dat we nooit alles opslaan in de database als UTF-8 wel. Het ging hier echt op de file encoding mis en nou zouden we uiteraard een precommit hook kunnen aanmaken in onze vcs, maar of je daar zo blij van wordt. Dan limiteer je meteen je ontwikkelaar in de tooling die ze kunnen gebruiken + de encoding van het bestand zou gewoon simpelweg niet moeten uitmaken voor wat er uiteindelijk aan de client wordt geserveerd. Al sla ik het op in een eigengemaakte encoding, zolang de webserver het kan lezen en kan outputten in de goede encoding is alles ok.
Het ging hier overigens nog niet eens over obscure editors die alles op zijn plaat lieten gaan. Eigenlijk alles dat niet UTF-8 met BOM ondersteunt maakt alles kapot, daar vallen een hoop populaire editors onder.

Ik kan me eigenlijk geen hedendaagse editor/IDE/tool voorstellen die geen UTF-8 ondersteunt.

Met BOM weet ik dan weer niet precies, maar waarom gebruik je überhaupt UTF-8 met BOM dan? Het wordt over het algemeen afgeraden om BOM te gebruiken met UTF-8.

[Cartman!]

Caelorum schreef op vrijdag 30 december 2016 @ 19:26:
[...]
<verhaal>

Je post komt over als "sla alles op met entities dan is het altijd goed" terwijl dat gewoon een heel slecht advies is. Handig alles als entities, wil je t een keer ergens anders dan html outputten en dan kun je alles terug omzetten Alles gewoon als UTF-8 opslaan en je bent er gewoon zonder rare fratsen. Noem eens een paar editors die niet goed kunnen omgaan met UTF-8?

[Caelorum]

Compizfox schreef op vrijdag 30 december 2016 @ 19:29:
[...]
Ik kan me eigenlijk geen hedendaagse editor/IDE/tool voorstellen die geen UTF-8 ondersteunt.

Met BOM weet ik dan weer niet precies, maar waarom gebruik je überhaupt UTF-8 met BOM dan? Het wordt over het algemeen afgeraden om BOM te gebruiken met UTF-8.

Ja, ik weet het maar zeg dat tegen MS...
Maar we gaan wat offtopic hier. Het punt dat ik wilde maken was dat het én niet zo veel werk is als het lijkt en dat het in sommige situaties nog behoorlijk zinvol is om te doen ook.

Cartman! schreef op vrijdag 30 december 2016 @ 19:45:
[...]

Je post komt over als "sla alles op met entities dan is het altijd goed" terwijl dat gewoon een heel slecht advies is. Handig alles als entities, wil je t een keer ergens anders dan html outputten en dan kun je alles terug omzetten Alles gewoon als UTF-8 opslaan en je bent er gewoon zonder rare fratsen. Noem eens een paar editors die niet goed kunnen omgaan met UTF-8?

Ah handig hoe je er dingen bij verzint. Zeg eens: in welk universum is het zinnig om een template-bestand dat voor html-output bedoelt is in te zetten voor iets anders? (in dit geval aspx en ascx-betanden voor html-output)
en ik heb het hier over UTf-8 met BOM. Iets dat ongelooflijk onzinnig is, maar helaas wel moet in dit geval en om een editor te noemen: VS Code, Atom, en zo nog wel een paar.

[ Voor 42% gewijzigd door Caelorum op 30-12-2016 19:49 ]

[Cartman!]

Caelorum schreef op vrijdag 30 december 2016 @ 19:46:
Ah handig hoe je er dingen bij verzint. Zeg eens: in welk universum is het zinnig om een template-bestand dat voor html-output bedoelt is in te zetten voor iets anders? (in dit geval aspx en ascx-betanden voor html-output)

Misschien bijvoorbeeld de data later ook willen exporteren als pdf om maar iets te noemen.

en ik heb het hier over UTf-8 met BOM. Iets dat ongelooflijk onzinnig is, maar helaas wel moet in dit geval en om een editor te noemen: VS Code, Atom, en zo nog wel een paar.

Gewoon geen BOM gebruiken zoals overal wordt geadviseerd.

[Caelorum]

Cartman! schreef op vrijdag 30 december 2016 @ 20:01:
[...]

Misschien bijvoorbeeld de data later ook willen exporteren als pdf om maar iets te noemen.
[...]

En daar gebruik je niet een apart template voor, maar de template die je specifiek hebt gemaakt voor html? Handig...

[...]Gewoon geen BOM gebruiken zoals overal wordt geadviseerd.

Weet je hoeveel werk en hoe foutgevoelig dat is met visual studio? Een bestand dat is opgeslagen in UTF8 zonder BOM, buiten VS word bij het opslaan in VS standaard omgezet naar met BOM. Dat is al genoeg om problemen te veroorzaken.

---

Maar dit wijkt nu echt zo zwaar van de originele vraag af, dat we beter via PM of in een apart topic verder kunnen discussieren.

[ Voor 9% gewijzigd door Caelorum op 30-12-2016 20:19 ]

[Cartman!]

Caelorum schreef op vrijdag 30 december 2016 @ 20:18:
En daar gebruik je niet een apart template voor, maar de template die je specifiek hebt gemaakt voor html? Handig...

Als je dezelfde templates kunt gebruiken is dat een heel stuk relaxter natuurlijk, copy/paste is slecht nietwaar?

Weet je hoeveel werk en hoe foutgevoelig dat is met visual studio? Een bestand dat is opgeslagen in UTF8 zonder BOM, buiten VS word bij het opslaan in VS standaard omgezet naar met BOM. Dat is al genoeg om problemen te veroorzaken.

Ik kan alleen maar zeggen dat de tijd dat een BOM me in de weg zat minstens 5 jaar geleden is maar dat zal ongetwijfeld aan mij liggen.

---

Maar dit wijkt nu echt zo zwaar van de originele vraag af, dat we beter via PM of in een apart topic verder kunnen discussieren.

Ik denk dat het best relevant is eigenlijk. De TS heeft moeite met encodings, de oplossing is simpel: gewoon overal dezelfde encoding gebruiken. Jij betwist dat blijkbaar door het opslaan van entities te adviseren en ik zou graag willen dat het topic eindigt met de conclusie dat het toch echt beter is gewoon de goede encodings te gebruiken.

[Caelorum]

Cartman! schreef op vrijdag 30 december 2016 @ 20:25:
[...]

Als je dezelfde templates kunt gebruiken is dat een heel stuk relaxter natuurlijk, copy/paste is slecht nietwaar? [...]

Ik ben het in het geval van html-templates nog niet tegengekomen. Vrijwel altijd wil je voor pdf een andere opzet hebben, maar dat kan ook aan mij liggen.

Verder is het uiteraard altijd een goed idee om altijd dezelfde encodings te gebruiken, maar dat wil niet zeggen dat opslaan met html-entities daar waar het zeker om html-output gaat gewoon ook een goed idee is. Als je data hebt die mogelijkerwijs in de toekomst niet alleen in html wordt gebruikt zou ik het niet doen, maar soms weet je het van te voren gewoon en daar kan je maar beter wel html entities gebruiken om eerder genoemde reden. (een foutje bij het opslaan is namelijk zo gemaakt)

[crisp]

DJMaze schreef op vrijdag 30 december 2016 @ 14:53:
De unicode 🛅 (Emoji Left luggage) wordt op deze website ook opgeslagen als &#128709;
En dat ligt aan de charset (charset=ISO-8859-15)

Dat klopt, legacy is een bitch. We willen dolgraag overstappen op unicode maar dat is een behoorlijke operatie met al onze content...

[Cartman!]

Caelorum schreef op vrijdag 30 december 2016 @ 20:38:
[...]
maar dat wil niet zeggen dat opslaan met html-entities daar waar het zeker om html-output gaat gewoon ook een goed idee is.

Dan zijn we het simpelweg niet eens Ik zie er geen voordeel (en wel nadeel) in dit te doen als je gewoon UTF8 kunt opslaan.

[YoshiBignose]

Nou uiteindelijk inderdaad opgelost... blijkbaar zijn m'n html/php bestanden geen UTF 8. Nooit geweten hoe of waar je dat in kan stellen, maar als ik via kladblok het bestand opnieuw opsla en bij codering dan kies voor UTF8 ipv ANSI is het opgelost. Ik las dat in notepad++ dit makkelijker gaat dus dat ga ik maar even proberen.

Toch vreemd dat ik dit probleem vroeger nooit heb gehad bij al deze sites.

[Compizfox]

YoshiBignose schreef op vrijdag 30 december 2016 @ 21:52:
Nou uiteindelijk inderdaad opgelost... blijkbaar zijn m'n html/php bestanden geen UTF 8.

Dacht ik het niet

[DJMaze]

YoshiBignose schreef op vrijdag 30 december 2016 @ 21:52:
als ik via kladblok het bestand opnieuw opsla en bij codering dan kies voor UTF8 ipv ANSI is het opgelost.

Helaas is dat niet de oplossing!
Er wordt dan een BOM (Byte Order Mark) opgeslagen in het bestand en dat werkt niet goed op internet.

Ik heb de afgelopen 15 jaar echt iedereen afgeraden om te werken met Notepad, dus nu ook

[YoshiBignose]

Er staat ook UTF8 zonder BOM. Moet ik die doen? Het lijkt gewoon prima te werken dus geen idee wat het verschil is

[Caelorum]

YoshiBignose schreef op zaterdag 31 december 2016 @ 15:20:
Er staat ook UTF8 zonder BOM. Moet ik die doen? Het lijkt gewoon prima te werken dus geen idee wat het verschil is

Altijd zonder BOM kiezen zelfs als het niet meteen problemen oplevert. Je komt altijd tooling tegen die BOM niet leuk vind met UTF-8 (ook al is het gewoon valide).

[DJMaze]

YoshiBignose schreef op zaterdag 31 december 2016 @ 15:20:
geen idee wat het verschil is

De eerste 2 bytes van je bestand

[YoshiBignose]

Ik heb het doorgelezen en snap het nog steeds niet maar goed m'n site laat nu geen rare tekens meer zien dus dat is het enige dat mij interesseert.

[ Voor 47% gewijzigd door YoshiBignose op 31-12-2016 18:40 ]

[YoshiBignose]

Even een kickje omdat de vraag gerelateerd is. Misschien weet iemand wel weer het juiste antwoord. Ik heb bij een andere site dit probleem nog, maar de tekst komt hier uit een MYSQL database. Zoals ik ook las in de links die jullie gaven moet het daar ook op utf 8 staan.

In mijn phpmyadmin staat utf8_general_ci en ook in de sql file bij een export zie ik CHARSET=utf8 staan. Op m'n html/php pagina's staat utf8. Ik heb voor de zekerheid de teksten in phpmyadmin nog even gekopieerd geplakt vanuit notepad++ met charset utf8 en dat staat ook goed. De server is dezelfde als m'n andere site waar het werkt dus ik ga ervanuit dat in de php.ini ook utf8 goed staat ingesteld. Wat mis ik dan nog? Want krijg dus nog steeds die vraagtekentjes bij ' en `

[NMe]

Je connectie naar MySQL toe.