Mac OS X Finder verkrüppelt UTF-8-Files

So langsam komme ich meiner Feindschaft mit dem UTF-8-Format auf die Schliche! Gestern habe ich herausgefunden, dass der Finder von Mac OS X beim Duplizieren einer einfachen, unschuldigen .php-Textdatei aus dem mächtigen UTF-8-Format das hässliche MacRoman-Format macht. Ohne Witz, probiert es selber aus: Im TextWrangler eine Datei erstellen, in »UTF-8, NO BOM« umwandeln, abspeichern. Diese dann im Finder duplizieren, mit TextWrangler wieder aufmachen und staunen. Wie sagt Kollege Ralle so schön? Dreckstool!!!

update: Offensichtlich lag’s nicht am Finder, sondern an den falschen Einstellungen im TextWrangler, der meine UTF-8-PHPs nicht korrekt als solche erkannt hat und dann standardmäßig etwas anderes einstellt. Diesen Standard habe ich nun geändert. Danke!

15 Kommentare

macx

Ich weiß nicht, was du für eine Konfiguration hast, doch wenn ich meine mit Zend Studio erstellten UTF-8-php-Dateien speicher, mit dem Finder kopiere und die Kopie dann in Zend öffne, habe ich weiterhin eine rein UTF-8 kodierte Datei.

bjoern

Ähnlich geht es mir, noch nie Probleme mit UTF-8 Dateien gehabt. Und ich speicher in der Regel alles Entwicklungs-spezifische in UTF-8 ab.
Vielleicht liegt es bei mir aber auch daran, dass ich kein PHP benutze grins

CottonIJoe

vielleicht liegts an textrwrangler?
probier mal subethaedit, kann wunderbar von einer codierung in die andere konvertieren oder neu interpretieren. konnte bisher alles verkorkste lesbar machen… obwohl mir dein »bug« noch nicht aufgefallen ist!

Peter Linzenkirchner

Das stimmt so nicht, es passiert etwas anderes. PHP-Dateien sind reine Textdateien, in denen die Kodierung nicht abgespeichert wird, im Gegensatz zum Beispiel zu rtf, wo im Header drin steht, in welcher Kodierung das Dokument ist.
Es ist damit schlicht ein Problem der Voreinstellung: TextEdit zum Beispiel hat als Voreinstellung für Textdateien »Automatisch«, es wird also versuchen zu erraten, in welcher Kodierung die Textdatei ist, und sich dabei einfach immer wieder irren. Wenn man umstellt auf UTF-8, dann macht es auch alle Textdateien in UTF-8 auf – auch, wenn bei der Erstellung Mac-Roman verwendet wurde.
In meinem Editor TextMate kann ich deshalb eine Kodierung für PHP-Dateien einstellen, zum Beispiel UTF-8 oder Windows-Latin etc. Dann wird TextMate alle Dateien mit der Endung .php auch so öffnen. Falls das mal nicht stimmt, habe ich im Menü die Möglichkeit: »Erneut öffnen mit Kodierung … «. Fremde PHP-Dateien sind in aller Regel nicht in UTF-8 sondern in Windows-Latin, bei denen muss ich das immer machen.
Mit dem Finder hat das meines Wissens nichts zu tun – aber vermutlich eine Menge mit den Voreinstellungen oder der Arbeitsweise von TextWrangler. Ich kenne das Problem mit meinen Editoren (BBEdit und TextMate) nicht.

Olaf Rosendahl

Moin, Moin!
Laut meinen Informationen (und meiner Erfahrung) sollten UTF-8 Dateien immer mit BOM (Byte Order Mark) abgespeichert werden. Dann sollte es keine Probleme mit der Erkennung geben.
Die „Finder-Probleme“ kann ich hier nicht reproduzieren.
Wenn man mit UTF-8 mit BOM arbeitet, kann ich vor der Benutzung von SubEthaEdit nur warnen, da es Probleme mit BOM hat. Zu finden im BugTracker:
https://www.codingmonkeys.de/bugs/browse/HYR-437
Schade, denn eigentlich ist SEE mein Lieblingseditor. So bleibt es bei BBEdit…

Maurus

Wiedermal typisch, erst meckern dann überprüfen ;-)
So schlecht wie alle sagen ist der Finder nämlich gar nicht.

Hendrik

Ich habe es mir schon gedacht. Wie sollte das Problem am Finder liegen? Der kann doch auch sonst alle Dateien fehlerfrei kopieren. Das kann gar kein Problem mit Textdateien geben — egal welche Kodierung.

Thomas Scholz

Olaf, du kannst PHP-Dateien nicht mit einem BOM speichern. Das BOM liegt außerhalb der PHP-Tags und versaut dann alle Scripte, weil es eventuell an der falschen Stelle ausgegeben wird.

Gerrit

Hach, dann wird dieses Posting ja doch noch lehrreich. Thomas, genau das hat mir mein Kollege auch neulich erklärt. Zum Teufel mit BOM! ;-)

hukl

