[PHP/ACCESS] 'ñ' karakter wil niet veranderd worden

[Belindo]

Ik zit met een raar probleem. Het begon met Highcharts die niet wilde exporteren, later bleek dat dit kwam doordat er een speciaal karakter in de grafiek stond. Een van de namen bevat namelijk de 'ñ'.

Namen komen uit een Access database.

M'n eerste gedachte was om dus de 'ñ' te vervangen door een 'n', door middel van:

PHP:

$naam = str_replace("ñ","n",$naam)

Dit gaf geen resultaat. Wanneer ik op dezelfde manier bijvoorbeeld een 'e' voor een 'x' verving, zag ik wel resultaat.

Na wat rondzoeken op Google heb ik een aantal dingen geprobeerd, waaronder de Charset vervangen (werkte niet).

PHP:

$naam = strtr($naam, "ñ", "n");

Werkt ook niet.

Ook oplossingen om met een array alle speciala characters te vervangen werkt niet. Kortom, de top 20 oplossingen van Google mbt. 'replace character' werken geen van allen.

Het wordt alleen nog gekker, wanneer ik handmatig een 'ñ' toevoeg aan de naam, wordt deze wél correct vervangen door een 'n':

PHP:

$naam = 'ñ_'.$naam;
$naam = str_replace("ñ","n",$naam)

Resulteert in 'n_niño'.

Waarom wordt die eerste 'ñ' wel vervangen, maar de 'ñ' in de naam die uit de database komt niet?

[ACM]

Belindo schreef op zondag 21 september 2014 @ 10:24:
Na wat rondzoeken op Google heb ik een aantal dingen geprobeerd, waaronder de Charset vervangen (werkte niet).

Hoe zeker ben je ervan dat je dit goed deed? Wat voor charset heeft de data in je Access-database?
Heb je de charset van je code veranderd of van de string die je terugkreeg uit Access?
Weet je zeker dat er een ñ in je Access-database staat en niet een html-encoded entity die je over het hoofd ziet omdat je naar html print?

[RobIII]

^ Dat en een linkje naar The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

En hoe zeker zijn we er van dat 't gaat om een ñ (ASCII 241 / 0xF1) en niet om een combining character: ñ (ofwel n + ̃ / n + ̃)?

Verder vind ik de ñ (eender welke variant) vervangen door n nogal lomp; je kunt veel beter zorgen dat je je encodings / charsets op orde hebt dan heb je het probleem helemaal niet en loop je bij een volgende keer dat er een é of õ of ☃ in je DB zit niet weer tegen 'tzelfde probleem aan

[ Voor 24% gewijzigd door RobIII op 21-09-2014 11:23 ]

[Belindo]

Als ik de Access database bekijk zie ik daarin ook een 'ñ' in de record staan.

De charset heb ik veranderd in de HTML head. Van ISO-8859-1 naar UTF-8. De 'ñ' veranderde toen in een '�'. Ik begrijp dat dat niet de bedoeling is.

Wanneer ik nu de string uit de database verander naar bijv. UTF-8, Krijg ik in nu 'nin�o' in plaats van 'niño'. Dit doe ik door middel van

PHP:

htmlspecialchars($mystr, ENT_SUBSTITUTE, "UTF-8")

(via Google). De Highcharts exporteert nu wél. Maar de naam is natuurlijk nog niet goed zo.

Wanneer ik echter een zelf getypte ñ toevoeg aan $mystr, vertaalt deze in bovenstaand voorbeeld naar een ñ

Er zit dus duidelijk verschil tussen een hardcoded ñ en de ñ die uit de database komt.

Ik ben niet van plan alleen de ñ te vervangen door een n, maar gelijk rekening te houden met andere characters (voor als er een André bijkomt bijvoorbeeld). Alleen wil ik dan wel begrijpen waarom ik in dit voorbeeld de ñ niet kan vervangen.

Edit: ik zie in m'n grafiek nu dus 'nin�o' staan, maar in de .PNG die ik exporteer staat er 'ni�o'. Lijkt erop dat Highcharts ook nog een en ander veranderd?

[ Voor 8% gewijzigd door Belindo op 21-09-2014 12:22 ]

[RobIII]

