Omgaan met exotische tekens

[Verwijderd]

Ik heb steeds gedoe met tekens zoals ö ş ã et cetera.

Ik had keurig netjes een php script geschreven dat een XML file moest uitlezen en waar nodig deze tekens moest vervangen door hun minder exotische variant, namelijk (in dit voorbeeld) o s a.

Gooi ik de boel op de server, worden de bovengenoemde tekens (ö ş ã) automatisch in DirectAdmin vervangen door de welbekende "veilige" html codes... waardoor mijn scriptje niet meer werkt.

Ja, wat doe je dan

Hoe gaan jullie om met dit soort gedoe?

Ik ben er onlangs achter gekomen dat je ook de encodings van je php scriptjes dient aan te passen als je echt wil dat alles goed wordt weergegeven (c.q. geëchood - wat een woord) , en niet slechts de encoding van de html pagina.

[Verwijderd]

Zorgen dat je gewoon precies weet wat je aan het doen bent. Zorg dat je weet welke encoding je bron heeft, welke encoding je server (webserver + script engine/programmeertaal), en dat alles op de juiste manier wordt vertaald indien nodig. Het mooist is natuurlijk zorgen dat alles UTF-8 is.

[Basz0r]

Ik had nog een site in m'n bookmarks staan die Encoding heel goed uitlegt, want dat is denk hetgeen wat je zoekt.

http://www.joelonsoftware.com/articles/Unicode.html

[Cartman!]

Verwijderd schreef op maandag 22 november 2010 @ 21:41:
...automatisch in DirectAdmin vervangen door de welbekende "veilige" html codes...

En waarom zou de software van je webhost er iets aan aanpassen, ik geen enkele reden waarom DirectAdmin aan je bestanden zou gaan komen. Gewoon uploaden met FTP en er gebeurt helemaal niks mee.

[Verwijderd]

Cartman! schreef op dinsdag 23 november 2010 @ 12:28:
[...]

En waarom zou de software van je webhost er iets aan aanpassen, ik geen enkele reden waarom DirectAdmin aan je bestanden zou gaan komen. Gewoon uploaden met FTP en er gebeurt helemaal niks mee.

Wablief?? Ik weet ook niet waarom DirectAdmin dat doet, maar m'n prachtig mooie script dat allerlei gekke tekens bevatte om die om te zetten was plots aangepast met allerlei &xxx; tekens ipv die eerder genoemde tekens.

[Cartman!]

Maar wanneer komt DirectAdmin aan jouw scripts dan? Je upload het met FTP, je bekijkt de pagina in je browser. Ik zie geen enkele stap DirectAdmin terugkomen.

[Herko_ter_Horst]

Waarschijnlijk denk je dat er iets met je files gebeurt juist vanwege een encoding issue. Dat DirectAdmin er aan zit lijkt mij de minst waarschijnlijke verklaring. Het kan zijn dat DA de files weergeeft met een verkeerde encoding (c.q. dat ie tekens in de HTML output escaped bij het weergeven) of dat je in je scripts uitgaat van de systeem default encoding die bij je webhost anders is dan bij je thuis.

De manier om te checken of DA echt iets met je files doet, is het bestand weer via FTP downloaden. Is het dan anders dan hoe het was toen je het uploade?

[ Voor 32% gewijzigd door Herko_ter_Horst op 24-11-2010 09:24 ]

[Verwijderd]

Cartman! schreef op woensdag 24 november 2010 @ 08:36:
Maar wanneer komt DirectAdmin aan jouw scripts dan? Je upload het met FTP, je bekijkt de pagina in je browser. Ik zie geen enkele stap DirectAdmin terugkomen.

Herko_ter_Horst schreef op woensdag 24 november 2010 @ 09:21:
Waarschijnlijk denk je dat er iets met je files gebeurt juist vanwege een encoding issue. Dat DirectAdmin er aan zit lijkt mij de minst waarschijnlijke verklaring. Het kan zijn dat DA de files weergeeft met een verkeerde encoding (c.q. dat ie tekens in de HTML output escaped bij het weergeven) of dat je in je scripts uitgaat van de systeem default encoding die bij je webhost anders is dan bij je thuis.

De manier om te checken of DA echt iets met je files doet, is het bestand weer via FTP downloaden. Is het dan anders dan hoe het was toen je het uploade?

Probleem opgelost.

Hoe dan ook, het ging iedere keer als volgt. Ik gebruik Notepad++ waar ik het nodige aan programmeersel maak en vervolgens op de WAMP server test. Vervolgens dacht ik, ik kopieer-plak de code uit Notepad++ op de online server via DirectAdmin i.p.v. ftp te gebruiken. DirectAdmin heeft namelijk een in-browser optie om pagina's aan te maken, te uploaden, te bewerken, op te slaan, et cetera. En deze gebruik ik nog wel eens.

Hoe dan ook, tijdens het 'plakken' ziet alle code er nog exact dezelfde uit. Wanneer ik de boel opsla, weer terugkeer naar het overzicht, en vervolgens weer op edit klik om de eerder genoemde pagina te bewerken, zie ik tot mijn grote verbazing dat die gekke tekens vervangen zijn door html codes. Hierdoor werkt het één en ander niet meer. Dat is het hele verhaal in een notendop.

Ik heb via Notepad++ het bestand met de ftp optie geüpload, en ja hoor, alles werkt picobello.

Zucht

[_Thanatos_]

Zorgen dat je alléén maar met unicode "rekent" en alléén naar UTF8 encoden zodra je de boel gaat opslaan in je database ofzo (en zelfs dat kan automagisch). Bij uitpoepen naar een client, altijd alle vormen van encodings en charsets op utf-8 gooien en dan gewoon outputten. Gaat vanzelf goed.

En zorg natuurlijk dat al je statische files, zoals css en javascript, ook UTF-8 zijn, anders gaat het alsnog naar de stront