[php] hoe formatering tekst bepalen? bijv.unicode

[red_indian]

korte uitleg:
ik zit met het probleem dat ik een tekst heb met speciale karakters. nu heb ik een functie gemaakt die netjes een 'é' omzet naar 'é'. als invoer gebruik ik een iframe in design mode in IE.

dit lijkt te werken, met de nadruk op lijkt.

als ik de tekst niet eerst 'utf8_decode()' gaat het niet goed. bij invoer vanaf een ENG-talige IE hoeft dit niet.

na wat spelen blijkt dat:
zelfs al lees/schrijf ik het eerst naar een tekstbestand, op één of andere manier blijft dit probleem zich voordoen.

bij de ene *moet* ik niet te encoden, bij de andere *moet* het wel.

vraag:
is het mogelijk om de formatering van een string te bepalen? danwel de formatering compleet te negeren?

* red_indian zit nl. al 2 uur op een dood spoor...

[ACM]

Als het goed is gebruikt IE gewoon de default charset die php meegeeft over de pagina
En wellicht kan je beter htmlentities() gebruiken

[Grum]

nu heb ik een functie gemaakt die netjes een 'é' omzet naar 'é'

Zonde van je tijd ...

http://php.net/htmlentities

[red_indian]

nee hoor. weet nl. wel dat die functie bestaat. maar mijn tekst bestaat ook uit html code. op zich zou ik dan > en < weer terug kunnen converten. ik pak gewoon alle ascii waardes boven de 127.

maar goed. het converteren is het probleem niet. de tekst ziet er na de ene conversie anders uit dan de andere. als tekst zie je in dezelfde string gewoon 'é' en verder op weer 'é', maar de ene wordt rare rotzooi en de andere gaat gewoon goed.

zal zo eens met een hexviewer het txt bestand bekijken.

[edit]
ik heb ook alle mogelijk <META> content-type's geprobeerd... helpt ook niets. dat vind ik nog wel het vreemdst, want je moet toch gewoon de formatering mee kunnen geven en dan een bepaalde formatering gebruiken?

[update]
grrrrrrr....

het probleem zit hem niet op dit niveau, maar op een lager data niveau gaat er iets mis. in het tekstbestand staat doodgewoon 'é' in beide gevallen. alleen de ene keer wordt dit een 'é' en de andere keer niet. nog vager dus. wij houden op de hoogte.

[Engineer]

.

[ Voor 100% gewijzigd door Engineer op 13-10-2018 11:46 ]

[red_indian]

het probleem lag ergens anders. sorrie en bedankt voor de reacties.

uiteindelijke reden lag aan mijn opslag, waardoor het leek dat dit aan codering lag. door utf-8 werd toevallig het verborgen karakter weggehaald gok ik.

hoe dan ook, wil je meer weten of heb je hetzelfde probleem, het ligt hieraan (incl. quick-fix): [topic=472214/1/25]