Hallo, ik heb een site gemaakt met een soort content manager, de gebruikers kunnen op de adminpagina een form invullen en vervolgens komt de inhoud van het form in een MySQL db. Wat men heeft getypt komt op de site te staan, bijvoorbeeld in nieuws, events, etc.
Het probleem is nu dat als ik een stukje text uit MSWord kopieer in het formulier (dat doen gebruikers, uiteraard!) dat allerlei tekens zoals ⌐ (Unicode, i guess?) in mijn database terecht komen. geen punt, IE zet die code wel weer om in het werkelijk bedoelde unicode teken, maar ik kan die tekst uit de db natuurlijk niet zomaar in een html pagina pleuren. voordat ik iets in een html pagina neerzet gebruik ik eerst
zodat ik zeker weet dat alle ongeldige tekens worden ge-htmlentitied. Bijvoorbeeld, als een gebruiker html tags in zijn post zet, worden die html tags inactief gemaakt. Maar htmlentities() maakt ook het gecodeerde Unicode karakter inactief
dus dan krijg ik bijvoorbeeld dit op mijn nieuws pagina:
...blabla met de titel “blabla” is bla bla....
terwijl ik dit bedoelde:
...blabla met de titel “blabla” is bla bla....
nu heb ik twee oplossingen in gedachten, maar beide is het vreselijk, ik hoop dat iemand een beter idee heeft, of hopelijk ervaring hiermee.
1) ik loop alle post data langs met een preg_match om %nnnn; te vinden en alle herkende &#nnnn; zet ik met een soort mapping-tabel om in een gelijkend us-ascii teken. probleem: hoe maak ik een tabel met ALLE unicode karakters en ALLE juiste alternatieven? Mij te veel werk, niet te doen!
2) ik probeer echte Unicode ondersteuning in te bouwen in de site+content manager. dat betekent: _alle_ html forms krijgen de tag accept-charset="UTF-8" zodat de browser Unicode content verstuurd ipv standaard us-ascii. de POST data sla ik gewoon op in de database. die post data bevat dus multibyte characters. als ik vervolgens de text uit de db weer in een html pagina zet, dan zeg ik:
De HTML pagina moet dan vervolgens nog dit krijgen:
en dan komen netjes alle unicode chars in mijn html pagina's!
proble(e)m(en): 1- de database slaat multibyte chars op, dus als ik een varchar(100) heb, dan is dat dus 100 chars, _zonder_ unicode van MSWord, maar als er 10 unicode chars instaan, dan werkt de varchar(100) eigenlijk als varchar(90)
2- alle normale string functies van PHP werken niet goed met multibyte chars.
3- wie garandeert dat ik post data nu nog wel met reg expressies kan controleren? die reg expr werken volgens mij ook niet met unicode.
4- een hele hele berg extra werk voor mij, met heel veel kans op fouten.
plzzzz, wie heeft er een betere oplossing of wat suggesties.
P.S.: een test of het bij GoT kan: “hoi” (hoi staat tussen openende en sluitende aanhalingstekens, gekopieerd vanuit wordXP. en dat blijkt redelijk te werken op GoT, Adjes wie heeft GoT geprogrammeerd??)
Het probleem is nu dat als ik een stukje text uit MSWord kopieer in het formulier (dat doen gebruikers, uiteraard!) dat allerlei tekens zoals ⌐ (Unicode, i guess?) in mijn database terecht komen. geen punt, IE zet die code wel weer om in het werkelijk bedoelde unicode teken, maar ik kan die tekst uit de db natuurlijk niet zomaar in een html pagina pleuren. voordat ik iets in een html pagina neerzet gebruik ik eerst
PHP:
1
2
| $str = htmlentities($str); echo $str; |
zodat ik zeker weet dat alle ongeldige tekens worden ge-htmlentitied. Bijvoorbeeld, als een gebruiker html tags in zijn post zet, worden die html tags inactief gemaakt. Maar htmlentities() maakt ook het gecodeerde Unicode karakter inactief
...blabla met de titel “blabla” is bla bla....
terwijl ik dit bedoelde:
...blabla met de titel “blabla” is bla bla....
nu heb ik twee oplossingen in gedachten, maar beide is het vreselijk, ik hoop dat iemand een beter idee heeft, of hopelijk ervaring hiermee.
1) ik loop alle post data langs met een preg_match om %nnnn; te vinden en alle herkende &#nnnn; zet ik met een soort mapping-tabel om in een gelijkend us-ascii teken. probleem: hoe maak ik een tabel met ALLE unicode karakters en ALLE juiste alternatieven? Mij te veel werk, niet te doen!
2) ik probeer echte Unicode ondersteuning in te bouwen in de site+content manager. dat betekent: _alle_ html forms krijgen de tag accept-charset="UTF-8" zodat de browser Unicode content verstuurd ipv standaard us-ascii. de POST data sla ik gewoon op in de database. die post data bevat dus multibyte characters. als ik vervolgens de text uit de db weer in een html pagina zet, dan zeg ik:
PHP:
1
2
| $str = htmlentities($str, ENT_COMPAT, "UTF-8"); echo $str; |
De HTML pagina moet dan vervolgens nog dit krijgen:
code:
1
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
en dan komen netjes alle unicode chars in mijn html pagina's!
proble(e)m(en): 1- de database slaat multibyte chars op, dus als ik een varchar(100) heb, dan is dat dus 100 chars, _zonder_ unicode van MSWord, maar als er 10 unicode chars instaan, dan werkt de varchar(100) eigenlijk als varchar(90)
2- alle normale string functies van PHP werken niet goed met multibyte chars.
3- wie garandeert dat ik post data nu nog wel met reg expressies kan controleren? die reg expr werken volgens mij ook niet met unicode.
4- een hele hele berg extra werk voor mij, met heel veel kans op fouten.
plzzzz, wie heeft er een betere oplossing of wat suggesties.
P.S.: een test of het bij GoT kan: “hoi” (hoi staat tussen openende en sluitende aanhalingstekens, gekopieerd vanuit wordXP. en dat blijkt redelijk te werken op GoT, Adjes wie heeft GoT geprogrammeerd??)
edit:
nog een foutje 2x zelfs
nog een foutje 2x zelfs
[ Voor 4% gewijzigd door Verwijderd op 23-05-2003 10:16 ]