String met umlaut omzetten

[sweebee]

Ik heb de volgende variabele:

$voornaam = "Joël";

Nu moet ik deze variabele omzetten naar Joel.

Hoe ga ik dit doen? Ik heb al rond gezocht en dit is het enige wat in de buurt kwam.

Alleen toen werd de ö = Y ipv o

$voornaam = strtr(utf8_decode($voornaam),
utf8_decode('ŜŒŽšœžŸ¥µÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýÿ'),
'SOZsozYYuAAAAAAACEEEEIIIIDNOOOOOOUUUUYsaaaaaaaceeeeiiiionoooooouuuuyy');

[Swedish Clown]

Mag ik vragen wat het doel hiervan is? Het komt bij mij nogal als een hack over en zeker met namen wil je niet "spelen". Hoe de naam wordt ingevoerd door de klant, is zoals je hem behandeld Daarmee gaan lopen "spelen" is vragen om gezeur IMO.

[sweebee]

Een deel van de naam wordt mee verstuurd naar een ideal transactie.

Alleen Qantani (ideal) staat karakters met umlauts niet toe waardoor ik een foutmelding krijg.

[markvt]

Kan je ze niet urlEncoden?

[Swedish Clown]

Welke specifieke foutmelding krijg je? Want als ik even vlug door de code van Qantani doorloop, zie ik geen aanleiding om speciale characters niet toe te laten?

[HuHu]

é = é

De HTML code is als volg opgebouwd: ampersand (&), letter (e), accent (acute), puntkomma ( ; ). Wat jij dus wilt is een alleen de losse letter.

Met http://php.net/htmlentities zet je Joël om in Joël. Er zijn maar een paar mogelijke accenten: grave, acute, circ, tilde, uml, ring, cedil, th, slash, horn, lig.

Je algoritme is dan als volgt:

code:

1. zet tekst om naar HTML met htmlentities()
2. zoek naar patroon: &(letter)(accent);
3. pak alleen de letter
(4. zet de tekst terug met html_entitiy_decode)

De laatste stap is optioneel en alleen nodig als je langere teksten doet.

Edit: even Googlen: http://stackoverflow.com/a/18669045

PHP:

preg_replace('/&([a-z]{1,2})(acute|cedil|circ|grave|lig|orn|ring|slash|th|tilde|uml|caron);/i','$1',htmlentities($value));

[ Voor 12% gewijzigd door HuHu op 09-12-2014 14:20 ]

[L-VIS]

De zoekterm die je wil gebruiken is diakritische (of diacritic) tekens.

[Rmg]

sweebee schreef op dinsdag 09 december 2014 @ 13:56:
Ik heb de volgende variabele:

$voornaam = "Joël";

Nu moet ik deze variabele omzetten naar Joel.

Hoe ga ik dit doen? Ik heb al rond gezocht en dit is het enige wat in de buurt kwam.

Alleen toen werd de ö = Y ipv o

$voornaam = strtr(utf8_decode($voornaam),
utf8_decode('ŜŒŽšœžŸ¥µÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýÿ'),
'SOZsozYYuAAAAAAACEEEEIIIIDNOOOOOOUUUUYsaaaaaaaceeeeiiiionoooooouuuuyy');

Kijk eens naar het eerste answer onder de stackoverflow vraag waar je bovenstaande code hebt gevonden

[? ?]

base64 encoden, in url stoppen en base64 decoden in je php bij het inlezen van de url.
Als er een umlaut of iets anders staat, is het met reden. Anders kan je net zo goed alle "i" karakters gaan deleten omdat je die niet mooi vindt...

[ Voor 46% gewijzigd door ? ? op 09-12-2014 14:24 ]

[HuHu]

? ? schreef op dinsdag 09 december 2014 @ 14:23:
base64 encoden, in url stoppen en base64 decoden in je php bij het inlezen van de url.
Als er een umlaut of iets anders staat, is het met reden. Anders kan je net zo goed alle "i" karakters gaan deleten omdat je die niet mooi vindt...

sweebee schreef op dinsdag 09 december 2014 @ 14:08:
Een deel van de naam wordt mee verstuurd naar een ideal transactie.

Alleen Qantani (ideal) staat karakters met umlauts niet toe waardoor ik een foutmelding krijg.

