Hallo!

Seit einiger Zeit schreibe ich meine Webseiten in dem Windows-Editor sowie in Apples TextEdit.

Mir ist beim Windows-Editor aufgefallen, wenn ich die Datei in der Codierung "Unicode" speichere, wird 40,9 KB groß. Speichere ich diese mit der Codierung "UTF-8" nimmt die gleiche Datei nur noch 20,7 KB in Anspruch.

Und jetzt meine Frage, kann TextEdit Dateien als UTF-8 speichern?

Ich möchte ungerne so riesige Dateien auf den Server laden.

Vielen Dank!

MfG

Schau mal in die Einstellungen von TextEdit...

kannste beim speichern auch angeben.
für texte, die </div> enthalten, kann ich auch Smultron (kostenlos) empfehlen. ist auch "nur" ein editor ohne sinnlosen quatsch, hat aber syntax highlighting für so ziemlich alles.

Bei TextEdit => Einstellungen => Reiter "Öffnen und Sichern" und dann Codierung für reine Textdaten.
Grüße Michi

void:
Da Smultron ja leider nicht mehr weiterentickelt wird, lohnt es sich Fraise anzuschauen. Basiert auf Smultron und ist auch kostenlos:

Nimm TextWrangler, kann alles, kostet nix

du meinst, den Speichern unter - Dialog von TextEdit

Nein, ich meine die Einstellungen. Sonst hätte ich Speichern-unter-Dialog gesagt

Unicode.org: UTF-8, UTF-16, UTF-32 & BOM: FAQ

insbesondere FAQ http://unicode.org/faq/utf_bom.html#gen6

Sprich: UTF-8 verbraucht am wenigstens Speicherplatz (8 Bits pro Zeichen), und kein BOM ist zur Erkennung zwingend notwendig, UTF-16 mehr (16 Bits pro Zeichen) und UTF-32 noch mehr (43 Bits pro Zeichen) -- in letzteren beiden Fällen ist ein BOM (Byte Order Mark) oder eine big-/little endian Byte Order zwingend notwendig .

Fürs WWW bzw. für Deine Zwecke ist UTF-8 ohne BOM vollkommen ausreichend bzw. den beiden anderen umfänglicheren Unicode-Arten zur Vermeidung von Problemen und aus genau den Gründen, weshalb Du hier fragst (UTF16, UTF32 machen eien Datei größer, weil jedes Zeichen mehr Bits verbraucht bzw. reserviert bekommt) unbedingt vorzuziehen. Das Dateisystem HFS+ von MacOSX und Microsofts NTFS und auch verschiedene andere Unix-Dateisysteme verwenden z.B. für ihre Dateinamen nahezu alle UTF-16.

Die Möglichkeiten bzw. die Bandbreite von UTF-16 und UTF-32 sind aber für die Zwecke im WWW völliger Overkill, da reicht UTF-8 vollkommen und erschöpfend aus bzw. ist die empfohlene Codierung der Wahl, wenn's um Unicode geht.

Passend dazu siehe auch:
W3C: Setting encoding in web authoring applications


Nachtrag: Wenn Du Deine Datei wie obig beschrieben einfach nur als "Unicode" abgespeichert hast statt als UTF-8 und Dir das Ergebnis zu groß ist, dann spricht vieles dafür, dass diese Datei als UTF-16 oder sogar als UTF-32 abgespeichert und jedes enthaltene Zeichen darin also mit mehr Bytes (16 Bit oder gar 32 Bit) abgespeichert worden ist. Overkill und für Deine Zwecke also unnötig bzw. kontraproduktiv.

dom_beta:

Nachtrag: Wenn Du Deine Datei wie obig beschrieben einfach nur als "Unicode" abgespeichert hast statt als UTF-8 und Dir das Ergebnis zu groß ist, dann spricht vieles dafür, dass diese Datei als UTF-16 oder sogar als UTF-32 abgespeichert und jedes enthaltene Zeichen darin also mit mehr Bytes (16 Bit oder gar 32 Bit) abgespeichert worden ist. Overkill und für Deine Zwecke also unnötig bzw. kontraproduktiv. Und wenn UTF-8- dann bitte drauf achten, dass ohne BOM abgespeichert wird (mancher Editor hat da standardmäßig "UTF mit BOM" teilweise voreingestellt). BOM bringt teilweise Probleme. Es darf nur ein einziges Mal auftauchen -- nämlich ganz am Anfang einer Datei, es muss die erste Byte-Sequenz dieser Datei überhaupt sein (kann man prima auch mit einem Hex-Editor sehen).
Das Vorhandensein des BOMs signalisiert: es folgt Unicode. Ausnahme: UTF-8, da brauchts ein solches BOM nicht zwingendermaßen, da er folgt die Erkennung anders.

Setzt sich eine Datei z.B. aus mehreren Code-Templates zusammen, und jedes Code-Template hat seinerseits wiederum am Dateianfang ein BOM stehen, fangen damit z.B. schon mal die Probleme an, weil plötzlich mehrere BOMs quer durch die Ergebnis-Datei verteilt sind durch die zusammengesetzten Text-Fragmente (wenn man z.B. mit SSI arbeitet oder PHP Includes) und damit unschöne Ergebnisse am Bildschirm nach sich ziehen bis hin zur kompletten Unleserlichkeit. Deshalb im WWW: UTF-8 möglichst ohne BOM, UTF-8 braucht kein BOM um die meisten Zeichen des Unicode-Spektrums umzusetzen. BOM dann, wenn man UTF-16 oder UTF-32 verwendet, dann ist es quasi zwingend.