nicht angemeldet
Linuchs
dedlfix
Der Martin
dedlfix
dedlfix
Matthias Apsel
dedlfix
dedlfix
Matthias Apsel
dedlfix
Rolf B
Moin,
es geht um ein Mini-Textsystem, mit dem man den variablen Teil einer webseite.php auf dieser Webseite ändern kann.
Die Eingabe erfolgt im <textarea> und wird per PHP in datei.txt geschrieben. Da PHP auf UTF8 eingestellt ist, erscheint die Anzeige nach dem Lesen der datei.txt und Einbinden ins HTML wie erwartet.
Doch bei Kontroll-Anzeige der datei.txt mit dem Firefox sind die Umlaute verkrüppelt, Firefox erkennt also die UTF8 Codierung nicht. Jedenfalls nicht, wenn datei.txt vom Server kommt. Dieselbe datei.txt (mit Filezilla vom Server kopiert) lokal wird vom FF aber korrekt angezeigt.
Kann eine pure Textdatei per PHP ein UTF8-Etikett bekommen? Mein Editor Geany kennt die Funktion Dokument > Unicode BOM schreiben. Habe ich angewendet, datei.txt wieder hochgeladen und nun kennt der FF auch die Umlaute, wenn sie vom Server kommen.
Habe natürlich im Web recherchiert, aber keinen brauchbaren Tipp gefunden.
Wird dieser BOMmel auch von anderen Umgebungen, z.B. Javascript akzeptiert?
Gruß, Linuchs
Tach!
Kann eine pure Textdatei per PHP ein UTF8-Etikett bekommen? Mein Editor Geany kennt die Funktion Dokument > Unicode BOM schreiben. Habe ich angewendet, datei.txt wieder hochgeladen und nun kennt der FF auch die Umlaute, wenn sie vom Server kommen.
Mehr als die BOM gibt es nicht. Zur Kodierung von Textdateien werden in den Dateisystemen keine Metadaten gespeichert. Und es gibt auch keinen systemübergreifenden Mechanismus, sie dem Empfänger mitzuteilen.
Im Falle von HTTP allerdings gibt es den Content-Type-Header und der kennt auch ein (optionales) charset-Attribut. Wenn dein Server also dieses Attribut mitgibt, kann der Empfänger auch ohne BOM den Inhalt richtig interpretieren.
Wird dieser BOMmel auch von anderen Umgebungen, z.B. Javascript akzeptiert?
Eine BOM wird bei UTF-8 nicht benötigt, weil hier die Bytereihenfolge festgelegt ist. Sie dient damit lediglich als Indikator, dass es sich um UTF-8 handelt. Die BOM ist ansonsten ein Teil des Unicode-Standards, und immer mehr Systeme erkennen sie. Garantiert ist das allerdings nicht.
dedlfix.
Hallo,
Im Falle von HTTP allerdings gibt es den Content-Type-Header und der kennt auch ein (optionales) charset-Attribut. Wenn dein Server also dieses Attribut mitgibt, kann der Empfänger auch ohne BOM den Inhalt richtig interpretieren.
korrekt. Und auch wenn das charset-Attribut optional ist, empfehle ich seine Verwendung bei textbasierten Dateiformaten wärmstens.
Wird dieser BOMmel auch von anderen Umgebungen, z.B. Javascript akzeptiert?
Eine BOM wird bei UTF-8 nicht benötigt, weil hier die Bytereihenfolge festgelegt ist.
Ja und nein. Ohne BOM weiß die verarbeitende Software nur: Wenn es irgendeine Unicode-Codierung sein soll, dann UTF-8. Es könnte aber auch so ziemlich jede 1-Byte-ISO-Codierung sein.
Mit BOM, auch bei UTF-8, ist der Fall dagegen klar.
Lästiger Nebeneffekt: Nicht jede Software erkennt die BOM als das, was sie sein soll. Und bei PHP-Dateien, die als UTF-8 mit BOM gespeichert sind, gilt die BOM aus PHP-Sicht bereits als Nutzinhalt. Ein nachfolgendes Senden von HTTP-Headern ist dann nur noch sehr umständlich möglich.
Meine Empfehlung ist daher, vorzugsweise ohne BOM zu speichern und stattdessen lieber andere Methoden zu nutzen (etwa wie erwähnt im HTTP-Header). Nur wenn es zwingend notwendig ist, weil irgendeine Softwarekomponente sonst partout nicht kooperieren möchte, würde ich widerwillig eine BOM verwenden.
Ciao,
Martin
Tach!
Eine BOM wird bei UTF-8 nicht benötigt, weil hier die Bytereihenfolge festgelegt ist.
Ja und nein. Ohne BOM weiß die verarbeitende Software nur: Wenn es irgendeine Unicode-Codierung sein soll, dann UTF-8. Es könnte aber auch so ziemlich jede 1-Byte-ISO-Codierung sein.
Mit BOM, auch bei UTF-8, ist der Fall dagegen klar.
Die Aufgabe der BOM ist, die Bytereihenfolge anzuzeigen, nicht die Kodierung des Dokuments. Dass man die BOM auch dafür nutzen kann, ist eine nicht beabsichtigte Nebenwirkung und ändert nichts daran, dass sie nicht benötigt wird, um ein UTF-8-Dokument korrekt zu lesen (wenn der Empfänger die Kodierung bereits kennt).
dedlfix.
Hallo Martin,
Ohne BOM weiß die verarbeitende Software nur: Wenn es irgendeine Unicode-Codierung sein soll, dann UTF-8.
Das BOM ist keine Pflicht. In keiner Codierung.
Rolf
Hallo,
Ohne BOM weiß die verarbeitende Software nur: Wenn es irgendeine Unicode-Codierung sein soll, dann UTF-8.
Das BOM ist keine Pflicht. In keiner Codierung.
das habe ich auch nicht gesagt. Aber du hast natürlich recht, die oben zitierte Aussage ist nicht korrekt. Wenn die Codierung und ggf. die Byte Order bekannt ist, braucht man keine BOM. Ohne BOM heißt also nicht zwingend UTF-8.
Allerdings gilt auch der Umkehrschluss: Wenn man sie weglässt, muss die Codierung anhand anderer Merkmale oder Informationen bestimmt oder vereinbart werden. Oder sie ist für eine bestimmte Umgebung einfach festgelegt (z.B. vom Softwareentwickler).
Schönes Wochenende,
Martin
Doch bei Kontroll-Anzeige der datei.txt mit dem Firefox sind die Umlaute verkrüppelt, Firefox erkennt also die UTF8 Codierung nicht.
Nein. Wenn die Textdatei keine BOM enthält, kann der Browser nicht wissen, was es ist. Das er beim lokalen Öffnen UTF-8 verwendet liegt an den Einstellungen des OS. Möglicherweise fügt aber Dein Webserver sogar Header mit einer falschen Kodierung bei, weil er es nicht anders weiß.
Lösung:
Sende vor der Textdatei einen header:
PHP:
Tabellenkalkheader( 'Content-Type: text/plain; charset=utf-8' );
und/oder Apache: (.htaccess)
AddDefaultCharset UTF-8
IndexOptions +Charset=UTF-8
Tach!
und/oder Apache: (.htaccess)
AddDefaultCharset UTF-8 IndexOptions +Charset=UTF-8
IndexOptions ist nur zuständig, wenn der Webserver ein Indexdokument generiert. Für die Angabe von Kodierungen anderer Dateien ist es nicht verwendbar, das ist Aufgabe von AddDefaultCharset und AddCharset.
dedlfix.
IndexOptions ist nur zuständig, wenn der Webserver ein Indexdokument generiert.
Ja. Ich habs stillschweigend mit reingesetzt, weil das XAMPP-Paket mit seinen merkwürdigen Voreinstellungen sonst womöglich weitere Fragen generiert. (Und gedacht, der Name "IndexOptions" sei eindeutig genug um zu zeigen, was das bewirkt).
Wird dieser BOMmel auch von anderen Umgebungen, z.B. Javascript akzeptiert?
Ich hab das hier mit einer csv datei mal untersucht für Dich. Keine Problems mit das BOM. MFG
Kommt das nicht ganz sehr darauf an, was man mit „Ich hab das hier mit einer csv datei mal untersucht“ so alles verbirgt? Da wäre nämlich die Frage, womit und worauf hin man die CSV-Datei "untersucht" hat und vor allem, wie man diese verarbeitet. Zerlegt man eine solche Datei nur anhand der Zeilen-und Spaltentrenner, so findet sich die BOM just im ersten Datentupel des ersten Datensatzes.
Ich würde das nicht mit „Keine Problems mit das BOM“ umschreiben wollen. Auch nicht - nach Retten des Dativs - mit „Keine Probleme mit dem BOM“.
Zerlegt man eine solche Datei nur anhand der Zeilen-und Spaltentrenner, so findet sich die BOM just im ersten Datentupel des ersten Datensatzes.
Ne, eben nicht. Aber Du kannst gerne weiterforschen ob split() das rausfiltert oder Mustache.js. Den Code hab ich ja offengelegt!
Tach!
Zerlegt man eine solche Datei nur anhand der Zeilen-und Spaltentrenner, so findet sich die BOM just im ersten Datentupel des ersten Datensatzes.
Ne, eben nicht. Aber Du kannst gerne weiterforschen ob split() das rausfiltert oder Mustache.js. Den Code hab ich ja offengelegt!
Das Problem daran ist, dass deine Datei wahlkreise.csv keine BOM enthält, so wie sie im Moment vom Server geliefert wird. Außerdem nimmst du die erste Zeile und wirfst sie ungesehen weg, weil du den Header der CSV-Datei nicht brauchst. Also was genau gibt es da jetzt zu sehen?
dedlfix.
Tach!
Zerlegt man eine solche Datei nur anhand der Zeilen-und Spaltentrenner, so findet sich die BOM just im ersten Datentupel des ersten Datensatzes.
Ne, eben nicht. Aber Du kannst gerne weiterforschen ob split() das rausfiltert oder Mustache.js. Den Code hab ich ja offengelegt!
Das Problem daran ist, dass deine Datei wahlkreise.csv keine BOM enthält, so wie sie im Moment vom Server geliefert wird.
Man testet ja auch nicht auf einem Produktivsystem!
Außerdem nimmst du die erste Zeile und wirfst sie ungesehen weg,
Das ist falsch!
weil du den Header der CSV-Datei nicht brauchst.
auch falsch! Der Code zeigt doch was mit der 1. Zeile gemacht wird! MFG
Tach!
Das Problem daran ist, dass deine Datei wahlkreise.csv keine BOM enthält, so wie sie im Moment vom Server geliefert wird.
Man testet ja auch nicht auf einem Produktivsystem!
Der Zusammenhang dabei und vor allem in Bezug auf die BOM ist dabei welcher? Wie soll das Beispiel etwas zeigen, wenn das eigentlich interessante Objekt gar nicht im Spiel ist?
Außerdem nimmst du die erste Zeile und wirfst sie ungesehen weg,
Das ist falsch!
weil du den Header der CSV-Datei nicht brauchst.
auch falsch! Der Code zeigt doch was mit der 1. Zeile gemacht wird!
Stimmt, da hab ich nicht genau hingesehen. Ändert aber auch nichts daran, dass du etwas zum Umgang mit einer BOM zeigen möchtest, wo gar keine BOM vorkommt.
dedlfix.
Wird dieser BOMmel auch von anderen Umgebungen, z.B. Javascript akzeptiert?
Ich hab das hier mit einer csv datei mal untersucht für Dich. Keine Problems mit das BOM. MFG
Das ist schön. Warum heißt Du jetzt eigentlich Emil?
Wird dieser BOMmel auch von anderen Umgebungen, z.B. Javascript akzeptiert?
Ich hab das hier mit einer csv datei mal untersucht für Dich. Keine Problems mit das BOM. MFG
Das ist schön. Warum heißt Du jetzt eigentlich Emil?
Wieso heißt Du jetzt Mitleser?
Wird dieser BOMmel auch von anderen Umgebungen, z.B. Javascript akzeptiert?
Ich hab das hier mit einer csv datei mal untersucht für Dich. Keine Problems mit das BOM. MFG
Das ist schön. Warum heißt Du jetzt eigentlich Emil?
"Der Beitrag ist unkonstruktiv oder provokativ"
Dem muss ich widersprechen. Der Beitrag ist unkonstruktiv und provokativ.
Hallo,
Dem muss ich widersprechen.
Nö, musst du nicht. Da stand kein „entweder“
Gruß
Kalk
Wird dieser BOMmel auch von anderen Umgebungen, z.B. Javascript akzeptiert?
Ich hab das hier mit einer csv datei mal untersucht für Dich. Keine Problems mit das BOM. MFG
Ergänzung:
Wie der CODE zeigt, wird auf die 1. Zeile der CSV Datei die JS-funktion split() angewandt. Eine für UTF-8 erzeugte BOM hat die Bytefolge 0xEF, 0xBB, 0xBF und befindet sich sozusagen direkt am Anfang der 1. Spalte WKR_NR.
Die Funktion split() ist jedoch so intelligent und filtert die BOM raus. Übrig bleibt nach dem split() tatsächlich WKR_NR ohne BOM.
Zumindest ist das im FF der Fall. Wer möchte kann das gerne selber nachvollziehen und auch selber recherchieren ob das irgendwo dokumentiert ist. MFG
Tach!
Wie der CODE zeigt, wird auf die 1. Zeile der CSV Datei die JS-funktion split() angewandt. Eine für UTF-8 erzeugte BOM hat die Bytefolge 0xEF, 0xBB, 0xBF und befindet sich sozusagen direkt am Anfang der 1. Spalte WKR_NR.
Die Funktion split() ist jedoch so intelligent und filtert die BOM raus. Übrig bleibt nach dem split() tatsächlich WKR_NR ohne BOM.
Hast du das wirklich überprüft, dass die BOM vor dem split() noch da ist und nicht bereits vorher entfernt wurde?
Zumindest ist das im FF der Fall. Wer möchte kann das gerne selber nachvollziehen und auch selber recherchieren ob das irgendwo dokumentiert ist.
Kann ich nicht nachvollziehen.
dedlfix.
Wenn Du's nachvollziehen willst, dann nimm bitte die BOM die ich angegeben habe und nicht willkürlich eine Andere!
Hallo Emil,
Wenn Du's nachvollziehen willst, dann nimm bitte die BOM die ich angegeben habe und nicht willkürlich eine Andere!
Warum nimmst du denn eine spezielle BOM?
Bis demnächst
Matthias
Tach!
Wenn Du's nachvollziehen willst, dann nimm bitte die BOM die ich angegeben habe und nicht willkürlich eine Andere!
Es gibt nur eine BOM: das Zeichen mit dem Codepoint U+FEFF. Genau das habe ich verwendet.
Also nochmal die Frage: Wie hast du geprüft, dass die BOM noch da ist, bevor du split() aufgerufen hast?
dedlfix.
Tach!
Wenn Du's nachvollziehen willst, dann nimm bitte die BOM die ich angegeben habe und nicht willkürlich eine Andere!
Also wenn "eine BOM", wie Du es beschreibst, "keinerlei Probleme" machen soll, dann darf es mit keiner BOM irgendwelche Probleme geben. Insoweit ist Deine Forderung neben der Sache.
Es gibt nur eine BOM
Ist missverstehbar: Wikipedia beschreibt eine BOM pro Kodierung.
Tach!
Ist missverstehbar: Wikipedia beschreibt eine BOM pro Kodierung.
Zitat: "eine charakteristische Bytefolge, die das Unicode-Zeichen U+FEFF (englisch zero width no-break space) codiert". Es gibt nur eine BOM, die sieht in diversen Kodierungen nur unterschiedlich aus. Auf Zeichenebene ist es aber immer dasselbe Zeichen.
dedlfix.
Mein lieber Dedlfix!
Ich habe nach allerhöchstem Bedacht nicht geschrieben, dass Du Unrecht hast, sondern dargelegt, dass Deine Äußerung "Es gibt nur eine BOM" missverstehbar ist. Auf Zeichenebene mag es nur eine "BOM" geben. Sieht man sich indes die (an diesem Punkt der Verarbeitung) für Programme (noch) wichtigen Bytes an, so sind in der offensichtlichen Absicht, eine Unterscheidbarkeit zu schaffen, einige unterschiedliche BOM für unterschiedliche Kodierungen definiert.
Wird dieser BOMmel auch von anderen Umgebungen, z.B. Javascript akzeptiert?
Ich hab das hier mit einer csv datei mal untersucht für Dich. Keine Problems mit das BOM. MFG
Ergänzung:
Wie der CODE zeigt, wird auf die 1. Zeile der CSV Datei die JS-funktion split() angewandt. Eine für UTF-8 erzeugte BOM hat die Bytefolge 0xEF, 0xBB, 0xBF und befindet sich sozusagen direkt am Anfang der 1. Spalte WKR_NR.
Die Funktion split() ist jedoch so intelligent und filtert die BOM raus. Übrig bleibt nach dem split() tatsächlich WKR_NR ohne BOM.
Zumindest ist das im FF der Fall. Wer möchte kann das gerne selber nachvollziehen und auch selber recherchieren ob das irgendwo dokumentiert ist. MFG
PS: Diese Bytefolge 0xEF, 0xBB, 0xBF (BOM für UTF-8!) wird übrigens auch entfernt wenn sie sich mittendrin im Text befindet.
Hallo Emil,
PS: Diese Bytefolge 0xEF, 0xBB, 0xBF (BOM für UTF-8!) wird übrigens auch entfernt wenn sie sich mittendrin im Text befindet.
Das ist gar nicht gut. Manchmal braucht man ein nullbreites geschütztes Leerzeichen als Wortverbinder.
Bis demnächst
Matthias
Tach!
PS: Diese Bytefolge 0xEF, 0xBB, 0xBF (BOM für UTF-8!) wird übrigens auch entfernt wenn sie sich mittendrin im Text befindet.
Auch das stimmt nicht. Javascript arbeitet (abgesehen von speziellen Objekten) bei Strings zeichenorientiert. Wenn du Bytes siehst, bist du nicht in Javascript, sondern irgendwo außerhalb.
dedlfix.
Hallo Emil,
PS: Diese Bytefolge 0xEF, 0xBB, 0xBF (BOM für UTF-8!) wird übrigens auch entfernt wenn sie sich mittendrin im Text befindet.
Nein, wird sie nicht. Das kannst Du allerdings bei Dir nicht feststellen, weil deine wahlkreis.csv kein einziges U+FEFF Zeichen enthält.
Ich habe mir eine CSV Datei gebastelt, die am Anfang und mittendrin ein BOM enthält. Diese habe ich per AJAX gefetcht, mit split(';') geteilt und dann die gelieferten Zeichencodes mit charCodeAt() analysiert.
Ergebnis: ein initiales BOM wird - mutmaßlich - vom XMLHttpRequest entfernt, es ist im responseText nicht mehr enthalten. Spätere U+FEFF Zeichen werden nicht entfernt. Auch nicht durch ein split. Getestet habe ich mit Chrome und Firefox.
Fazit: Die Welt ist so, wie man sie erwarten sollte.
Und nur für Dich offenbare ich dafür auch meine Dummy-Homepage, auf der ich das hinterlegt habe - damit Du mir nicht erzählst, ich würde virtuell herumphantasieren statt irgendwas vorzulegen.
http://borchmann.one/test/csvbom.html
Was passiert, steht im Code. Kennst Du ja.
Rolf
Mit ajax oder fetch hat das gar nichs zu tun. Das BOM wird von split entfernt, Code zum testen:
function getbom(){
var str = "\uFEFF"+"a;b"+"\uFEFF";
var ab = str.split(";");
var bb = new Blob([str]);
console.log( "Länge String mit BOM: "+bb.size+" bytes\n", ab );
}
und hier die DEMO, Console gucken:
Länge String mit BOM: 9 bytes
Array [ "a", "b" ]
Die BOM wird sowohl am Anfang als auch am Ende entfernt. So geht eine sachliche Diskussion!
Hallo Emipl,
So geht eine sachliche Diskussion!
Eher nicht. Dein Beitrag ist unsachlich, weil er Fakten ignoriert und den Leser zu täuschen versucht. Die Konsole zeigt das BOM nicht an, wie ich zuvor schon feststellte. Hast du dir meine Demo überhaupt angeschaut?
Lass dir die Längen der Strings in ab sowie die Zeichen darin, von 0 bis ab[i].length-1, mit charCodeAt ausgeben, so wie ich das getan habe. Dann wirst du sehen, dass das BOM da noch drin ist.
Rolf
Tach!
Mit ajax oder fetch hat das gar nichs zu tun. Das BOM wird von split entfernt, Code zum testen:
Auch ich habe das bei mir so gesehen, dass nach einem Ajax-Request keine BOM am Anfang der Daten mehr enthalten war. Dazu habe ich deinen Code genommen und die wahlkreise.csv um eine BOM erweitert. Sie war ja ohne. Überprüft habe ich die Datei mit einem Hexdump, die BOM und Umlaute waren da und UTF-8-kodiert. Nach dem Ajax-Request war das Zeichen charCodeAt(0) bereits keine BOM mehr. Deswegen habe ich dich ja aufgefordert, den String nach dem Ajax-Request und vor dem split() zu überprüfen.
function getbom(){ var str = "\uFEFF"+"a;b"+"\uFEFF"; var ab = str.split(";"); var bb = new Blob([str]); console.log( "Länge String mit BOM: "+bb.size+" bytes\n", ab ); }und hier die DEMO, Console gucken:
Länge String mit BOM: 9 bytes Array [ "a", "b" ]Die BOM wird sowohl am Anfang als auch am Ende entfernt.
Ist vielleicht immer noch einfach nur dein Firefox zu alt? Jedenfalls prüfst du hier nur die Länge des zum Blob gewandelten String vor dem split() einerseits und siehst das was dir die Console andererseits anzeigt. Es wäre sinnvoll, die beiden Teilstrings in ab genauer zu untersuchen.
Bei mir im aktuellen Firefox sieht das Ergebnis jedenfalls so aus.
Beide BOMs sind noch vorhanden. Ich erweitere mal deine Codevorlage, so dass ich von den beiden Teilstrings sowohl die Länge in Zeichen als auch die Codepoints der Zeichen ausgebe.
Ich sehe da also eine Länge von jeweils zwei Zeichen und die vorhandenen BOMs.
Die BOM wird mir allerdings nicht angezeigt, wenn ich die Strings mit alert(ab[0]) ausgebe oder direkt in console.log(ab[0]) als String anstatt in einem Array. Das ist aber nur ein Problem der Anzeige, denn mit charCodeAt() lässt sich nach wie vor prüfen, dass die Zeichen da sind.
Der Chrome hingegen zeigt die BOMs auch bei Strings innerhalb eines Arrays nicht an. Aber auch hier lässt sich mit length und charCodeAt() die Existenz nachweisen.
dedlfix.
Soso. Da Dein Code in node nur Fehler schmeisst habe ich das mal nachgemacht:
Ohne BOM:
str = "a;b";
'a;b'
ab = str.split(";");
[ 'a', 'b' ]
ab[0].length
1
ab[1].length
1
Mit BOM:
str = "\uFEFF"+"a;b"+"\uFEFF";
'a;b'
ab = str.split(";");
[ 'a', 'b' ]
ab[0].length
2
ab[1].length
2
Die BOM wird also weder am Anfang noch am Ende noch zwischendrin und schon gar nicht von split ausgefiltert. Zu Deinem Irrtum führt Folgendes: Was die Variablen enthalten ist eine Sache, was in der Console DARGESTELLT wird und entscheidet sich hier daran, welche Zeichen DARSTELLBAR sind.
trim würde übrigens die BOM wie auch andere nicht darstellbare Zeichen am Anfang und/oder Ende entfernen (Fortsetzung von obigem):
ab[0]=ab[0].trim()
'a'
ab[0].length
1
PS: Es funktioniert auch so im Chrome. Schönen Abend und keine Ursache, ich habs gern gemacht. MFG
Hi Linuchs,
BOM ist lästig und sollte man nicht verwenden für UTF-8.
Wenn es Dir allerdings darum gehen sollte, automatisch zu erkennen, in welcher Kodierung die geleferte Datei vorliegt, dann gibt es zumindest ein paar Algorithmen, mit denen man diese abschätzen kann.
Das funktioniert leider nicht sicher, aber zur Unterscheidung von ISO8859-1 und UTF-8 reicht es meistens. Manche Editoren nutzen diese wohl auch.
Hier im Archiv gibt es bestimmt is_utf8() oder ' was Ähnliches. PHP hat da wohl auch eine Funktion. Bei den ISOs und "Codepages" sieht es schon schlechter aus. Die klassische IBM Codepage 437 und die 850 (usw.) kann man wohl nicht automatisch auseinanderhalten. Da müsstest Fu dann ggf auf dem Server ein Visualisierungsmodul basteln, mit dessn Hilfe der User entscheiden kann.
LG
RoRo
Hi,
und Filter für den Upload kannt Du auch im PHP-Prepend-File einrichten. Dann kann man sie nicht vergessen in der allgemeinen Programmierung.
LG
RoRo