Dateien nachträglich konvertieren?

Beim Start mit Calc (auf Basis xlsx-Format) hatte ich Probleme mit Verknüpfungen.
Diese konnte ich beseitigen, indem ich die Dateien vorher im ods-Format abspeicherte.

Nun stellt sich mir die Frage, wie ich mit meinen Dateien aus 2 “Welten” zukünftig umgehe.

Anfangs (beim Start mit LibreOffice) gab ich an, im xlsx-Format bleiben zu wollen.
Kann ich das in den Einstellungen irgendwo ändern?
ZB. automatisches Öffnen von xlsx-Daten im ods-Format und automatisches Speichern im ods-Format?

Aber dann stehen überall ungenutzte xslx-Daten rum, die nur Platz und Übersicht nehmen.

Wie geht man am Sinnvollsten mit dieser Situation um?

Hallo

prinzipiell gilt - und das eigentlich nicht nur für LibreOffice - dass man grundsätzlich im nativen Format der Anwendung arbeitet und das heisst im Falle von LibreOffice eben im OpenDocument Format (.ods, .odt, .odp, etc …). Fremdformate sollte man nur zum Datenaustausch verwenden und Änderungen aber im nativen Format nachtragen (Ganz schlecht ist: .ods → xlsx → .ods → xlsx …, da kannst Du definitv davon ausgehen irgendwann ein Problem zu bekommen).

Die Entscheidung am Anfang Deiner “LibreOffice-Karriere” war also in diesem Sinne keine gute Entscheidung. Die bestehenden .xlsx Dateien würde ich in Deinem Falle alle einmal laden und im nativen Format abspeichern (Save As) und wenn alles gut gegangen ist, kannst Du die .xlsx Dateien anschließend löschen (muss ja nicht sofort sein, könntest ja Problem mit der Konvertierung eventuell auch erst später bemerken). Am Rande: Man kann auch das im Prinzip auch automatisieren, da man LibreOffice an der Kommanzeile aufrufen kann (Batch, Skripte; Kommando libreoffice6.3 --convert-to ods {pfad zur xlsx Datei}).

Zur Änderung des Default Format beim Speichern neuer Dateien: Extra -> Optionen -> Laden/Speichern -> Kategorie: Einstellungen für das Stamdarddateiformat und ODF. Da kannst Du für jeden Dokumenttyp festlegen, was Du haben willst.

Und eines bleibt noch offen: Öffnest Du eine .xlsx Datei, und drückst auf den Speichern Button (nicht Speichern als) dann bleibt es bei .xlsx auch wenn Du wie oben beschrieben, ein anderes Dateiformat als Standard angegeben hast. Um als für bestehende und geöffnete Datei ein anderes Format zu erwzingen, musst Du definitv Spechern als verwenden und das neue Format angeben/auswählen.

Ich hoffe das hilt ein wenig.

Vielen Dank für die ausführliche Antwort!

Da ich beim Aufbau des neuen Win10-PC sehr viele Office-Dateien an viele Plätze übertragen habe, davon aber nur wenige im ods-Format geändert wurden, könnte es vielleicht praktischer sein, die wenigen ods-Dateien extern zu sichern, und mit LibreOffice ganz neu anzufangen.

Nach einem Neuanfang könnte ich dann auf die gesicherten ods-Dateien zurückgreifen.

Wie könnte das gehen?
Deinstallieren und neu installieren, um dann die Entscheidung (s.o.) richtig zu treffen?
Oder sind andere bessere Wege bekannt?

Außerdem: welche wichtigen, später nicht änderbaren Entscheidungen sollte ich zudem noch kennen, bevor ich mit LibreOffice neu beginne?

Einen weiterhin schönen Feiertag!

Hallo - das mit dem Plan “Deinstallieren und neuinstallieren” verstehe ich nicht. Wie in meiner Antwort geschrieben, kannst Du das Standardformat unter dem gespeichert werden soll jederzeit umstellen. Von welcher Entscheidung bei Neuinstallation Du da sprichst verstehe ich gar nicht und wenn da irgendwas eingestellt hilft eine Neuinstallation in der Regel sowieso nichts, da solche Einstellungen Im Benutzerprofil stehen, dass bei einer Neuinstallation überhaupt nicht angefasst wird (Mir fällt nur ein, dass man bei der Neuinstallation eventuell die Zurodnung von MS Office Dokumentenformaten wie .xlsx etc. zu LibreOffice festlegen könnte. Das weiß ich nicht so ganz genau nicht, da ich MS Office schon lange nicht mehr verwendet habe und Windows eher meide. Das hätte allerdings auch keinen Einfluß auf das Thema hier)

