Dateipfad / -name encodet unterschiedlich auf Windows und macOS

[it-vbfk]

Hallo

Wollte nur hier kurz mal melden, dass Dateinamen (zB Medien-Dateien wie PPTX), die Umlaute enthalten, auf Windows und macOS in der Ablaufplan-Datei anders encodiert werden.

Dies ist besonders lästig, wenn die Präsentation auf macOS vorbereitet wird, und dann am Sonntag solche Dateien auf magische Weise nicht mehr gefunden werden.

Hier eine Beispiel-col (der Plaintext)

Gespeichert auf Windows:

object AblaufPlanItems: TAblaufPlanItems
items = <
item
Caption = 'OpenDocument Pr'#228'sentation (neu)'
Color = clBlack
FileName = '..\OpenDocument Pr'#228'sentation (neu).odp'
Props = []
end>
end


Und da die selbe Präsentation gespeichert auf macOS:

object AblaufPlanItems: TAblaufPlanItems
items = <
item
Caption = 'OpenDocument Pra'#776'sentation (neu)'
Color = clBlack
FileName = '../OpenDocument Pra'#776'sentation (neu).odp'
Props = []
end>
end

Die DirectorySeperator-chars sinds nicht, alles ohne Umlaute funktioniert nämlich.

Lt schneller Google-Suche wäre hier #228 die richtige encodierung (für ä).

Bitte um Hilfe (oder um Behebung).

Danke

[Sebastian]

Es sind leider beides gültige Encodierungen für ä. Also a#776 generell zu #228 umzuformen, gibt Schwierigkeiten unter Windows, wenn dir jemand eine Datei mit a#776 bringt. MacOS scheint beim Dateinamen beide Encodierungen gleichwertig zu behandeln, während Windows die beiden Dateinamen unterscheidet.

Was mir momentan am sinnvollsten erscheint, wäre beim Schreiben vom Ablaufplan auf dem Mac a#776 nach #228 umzuformen (und weitere Encodierungen dementsprechend). Das kann dann Mac und Windows lesen. Der Windows Explorer und der Mac Finder wandeln a#776 im Dateinamen nach #228 beim Kopieren übers Netzwerk um. Schwierigkeiten könnte es aber z.B. geben, wenn die Dateien über eine Cloud synchronisiert werden, und das Synchronisationsprogramm diese Umwandlung nicht vornimmt.

[it-vbfk]

Also a#776 generell zu #228 umzuformen, gibt Schwierigkeiten unter Windows, wenn dir jemand eine Datei mit a#776 bringt.

Naja.. ich sag mal so: gerade eben weil das so encodiert wird, haben wir die Probleme. Nach manuellem Ändern von a#776 auf #228 ist alles in Ordnung (auf Windows).

[it-vbfk]

Hallo

Darf ich den aktuellen Stand hierzu bitte erfragen?

Dieser Bug ist relativ lästig, da Präsentationen die auf macOS vorbereitet werden, nicht direkt in einer Windows-Instanz verwendet werden kann und erst Nacharbeiten erfordert (eben meist Sonntag kurz vor oder teilweise sogar erst während dem Gottesdienst, wenn das jeweilige Medium gebraucht wird (alles gleich betroffen: PPTX mit Umlaut, Song mit Umlaut im Dateinamen, usw. usf.))

1) Ablaufplan auf macOS vorbereiten
2) Testdatei: zB eine PPTX vorbereiten mit Umlauten im Dateinamen
3) Speichern
4) genau diesen Plan auf Songbeamer auf Windows öffnen
5) Datei wird nicht gefunden

Interessant: umgekehrt gibts keine Probleme, dh eine Windows-Version kann unter macOS ganz normal gelesen werden

[Sebastian]

Das sollte schon längst behoben sein. Bitte probiere es mal mit der aktuellen Build:
https://www.songbeamer.de/bin/OSX/SongBeamer_Forum.dmg

Bitte beachte das Dokument "Schadsoftware Prüfung".

[it-vbfk]

Schaut gut aus, danke!
Encondings sind unter macOS und Windows die selben.

Gibt's die Version auch bald als offiziellen Release?