*schmunzel
Ja UTF8 ist ja nun wirklich eines der wenigen Dinge die der Finder problemfrei handhabt. Das hätte mich wirklich geschockt sollte es ein Finder Problem gewesen sein.
Zum BOM kann ich nur sagen: »Niemand braucht BOM«. Entweder dein Editor kann UTF8 und erkennt die Encodings automatisch oder es kann kein UTF8 und benimmt sich entsprechend daneben. Die Encodings an sich sind eigentlich eindeutig genug dass es keines BOMs bedarf. Das wurde mir aber auch erst klar als ich BOM bei meinem Lieblingseditor, Textmate, von den Entwicklern einforderte, diese mich dann aber erstmal über Encodings belehrten.
Entsprechende Wikipedia Artikel sowie die Betrachtung der unterschiedlich encodierten Files via Hexeditor beleuchten die Sache noch etwas anschaulicher:
http://en.wikipedia.org/wiki/Character_encoding

Olaf Rosendahl

Moin, Moin!
„Niemand braucht BOM“
Doch, ich. ;-)
Ich benutze kein PHP, sondern Lasso (oder vornehmer: LDML). Lasso ist einerseits der Begriff für die Sprache, andererseits für das Produkt, den Lasso Professional Server. Und Lasso benötigt unbedingt den BOM.
Lasso entstand vor vielen Jahren auf dem Mac und war zu dieser Zeit die eleganteste Möglichkeit, dynamische Websites auf dem Mac zu erstellen. Mittlerweile läuft Lasso auch auf Windows und Linux. es ist allerdings nicht kostenfrei, man erhält aber tatsächlch etwas für sein Geld.
Lasso ist wirklich elegant. Nach dem Erscheinen von MacOS X habe ich mich einmal kurz mit PHP beschäftigt, es dann aber wieder verworfen. Dann lieber gleich Python… ;-)
Wer sich für Lasso interessiert:
http://www.omnipilot.com/lasso/
Ein kurzer Blick lohnt sich auf jeden Fall!

Olaf Rosendahl

Moin, Moin!
Sorry, Nachtrag zum Thema Lasso:
http://en.wikipedia.org/wiki/Lasso_programming_language
Das soll es dann aber auch gewesen sein! ;-)

Thomas Scholz

Die automatische Erkennung ist alles andere als trivial, weil ein gültiges UTF-8-Dokument durchaus auch ein gültiges ISO-8859-1-Dokument sein kann.
Scite benutzt ein sogenanntes »UTF-Cookie«, einen eindeutigen Textstring, der innerhalb der beiden ersten Zeilen eines Dokumentes auftauchen kann (in einem Kommentar beispielsweise), um UTF_8-Dokumente ohne BOM zu erkennen.
Das entspricht zwar keinem offiziellen Standard – aber dafür funktioniert es. Man muß dann eben immer dran denken, es auch einzubauen … einer der wenigen Fälle, in denen der »menschliche Faktor« ein Mehr an Zuverlässigkeit bedeutet. :)

hukl

Hmm also ich hatte ehrlichgesagt noch keine Probleme bei der automatischen Erkennung. Spätestens seit Tiger. Egal ob es nun Text, XML, PHP, CSS, irgendwelche Configdateien von Unixtools sind. Gerade solche hacks wie ein UTF-Cookie finde ich ja höchst fraglich. Die Programmierer der Software haben da was Grundsätzliches nicht verstanden. Alle von mir verwendeten Programme kommen klaglos ohne BOM aus. Nunja, jeder so wie er kann ;)

Name geändert

Ist ja alles schon alt, trotzdem noch ein Kommentar:

Hab ein PHP-Skript in FileWrangler erst als »utf-8« abgespeichert (also mit BOM). Alles lief wunderbar, bis ich versuchte eine Weiterleitung über »header(‘Location: ...’);« einzubauen. Plötzlich ging nichts mehr: alles was ich im Browser sah, war ein leeres Fenster. Ich rufe also den Support an, der prüft, kann nichts finden, aber seine Datei mit demselben (!) Inhalt funktioniert tadellos. Nur wenn er meine Datei aufruft, sieht er ein paar merkwürdige Zeichen Datenmüll (die ich ja nicht sehe). Kopfkratzen allerseits. Dann die Lösung: Wenn ich seine und meine Datei vergleiche, dann ist meine (s.o.) utf-8, seine aber: utf-8, no BOM! Was er sieht – und was die Ausführung des Skripts stört – ist also offensichtlich, das, was Thomas Scholz oben beschreiben hat: »Das BOM liegt außerhalb der PHP-Tags und versaut dann alle Scripte, weil es eventuell an der falschen Stelle ausgegeben wird.«

Kommentar verfassen

Mit dem Absenden dieses Formulars erklären Sie sich damit einverstanden, dass ich die von Ihnen eingegeben Daten auf meinem Webserver speichere. Ihr Name, der Kommentartext und die angegeben Website werden für die anderen Besucher von praegnanz.de angezeigt. Ich gebe jedoch insbesondere Ihre E-Mail-Adresse nicht an Dritte weiter und nutze diese auch nicht zu Marketing- oder Statistik-Zwecken. Sie können alle Daten zu einem späteren Zeitpunkt wieder entfernen lassen.