SEPA konformen String erzeugen mit preg_replace

[dedlfix]

Tach!

Die ereg-Funktionen und die mb_ereg-Funktionen stammen aus verschiedenen Erweiterungen, ich sehe keinen Grund dafür, warum die mb_ereg-Funktionen in naheliegender Zukunft auch missbilligt werden sollten. In der Begründung heißt es zwar, dass die POSIX-Syntax für reguläre Ausdrücke zugunsten der Perl-Syntax aufgegeben worden sei, aber inzwischen sind PHPs preg-Funktionen auch schon lange nicht mehr Perl-kompatibel und werden sie vermutlich auch nicht mehr werden. 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.

Besser ist es, bei preg_... zu bleiben und da den Modifizierer u (kleines u, das große steht für was anderes) zu verwenden.
Ich bin mir mangels Dokumentation nicht sicher, aber ich nehme an, dass man in diesem Fall auch noch die interne Zeichenkodierung mit mb_internal_encoding() setzen müsste.

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

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. Es wäre auch ziemlich verwechslungsträchtig, zwei gleich aussehende Zeichen zuzulassen. Und zum anderen, warum sollte von einem Anführungszeichen-Paar nur eins verwendet werden?

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.

dedlfix.