Hallo jnanon, ich vermute, mit Anfangs (beim Start mit LibreOffice) gab ich an, im xlsx-Format bleiben zu wollen. meinst Du die Entscheidung beim Installationsassistenten, dass LO sich für die Microsoft Office Dateien zuständig fühlen soll. Es besteht aus meiner Sicht keine Notwendigkeit, diese Wahl rückgängig zu machen. Es bedeutet lediglich, dass ein Doppelklick auf z.B. eine docx Datei, diese Datei in Writer öffnet. Solange Du nicht noch parallel auf dem Windows 10 PC ein MS Office mit Word und Exel laufen hast, würde ich mir diesen Komfort an Deiner Stelle nicht nehmen.

Und für den anderen Aspekt hat Opaque doch schon einen gut gangbaren Weg aufgezeigt. MSO Dateien öffnen und mit Speichern unter im ODF Format ablegen, unter Extras > Optionen > Allgemein > Laden / Speichern für alle Dokumententypen als Standard das jeweilige ODF-Format festlegen. MSO-Dateien (ggf. extern) sichern. Einfaches De- / Reinstallieren würde den Std-Dok-Typ übrigens nicht ändern.

Cheers, da war Opaque zum Thema ‘neu installieren und Anfangsentscheidungen’ schneller ,-)

@anon73440385 , Deinen Ansatz mit Script finde ich interessant für so einen Systemwechsel. Für LO mit einer cmd könnte es so ausschauen:

  1. Datei ‘loconvert_ods.cmd’: "C:\Program Files (x86)\LibreOffice\program\soffice.exe" --convert-to ods %1

  2. Datei ‘loconvert_odt.cmd’: "C:\Program Files (x86)\LibreOffice\program\soffice.exe" --convert-to odt %1

  3. Datei ‘convert.cmd’:

Forfiles /P "%cd%" /M *.xlsx /C "cmd /c %cd%\loconvert_ods.cmd @file"

Forfiles /P "%cd%" /M *.docx /C "cmd /c %cd%\loconvert_odt.cmd @file"

Das 3er-Set jeweils in das gewünschte Verzeichnis kopieren und mit Dopplel-Klick convert.cmd aufrufen. Kann man nach belieben um xls, ppt, usw. erweitern. Das die eine cmd, die anderen startet muss sein, da Forfiles sonst mit dem Aufruf von soffice.exe + Parameter nicht klar kommt. libreoffice6.3 geht in Windows übrigens nicht. O.g. Pfad gilt für LO 32 Bit.

Ergänzung: Funktioniert nicht mit kennwortgeschützten Dateien.

Da ich viele (hunderte bis tausende) Office-Dokumente habe, ist Batch-Verarbeitung sicher eine gute Idee.
Nur kommt erschwerend hinzu, dass sich die Dokumente in einer vielfältigen Ordnerstruktur befinden.

Was Cookievore oben anbietet, ist sicher gut, aber für mich (bei meinen laienhaften Kenntnissen) so nicht umsetzbar. Ich brauchte da wirklich einfache(re) Handlungsanweisungen.

Außerdem irritiert mich im vorletzten Kommentar eine kurze Anmerkung:
“Libreoffice6.3 geht in Windows übrigens nicht”.
Ich habe unter Win10 (64bit) LibreOffice6.3 installiert.
Spricht da wirklich etwas gegen?

Zum letzten Kommentar, zu schreibgeschützten Dolumenten:
Ich habe tatsächlich einige wenige schreibgeschützte Dokumente vertreut in der Ordnerstruktur.
Diese Wenigen könnten natürlich “manuell” mit Speichern unter konvertiert werden.
Nur was passiert innerhalb eines Batchlaufes, wenn dieser auf so ein schreibgeschütztes Dokument stößt? Bricht dann alles ab?

