Moin!

Hmm ... ok, nur wie? *g* UltraEdit und PSPad sind die eingesetzten Editoren und da hab ich jetzt keine passende Option für gefunden. Kennst du evtl. einen ähnlich gut ausgestatteten Editor, der UTF-8 speichern kann ohne BOM?

Tja, sowas blödes aber auch. :)

UniRed macht sowas nicht (getestet mit Weaverslave, der noch kein Unicode kann).

Helfen tut dir natürlich auch jeder andere UTF-8-unfähige Browser, denn der dürfte sicher in der Lage sein, die drei ersten Byte aus der Datei rauszuwerfen. Der Windows-Notepad sollte das z.B. leisten können.

Oder alternativ: Wie kann ich den Lösungsvorschlag aus dem mitgeschickten URL umsetzen, d.h. den BOM in PHP entfernen? Hast du bzw. sonst jemand hierfür eine Idee?

Nun ja, es dürfte nicht allzu schwierig sein, eine Datei erst einzulesen, die ersten drei Byte dann zu entfernen und den Rest dann auszugeben, oder?

- Sven Rautenberg

Hallo Helge,

Hmm ... ok, nur wie? *g* UltraEdit und PSPad sind die eingesetzten Editoren
und da hab ich jetzt keine passende Option für gefunden. Kennst du evtl.
einen ähnlich gut ausgestatteten Editor, der UTF-8 speichern kann ohne BOM?

In den direkten Programmeinstellungen von UltraEdit gibt es eine derartige Option nicht. Auf http://www.ultraedit.com/products/ findet sich aber versteckt für die Versionen ab 10.10a im Changelog folgendes:

"- Added INI settings allowing user to determine if the BOM should be written:
   Write UTF-8 BOM = 1 - This setting causes the editor to write out the Byte Order Mark (BOM) header in a file
   when it is saved.
   If this is not set, it will not write out the BOM unless the file contained it when it was
   loaded into the editor. If so, the BOM will be written to the file irrespective of the setting.
   The BOM is an industry standard indicating the contents of the file for various UNICODE formats.
   This is set be default internally.
   Write UTF-8 BOM NF = 1 - This setting causes the editor to write out the Byte Order Mark (BOM) header in a file
   when it is saved if the file is a new file created within UltraEdit.
   If the Write UTF-8 BOM setting above is set, then the BOM will always be written and this is ignored.
   Otherwise, the BOM will only be written out for new files if this is set."

Oder kurz: Mit "Write UTF-8 BOM = 0" und "Write UTF-8 BOM NF = 0" kann man UltraEdit anweisen beim Neuanlegen bzw. beim Speichern der Datei die BOM-Bytes nicht zu schreiben, es sei denn die Datei enthielt diese bereits (was beim Neuanlegen nie der Fall ist).

Das er die BOM-Bytes beim Speichern nicht entfernt wenn diese vorhanden waren führt beim Konvertieren zu einem interessanten Verhalten: Wenn man eine Datei von utf-8 (mit BOM) nach ASCII konvertiert, entfernt UltraEdit die BOM Bytes. Konvertiert man die Datei _direkt_ zurück (ohne sie vorher zu schließen), sind sie jedoch wieder da.
Konvertiert man die Datei jedoch nach ASCII, schließt sie, öffnet sie erneut und konvertiert nach utf-8 werden die BOM-Bytes nicht geschrieben.

Es gibt noch etwas zu beachten: UltraEdit erkennt ohne BOM-Bytes und ohne gültige Multi-Byte Zeichen die Datei nicht als UTF-8 (was auch nicht verwundert, da sie ja mit einer ASCII-Datei 100% übereinstimmt). Erst wenn gültige Multibyte Zeichen erkannt werden wird die Datei auch ohne BOM als utf-8 erkannt, was für das Speichern von neuen Sonderzeichen wichtig ist.

PSPad schreibt wie UltraEdit die BOM-Zeichen nur, wenn diese in der Ausgangsdatei vorhanden waren. Allerdings muss man bei PSPad darauf achten _vor_ dem öffnen der Datei schon das richtige Encoding zu wählen, bzw. die Datei nach der Auswahl neu zu laden.

Ob die BOM-Bytes nun da sind oder nicht lässt sich prima mit Phase5 überprüfen, der auch noch kein unicode kann.

Bei so viel Editor-Verwirrung muss ich allerdings sagen, dass eine php-Seitige Vorbeugung die Fehlergefahr stark eingrenzen würde. Ansonsten hoffe ich, dass das weiterhilft ;-).

Grüsse,
  Christian