Unicode (UTF-8 mit Signatur) - Codepage 65001 beim Speichern

[Lupus Goebel]

Hallöschen,


ich arbeite mit Microsoft Visual Web Developer 2008 Express Edition und
muss wegen einem Serverfehler alle Dateien öffnen und neu speichern.
Bisher hatte ich bei Speichern unter:

Unicode (UTF-8 ohne Signatur) - Codepage 65001

angegeben. Nun muss alles als

Unicode (UTF-8 mit Signatur) - Codepage 65001

gespeichert werden.

Gibt es da ein Trick wie ich alle auf einmal neu speichern kann oder
muss ich wirklich alle Dateien einzeln öffnen?

Darüber hinaus habe ich noch MS Expression Web 2 und Expression Web 4.
Evtl. kann ich ja die dazu missbrauchen per VBA oder einem ADD-Inn?

Mein Provider arbeitet am Problem und ich hoffe das er vor mir eine
Lösung findet. Bis dahin kann ich die Codierung in der web.config nicht
eintragen. Denn so hatte ich es bisher und da ging es prima.

[Arno Welzel]

Post by Lupus Goebel
Hallöschen,
ich arbeite mit Microsoft Visual Web Developer 2008 Express Edition und
muss wegen einem Serverfehler alle Dateien öffnen und neu speichern.
Unicode (UTF-8 ohne Signatur) - Codepage 65001
angegeben. Nun muss alles als
Unicode (UTF-8 mit Signatur) - Codepage 65001
gespeichert werden.

Gemeint damit vermutlich UTF-8 bisher ohne Byte-Order-Mark und jetzt
soll es mit Byte-Order-Mark sein.

Post by Lupus Goebel
Gibt es da ein Trick wie ich alle auf einmal neu speichern kann oder
muss ich wirklich alle Dateien einzeln öffnen?

Ich würde eher eine Kommandozeilentool zur Konvertierung nehmen, z.B.
"recode":

<http://gnuwin32.sourceforge.net/packages/recode.htm>

Dass dann ggf. mit einem kleinen Script kombiniert sollte je nach Zahl
der zu bearbeitenden Dateien evtl. schneller gehen, als in Visual Web
Developer.

[Stefan Scholl]

Post by Arno Welzel

Post by Lupus Goebel
Unicode (UTF-8 mit Signatur) - Codepage 65001
gespeichert werden.

Gemeint damit vermutlich UTF-8 bisher ohne Byte-Order-Mark und jetzt
soll es mit Byte-Order-Mark sein.

Post by Lupus Goebel
Gibt es da ein Trick wie ich alle auf einmal neu speichern kann oder
muss ich wirklich alle Dateien einzeln öffnen?

Ich würde eher eine Kommandozeilentool zur Konvertierung nehmen, z.B.

Kann Recode UTF-8 mit BOM? Weil die BOM ist eigentlich unnötig in
dem Fall und nur eine Microsoft-Spinnerei unter Windows.


Ggf. eher ein Script schreiben welches die 3 Bytes 0xEF,0xBB,0xBF
an jede Datei voran stellt.

[Christoph Schneegans]

Weil die BOM ist eigentlich unnötig in dem Fall und nur eine
Microsoft-Spinnerei unter Windows.

Spinnerei, schon klar. Die unbestreitbaren Vorteile von UTF-8-BOMs
bezweifeln nach meiner Erfahrung nur Leute, die irgendeine Software
aus dem letzten Jahrtausend einsetzen (müssen), die BOMs nicht
versteht. Rein interessehalber, welche ist es denn bei dir?

[Claus Reibenstein]

Post by Christoph Schneegans

Weil die BOM ist eigentlich unnötig in dem Fall und nur eine
Microsoft-Spinnerei unter Windows.

Spinnerei, schon klar. Die unbestreitbaren Vorteile von UTF-8-BOMs

Als da wären?

Gruß. Claus

[Paul Ebermann]

Post by Claus Reibenstein

Post by Christoph Schneegans

Weil die BOM ist eigentlich unnötig in dem Fall und nur eine
Microsoft-Spinnerei unter Windows.

Spinnerei, schon klar. Die unbestreitbaren Vorteile von UTF-8-BOMs

Als da wären?

Hmm, ich sehe genau einen: Man erkennt sofort, dass die jeweilige Datei
(bzw. der Datenstrom) UTF-8-kodiert ist, was man sonst erraten müsste
(oder aus eventuell mitgeschickten MIME-Headern oder erkennt - im
Dateisystem gibt es die aber meiner Erfahrung nach leider nicht).

Nachteile sind halt, dass alle Software, die etwas anderes da erwartet,
dann nicht mehr funktioniert, also etwa das #! in ausführbaren
Skript-Dateien in Unix.

Und bei Systemen wie PHP wird dadurch gleich etwas (nämlich die BOM)
ausgegeben, was einen daran hindert, noch vorher die Header-Zeilen zu
ändern, und auch daran, andere Daten als UTF-8-Text auszugeben (z.B.
Bilder oder mal einen UTF-16-Text).

