Webcam einbinden und refreshen

[Gert]

denn wer Skripte selber anpassen möchte sollte zumindest in der Lage sein seinen Editor passend zu konfigurieren.

Gut gebrüllt, Löwe

Bei Deiner Lösung hätte der User allerdings keine Wahl mehr, ob er möchte oder nicht, er MUSS das Passwort in der config.php offline ändern.

... bis auf den komischen UTF-Marker, der jetzt diese Probleme verursacht.

Die Standard Konfiguration von notepad++ öffnet nun mal eine uft-8 ohne BOM codierte Datei als ANSI und speichert sie dann auch so ab, wenn kein Zeichen enthalten ist, an der notepad++ erkennen kann, dass es utf-8 ohne BOM ist. Und dann gibt es bestimmt auch Leute, die sowohl ANSI codierte als auch utf-8 codierte Projekte bearbeiten müssen, und die lassen sicher gerne die automatische Erkennung der Codierung in der Konfiguration von notepad++.

Ich dachte eigentlich, das mit dem "komischen" utf-8 marker ist schon lange durch,

Gert

PS:

Ohne den "Marker" erkennt Notpad dann aber UTF-8 überhautp nicht und dann sollte es kein Problem geben.

Wenn die config.php ANSI codiert ist, funktionieren z. B. Umlaute im Passwort nicht mehr, und wer weiss, was noch alles.

[cmb]

Hallo Holger, hallo Gert,

IMO ist der auch unnötig, denn wer Skripte selber anpassen möchte sollte zumindest in der Lage sein seinen Editor passend zu konfigurieren.

Ich bin zwar in der Lage Skripte anzupassen, aber ich kann meinen Editor (Komodo Edit von ActiveState) nicht so anpassen, dass er UTF-8 ohne BOM schreibt. Sind keine Nicht-ASCII-Zeichen vorhanden schreibt der Editor das BOM, wenn ich UTF-8 forciere. Daher finde ich den "utf8-marker" recht sinnvoll.

Ohne den "Marker" erkennt Notpad dann aber UTF-8 überhautp nicht und dann sollte es kein Problem geben.

Enthielte config.php keine Nicht-ASCII-Zeichen und wäre als ASCII gespeichert gäbe es vermutlich Probleme sobald dort ein Anwender im Editor Nicht-ASCII-Zeichen (z.B. für das Password) eingibt. Wenn er dann achtlos speichert, werden viele Editoren eben die Standardkodierung des Systems annehmen -- und die ist wohl eher selten UTF-8. (Ich sehe gerade, dass Gert schneller war)

Allgemein ist das BOM bei UTF-8 übrigens eine sehr schlechte Idee, da die Byte-Folge in UTF-8 fest definiert ist (und nicht von der Endianess der jeweiligen Maschine abhängt):

The Unicode Standard does permit the BOM in UTF-8, but does not require or recommend its use.

Christoph

[Gert]

Hallo,

2 Dinge halte ich nach wie vor für sinnvoll:

1. In einem utf-8 codierten System sollte auch die config.php utf-8 codiert sein.

2. Da es mit dem BOM die bekannten Probleme gibt, sollten die Dateien eine "Ersatzkennung" tragen, damit Programme auch ohne BOM erkennen können, dass es sich um eine utf-8 codierte Datei handelt - bei uns ist das der utf8 marker.

Es ist so wie immer - wer das eine will, muss das andere mögen. Wir wollen die vielen Vorteile in Anspruch nehmen, die utf-8 bietet, also müssen wir mit einigen wenigen Nachteilen leben. Einer dieser Nachteile ist, dass man die Core Dateien nicht mit einem x-beliebigen 0815-Editor bearbeiten sollte, und man eben wissen muss, dass die Dateien in der Codierung "utf-8 ohne BOM" abgespichert werden müssen, falls der Editor das trotz utf-8 marker nicht erkennt.