Den Befehl Libreoffice6.3 gibt es unter Windows nicht. So nur unter Linux. Unter Windows ist es der o.g. längliche Pfad zu soffice.exe um die Konvertierung über die Kommandozeile durchzuführen. Würde die auch hochladen, geht aber mit meinem Karma in Kommentaren nicht.

Mit sehr viel mehr Aufwand kann man sicher auch einen rekursiven Algorithmus schreiben, der durch alle Verzeichnisse geht. Das wird aber OT für diese Plattform, die sich auf die Nutzung von LO fokussiert.

Wenn das Script auf eine schreibgeschützte Datei trifft, passiert genau nichts. Ich habe das in dem Script nicht abgefangen. Diese Datei wird eben nicht konvertiert. Das war’s.

Hatte auch ähnlich viele (>4.000) Office-Dokumente zu konvertieren. Auch in reichlich Unterverzeichnissen verteilt. Das Gros habe ich in einer Aktion erledigt, verzeichnisweise. Und der Rest war immer dann dran, wenn ich wieder auf ein unkonvertiertes Verzeichnis gestoßen bin. Aber vielleicht findest Du eine bessere Vorgehensweise für Dich.

ich würde gerne eine Großaktion starten, mit den von Dir beschriebenen Kommandozeilen.
Leider passiert aber beim Versuch (Doppelklick auf die Datei convert.cmd) nichts, außer dem kurzen Aufblenden eines schwarzen Fensters, in dem einige Befehle ablaufen. Läuft zu schnell, um Genaues zu erkennen.
Jedenfalls befindet sich im Ordner der Ausführung keine konvertierte .ods-Datei. Das war doch der Sinn der Übung. Kann es sein, dass sich der Aufbau der Befehle ändert, weil ich mit der Version LibreOffice6.3 mit 64 bis arbeite? Ich gebe die Dateiinhalte hier zur Prüfung wider:

  1. Datei ‘loconvert_ods.cmd’: “C:\Program Files\LibreOffice\program\soffice.exe” --convert-to ods %1
  2. Datei ‘convert.cmd’: Forfiles /P “%cd%” /M *.xlsx /C “cmd /c %cd%\loconvert_ods.cmd @file

Vielleicht gibt es einen einfachen Formatfehler?

Sieht eigentlich gut aus. 2 Dateien, Pfad soffice.exe entspricht Deinem 64-Bit Windows 10, da hätte ich nur die Idee, dass es sich bei Deinen Dateien vielleicht nicht um .xlsx, sondern um .xls handelt oder dass die beiden cmd-Dateien nicht im selben Ordner mit den zu konvertierenden Dateien stehen?

Wenn Du sehen willst, welche Ausgaben das Script liefert, müsste es manuel in einer Konsole gestartet werden. Win + R, cmd, Enter, mit cd <Verzeichnisname> zu einem Verzeichnis mit den zu konvertierenden Dateien hangeln, convert.cmd, Enter.

Also Leute - seid mir bitte nicht böse, aber das ist doch Blödsinn ein Shellscript per Doppelklick zu starten und so jeden Fehler unsichtbar zu machen dem man sonst im Kommandfenster hätte.

@anon73440385 , ich schätze Deine Beiträge sehr, aber etwas konstruktiver könnte es hier schon sein. Sich komplett manuell auf der Konsole durch die Verzeichnisse zu hangeln kann es mMn nicht sein, falls Du das damit zum Ausdruck bringen wolltest. Da bietet sich der Start durch einen Doppel-Klick nun mal an. Das Script macht im Zweifel nichts, kann keinen Schaden anrichten und normalerweise sind die konvertierten Dateien am Ende einfach da. Ich hatte ja schon angedeutet, dass nicht aller denkbarer Komfort da drin steckt.

Im konstruktiven Sinne hier eine Ergänzung: in der ‘convert.cmd’ noch eine Zeile mit pause anfügen und das Fenster bleibt offen, wartend auf einen Tastendruck, so dass man die Ausgabe sehen kann. Damit ist die Beschreibung zum manuellen Debuggen aus meinem vorhergehenden Kommentar obsolet. Ok?