Klar, das könnte man ändern, indem man alle entsprechende Software so
anpasst, dass eine UTF-8-BOM da ignoriert wird (und dann sollte
konsequenterweise auch eine UTF-16-BOM dazu führen, dass der Quelltext
auch als UTF-16 interpretiert werden kann).


Paul

[Stefan+ (Stefan Froehlich)]

Post by Paul Ebermann
Nachteile sind halt, dass alle Software, die etwas anderes da
erwartet, dann nicht mehr funktioniert, also etwa das #! in
ausführbaren Skript-Dateien in Unix.

Ich halte ganz generell jede Art von Metainformation innerhalb einer
Datei fuer groben Unfug (genau aus diesem Grund, weil man sich dann
nie mehr sicher sein kann, wer was wie interpretiert oder auch
nicht).

Post by Paul Ebermann
Klar, das könnte man ändern, indem man alle entsprechende Software
so anpasst, dass eine UTF-8-BOM da ignoriert wird (und dann sollte
konsequenterweise auch eine UTF-16-BOM dazu führen, dass der
Quelltext auch als UTF-16 interpretiert werden kann).

Noch netter waere es, wenn sich z.B. die Betriebssysteme um
derartigen Schnickschnack kuemmer wuerden. Aber zugegeben, das
zeichnet sich jetzt auch nicht gerade ab.

Servus,
Stefan

[Paul Ebermann]

Post by Stefan+ (Stefan Froehlich)

Post by Paul Ebermann
Nachteile sind halt, dass alle Software, die etwas anderes da
erwartet, dann nicht mehr funktioniert, also etwa das #! in
ausführbaren Skript-Dateien in Unix.

Ich halte ganz generell jede Art von Metainformation innerhalb einer
Datei fuer groben Unfug (genau aus diesem Grund, weil man sich dann
nie mehr sicher sein kann, wer was wie interpretiert oder auch
nicht).

