Zeichenkodierung kenne ich eigentlich von von der Konvertierung von Textdateien, wobei kennen eigentlich schon übertrieben ist. - Aber unsere EDV-Abteilung betreibt neuerdings ein NAS-System mit neuer Backupsoftware, dass auch zur Datensicherung von Windows-XPpro- und Mac-Daten verwendet wird. Und da gibt es jetzt Probleme, weil diverse, auch bei der Migration der Daten entstandene, Sonderzeichen nur Vollsicherungen zulassen. Wir werden natürlich an der Planung immer erst beteiligt, wenn die ersten Fehler auftreten.

Der EDV-Kollege sagt jetzt einfach mal, dass von unserer (Mac-) Seite (: Viele Kundendruckdaten) evtl. 7bit-kodierte Dateien draufgespeichert werden. Kann das sein? Bis wann wurden am Mac solche Daten erzeugt? Welche Kodierung gilt jetzt?

Puh. Wie wärs mit: ihr habt beide keine Ahnung und holt Euch am besten externes Knowhow?

-Ralph

Hat überhaupt jemals irgendein Mac 7bitig gespeichert?

Danke für die Blumen.

Aber ich kann da auch nichts finden außer bei Wikipedia, dass die bei Apple schon spätestens Mitte der neunziger Jahre mit 8bit-ASCII-Kodierung gearbeitet haben, der gegenüber DOS ein paar Zeichen anders gesetzt hatte.

Bleibt aber weiterhin die Frage, mit was wir heute auf dem Mac arbeiten. Irgendwie lässt sich da nirgends mehr Einer drüber aus.

Hallo,

mit was wir am Mac zur Zeit (also unter OS X) arbeiten ist sehr einfach: Unicode, 16Bit wahrscheinlich ... Wie sonst wären Dateinamen in chinesischen oder japanischen Zeichen möglich? Aber ob euch das weiterhilft?

Zu den Dateinamen unter Mac OS 9 und früheren Systemversionen: die waren natürlich immer schon 8 Bit, allerdings in der Mac Roman-Kodierung. Das heisst, dass die Zeichen oberhalb 7 Bit (= ab Nummer 128 ) teilweise anders belegt sind als im Windows bzw. Latin-Zeichensatz. Das betrifft in erster Linie die Umlaute. Ausserdem waren in den Datei- und Ordnernamen am Mac schon immer alle Zeichen des 8 Bit ASCII-Zeichensatzes zugelassen, mit Ausnahme des Doppelpunkts. Unter Windows sind bis jetzt bei weitem nicht alle Zeichen des ASCI-Zeichensatzes als Dateinamen zugelassen - somit muss es bei einfachem Portieren von Mac-Dateien auf Windows-Systemen zu Problemen kommen. Berüchtigt zum Beispiel der Apfel, Slash, Backslash, Fragezeichen und diverse Sonderzeichen, wie z. B. das @. Als gemeinsamer Nenner ist nur eingeschränktes 7Bit-ASCI möglich (keine Umlaute, keine Sonderzeichen, nur Buchstaben, Ziffern, Leerzeichen, Bindestrich und Unterstrich.

Aus eigenen Versuchen ist mir soviel bekannt, dass ein Backup auf ein Windows-System nicht funktioniert, nach meinem Wissen, weil das Windows-Dateisystem Unicode-Dateinamen nicht unterstützt. Ausserdem kommt es mit den langen Pfaden nicht klar (unter Windows sind zwar lange Dateinamen möglich, aber m. W. darf die Gesamtlänge des Pfades 256 Zeichen nicht überschreiten) Zudem sind die Namen von Ordnern erheblich stärker eingeschränkt als die Namen von Dateien, was es alles in allem unmöglich macht, Mac-Dateien komplett auf einem Windows-Volume abzubilden, wenn das die Software nicht speziell unterstützt, und zum Beispiel die Dateinamen umkodiert.

Insbesondere NAS-Systeme auf Windows-Basis kann man nach meiner Erfahrung für die Zusammenarbeit mit Macs vergessen. Da funktionieren in der Regel nicht mal lange Dateinamen geschweige denn die Unicode-Zeichen. Was ihr braucht ist einfach eine Backup-Software, die damit umgehen kann.

Viele Grüße
Peter

Und das ist noch nicht mal alles.

Weiter gehts mit den Metadaten wie Ressource und Datafork der Macdateien. Denn selbst wenn ne Datei 8.3 konform mit ohne Leerzeichen und nur a-Z und 0-9 enthält ist sie hin, wenn die Backupsoftware es nicht schafft beim zurücksichern der Datei auch die Ressource wieder beizulegen.

HFS+ am Mac: Unicode, Geschmacksrichtung UTF-8 decomposed.

-Ralph

So, dank eurer Unterstützung und einigen Stunden Lesen gestern abend konnte ich mich jetzt mit meinem Kollegen verständigen. Und jetzt noch mal die Zusammenfassung, wie ich es verstanden habe:

Das NAS-System wird unter Suse-Linux 10 verwaltet, als Zeichenkodierung wird UTF8 verwendet. Das Dateisystem der Festplatten ist ein SAN-Dateisystem von der Firma EMC und die Abbildung für die zugreifenden Rechner ist als NTFS und NFS möglich, wobei NTFS verwendet wird.

Neue Dateien, die von Mac und PC erstellt werden, sind auch problemlos unterm anderen Betriebssystem PC (XPpro) oder Mac (10.3/10.4) lesbar. PCs können auch Sonderzeichen verwenden. Vom Mac aus sind Umlaute und ß möglich, wenn aber unerwünschte Sonderzeichen im Dateinamen enthalten sind, dürfen diese Dateien dort nicht gespeichert werden.

Unsichtbare Macdateien sind vom PC aus nicht zu sehen.

Probleme treten bei verwendeten Sonderzeichen (auch Umlaute und ß) auf, wenn ZIP-Dateien mit WinRar auf dem PC erzeugt und mit dem ZIP-Programm von MacOSX wieder geöffnet werden und umgekehrt. -> Evtl. hat das was mit der Umkodierung zwischen UTF-8 und UTF-16 (Unicode) zu tun.

Verwende ich jedoch WinRar um Rardateien zu erzeugen und entpacke sie am Mac mit Unrar gibt es keine Probleme. -> Das heißt, man sollte ZIP-Dateien unter dem richtigen Betriebssystem wieder entpacken und viellleicht finde ich ja auch noch ein Programm für den Mac, mit dem Rardateien erzeugt werden können.

Die Verstümmelung der auf dem ehemaligen Linuxdatenserver enthaltenen Sonderzeichen und die Sichtbarmachung der eigentlich unsichtbaren Macdateien unter XPpro entstand vermutlich durch die Migration der Linserverdaten über NFS auf das neue NAS-System. Das müssen die halt jetzt über ein Skript wieder rückgängig machen. Mal sehen, was so geht.

Fazit: Mit kleinen Einschränkungen kann man scheinbar mit dem System arbeiten, man ist ja nicht verwöhnt, wobei wir auf jeden Fall die ersten Backups nach der Bereinigung der Daten abwarten müssen. Die oben erwähnten Punkte mit den langen Pfadnamen, den Resourcedateien und die Backup-Software behalten wir dabei im Auge.

Kompliziertes Thema, und ich hoffe, das können jetzt auch noch Andere verstehen, so wie ich es geschrieben habe.