Hakuna matata!
Wenn du kannst, dann benutze besser mb_ereg_replace(), dafür ist auch viel besser dokumentiert, wie man die richtige Zeichenkodierung einstellt.
Nein! ereg_... sind die POSIX-Funktionen. Die sind eigentlich deprecated. Es wundert mich, dass sie bei den MB-Strings noch erlaubt sind.
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.
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.
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. Aber auch wenn, dann bedeutet das ja noch nicht, dass die zu untersuchende Zeichenkette auch im ASCII-Wertebereich liegt.
“All right, then, I'll go to hell.” – Huck Finn