Hmm, wo würdest du denn solche Metainformationen ("verwende bitte bash,
um dieses Skript auszuführen", "diese Datei ist XHTML, Latin-1-kodiert")
sonst unterbringen? Mit MIME (in E-Mails und HTTP z.B.) kann man das in
die entsprechenden Header-Zeilen schreiben, aber als Dateien?
Soll das Dateisystem (bzw. "alle Dateisysteme") ein paar passende Felder
bereitstellen, so dass das da abgelegt werden kann?

Dann braucht man nur noch Unterstützung dafür in in etwa allen
Editoren/Betriebssystemen/Programmiersprachen/Archiv-Formaten.

Ansonsten geht solche Information gerne mal verloren, wenn eine Datei
kopiert wird. Im Inneren der Datei sind sie gegen das "Verlorengehen"
immer noch am besten geschützt.

Paul

[Claus Reibenstein]

Post by Paul Ebermann
Hmm, wo würdest du denn solche Metainformationen ("verwende bitte bash,
um dieses Skript auszuführen", "diese Datei ist XHTML, Latin-1-kodiert")
sonst unterbringen?

In den Dateiattributen.

Post by Paul Ebermann
Soll das Dateisystem (bzw. "alle Dateisysteme") ein paar passende Felder
bereitstellen, so dass das da abgelegt werden kann?

OS/2 tut das schon seit Jahren. Wie detailliert diese Attribute heute
sind, kann ich allerdings nicht sagen. Meine OS/2-Zeit liegt dank IBM
schon einige Jahre zurück.

Bei anderen Betriebssystemen sieht es allerdings ziemlich schlecht damit
aus.

Post by Paul Ebermann
Dann braucht man nur noch Unterstützung dafür in in etwa allen
Editoren/Betriebssystemen/Programmiersprachen/Archiv-Formaten.

Ich gehe mal davon aus, dass die entsprechenden OS/2-Tools dies auch tun.

Post by Paul Ebermann
Ansonsten geht solche Information gerne mal verloren, wenn eine Datei
kopiert wird.

OS/2 kopiert diese Attribute mit.

Post by Paul Ebermann
Im Inneren der Datei sind sie gegen das "Verlorengehen"
immer noch am besten geschützt.

Stören dort aber das eine oder andere Tool, welches damit nicht klar kommt.

Gruß. Claus

[Gustaf Mossakowski]

Post by Claus Reibenstein

Post by Paul Ebermann
Hmm, wo würdest du denn solche Metainformationen ("verwende bitte
bash, um dieses Skript auszuführen", "diese Datei ist XHTML,
Latin-1-kodiert") sonst unterbringen?

In den Dateiattributen.

Post by Paul Ebermann
Soll das Dateisystem (bzw. "alle Dateisysteme") ein paar passende
Felder bereitstellen, so dass das da abgelegt werden kann?

OS/2 tut das schon seit Jahren. Wie detailliert diese Attribute heute
sind, kann ich allerdings nicht sagen. Meine OS/2-Zeit liegt dank IBM
schon einige Jahre zurück.
Bei anderen Betriebssystemen sieht es allerdings ziemlich schlecht damit
aus.

Nee, Windows und Mac OS/Mac OS X unterstützen sowas schon lange. Siehe
z. B. <http://de.wikipedia.org/wiki/Alternativer_Datenstrom>. Ein
Problem bei der Verwendung dieser Datenströme ist vermutlich die
fehlende Interoperabilität zwischen den unterschiedlichen Betriebs- und
Dateisystemen.

Gruß, Gustaf

[Thomas 'PointedEars' Lahn]

Post by Claus Reibenstein

Post by Paul Ebermann
Hmm, wo würdest du denn solche Metainformationen ("verwende bitte bash,
um dieses Skript auszuführen", "diese Datei ist XHTML, Latin-1-kodiert")
sonst unterbringen?

In den Dateiattributen.

*prust*

Post by Claus Reibenstein

Post by Paul Ebermann
Soll das Dateisystem (bzw. "alle Dateisysteme") ein paar passende Felder
bereitstellen, so dass das da abgelegt werden kann?

OS/2 tut das schon seit Jahren.

Ach, *deshalb* sind OS/2 und HPFS heute noch immer so weit verbreitet ;->

Post by Claus Reibenstein
Wie detailliert diese Attribute heute sind, kann ich allerdings nicht
sagen. Meine OS/2-Zeit liegt dank IBM schon einige Jahre zurück.

OS/2 ist jenseits der wirrtuellen Welt bedeutungslos geworden. Bevor es
2001 starb, hatte IBM noch HPFS durch JFS ersetzt (um nicht länger von
Microsoft abhängig zu sein).

Post by Claus Reibenstein
Bei anderen Betriebssystemen sieht es allerdings ziemlich schlecht damit
aus.

NTFS, XFS, ext2/ext3, einige UFS-Versionen, und HFS+ unterstützen erweiterte
Dateiattribute.

Post by Claus Reibenstein

Post by Paul Ebermann
Dann braucht man nur noch Unterstützung dafür in in etwa allen
Editoren/Betriebssystemen/Programmiersprachen/Archiv-Formaten.

Ich gehe mal davon aus, dass die entsprechenden OS/2-Tools dies auch tun.

Post by Paul Ebermann
Ansonsten geht solche Information gerne mal verloren, wenn eine Datei
kopiert wird.

OS/2 kopiert diese Attribute mit.

Post by Paul Ebermann
Im Inneren der Datei sind sie gegen das "Verlorengehen"
immer noch am besten geschützt.

Stören dort aber das eine oder andere Tool, welches damit nicht klar kommt.
Gruß. Claus

[Thomas 'PointedEars' Lahn]

[Zu früh abschickt --> Cancel & Supersedes]

Post by Claus Reibenstein

Post by Paul Ebermann
Hmm, wo würdest du denn solche Metainformationen ("verwende bitte bash,
um dieses Skript auszuführen", "diese Datei ist XHTML, Latin-1-kodiert")
sonst unterbringen?

In den Dateiattributen.

*prust*

Post by Claus Reibenstein

Post by Paul Ebermann
Soll das Dateisystem (bzw. "alle Dateisysteme") ein paar passende Felder
bereitstellen, so dass das da abgelegt werden kann?

OS/2 tut das schon seit Jahren.

Ach, *deshalb* sind OS/2 und HPFS heute noch immer so weit verbreitet ;->

Post by Claus Reibenstein
Wie detailliert diese Attribute heute sind, kann ich allerdings nicht
sagen. Meine OS/2-Zeit liegt dank IBM schon einige Jahre zurück.

OS/2 ist jenseits der wirrtuellen Welt bedeutungslos geworden. Bevor es
2001 starb, hatte IBM noch HPFS durch JFS ersetzt (um nicht länger von
Microsoft abhängig zu sein).

Post by Claus Reibenstein
Bei anderen Betriebssystemen sieht es allerdings ziemlich schlecht damit
aus.

NTFS, XFS, ext2/ext3, einige UFS-Versionen, und HFS+ unterstützen erweiterte
Dateiattribute. Support dafür schaltet man aber nur an, wenn man es
wirklich braucht, da es an der FS-Performance kratzt.

Post by Claus Reibenstein

Post by Paul Ebermann
Ansonsten geht solche Information gerne mal verloren, wenn eine Datei
kopiert wird.

OS/2 kopiert diese Attribute mit.

Und Windows vermutlich per Default auch (wobei es beim Schreiben Probleme
geben dürfte). Das war es dann aber schon.

Post by Claus Reibenstein

Post by Paul Ebermann
Im Inneren der Datei sind sie gegen das "Verlorengehen"
immer noch am besten geschützt.

Stören dort aber das eine oder andere Tool, welches damit nicht klar kommt.

Dann ist dieses Tool durch eine funktionierende Version zu ersetzen.
Entweder Unicode-Support oder kein Unicode-Support, aber bitte nicht
irgendwas dazwischen!


PointedEars

[Stefan+ (Stefan Froehlich)]

Post by Paul Ebermann

Post by Stefan+ (Stefan Froehlich)
Ich halte ganz generell jede Art von Metainformation innerhalb
einer Datei fuer groben Unfug (genau aus diesem Grund, weil man
sich dann nie mehr sicher sein kann, wer was wie interpretiert
oder auch nicht).

Hmm, wo würdest du denn solche Metainformationen ("verwende bitte
bash, um dieses Skript auszuführen", "diese Datei ist XHTML,
Latin-1-kodiert") sonst unterbringen? Mit MIME (in E-Mails und
HTTP z.B.) kann man das in die entsprechenden Header-Zeilen
schreiben, aber als Dateien? Soll das Dateisystem (bzw. "alle
Dateisysteme") ein paar passende Felder bereitstellen, so dass das
da abgelegt werden kann?

Das waere Aufgabe des Betriebssystems (und damit verbunden
natuerlich u.U. auch eine des Dateisystems). Bestehende Varianten
(und deren Probleme) wurden Dir ja bereits von anderen genannt.

In einer idealen Welt koennte man das gewuenschte Encoding beim
Oeffnen der Datei angeben - was gehen mich als Anwendungsprogramm
schliesslich die Interna der Datenspeicherung an? Damit waeren dann
auch die Inkompatibilitaeten weitgehend fort... der Haken daran ist
halt, dass der Zug dafuer bereits zu einer Zeit abgefahren ist, als
sich noch kein Mensch ueber Encodings den Kopf zerbrochen hat.

Servus,
Stefan

[Thomas 'PointedEars' Lahn]

Post by Stefan+ (Stefan Froehlich)

Post by Paul Ebermann

Post by Stefan+ (Stefan Froehlich)
Ich halte ganz generell jede Art von Metainformation innerhalb
einer Datei fuer groben Unfug (genau aus diesem Grund, weil man
sich dann nie mehr sicher sein kann, wer was wie interpretiert
oder auch nicht).

Hmm, wo würdest du denn solche Metainformationen ("verwende bitte
bash, um dieses Skript auszuführen", "diese Datei ist XHTML,
Latin-1-kodiert") sonst unterbringen? Mit MIME (in E-Mails und
HTTP z.B.) kann man das in die entsprechenden Header-Zeilen
schreiben, aber als Dateien? Soll das Dateisystem (bzw. "alle
Dateisysteme") ein paar passende Felder bereitstellen, so dass das
da abgelegt werden kann?

Das waere Aufgabe des Betriebssystems (und damit verbunden
natuerlich u.U. auch eine des Dateisystems). Bestehende Varianten
(und deren Probleme) wurden Dir ja bereits von anderen genannt.
In einer idealen Welt koennte man das gewuenschte Encoding beim
Oeffnen der Datei angeben - was gehen mich als Anwendungsprogramm
schliesslich die Interna der Datenspeicherung an?

Ein UTF-8-codierter Text ist etwas anderes als ein ISO-8859-1-codierter
Text, selbst wenn er dieselben Zeichen und sogar dieselben Codesequenzen
enthält. Einen FTP- oder SCP-Client ginge das etwas an, denn er müsste
die Datei als "verändert" bewerten und ggf. nachfragen, ob das Original
überschrieben werden soll.

Post by Stefan+ (Stefan Froehlich)
Damit waeren dann auch die Inkompatibilitaeten weitgehend fort...

Im Gegenteil.

Post by Stefan+ (Stefan Froehlich)
der Haken daran ist halt, dass der Zug dafuer bereits zu einer Zeit
abgefahren ist, als sich noch kein Mensch ueber Encodings den Kopf
zerbrochen hat.

Richtig. Zudem blähte es das Betriebs- und Dateisystem und jede
Datenübertragung künstlich auf.


PointedEars

[Arno Welzel]

Post by Paul Ebermann

Post by Stefan+ (Stefan Froehlich)

Post by Paul Ebermann
Nachteile sind halt, dass alle Software, die etwas anderes da
erwartet, dann nicht mehr funktioniert, also etwa das #! in
ausführbaren Skript-Dateien in Unix.

Ich halte ganz generell jede Art von Metainformation innerhalb einer
Datei fuer groben Unfug (genau aus diesem Grund, weil man sich dann
nie mehr sicher sein kann, wer was wie interpretiert oder auch
nicht).

Hmm, wo würdest du denn solche Metainformationen ("verwende bitte bash,
um dieses Skript auszuführen", "diese Datei ist XHTML, Latin-1-kodiert")
sonst unterbringen? Mit MIME (in E-Mails und HTTP z.B.) kann man das in
die entsprechenden Header-Zeilen schreiben, aber als Dateien?
Soll das Dateisystem (bzw. "alle Dateisysteme") ein paar passende Felder
bereitstellen, so dass das da abgelegt werden kann?

Es gibt Dateisysteme, die sowas durchaus unterstützen. Selbst NTFS
könnte das grundsätzlich in alternate data streams - es wird nur in der
Praxis nicht genutzt, wohl wegen der heilige Kuh der
Abwärtskompatibilität, die unter Windows eben die Dateiendung dafür
voraussetzt.

[Thomas 'PointedEars' Lahn]

Post by Arno Welzel

Post by Paul Ebermann
Hmm, wo würdest du denn solche Metainformationen ("verwende bitte bash,
um dieses Skript auszuführen", "diese Datei ist XHTML, Latin-1-kodiert")
sonst unterbringen? Mit MIME (in E-Mails und HTTP z.B.) kann man das in
die entsprechenden Header-Zeilen schreiben, aber als Dateien?
Soll das Dateisystem (bzw. "alle Dateisysteme") ein paar passende Felder
bereitstellen, so dass das da abgelegt werden kann?

Es gibt Dateisysteme, die sowas durchaus unterstützen. Selbst NTFS
könnte das grundsätzlich in alternate data streams - es wird nur in der
Praxis nicht genutzt, wohl wegen der heilige Kuh der
Abwärtskompatibilität, die unter Windows eben die Dateiendung dafür
voraussetzt.

Weitaus gewichtiger dürfte sein, dass Dateiattribute schnell mal
kaputt/verloren gehen können. Und schon wird aus einem Foto eine Textdatei
oder aus einer harmlosen Textdatei Schadsoftware. (Sowas klappt ja bei
Windows schon mit Suffixen ─ wo man den Fehler immerhin noch ohne Hex-Editor
sehen kann, wenn man will ─ recht gut.)

Darüberhinaus wäre es unperformant, die genannten Informationen im
Dateisystem zu speichern; damit es interoperabel ist, müssten es zumindest
teilweise Unicode-Strings sein (mit Inode-Referenzen funktioniert es nicht).
Magic Bytes (u.a. Shebang und BOM) funktionieren da viel besser.

[Arno Welzel]

Post by Thomas 'PointedEars' Lahn

Post by Arno Welzel

Post by Paul Ebermann
Hmm, wo würdest du denn solche Metainformationen ("verwende bitte bash,
um dieses Skript auszuführen", "diese Datei ist XHTML, Latin-1-kodiert")
sonst unterbringen? Mit MIME (in E-Mails und HTTP z.B.) kann man das in
die entsprechenden Header-Zeilen schreiben, aber als Dateien?
Soll das Dateisystem (bzw. "alle Dateisysteme") ein paar passende Felder
bereitstellen, so dass das da abgelegt werden kann?

Es gibt Dateisysteme, die sowas durchaus unterstützen. Selbst NTFS
könnte das grundsätzlich in alternate data streams - es wird nur in der
Praxis nicht genutzt, wohl wegen der heilige Kuh der
Abwärtskompatibilität, die unter Windows eben die Dateiendung dafür
voraussetzt.

Weitaus gewichtiger dürfte sein, dass Dateiattribute schnell mal
kaputt/verloren gehen können. Und schon wird aus einem Foto eine Textdatei

Was Systeme wie MacOS nicht daran hindert, es mit HFS+ trotzdem so zu
machen - und das durchaus erfolgreich und nicht zwangsläufig mit
nennenswertem Performanceverlust.

Post by Thomas 'PointedEars' Lahn
oder aus einer harmlosen Textdatei Schadsoftware. (Sowas klappt ja bei
Windows schon mit Suffixen ─ wo man den Fehler immerhin noch ohne Hex-Editor
sehen kann, wenn man will ─ recht gut.)

Nun ja - dass eine harmlose Textdatei zu Schadsoftware wird, geht bei
Unix-artigen Systemen ja auch recht einfach - denn die Information "darf
ausgeführt werden" wird ja auch als Attribut gespeichert.

[Ralf Döblitz]

Post by Christoph Schneegans

Weil die BOM ist eigentlich unnötig in dem Fall und nur eine
Microsoft-Spinnerei unter Windows.

Spinnerei, schon klar. Die unbestreitbaren Vorteile von UTF-8-BOMs
bezweifeln nach meiner Erfahrung nur Leute, die irgendeine Software
aus dem letzten Jahrtausend einsetzen (müssen), die BOMs nicht
versteht. Rein interessehalber, welche ist es denn bei dir?

Nö, UTF-8-BOMs sind Schwachsinn, da bei UTF-8 die rejeinfolge der Bytes
eh klar ist. Und innerhalb beliebiger Nutzdaten kodieren zu wollen, in
welcher Kodierung die Daten vorliegen ist nicht sinnvoll. Wenn es
sinnvoll sein soll, dann muß man das schon wie bei TIFF formal
definieren.

Ralf

[Thomas 'PointedEars' Lahn]

Post by Ralf Döblitz

Post by Christoph Schneegans

Weil die BOM ist eigentlich unnötig in dem Fall und nur eine
Microsoft-Spinnerei unter Windows.

Spinnerei, schon klar. Die unbestreitbaren Vorteile von UTF-8-BOMs
bezweifeln nach meiner Erfahrung nur Leute, die irgendeine Software
aus dem letzten Jahrtausend einsetzen (müssen), die BOMs nicht
versteht. Rein interessehalber, welche ist es denn bei dir?

Nö, UTF-8-BOMs sind Schwachsinn, da bei UTF-8 die rejeinfolge der Bytes
eh klar ist. Und innerhalb beliebiger Nutzdaten kodieren zu wollen, in
welcher Kodierung die Daten vorliegen ist nicht sinnvoll. Wenn es
sinnvoll sein soll, dann muß man das schon wie bei TIFF formal
definieren.

Du hast offensichtlich nicht ausreichend über das Problem nachgedacht.

1. Es ist nicht die Ausnahme, sondern vielmehr die Regel bei
Informationseinheiten, dass den Nutzdaten Meta-Information vorangeht bzw.
ihnen folgt. man magic, ID3.

2. Der Unicode-Standard definiert, wie die BOMs auszusehen haben. Der BOM
steht nicht "innerhalb beliebiger Nutzdaten", sondern immer am Anfang
der Datei bzw. unmittelbar vor den Nutzdaten.

Zumindest das ist nicht wesentlich anders als bei TIFF. TIFF ist jedoch
im Unterschied zu Unicode alles andere als wohldefiniert, deshalb gibt es
damit auch so viele Kompatibilitätsprobleme. Bei der Erwähnung von TIFF
als positives Gegenbeispiel kann sich also nur um einen (schlechten)
Scherz handeln.

4. Die Byte-Folge

EF BB BF 52 61 6C 66 20 44 C3 B6 62 6C 69 74 7A

stellt etwas anderes dar als die Byte-Folge

52 61 6C 66 20 44 C3 B6 62 6C 69 74 7A

und es sicher nicht sinnvoll, im zweiten Fall für die korrekte
Darstellung die semantisch einzig sinnvolle, weil korrekte Codierung
(hier: UTF-8) erst erraten oder dafür ein Dateiformat oder ein höheres
Protokoll bemühen zu *müssen*.


PointedEars

[Ralf Döblitz]

Post by Thomas 'PointedEars' Lahn

Post by Ralf Döblitz

Post by Christoph Schneegans

Weil die BOM ist eigentlich unnötig in dem Fall und nur eine
Microsoft-Spinnerei unter Windows.

Spinnerei, schon klar. Die unbestreitbaren Vorteile von UTF-8-BOMs
bezweifeln nach meiner Erfahrung nur Leute, die irgendeine Software
aus dem letzten Jahrtausend einsetzen (müssen), die BOMs nicht
versteht. Rein interessehalber, welche ist es denn bei dir?

Nö, UTF-8-BOMs sind Schwachsinn, da bei UTF-8 die rejeinfolge der Bytes
eh klar ist. Und innerhalb beliebiger Nutzdaten kodieren zu wollen, in
welcher Kodierung die Daten vorliegen ist nicht sinnvoll. Wenn es
sinnvoll sein soll, dann muß man das schon wie bei TIFF formal
definieren.

Du hast offensichtlich nicht ausreichend über das Problem nachgedacht.

Im Ggensatz zu dir habe ich das.

Post by Thomas 'PointedEars' Lahn
1. Es ist nicht die Ausnahme, sondern vielmehr die Regel bei
Informationseinheiten, dass den Nutzdaten Meta-Information vorangeht bzw.
ihnen folgt. man magic, ID3.

"magic" sind Bytefolgen in Nutzdaten, die charakteristisch für den
Datentyp sind. Sie sind keine getrennten Metadaten, im Gegensatz zu
einem BOM.

Post by Thomas 'PointedEars' Lahn
2. Der Unicode-Standard definiert, wie die BOMs auszusehen haben. Der BOM
steht nicht "innerhalb beliebiger Nutzdaten", sondern immer am Anfang
der Datei bzw. unmittelbar vor den Nutzdaten.

"innerhalb beliebiger Nutzdaten" soll heißen, daß du einfach in ein
File, für das keine entsprechende Struktur definiert ist, Metadaten
hineinstecken willst. Nur ist dies für *beliebige* Nutzdaten eben nicht
definiert und wird somit zwangsläufig zu Kompatibilitätsproblemen
führen. Deshalb will man solchen Unsinn auch nicht machen.

Post by Thomas 'PointedEars' Lahn
Zumindest das ist nicht wesentlich anders als bei TIFF. TIFF ist jedoch
im Unterschied zu Unicode alles andere als wohldefiniert, deshalb gibt es
damit auch so viele Kompatibilitätsprobleme. Bei der Erwähnung von TIFF
als positives Gegenbeispiel kann sich also nur um einen (schlechten)
Scherz handeln.

Jein, TIFF hat eine recht wolhdefinierte Struktur. Nicht jede Software
kann mit jedem Tag-Typ umgehen, aber es ist klar definiert, wie das File
aufgebaut ist, wie Tags aussehen und damit könntest du auch problemlos ein
Tag für das character encoding definieren, wenn du das bräuchtest
(praktisch dürfte das bei Bildern wohl irrelevant sein, im Gegensatz zur
Byteorder, für die es - Überraschung - ein wohldefiniertes Tag gibt).

Post by Thomas 'PointedEars' Lahn
4. Die Byte-Folge
EF BB BF 52 61 6C 66 20 44 C3 B6 62 6C 69 74 7A
stellt etwas anderes dar als die Byte-Folge
52 61 6C 66 20 44 C3 B6 62 6C 69 74 7A

Eben. Und deshalb läßt man solche Manipulationen auch sein.

Post by Thomas 'PointedEars' Lahn
und es sicher nicht sinnvoll, im zweiten Fall für die korrekte
Darstellung die semantisch einzig sinnvolle, weil korrekte Codierung
(hier: UTF-8) erst erraten oder dafür ein Dateiformat oder ein höheres
Protokoll bemühen zu *müssen*.

Doch, genau das ist es. Entweder es gibt externe Informationen für das
konkrete File oder man muß generelle Übereinkünfte über das Encoding
treffen.

Ralf

[Christoph Schneegans]

Post by Ralf Döblitz
UTF-8-BOMs sind Schwachsinn, da bei UTF-8 die rejeinfolge der
Bytes eh klar ist.

Dein Logik-Modul klemmt gewaltig. Nur weil es bei UTF-8 keine "byte
order" gibt, sind UTF-8-BOMs kein "Schwachsinn". Nenn das BOM doch
einfach "Signatur", wie im Subject, schon paßt's.

[Christoph Schneegans]

Post by Lupus Goebel
ich arbeite mit Microsoft Visual Web Developer 2008 Express
Edition und muss wegen einem Serverfehler alle Dateien öffnen und
Unicode (UTF-8 ohne Signatur) - Codepage 65001
angegeben. Nun muss alles als
Unicode (UTF-8 mit Signatur) - Codepage 65001
gespeichert werden.

Gute Idee. UTF-8-codierte Dateien sollten stets mit BOM gespeichert
werden, um die Zeichencodierung explizit anzugeben. Daß es blöd ist,
wenn jemand die Codierung einer Datei erraten mußt, merkst du ja
gerade.

Dieses Skript schreibt für alle Dateien mit der angegebenen
Erweiterung ein UTF-8-BOM. Einfach etwa als add-bom.vbs speichern
und dann den gewünschten Ordner per Drag and Drop darauf ablegen:

----------------------------8<----------------------------

Const Extension=".txt"

Set fso = WScript.CreateObject("Scripting.FileSystemObject")
Set rootFolder = fso.getFolder(WScript.Arguments(0))
ProcessDirectory rootFolder

Sub ProcessDirectory(folder)

For Each file in folder.Files
If Right(file.Name, Len(Extension)) = Extension Then
'Datei einlesen.
Set str = WScript.CreateObject("ADODB.Stream")
str.Charset = "Utf-8"
str.Open
str.LoadFromFile file
Const adReadAll = -1
data = str.ReadText(adReadAll)
str.Close

'Datei schreiben.
Set str = WScript.CreateObject("ADODB.Stream")
str.Charset = "Utf-8"
str.Open
str.WriteText(data)
Const adSaveCreateOverWrite = 2
str.SaveToFile file, adSaveCreateOverWrite
str.Close
End If
Next

For Each subFolder in folder.SubFolders
ProcessDirectory(subFolder)
Next

End Sub

---------------------------->8----------------------------

Mach vor der Ausführung eine Sicherungskopie deiner Dateien.

Mehrfache Ausführung ist harmlos; die BOM-Bytes werden sich dadurch
nicht vervielfachen. Das Skript funktioniert, weil ADODB.Stream
standardmäßig ein UTF-8-BOM schreibt. Steuern kann man das bei
diesem Ansatz leider nicht.

Post by Lupus Goebel
Mein Provider arbeitet am Problem und ich hoffe das er vor mir
eine Lösung findet. Bis dahin kann ich die Codierung in der
web.config nicht eintragen.

Brauchst du mit UTF-8-BOM auch nicht; ASP.NET geht dann immer von
UTF-8 aus.

[Lupus Goebel]

Gude Morsche,

Am 19.02.2011 04:17 schrieb Christoph Schneegans:

[...]

Post by Christoph Schneegans
Gute Idee. UTF-8-codierte Dateien sollten stets mit BOM gespeichert
werden, um die Zeichencodierung explizit anzugeben. Daß es blöd ist,
wenn jemand die Codierung einer Datei erraten mußt, merkst du ja
gerade.
Dieses Skript schreibt für alle Dateien mit der angegebenen
Erweiterung ein UTF-8-BOM. Einfach etwa als add-bom.vbs speichern
----------------------------8<----------------------------
Const Extension=".txt"
Set fso = WScript.CreateObject("Scripting.FileSystemObject")
Set rootFolder = fso.getFolder(WScript.Arguments(0))
ProcessDirectory rootFolder
Sub ProcessDirectory(folder)
For Each file in folder.Files
If Right(file.Name, Len(Extension)) = Extension Then
'Datei einlesen.
Set str = WScript.CreateObject("ADODB.Stream")
str.Charset = "Utf-8"
str.Open
str.LoadFromFile file
Const adReadAll = -1
data = str.ReadText(adReadAll)
str.Close
'Datei schreiben.
Set str = WScript.CreateObject("ADODB.Stream")
str.Charset = "Utf-8"
str.Open
str.WriteText(data)
Const adSaveCreateOverWrite = 2
str.SaveToFile file, adSaveCreateOverWrite
str.Close
End If
Next
For Each subFolder in folder.SubFolders
ProcessDirectory(subFolder)
Next
End Sub
---------------------------->8----------------------------

Bekomme jedoch leider vom "Windows Script Host" folgende Fehlermeldung:
Skript: \utf8.vbs
Zeile: 4
Zeichen: 1
Fehler: Index außerhalb des gültigen Bereichs
Code: 800A0009
Quelle: Laufzeitfehler in Microsoft VBScript

Post by Christoph Schneegans
Mach vor der Ausführung eine Sicherungskopie deiner Dateien.

Na ein bissel Abenteuer braucht der Mensch doch ;-)

[..]

Post by Christoph Schneegans

Post by Lupus Goebel
Mein Provider arbeitet am Problem und ich hoffe das er vor mir
eine Lösung findet. Bis dahin kann ich die Codierung in der
web.config nicht eintragen.

Brauchst du mit UTF-8-BOM auch nicht; ASP.NET geht dann immer von
UTF-8 aus.

Braves ASP.NET

[Lupus Goebel]

Hallöschen Christoph,

Am 19.02.2011 08:01 schrieb Lupus Goebel:

[..]

Skript: \utf8.vbs
Zeile: 4
Zeichen: 1
Fehler: Index außerhalb des gültigen Bereichs
Code: 800A0009
Quelle: Laufzeitfehler in Microsoft VBScript

Post by Christoph Schneegans
Mach vor der Ausführung eine Sicherungskopie deiner Dateien.

Habe ein bissel rumgemacht und umgeschrieben und es scheint zu gehen.

\\\
Const Extension = ".aspx"

Set fso = WScript.CreateObject("Scripting.FileSystemObject")
set WSHShell = CreateObject("WScript.Shell")
Set rootFolder = fso.getFolder(WSHShell.CurrentDirectory)

ProcessDirectory rootFolder

Sub ProcessDirectory(folder)
Const adReadAll = -1
Const adSaveCreateOverWrite = 2
For Each file in folder.Files
If Right(file.Name, Len(Extension)) = Extension Then
'Datei einlesen.
Set str = WScript.CreateObject("ADODB.Stream")
str.Charset = "Utf-8"
str.Open
str.LoadFromFile file

data = str.ReadText(adReadAll)
str.Close
'Datei schreiben.
Set str = WScript.CreateObject("ADODB.Stream")
str.Charset = "Utf-8"
str.Open
str.WriteText(data)

str.SaveToFile file, adSaveCreateOverWrite
str.Close
End If
Next
For Each subFolder in folder.SubFolders
ProcessDirectory(subFolder)
Next
End Sub
///

[Christoph Schneegans]

Skript: \utf8.vbs
Zeile: 4
Zeichen: 1
Fehler: Index außerhalb des gültigen Bereichs
Code: 800A0009
Quelle: Laufzeitfehler in Microsoft VBScript

Du hast das Skript per Doppelklick gestartet. Das solltest du nicht.

[Lupus Goebel]

Hallöschen,

Post by Christoph Schneegans

Skript: \utf8.vbs
Zeile: 4
Zeichen: 1
Fehler: Index außerhalb des gültigen Bereichs
Code: 800A0009
Quelle: Laufzeitfehler in Microsoft VBScript

Du hast das Skript per Doppelklick gestartet. Das solltest du nicht.

Ähem, nö. Mit Maus auf Datei und Return gedrückt. Es hatte aber auch
noch andere Fehlermeldungen gegeben die es bei meinen Änderungen nicht
gibt. Dort kann man es auch per Doppelklick starten.

[Christoph Schneegans]

Post by Lupus Goebel

Post by Christoph Schneegans
Du hast das Skript per Doppelklick gestartet. Das solltest du
nicht.

Ähem, nö. Mit Maus auf Datei und Return gedrückt.

Argh! Lies meine Postings und versuch zu verstehen, was

WScript.Arguments(0)

heißen könnte.

[Lupus Goebel]

Hallo Christoph,

Post by Christoph Schneegans

Post by Lupus Goebel

Post by Christoph Schneegans
Du hast das Skript per Doppelklick gestartet. Das solltest du nicht.

Ähem, nö. Mit Maus auf Datei und Return gedrückt.

Argh! Lies meine Postings und versuch zu verstehen, was
WScript.Arguments(0)
heißen könnte.

:-( wer lesen kann ist klar im Vorteil.
Ich hatte <den gewünschten Ordner per Drag and Drop darauf ablegen>
falsch verstanden und dachte Du meinst: "Kopiere die VBS Datei in den
entsprechenden Ordner."

Das habe ich nun mal versucht, bekomme dennoch eine Fehlermeldung. Und
zwar immer dann, wenn es den entsprechenden Dateityp mehr wie einmal im
Ordner gibt.

Das verhindere ich dadurch, das ich die zwei Konstanten direkt nach der
*sub* und noch vor der *For-Each* Schleife lege.

Also so.
\\\
Sub ProcessDirectory(folder)
Const adReadAll = -1
Const adSaveCreateOverWrite = 2
For Each file in folder.Files
If Right(file.Name, Len(Extension)) = Extension Then
....
///

Letztendlich funktionieren scheinbar beide Varianten, Deine und die ich
daraus gemacht habe (MID:<***@mid.individual.net>)