[sschalkwijk]

Gebruik je de API of de PHP class van Qantani?

Als je namelijk de API gebruikt zou enkel de php functie htmlentities() welke HuHu reeds aanhaalt wellicht voldoende zijn.

Uit de documentatie van Qantani (https://www.qantani.com/nl/documentatie/api-documentatie):

Let vooral op karakters als < en &. Deze moeten respectievelijk worden gecodeerd als

code:

<

en

code:

&

.

[kwaakvaak_v2]

Wat jij bedoeld heet transliteration, en daar zijn gelukkig als redelijk wat packages voor gemaakt


https://packagist.org/search/?q=transliteration

[rvnieuwh]

Via Powershell kan het via onderstaand Function

function Convert-DiacriticCharacters {
param ( [string]$inputString )
$inputString = $inputString.Replace("ß","ss")
$inputString = $inputString.Replace("ä","ae")
$inputString = $inputString.Replace("Ä","Ae")
$inputString = $inputString.Replace("ö","oe")
$inputString = $inputString.Replace("Ö","Oe")
$inputString = $inputString.Replace("ü","ue")
$inputString = $inputString.Replace("Ü","Ue")
[string]$formD = $inputString.Normalize( [System.text.NormalizationForm]::FormD )
$stringBuilder = new-object System.Text.StringBuilder
for ($i = 0; $i -lt $formD.Length; $i++){
$unicodeCategory = [System.Globalization.CharUnicodeInfo]::GetUnicodeCategory($formD[$i])
$nonSPacingMark = [System.Globalization.UnicodeCategory]::NonSpacingMark
if($unicodeCategory -ne $nonSPacingMark){ $stringBuilder.Append($formD[$i]) | out-null }
}
$stringBuilder.ToString().Normalize([System.text.NormalizationForm]::FormC)
} # end function Convert-DiacriticCharacters

[ Voor 6% gewijzigd door rvnieuwh op 09-12-2014 14:38 ]

[glashio]

PHP:

mb_internal_encoding('UTF-8');

function str_ascii($str) {
    static $table = array(
        'Ŝ'=>'S', 'š'=>'s', 'Ð'=>'Dj', 'Ž'=>'Z', 'ž'=>'z', 'C'=>'C', 'c'=>'c', 'C'=>'C', 'c'=>'c',
        'À'=>'A', 'Á'=>'A', 'Â'=>'A', 'Ã'=>'A', 'Ä'=>'A', 'Å'=>'A', 'Æ'=>'A', 'Ç'=>'C', 'È'=>'E', 'É'=>'E',
        'Ê'=>'E', 'Ë'=>'E', 'Ì'=>'I', 'Í'=>'I', 'Î'=>'I', 'Ï'=>'I', 'Ñ'=>'N', 'Ò'=>'O', 'Ó'=>'O', 'Ô'=>'O',
        'Õ'=>'O', 'Ö'=>'O', 'Ø'=>'O', 'Ù'=>'U', 'Ú'=>'U', 'Û'=>'U', 'Ü'=>'U', 'Ý'=>'Y', 'Þ'=>'B', 'ß'=>'Ss',
        'à'=>'a', 'á'=>'a', 'â'=>'a', 'ã'=>'a', 'ä'=>'a', 'å'=>'a', 'æ'=>'a', 'ç'=>'c', 'è'=>'e', 'é'=>'e',
        'ê'=>'e', 'ë'=>'e', 'ì'=>'i', 'í'=>'i', 'î'=>'i', 'ï'=>'i', 'ð'=>'o', 'ñ'=>'n', 'ò'=>'o', 'ó'=>'o',
        'ô'=>'o', 'õ'=>'o', 'ö'=>'o', 'ø'=>'o', 'ù'=>'u', 'ú'=>'u', 'û'=>'u', 'ý'=>'y', 'þ'=>'b', 'ÿ'=>'y'
    );

    return strtr($str, $table);
}

gebruik ik in me includes

[HuHu]

glashio schreef op dinsdag 09 december 2014 @ 14:50:

PHP:

mb_internal_encoding('UTF-8');

function str_ascii($str) {
    static $table = array(
        'Ŝ'=>'S', 'š'=>'s', 'Ð'=>'Dj', 'Ž'=>'Z', 'ž'=>'z', 'C'=>'C', 'c'=>'c', 'C'=>'C', 'c'=>'c',
        'À'=>'A', 'Á'=>'A', 'Â'=>'A', 'Ã'=>'A', 'Ä'=>'A', 'Å'=>'A', 'Æ'=>'A', 'Ç'=>'C', 'È'=>'E', 'É'=>'E',
        'Ê'=>'E', 'Ë'=>'E', 'Ì'=>'I', 'Í'=>'I', 'Î'=>'I', 'Ï'=>'I', 'Ñ'=>'N', 'Ò'=>'O', 'Ó'=>'O', 'Ô'=>'O',
        'Õ'=>'O', 'Ö'=>'O', 'Ø'=>'O', 'Ù'=>'U', 'Ú'=>'U', 'Û'=>'U', 'Ü'=>'U', 'Ý'=>'Y', 'Þ'=>'B', 'ß'=>'Ss',
        'à'=>'a', 'á'=>'a', 'â'=>'a', 'ã'=>'a', 'ä'=>'a', 'å'=>'a', 'æ'=>'a', 'ç'=>'c', 'è'=>'e', 'é'=>'e',
        'ê'=>'e', 'ë'=>'e', 'ì'=>'i', 'í'=>'i', 'î'=>'i', 'ï'=>'i', 'ð'=>'o', 'ñ'=>'n', 'ò'=>'o', 'ó'=>'o',
        'ô'=>'o', 'õ'=>'o', 'ö'=>'o', 'ø'=>'o', 'ù'=>'u', 'ú'=>'u', 'û'=>'u', 'ý'=>'y', 'þ'=>'b', 'ÿ'=>'y'
    );

    return strtr($str, $table);
}

gebruik ik in me includes

Dat soort (zelfgemaakte) tabellen moet je vermijden. Vaak zijn die incorrect of incompleet, zo ook de jouwe. Bijvoorbeeld de œ mist. De ð vervangen door een o lijkt me niet correct, zeker omdat je de bijbehorende hoofdletter Ð vervangt door Dj.

[Soultaker]

Transliteration naar ASCII kun je doen met iconv.

Trouwens is de ë in Joël een trema, geen umlaut.

[? ?]

HuHu schreef op dinsdag 09 december 2014 @ 14:26:
[...]


[...]

So? In Base64 ziet Joël er zo uit: Sm/rbA==
http://www.motobit.com/util/base64-decoder-encoder.asp
Wat is er mis met urlencoden trouwens?
http://meyerweb.com/eric/tools/dencoder//

[ Voor 26% gewijzigd door ? ? op 09-12-2014 15:48 ]

[HuHu]

? ? schreef op dinsdag 09 december 2014 @ 15:44:
[...]

So? In Base64 ziet Joël er zo uit: Sm/rbA==
http://www.motobit.com/util/base64-decoder-encoder.asp

Wat is er mis met urlencoden trouwens?
http://meyerweb.com/eric/tools/dencoder/

Waar haal jij vandaan dat het om een URL gaat? Ik lees dat het om ideal gaat. Het lijkt me niet handig dat Joël op zijn bankafschrift Sm/rbA== ziet staan.

[ Voor 12% gewijzigd door HuHu op 09-12-2014 15:47 ]

[? ?]

Foutje, maar alsnog: WTF is er mis met base64.

[HuHu]

? ? schreef op dinsdag 09 december 2014 @ 15:48:
Foutje, maar alsnog: WTF is er mis met base64.

Als je een ideal transactie doet, dan moet de verkoper aan de bank laten weten wat er op het bankafschrift moet staan. Daarbij accepteert de bank alleen ASCII karakters, zonder diakritische tekens. Je kunt de API van de bank niet veranderen. Dus je moet je eigen systeem aanpassen.

Je wilt niet dat er op bankafschriften base64 encoded berichten komen te staan. Dat leest niet prettig voor de klant, want mensen zijn niet zo goed in base64 decoding. Je moet dus een leesbaar bericht aanleveren bij de bank.

[? ?]

Klantnummer dan maar?
En anders alles wat niet ASCII is vervangen door een vraagteken.

De omgekeerde aanpak met dit vervangen we door dat is kans op fouten als je een char over het hoofd ziet, er ergens een bij komt of een Chinees iets besteld.

En kan iemand me eens vertellen waarom Joël op zijn eigen bankafschriften zijn eigen naam moet zien staan?

[ Voor 18% gewijzigd door ? ? op 09-12-2014 15:54 ]

[Gamebuster]

Back to the 00's.

[Soundless]

? ? schreef op dinsdag 09 december 2014 @ 15:48:
Foutje, maar alsnog: WTF is er mis met base64.

Volgens https://www.qantani.com/nl/documentatie/api-documentatie moeten '<' en '&' omgezet worden naar '<' en '&', ofwel, ze moeten htmlencode worden. Dus pleur je de hele string in een htmlencode en klaar ben je. Hoezo zou je ooit base64 voor zoiets willen gebruiken?

[.oisyn]

? ? schreef op dinsdag 09 december 2014 @ 15:52:
Klantnummer dan maar?
En anders alles wat niet ASCII is vervangen door een vraagteken.

De omgekeerde aanpak met dit vervangen we door dat is kans op fouten als je een char over het hoofd ziet, er ergens een bij komt of een Chinees iets besteld.

En kan iemand me eens vertellen waarom Joël op zijn eigen bankafschriften zijn eigen naam moet zien staan?

Het is niet het een óf het ander. Ik zou beide doen - standaard karakters omzetten, voor de rest alle karakters boven codepoint 127 vervangen door een vraagteken.

[JerX]

Gamebuster schreef op dinsdag 09 december 2014 @ 15:53:
Back to the 00's.

Zal je verbazen hoeveel programma's umlaut niet accepteren.

Hier nog een vb scriptje (beetje dirty):

code:

Request.Put "$voornaam", Replace(Replace(Replace(Replace(Request.Get("$voornaam"), "ä", "ae"),"ö", "oe") ,"ü","ue"),"ß","ss")

[? ?]

JerX schreef op dinsdag 09 december 2014 @ 15:56:
[...]
Request.Put "$voornaam", Replace(Replace(Replace(Replace(Request.Get("givenName"), "ä", "ae"),"ö", "oe") ,"ü","ue"),"ß","ss")

Voor iemand die zoiest gebruikt in een webshop, moeten ze de guillotine terugbrengen

Wat .oisyn zegt, en misschien alles wat niet a-z, A-Z is weggummen.

[ Voor 9% gewijzigd door ? ? op 09-12-2014 15:59 ]

[JerX]

? ? schreef op dinsdag 09 december 2014 @ 15:57:
[...]

Voor iemand die zoiest gebruikt in een webshop, moeten ze de guillotine terugbrengen

Had even niet gezien dat het voor web was

[HuHu]

? ? schreef op dinsdag 09 december 2014 @ 15:52:
Klantnummer dan maar?
En anders alles wat niet ASCII is vervangen door een vraagteken.

De omgekeerde aanpak met dit vervangen we door dat is kans op fouten als je een char over het hoofd ziet, er ergens een bij komt of een Chinees iets besteld.

En kan iemand me eens vertellen waarom Joël op zijn eigen bankafschriften zijn eigen naam moet zien staan?

Gast, serieus . Bij een ideal implementatie moet je aan de bank naam, rekeningnummer, woonplaats, bedrag, omschrijving, datum, et cetera doorgeven. Alles zonder diakritische tekens. Ik heb m'n eigen ideal implementatie niet bij de hand, maar het is een hele waslijst en de eisen zijn strikt.

Dan kun je wel eigenwijs zijn en aan de bank, in plaats van de naam, klantnummers of base64 encoded berichten of Jo?l doorgeven; maar dan mislukt je transactie.

De vraag in de OP is simpel: hoe verwijder je diakritische tekens.

[Herko_ter_Horst]

Wacht eens even. Nergens in de API-documentatie van Qantani staat dat dit moet.

Wat er staat is dat het bericht in XML met UTF-8 encoding moet worden aangeleverd. Verder staat er alleen dat XML-entities ge-escaped moeten worden (dit is logisch). Er staat NIETS over het vervangen van niet-ASCII tekens door hun ASCII variant.

@TS: waarom denk je dat dit moet? Heeft Qantani dit naar jou aangegeven? Wat is de foutmelding die je krijgt?

[ Voor 6% gewijzigd door Herko_ter_Horst op 09-12-2014 16:02 ]

[? ?]

HuHu schreef op dinsdag 09 december 2014 @ 15:59:
[...]

Gast, serieus . Bij een ideal implementatie moet je aan de bank naam, rekeningnummer, woonplaats, bedrag, omschrijving, datum, et cetera doorgeven. Alles zonder diakritische tekens. Ik heb m'n eigen ideal implementatie niet bij de hand, maar het is een hele waslijst en de eisen zijn strikt.

Dan kun je wel eigenwijs zijn en aan de bank, in plaats van de naam, klantnummers of base64 encoded berichten of Jo?l doorgeven; maar dan mislukt je transactie.

De vraag in de OP is simpel: hoe verwijder je diakritische tekens.

in België doen wij normaal bij de bank.

Mijn gezamelijke rekening heeft geen vermelding van mijn naam trouwens, (wel de afkorting van de familienamen van beide partners). Veel geluk aan de webshops om die te raden...

[sweebee]

Herko_ter_Horst schreef op dinsdag 09 december 2014 @ 16:02:
Wacht eens even. Nergens in de API-documentatie van Qantani staat dat dit moet.

Wat er staat is dat het bericht in XML met UTF-8 encoding moet worden aangeleverd. Verder staat er alleen dat XML-entities ge-escaped moeten worden (dit is logisch). Er staat NIETS over het vervangen van niet-ASCII tekens door hun ASCII variant.

@TS: waarom denk je dat dit moet? Heeft Qantani dit naar jou aangegeven? Wat is de foutmelding die je krijgt?

Ik maak gebruik van de front-end functie. Dus niet de API.

Na de bestelling geef ik een gegenereerde klantnummer mee aan de link naar ideal. Dat nummer bestaat ook uit letters uit de namen. Maar ik merk al dat het makkelijker gezegd dan gedaan is, dus ik kan beter het klantennummer anders generen.

Ik ben bezig met een projectje met ideal dus om beter php te leren.

[ Voor 3% gewijzigd door sweebee op 09-12-2014 16:06 ]

[? ?]

Tadaa :-)
Eigen problemen gemaakt, eigen problemen opgelost. Altijd eerst even nadenken of de vraag die je stelt niet gewoon verkeerd is.

