CSVImport verliert die erste Spalte, wenn die Importdatei UTF8 mit BOM ist

[s.schoeling@…]

Kann man sich drüber streiten ob das ein Bug ist, BOM in UTF8 sind zwar erlaubt, werden aber vom Standard weder gefordert noch empfohlen, weil UTF8 eh byte orientiert codiert wird, und deshalb keine Endianess hat.

Problem ist, dass das BOM im ersten Headerfeld landet, was dann nicht korrekt erkannt wird.

Text::CSV hat keine Möglichkeit das zu filtern, und IO::File und IO::Handle auch nicht. Man kann das über nen IO::via Layer mit File::BOM filtern, aber das schreddert read/seek/tell Operationen auf dem Filehandle.

Bleibt eigentlich nur noch manuell filtern, oder den custom bom_open von File::BOM zu benutzen, dann gehen einem aber die Vorteile von den IO Layern verloren.

Schmeiß den Code einfach raus, der das BOM schreibt. Heutzutage kann eh jedes Textprogramm mit UTF-8 ohne BOM umgehen; BOM produziert mehr Probleme, als es löst (zumindest bei UTF-8).

Der Code der BOM schreibt nennt sich notepad.exe. Andere Programme machen son Scheiß nicht.

Ach ups, ich dachte, Lx-Office würde BOM schreiben. Hab das Ticket nur so halb gelesen.

Evil workaround: Datei normal öffnen, ersten drei Zeichen lesen & auf BOM prüfen, falls ja, an Text::CSV die geöffnete und auf Offset 3 stehende Datei übergeben.

behoben in 07a38b9f29bf31183286ac25fa460badbf0bee23