nicht angemeldet
Moin Moin!
Die JS-Engine versteht immer dasselbe unter \b, weil das in ECMAScript so festgelegt ist; eine Lokalisation gibts da nicht.
Wie kann man nur so vernagelt sein? Naja, es bleibt ja noch die Hoffnung, dass irgendwann mal jemand die Spec verbessert.
Möglichkeiten gäbe es ja einige, z.B. nutzt die Definition nur drei Flags (g, i und m), Mozilla fügt noch y (sticky) hinzu. Da bleibt noch genügend Luft für ein Flag, das \b, \w und \W auf die (irgendwie) ausgewählte Sprache erweitert.
Die größere Frage ist da eher, wie man die Sprache auswählt. <html lang="de"> wäre ein Weg, aber niemand hintert mich, mehrere Sprachen in einem Dokument zu verwenden, z.B. mit <div lang="fr">. Wenn Javascript dann aus verschiedenen Dokumentteilen Strings extrahiert, muß die RE-Engine jeweils anhand der String-Herkunft entscheiden, welche Sprache gerade zur Anwendung kommt. Die String-Objekte müßten also um ein Attribut erweitert werden, dass die Sprache (für die RE-Engine) enthält.
Richtig übel wird das Modell allerdings, wenn jemand Strings aus verschiedenen Sprachen aneinander hängt und die RE-Engine darauf ansetzt. Welche Sprache ist dann zu verwenden?
Die Frage kann Perl auch nicht beantworten, dort wird die Locale global gesetzt, die per Locale ausgewählte Sprache gilt dann für alle REs und alle Strings. Das Modell wäre in Javascript auch recht einfach: document.setLocate("de-DE"), dann matcht /\w/ auch Umlaute und ß.
Alexander
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".