Belindo schreef op zondag 21 september 2014 @ 12:21:
Als ik de Access database bekijk zie ik daarin ook een 'ñ' in de record staan.

Hoe zie jij 't verschil tussen ñ en ñ ?

Again: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Wat je nu doet is de shotgun approach: in 't wilde weg zaken aanpassen en hopen dat er iets werkt. Zo werkt 't niet en krijg je 't nooit goed. Loop alles methodisch na; je DB, je code, de encodings van je code (en dus ook .js files e.d.), de HTTP headers die je stuurt, META tags (die had je al gevonden) met charsets enz. Er zijn téveel factoren om maar in 't wilde weg wat aan te gaan lopen klooien. En als je dan een combinatie vindt die (toevallig) lijkt te werken heb je over twee weken weer hetzelfde probleem.

[ Voor 13% gewijzigd door RobIII op 21-09-2014 12:30 ]

[Verwijderd]

Een vriendin van mij met een spaanse achternaam met zo'n golfje boven op de n stond ook doodleuk op haar ID en paspoort een vraagtegen. haha Dus ñ werd: ?
Waarschijnlijk had de overheid hetzelfde soort probleem met die karakter.

[alienfruit]

Kan je het onderstaande niet doen als je letters wilt romanizen (of transliteration) ?

PHP:

$results = iconv("UTF_8", "ISO-8859-1//TRANSLIT", $str)

[Woy]

Heeft str_replace in PHP uberhaupt wel support voor UTF-8 of multi byte characters? Als ik dit zie: http://php.net/manual/en/ref.mbstring.php vermoed ik van niet.

edit:
Als ik de comments zie, zou dat niet het probleem moeten zijn

Please note that all the discussion about mb_str_replace in the comments is pretty pointless. str_replace works just fine with multibyte strings

[ Voor 41% gewijzigd door Woy op 22-09-2014 15:05 ]

[HuHu]

Woy schreef op maandag 22 september 2014 @ 15:03:
Heeft str_replace in PHP uberhaupt wel support voor UTF-8 of multi byte characters? Als ik dit zie: http://php.net/manual/en/ref.mbstring.php vermoed ik van niet.

Bovenste comment op die pagina:

Please note that all the discussion about mb_str_replace in the comments is pretty pointless. str_replace works just fine with multibyte strings

En ja: str_replace werkt gewoon en er is geen speciale mb_ variant voor nodig. Maar het vervangt alleen tekens die exact hetzelfde zijn. Zoals RobIII hierboven al zegt zijn er meerdere mogelijkheden om het karakter ñ te maken en de ene matched niet op de andere.

[Woy]

HuHu schreef op maandag 22 september 2014 @ 15:05:
[...]

Bovenste comment op die pagina:


[...]


En ja: str_replace werkt gewoon en er is geen speciale mb_ variant voor nodig. Maar het vervangt alleen tekens die exact hetzelfde zijn. Zoals RobIII hierboven al zegt zijn er meerdere mogelijkheden om het karakter ñ te maken en de ene matched niet op de andere.

Dat had ik inderdaad al in mijn post erbij geëdit

[MSalters]

HuHu schreef op maandag 22 september 2014 @ 15:05:
[...]
En ja: str_replace werkt gewoon en er is geen speciale mb_ variant voor nodig. Maar het vervangt alleen tekens die exact hetzelfde zijn. Zoals RobIII hierboven al zegt zijn er meerdere mogelijkheden om het karakter ñ te maken en de ene matched niet op de andere.

Tsja, volgens Unicode is ñ gelijk aan ñ. De TS heeft wat dat betreft redelijke verwachtingen. Encodings zijn een detail wat een high-level functie als "Replace( )" zou moeten afschermen. (Het zou een ander verhaal zijn als je het hebt over low-level functies als zeg " TransformToNFC" die expliciet over encodings gaan)

Waar het fout gaat is in het gebruik van niet-Unicode functies zoals PHP's str_replace.

[Voutloos]

En voor 't bewijs: http://3v4l.org/ISU7A

Sinds 4.3.0 wordt de enkele char al prima vervangen, maar de combined versie niet.

