Es gibt in PRCE, das ist die Syntax für die Regulären Ausdrücke, gewisse Zeichen mit einer speziellen Bedeutung. Eigentlich werden die üblichsten maskiert, denoch gibt es Sonderzeichen, die durch die Maskierung durchfallen. Ganz gefährlich sind: \, /, ", ' (Und die, die als Begrenzer gebraucht werden, hier nun /, kann aber auch # sein zum Beispiel). Warum nun _ auch nicht geht, weiss ich nicht - vorstellen kann ich es mir eigentlich nicht.

@MySQL: Doch, umlaute gehen durchaus. Prinzipiell gehen alle Zeichen, ausser die, die eine Sonderbedeutung haben. Das heisst, chinesische Schriftzeichen kann man auch nehmen - ist aber herzlich sinnlos.

Hi,

Wenn es in der DB richtig steht und diese dort UTF-8 codiert sind, dann werden sie im LotgD auch als UTF-8 ausgegeben. Bitte beachte, dass wenn du auf native UTF-8 Unterstützung aus bist die Änderungen größer sein werden, als du zur Zeit denkst. Da PHP von Haus aus meist nicht Unicode aware Funktionen hat und man explizit die mb_* Varianten nutzen muss oder bei regex den "u" modifier usw usf!

Du hast zwar die DB die Templates und die Skripte auf UTF-8 konvertiert, aber benutzt wahrscheinlich weiterhin String-Funktionen die UTF-8 gar nicht "kennen" und somit bekommst du am Ende trotzdem wieder ISO. Das kannst du natürlich mit Verschiedenen Tricks umgehen (=Pseudo-UTF-8) oder native angehen und konsequent alle Funktionen durch UTF-8 fähige zu ersetzen. (=natives UTF-8).

Natürlich kannst du auch mit Pseudo-UTF-8 "leben" aber die zukünftigen Probleme sind dann einprogrammiert. Wenn Backend (DB) und Frontend (PHP) eine andere Codierung verwenden, ist es immer eine Problemquelle.

Solltest du Interesse an eine moderne LotgD Version mit nativer UTF-8 Unterstützung sowie lauffähig unter PHP7 haben siehe den DS3.5 Thread hier