Ich rede nicht davon, sich auf der Kommandozeile durch Verzeichnisse zu hangeln sondern davon, auf der Kommdozeile Skripte zu starten um Fehler zu sehen, was ja jetzt auch offensichtlich erfolgt ist. Und was an dem mittelbaren Ratschlag das Kommando doch unter einer Eingabeaufforderung zu testen, unkonstruktiv sein soll, sehe ich nicht ganz. Sei doch ehrlich - Dich stört das Wort Blödsinn (und da habe ich schon mal vorab gebeten mir nicht böse zu sein) - was ich hier natürlich gerne wiederhole.

Guten Morgen,

ich habe den Fehler jetzt sichtbar gemacht. Siehe

Könnte es ein, dass es an dem Verzeichnisnamen Eigene Dateien (mit Leerzeichen in der Mitte) liegt?

Aber wie ändert man das in den cmd-Dateien?

Ah, verstehe. Die Idee, die ‘loconvert_ods.cmd’ in einen Pfad ohne Leerstellen zu legen, war gut. Bitte ändere die ‘convert.cmd’ wie folgt (beachte ‘@path’ am Ende):

Forfiles /P "%cd%" /M *.xlsx /C "cmd /c C:\Users\Jürgen\loconvert_ods.cmd @path"

Oder lass das zweite %cd% in der ursprünglichen Zeile weg, dann aber ‘loconvert_ods.cmd’ mit in das Verzeichnis stellen:

Forfiles /P "%cd%" /M *.xlsx /C "cmd /c loconvert_ods.cmd @file"

Das läuft bei mir beides mit den gleichen Pfaden wie bei Dir durch (trotz Leerstellen im Pfad).

Danke! Ein anderer Fehler tritt jetzt etwas später auf :wink: Siehe unten:

Nun scheint er ein Problem mit meinem Vornamen (der ein “ü” enthält) zu haben.
Bin wiedermal ratlos. Aber anscheinend nicht ohne Helfer :-))

Hab im Moment keine Idee, was Microsoft da verbrochen hat. Kann es aber hier nachvollziehen. Dann nimm bitte die andere Variante, in der beide cmd-Dateien im fraglichen Verzeichnis untergebracht werden. Die kommt an der kritischen Stelle ohne die Auswertung des Pfades aus und bleibt somit auch nicht an äöüß und Leerstellen hängen.

Also, Windows stellt sich selbst ein Bein. (Wen es interessiert: wird die cmd-Datei mittels notepad erstellt, bekommt die Datei fix die Codepage 1250 zugewiesen. Und die lässt sich im Kontext Forfiles nicht mit der DOS Codepage 850 zusammenbringen. Echt schräg.) Wie gesagt, nutze bitte Variante 2 Forfiles /P "%cd%" /M *.xlsx /C "cmd /c loconvert_ods.cmd @file", wo beide cmd-Dateien im zu konvertierenden Verzeichnis liegen. Mit Dateinamen, die äöüß enthalten, funktioniert es.

Volltreffer! Jetzt geht es einwandfrei. Vielen Dank dafür!
Leider hätte ich noch ein paar Bedarfe:

  1. ich würde gerne nach der erfolgten Konvertierung mit einem zusätzlichen Befehl die konvertierten MS-Office-Dateien in dem Verzeichnis löschen. Da ich bereits alle MS-Office-Dateien extern gesichert habe, wäre das kein Risiko oder Verlust.
  2. Kennwortgeschützte Dateien können so nicht konvertiert werden.
    Und die Eingabeaufforderung zeigt auch keinen Fehler an. Das Skript läuft einfach durch. Insofern wäre es ungut, wenn alle MS-Office-Dateien im Verzeichnis gelöscht würden.
    Entweder, die Dateien mit Kennwort müssten bleiben, oder ich brauchte irgendeinen Hinweis, dass Dateien nicht konvertiert wurden.
  3. Die konvertierten Dateien erhalten alle Datum und Zeit der Konvertierung. Ist es möglich, die MS-Office-Zeiten beizubehalten?
    Ich hoffe, ich überstrapaziere nicht die Hilfsbereitschaft oder Geduld. In jedem Falle schon jetzt großes Dankeschön an alle Beteiligten und schönen Sonntag!