[Herko_ter_Horst]

Voor klantnummers zou ik gewoon een tellertje gebruiken. Ik zou nooit identifiers gebruiken waar informatie in verstopt zit.

[MSalters]

De correcte methode om accenten (diakrieten) te verwijderen van Unicode is overigens relatief simpel.

In Unicode is er een aparte range van diakrieten: "Combining Diacritical Marks", U+0300 - U+036F. Nu is Joël waarschijnlijk geschreven met een Latin-1 ë, dus "U+00EB LATIN SMALL LETTER E WITH DIAERESIS"

Je kunt de diakrieten verwijderen met een standaard transformatie, "decomposition". Het resultaat is dan in NFD, Normal Form Decomposed. ë wordt dan e". Concreet zijn in NFD alle diakrieten losgemaakt en gebruiken ze de range U+0300 - U+036F. Door uit een NFD string de karakters te verwijderen tussen U+0300 en U+036F verwijder je dus precies de diakrieten, en niets meer.

O ja, als een side benefit wordt æ in NFD ook vertaald naar ae, en ij naar ij.

[Feanathiel]

Herko_ter_Horst schreef op dinsdag 09 december 2014 @ 17:31:
Voor klantnummers zou ik gewoon een tellertje gebruiken. Ik zou nooit identifiers gebruiken waar informatie in verstopt zit.

Ik ga even uit van een oplopende teller: daar zit nou net in met hoeveel klanten je te maken hebt gehad.

[Hipska]

Sommige DB's leveren een niet oplopende id voor primary key. Dat is interessant bij zo'n gevoelige informatie.

[Acid_Burn]

Feanathiel schreef op dinsdag 09 december 2014 @ 21:43:
[...]


Ik ga even uit van een oplopende teller: daar zit nou net in met hoeveel klanten je te maken hebt gehad.

Ach gewoon begonnen met een random offset van 242123 ofzo