UTF-8 Formularfeld validierung

[Christian Kruse]

你好 bepe,

mein ziel war rauszufinden ob es locale abhängig ist dass ein \w in
einer regex auch wirklich alle zeichen dieser sprache als word-character
erkennt. somit hätte en_US z.b. einen umlaut nicht als word-character
erkennen dürfen. hat es aber (die server locale war auf de_DE gesetzt.)

Naja, \w in der libpcre matcht ja nur alle word characters and digits
bis zu Codepoint 128. Wenn ich mal zitieren darf:

In UTF-8 mode, characters with values greater than 128 never match \d, \s,
or \w, and always match \D, \S, and \W. This is true  even when Unicode
character property support is available.

Deshalb ist es eh nicht das, was du suchst. Wenn du wirklich
locale-abhängiges matchen möchtest, musst du den UTF-8-Mode ausschalten
und ein Locale verwenden, dass einen 1-Byte-Kodierung verwendet. Das hat
aber nix mit setlocale() zu tun, sondern mit der libpcre, die in diesem
Punkt auf eher auf Performance als auf korrekten Support setzt.

weiters weiss ich nicht wie ratsam es ist, bei jedem aufruf der seite
die locale zu setzen.

Das ist völlig problemlos. Das macht das Forum hier auch, z. B. um die
Datum-Strings lokalisiert auszugeben.

ich wollte damit sagen, dass mir nicht ganz klar ist, wie sich das
(ver-)setzen einer locale auf andere php prozesse/threads auswirkt.

Das ist doch alles nachlesbar…

welchen context überschreibt setlocale() nun? die server locale? die
prozess locale? die PHP-thread-weite locale? wie wirkt sich das aus wenn
php als CGI bzw. apache modul konfiguriert ist?

setlocale() überschreibt das Prozess-Locale. Heisst, wenn du PHP in einem
Multithreaded-Kontext verwendest, etwa bei einem Apache-Worker-MPM, dann
überschreiben sich die setlocale()-Aufrufe gegenseitig. Ansonsten, in einer
„traditionellen“ Multi-Prozess-Umgebung wirkt sich das nicht gross weiter
auf andere Prozesse aus. Das Locale wird nach Beenden des Scripts wieder
zurückgesetzt (gehört mit zur Prozedur zur Wiederherstellung des
Environments), es wirkt sich also auch im Modul-Modus nicht auf den Apache
aus.

meine site würde z.b. beim aufruf einer seite im unterverzeichnis /de
eine andere locale setzen als bei aufruf einer seite in /pl. ich denke
dass dies ein ganz normales problem multilingualer seiten ist.

Naja, „Problem“ ist übertrieben ;)

ich versuche diese 'locale-awareness' ein wenig dahingehend zu
umschiffen, dass ich UTF-8 als zeichensatz verwende, und ansonsten
intern für alles andere (z.b. datum, preise in DB, externe web services
etc.)  ein fixes standard format verwende (z.b. '.' als komma, unix
timstamps für datum) und das nur auf der präsentationsebene (template
engine) für das jeweilige portal formatiere.

lass mir aber gern andere konzepte & strategien aufzeigen diesbezüglich.

Na, die Strategie ist schon ganz sinnvoll so, andere (inkl. mir) machen es
auch nicht anders. Aber gerade die Repräsentation nach aussen machen
Locales um vieles einfacher, vor allem deshalb, weil man damit gleich einen
ganzen Rutsch von Sprachen unterstützen kann ohne etwas am Source ändern zu
müssen – hat schließlich alles schonmal jemand aufgeschrieben, in den
Locale-Definitionen ;)

再见,
 克里斯蒂安