Die dazu notwendige Software (z. B. notepad++) gibt es kostenlos im Netz, jetzt müssen wir noch überlegen, in welcher Form wir das notwendige Wissen bereitstellen (readme.php, Wiki oder so). Und wir müssen wohl damit leben, dass es immer wieder Anwender geben wird, die es für einfacher befinden, im Forum nachzufragen,

Gert

[cmb]

Hallo Gert,

ja, Dokumentation ist immer gut. Warum nicht im User Manual im XH-Wiki? Dort sollte der User sowieso nachlesen, wenn er die Infos nicht schon kennt.

Und wir müssen wohl damit leben, dass es immer wieder Anwender geben wird, die es für einfacher befinden, im Forum nachzufragen,

Na ja. Wenn ein Anwender direkt nach dem Login wieder rausgeworfen wird -- wie soll er erahnen, dass das an einem BOM in config.php oder einer der languages/ Dateien liegt? Da kann ich schon verstehen, wenn er hier nachfragt.

Christoph

[Holger]

Hmm,

jetzt mal generell - ohne wieder eine hitzige Debatte zu entfachen:

Wir wollen die vielen Vorteile in Anspruch nehmen, die utf-8 bietet, also müssen wir mit einigen wenigen Nachteilen leben. Einer dieser Nachteile ist, dass man die Core Dateien nicht mit einem x-beliebigen 0815-Editor bearbeiten sollte, und man eben wissen muss, dass die Dateien in der Codierung "utf-8 ohne BOM" abgespichert werden müssen, falls der Editor das trotz utf-8 marker nicht erkennt.

Das ist so pauschal nicht richtig, trifft vielleicht aber für CMSimple_XH zu.

Wenn in einem utf-8 System alle beteiligten Komponenten alles richtig machen (z.B. passenden charset-header senden):

