SEPA konformen String erzeugen mit preg_replace

[1UnitedPower]

Hakuna matata!

Wenn das Argument nochmal angeführt werden sollte und die PHP-Macher sich auf einen Standard zurückbesinnen wollten, dann hätten die preg-Funktionen m.M.n. auch nur sehr schlechte Karten auf eine aussichtsreiche Zukunft.

Es geht auch darum, keine zwei verschiedene Regexp-Syntaxen zu verwenden. Die pregs sind mächtiger als die eregs. Und da pregs mit UTF-8 umgehen können, sehe ich keinen Grund, die mb_eregs zu verwenden.

Inwiefern mächtiger? Perls reguläre Ausdrücke sind in der Tat mächtiger, weil sie über die regulären Sprachen hinaus auch kontextfreie Sprachen entscheiden können (dank rekursiven Definitionen). PHPs "perl" regelar expressions können das allerdings nicht und sind damit auch nicht mächtiger als die regulären Ausdrücke aus dem POSIX Standard.

Für die mb_eregs spricht, dass es sich dabei wirklich um standkonforme Sytanx handelt und nicht um eine weitere selbstgestrickte Syntax, die sich als perl-konform verkauft. Dagegen spricht, dass sie in der PHP-Community offensichtlich weniger beliebt sind.

Nein, mbstrings und preg sind zwei verschiedene Erweiterungen. mb_irgendwas wirkt nur auf mb_irgendwasanderes. Der preg-Modifizierer u ist davon nicht beeinflusst.

Asche über mein Haupt, das kann man sogar an der Stelle der Dokumentation nachlesen, die ich selber verlinkt habe.

Allerdings ist UTF-8 in dem vorliegenden Fall völlig irrelevant, weil die erlaubten Zeichen sowieso alle nur im ASCII-Bereich liegen.
Wirklich? Ich kann in der ASCII-Tabelle keine Entsprechung zum SINGLE LOW-9 QUOTATION MARK, welches Jonny 5 hier identifziert hat, entdecken.

Ich kann im SEPA-Zeichensatz kein SINGLE LOW-9 QUOTATION MARK finden. weil ich davon ausgehe, dass das von tami verwendete Dokument fehlerhaft ist und das von der Bundesbank mehr Glaubwürdigkeit hat.

Achso, das ergibt Sinn ja.

Aber auch wenn, dann bedeutet das ja noch nicht, dass die zu untersuchende Zeichenkette auch im ASCII-Wertebereich liegt.

Alle erlaubten Zeichen liegen im ASCII-Bereich. Alles was mit Bytes > 0x7F kodiert wird, ist sowieso nicht nicht erlaubt und fliegt raus. Es gibt keine unerlaubten Zeichen, die mit Bytes erlaubter Zeichen kodiert werden. Damit ist alles unerlaubte auch bei ASCII-Filterung problemlos rausgefiltert.

Stimmt, ich hatte nicht bedacht, dass Bytes, wenn sie Teil eine Multybyte-Sequenz sind, stets einen höheren Wert haben als 0x7F, weil das erste Bit stets eine 1 sein muss. Vermutlich aus genau diesem Grund.