RobIII schreef op zondag 21 september 2014 @ 11:19:
Verder vind ik de ñ (eender welke variant) vervangen door n nogal lomp; je kunt veel beter zorgen dat je je encodings / charsets op orde hebt dan heb je het probleem helemaal niet en loop je bij een volgende keer dat er een é of õ of ☃ in je DB zit niet weer tegen 'tzelfde probleem aan

Dit.

Dit soort replacements is symptoombestrijding.

[Belindo]

Bedankt voor alle reacties. Zoals eerder aangegeven ligt het probleem waarschijnlijk in de verschillende charsets.

Kleine beschrijving van het proces:
Via een webpagina koppel ik fout geschreven namen aan de correcte naam. Deze lijst met correcte namen komt uit een database waar ik geen full access toe heb. Het verantwoordelijke team heeft nog niet gereageerd op de vraag welke charset de MSSQL database heeft. Ik plaats de foute en correcte naam mapping in m'n eigen Access database. Daarin kan ik geen charset vinden. Vervolgens toon ik op een andere pagina data, gelinkt aan de juist gespelde namen, zoals ik die eerder gemapt hebt.

Ik zit dus met verschillende systemen en pagina's en m'n vermoeden is dat daar iets niet goed gaat.

Na wat meer Google ben ik erachter gekomen dat de hexdec waarde van de letter F1 is. Dit zegt mij verder weining, behalve dat ik het karakter met onderstaande code wél kan vervangen naar een normale n:

PHP:

str_replace(chr(hexdec('F1')),"n",$mystr)

Ik heb voor nu dus een oplossing, alleen ben ik hier natuurlijk niet tevreden mee. Het liefst heb ik het zo dat Highcharts gewoon exporteert zoals de naam hoort te zijn, hier ging het immers fout, ik heb geen issues met het tonen van de data op de pagina's, dat gaat dus goed.

Voutloos schreef op dinsdag 23 september 2014 @ 14:45:
En voor 't bewijs: http://3v4l.org/ISU7A

Sinds 4.3.0 wordt de enkele char al prima vervangen, maar de combined versie niet.

[...]
Dit.

Dit soort replacements is symptoombestrijding.

Als ik dit goed begrijp staat er dus een combining character in m'n database? Die dus niet vervangen kan worden met str_replace.

alienfruit schreef op maandag 22 september 2014 @ 12:32:
Kan je het onderstaande niet doen als je letters wilt romanizen (of transliteration) ?

PHP:

$results = iconv("UTF_8", "ISO-8859-1//TRANSLIT", $str)

Dit geeft een leeg resultaat terug.

[ Voor 22% gewijzigd door Belindo op 24-09-2014 10:52 ]

[RobIII]

Belindo schreef op woensdag 24 september 2014 @ 10:43:
Na wat meer Google ben ik erachter gekomen dat de hexdec waarde van de letter F1 is.

Was je dat hier niet ook al verteld? Lees je überhaupt wat ik zeg

Belindo schreef op woensdag 24 september 2014 @ 10:43:
Ik heb voor nu dus een oplossing

Nee, je hebt 't symptoom bestreden wat ook al vaker is aangegeven in dit topic

Belindo schreef op woensdag 24 september 2014 @ 10:43:
Als ik dit goed begrijp staat er dus een combining character in m'n database? Die dus niet vervangen kan worden met str_replace.

Je zegt net zelf dat je char 0x1F is, hoe is dat dan een combining character? Ook dat staat toch gewoon in RobIII in "\[PHP/ACCESS] 'ñ' karakter wil niet veranderd worden"? Heb je die linkjes al eens aangeklikt? Maar goed, de linkjes uit die post: hier eens wat er bij 1F staat en kijk hier eens wat een combining character inhoudt. Ik snap niet hoe je er dan bij komt dat het een combining character is terwijl 't replacen van "hexec(1F)" werkt (voor dit specifieke geval).

Belindo schreef op woensdag 24 september 2014 @ 10:43:
Dit geeft een leeg resultaat terug.

En is ook helemaal niet boeiend want ook dat is symptoombestrijding.

Misschien ook even lezen: Programming FAQ - Getallen en talstelsels en dan vooral over notaties (0x1F / "1F" / 31). Maar 't belangrijkst is dat je The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) leest. Er staat niet voor niets "No excuses" in de titel

[ Voor 11% gewijzigd door RobIII op 24-09-2014 11:15 ]