• muss die PHP-Datei (cms.php, functions.php usw.) nicht einmal utf-8 kodiert sein (Umlaute sollten in PHP-Scripten nicht vorkommen - vielleicht ist das in Kommentaren bei _XH derzeit so?)
• CSS-Dateien sollten per @charset den Browser informieren (wenn wirklich Non-ASCII Zeichen in Kommentaren etc. stehen) und dürfen - angeblich - sogar ein BOM enthalten ( http://www.w3.org/International/questio ... set.de.php )
• In Passwörter gehören keine Umlaute wie ÄÖÜ. Hier ist generell mit Problemen zu rechnen (siehe so namenhafte Anwendungen wie Tortoise oder ICQ, die damit Probleme haben/hatten). Erlaubte "Sonderzeichen" sind %$.! usw. (was eigentlich auch allgemein bekannt ist)

Es bleiben lediglich die Sprachdateien. Hier müssen die Entwickler aufpassen und die User besser online ändern, wenn sie es einfach haben möchten.
Es gibt von Christoph ja sogar ein Tool für komplett neue Übersetzungen. Bestehende Sprachdateien werden, wegen der evtl. enthaltenen Sonderzeichen, ja (wie mit Marker) oft automatisch richtig erkannt.

Schaut euch mal die Zeichenkodierung der Skripte von anderen großen Projekten an. Dort gibt es massenweise PHP-Dateien die nicht in utf-8 vorliegen, das System läuft aber trotzdem.

Aus diesen Gründen finde ich den Marker eben unnötig und er führt ja im aktuellen Fall (config.php in Notepad) eher zu Problemen als das er hilft.
Ich persönlich ignoriere den Marker einfach (er stört mich also auch nicht), in meinen Skripten verwende ich ihn aber aus o.g. Gründen nicht.

Holger

[cmb]

Hallo Holger,

grundsätzlich hast Du natürlich recht. Der utf8-marker ist eigentlich nicht nötig (ich kann selbstverständlich auch mit meinem Editor ohne Marker Probleme vermeiden).

Umlaute sollten in PHP-Scripten nicht vorkommen - vielleicht ist das in Kommentaren bei _XH derzeit so?

Eigentlich sollten Umlaute (und andere Nicht-ASCII-Zeichen) in allen Programmdateien (nicht nur PHP) vermieden werden. Das ist auch kein Problem, wenn man in englischer Sprache programmiert und kommentiert. Wer aber in einer anderen Sprache programmiert, der kommt um Nicht-ASCII-Zeichen zumindest in den Kommentaren nicht umhin. Und manchmal möchte man auch Nicht-ASCII-Zeichen im Code selbst verwenden -- da muss man dann dran denken, diese entsprechend zu escapen (werde ich bei Advancedform_XH für die nächste Version machen ).

z.B. passenden charset-header senden

Ein guter Punkt! Das sollten wir auf die Roadmap setzen. Bisher verlässt sich CMSimple ja ausschließlich auf <meta http-equiv> was ein bisschen suboptimal ist.

Es gibt von Christoph ja sogar ein Tool für komplett neue Übersetzungen. Bestehende Sprachdateien werden, wegen der evtl. enthaltenen Sonderzeichen, ja (wie mit Marker) oft automatisch richtig erkannt.

<ADD>Wenn man vor lauter, lauter bei seinen eigenen Plugins nicht mehr durchblickt Dieses Plugin ist der Translator_XH, und hat nichts mit Utf8_XH zu tun. Hier findet keinerlei Erkennung oder Sonderbehandlung bzgl. der Kodierung statt. Das sollte aber auch nicht nötig sein. Das Plugin verwendet beim Lesen und Speichern diejenige Kodierung, die der Browser vorgibt, und das ist normalerweise diejenige, die in meta_codepage eingetragen ist. Das ist bei den Spracheinstellungen im Core das gleiche. Es ist also völlig egal, ob in der Sprachdatei bereits Nicht-ASCII-Zeichen enthalten sind, oder nicht. Bei meta_codepage UTF-8 wird eben als UTF-8 gespeichert.</ADD>

Die UTF-8-Erkennung von Utf8_XH funktioniert ganz einfach: sobald ein BOM oder irgendein ANSI kodiertes Nicht-ASCII-Zeichen in der Datei vorkommt (dank UTF-8 reicht zur Erkennung eine einfache Regex; mb_detect_encoding() ist nicht mal nötig), wird diese als nicht korrekt kodiert angezeigt.

Christoph

[cmb]

Hallo Zusammen,

eigentlich gehört das nicht in diesen Thread (sorry Wolfgang, dass wir Deinen Thread gekapert haben), aber da's nun mal passiert ist...

Wir könnten in cms.php nach dem include()n von config.php und den Sprachdateien auch eine Prüfung auf headers_sent() vornehmen, und ggf. einen entsprechenden Hinweis ausgeben. Das verhindert zwar nicht, dass ein BOM in config.php kommt, aber zumindest erleichtert es, den Fehler zu finden.

Christoph

[Gert]

Es bleiben lediglich die Sprachdateien.

Solange man in die config.php per Backend Umlaute eintragen kann (author, publisher), sollte auch die utf-8 codiert sein,

Gert

[cmb]

Hallo Gert,

Solange man in die config.php per Backend Umlaute eintragen kann (author, publisher), sollte auch die utf-8 codiert sein,

Gutes Argument!

Christoph

[Holger]

Gutes Argument!

Schon. Aber was ist denn schlimmer:
- ein Auto-Logout durch das BOM
- ein falsch kodierter Umlaut in den nicht ganz so wichtigen Meta-Angaben, der sich problemlos online berichtigen lässt

Ich finde, ihr macht es euch selber viel schwerer als nötig.
Setzt das Passwort zurück auf "test" und gut ist's. Die neue Lösung bringt doch Null Sicherheitsgewinn...
Die Zeit für den BOM-Support und die Sinnhaftigkeit von UTF-8 Markern wäre besser beim programmieren / diskutieren eines ordentlichen Sicherheitskonzeptes aufgehoben.

Holger