Leerzeichen, Umlaute und ß in Dateinamen beim ersten Speichern

• 28. Aug 2020 - 19:11

Beim ersten Speicher einer Partitur übernimmt MuseScore den Dateinamen aus dem Titel der Partitur. Das ist ok. Jedoch werden dabei Leerzeichen in Unterstriche, Umlaute in 'ae', 'oe' bzw. 'ue' und 'ß' in 'ss' umgewandelt. Dies war notwendig bei Uraltversionen von MS-DOS und Windows 3.11, wo diese Zeichen nicht in Dateinamen verwendet werden durften. Um sie zu übernehmen, muss beim Speichern die Zeile mit dem Dateinahmen mühsam editiert werden. Das nervt!
Gibt es eine Möglichkeit, diese unnötigen Umwandlungen abzuschalten?

Comments

• 28. Aug 2020 - 19:39

Mmh, entweder hast Du die Spracheinstellungen in Windows auf etwas geändert, was die deutschen Zeichen nicht enthält oder Du hast unter Bearbeiten -> Einstellungen -> Sprache etwas falsches eingestellt (bei mir steht System).

Nachtrag: Die Spracheinstellungen in Musescore sind natürlich für die Oberfläche von Musescore. Aber evtl. hängt das damit zusammen. Evtl. ist das Verhalten so, wenn man Englisch oder so auswählt.

Antworten

• 28. Aug 2020 - 22:36

Nein. Auch heute noch verwendet Windows kein Unicode für Dateinamen und es kommt daher zu Problemen wenn man Dateien mit solchen Namen mit anderen Plattformen wie macOS oder Linux austauschen will.

Antworten

• 28. Aug 2020 - 23:06

Überfordere mich doch nicht mit solchen Begrifflichkeiten, ich bin doch kein "Coder", sondern nur ein ganz gewöhnlicher Mensch, der in der Menge untergeht ;-). Vermutlich habe ich zu wenig Ahnung darüber, aber mein Gedanke hierzu: Kann man nicht die Zeichenkodierung in jedem Betriebssystem irgendwo einstellen?

Antworten

• 29. Aug 2020 - 00:04

Kann man nicht die Zeichenkodierung in jedem Betriebssystem irgendwo einstellen?
Inzwischen sicherlich. Aber man kann es von unhandlich, unflexible und undurchsichtig bis einfach und elegant machen.
Beim OP irritiert mich, das er den Dateinamen per Hand auf mit Umlauten und Leerzeichen abändert und abspeichert.
Unter Linux würde ich fragen: Wie verhält sich Musescore, wenn Du es so aufrufst:
export LANG=de_DE;UTF-8;/usr/bin/mscore
So, habe mal getestet mit folgendem Aufruf:
export LANG="en_GB.US-ASCII";/usr/bin/mscore -a alsa
Auch da bietet mir Musescore die Umlaute aus dem Titel im Dateinamen an.
Mir fällt dazu erstmal nichts weiter ein.

Edit: Ähm, wieso konnte ich da Umlaute eingeben? MS verwaltet wohl intern UTF-8.

Antworten

• 29. Aug 2020 - 01:05

liegt der Grund darin vielleicht, dass MuseScore unter Windows nicht mit der UTF-8 Kodierung klarzukommen scheint?
Ich vermute, das MuseScore intern eh sein eigenes Ding macht (deswegen werden die auch ihre Schriftdateien fest einkompiliert haben). Das Problem liegt da wohl eher zwischen Qt und Windows (mit Windows als Störenfried).

Auch das WWW überfordert mich aus der Ferne diesbezüglich.
Das liegt an die Webseitenbetreiber, die immer noch denken, das die Metaangabe im HTML hat was mit dem den zu verwendenden Zeichensatz zu tun. Die auszugebenden Dateien müssen mit den Server-Header-Angaben übereinstimmen. Sprich, es muß der passende Header zur Datei gesendet werden.

_Word scheint demnach z.B. eine Einstellung zu haben, die Kodierung auszuwählen: _
Da Du nur Word schreibst, meinst Du sicherlich das Ungemach aus dem Hause M$. Wenn ich nicht noch ein paar Tastenkürzel aus dem letzten Jahrtausend wüßte, wüßte ich nicht, wie ich das bedienen soll. Wenn mein Glück anhält, brauche ich das auch nie wieder zu nutzen.
Unter W10 gibt es die Möglichkeit, auf UTF-8 umzustellen, ist aber als Beta markiert. Und inwieweit sich das auswirkt, kann ich nicht beurteilen.
Habe hier den umgekehrten Weg (UTF-8 deaktivieren) gefunden, aber der Weg ist der gleiche:
https://www.commusic.de/hilfe/module_2_5_38_print.html

Antworten

• 29. Aug 2020 - 01:30

Da Du nur Word schreibst, meinst Du sicherlich das Ungemach aus dem Hause M$. Wenn ich nicht noch ein paar Tastenkürzel aus dem letzten Jahrtausend wüßte, wüßte ich nicht, wie ich das bedienen soll.

Ist nur auf Arbeit vonnöten, schon lange nicht mehr privat ;-).

Antworten

• 28. Aug 2020 - 23:36

Das Windows im Zeitalter von UTF-8/16/32 noch mit Codepages rumhantiert, glaube ich gern, da es mein Bild von dieser Firma bestärkt.
Um es zu testen hatte ich extra ein aktuelles W10 mit MS3.5 gestartet. Eine neue Partitur mit "schönen und übelmäßigem" Titel angelegt und mir wurde der Dateiname incl. der Leerzeichen genauso zum speichern angeboten.
Darum vermute ich, daß das Gebietsschema (so heißt das wohl) auf etwas nicht deutschsprachiges gestellt und deswegen anders angeboten wurde. Erklärt allerdings die Unterstriche für die Leerzeichen nicht.
Muß morgen diesbezüglich einmal testen, da ich hin und wieder Dateien zwischen W10 und Linux (auch UTF-8-Textdateien, diese allerdings über eine Versionsverwaltung und Notepad++ kann, wenn ich mich recht entsinne, auch UTF-8) austausche und mir jetzt nicht bewußt bin, das ich seit W10 Probleme damit hatte. Allerdings verwende ich außer den Dateimanager auch kein produktives Programm aus dem Hause Microsoft.

Antworten

• 29. Aug 2020 - 12:57 
//---------------------------------------------------------
//   createDefaultFileName
//---------------------------------------------------------
 
static QString createDefaultFileName(QString fn)
      {
      //
      // special characters in filenames are a constant source
      // of trouble, this replaces some of them common in german:
      //
      fn = fn.simplified();
      fn = fn.replace(QChar(' '),  "_");
      fn = fn.replace(QChar('\n'), "_");
      fn = fn.replace(QChar(0xe4), "ae"); // ä
      fn = fn.replace(QChar(0xf6), "oe"); // ö
      fn = fn.replace(QChar(0xfc), "ue"); // ü
      fn = fn.replace(QChar(0xdf), "ss"); // ß
      fn = fn.replace(QChar(0xc4), "Ae"); // Ä
      fn = fn.replace(QChar(0xd6), "Oe"); // Ö
      fn = fn.replace(QChar(0xdc), "Ue"); // Ü
      fn = fn.replace(QChar(0x266d),"b"); // musical flat sign, happen in instrument names, so can happen in part (file) names
      fn = fn.replace(QChar(0x266f),"#"); // musical sharp sign, can happen in titles, so can happen in score (file) names
      fn = fn.replace( QRegExp( "[" + QRegExp::escape( "\\/:*?\"<>|" ) + "]" ), "_" ); //FAT/NTFS special chars
      return fn;
      }
 
QString MuseScore::saveFilename(QString fn)
      {
      return createDefaultFileName(fn);
      }

An zig Stellen benutzt, nirgends plattformspezifisch.

Antworten

• 29. Aug 2020 - 13:44

Logisch. Der oben gezeigte Code frißt unter Linux nur Laufzeit ohne irgendwas zu ersetzen. Damit da Ersetzungen rauskommen muß man Linux schon darauf prügeln, was man nicht will. ;-)
So wie der Code geschrieben ist, ist er schon mehr oder weniger plattformabhängig. Allerdings ist er auch böse. Da müßte man mal ein paar Polen, Tschechen, Slowener, ... fragen, bei denen der Code Ersetzungen vornimmt.

Antworten

• 29. Aug 2020 - 14:41

Mein Fehler. Sehe gerade: keycode 48 (keysym 0xe4, adiaeresis).
Ich vermute, der obige Code ist schon länger drin und wurde als Schnellhack von einem deutschen Programmierer eingebracht.
Mir schwand da was. Das ist böser Code. Ist die Frage, wann er aufgerufen wird. Kommt er nur zur Anwendung, wenn die Spracheinstellung de_DE ist kann man ein Auge zudrücken, bei de_DE;UTF-8 ist der Code schon wieder sehr böse. Kommt der Code unabhängig von den Spracheinstellungen zum Einsatz (was ich nicht glaube, weil es sonst viele bitterböse Forumseinträge außerhalb des deutschen Forumteils gäbe), dann ist der Code oberböse.
Wird die Zeichenkette, die als Dateiname verwendet werden soll mit dem Code behandelt, dann ist der Code sinnlos, da der keysym nicht in der Zeichenkette erhalten ist.
Wenn man die Beschränktheiten des Filesystems umgehen will, einfach einen neutralen Dateinamen vorgeben.

Antworten

• 29. Aug 2020 - 14:48

Der Code kommt immer zum Tragen wenn ein Dateiname aus Temperatur Titel einer Partitur generiert wird.
Und ja, der ist schon sehr lange drin, sein mehr als 8 Jahren, 412ca454 hatte es bereits, der alleresrte Gig(Hib) commit (dem Begin der MuseScore 2 Entwicklung), der Code stammt wohl aber schon aus MuseScore 1

Antworten

• 29. Aug 2020 - 15:39

Ich stehe gerade aufm Schlauch. Meiner Meinung nach kann und konnte der Code im Gebrauch mit dem generieren des Dateinamens nicht funktionieren bzw. funktioniert haben.
Der Code wandelt Tastatureingaben (keysym - sprachunabhängig). Die entstandene Zeichenkette steht in Variable $TITLE.
Beispiel: Ich drücke auf der Tastatur mit deutschem Layout die Taste ä, es wird der keysym 0xe4 übergeben. Dann wird je nach verwendeter Sprache der keysym 0xe4 in (einfachheitshalber 8-Bit-ASCII) ASCII 132d 0x84h und mit deutscher Charmap ä. Also müßte der Code so ausehen:
fn = fn.replace(QChar(0x84), "ae"); // auch böse
richtiger wäre s/ä/ae/

Der gepostete Code funktioniert nur, wenn die Tastatureingabe abgefangen würde ersetzt und dann in den String geschrieben würde.
Das das aber beim OP zuschlägt ist mir ein Rätsel.
Kann aber auch sein, das ich wieder etwas durcheinanderschmeiße. C/C++/Qt kann ich zwar halbwegs lesen aber schreiben tue ich in anderen Sprachen.

Antworten

• 29. Aug 2020 - 14:52

Ja, unter Linux, vermutlich auch unter macOS. Eine solche Datei lässt sich aber nicht zu Windows transferieren.
Du kannst jedes beliebige Zeichen in Dateinamen verwenden (In POSIX alles ausser '/' in '\0'), der von MuseScore vorgeschlagene Dateiname, basierend auf dem Titel der Partitur, wird diese aber nicht beinhalten.

Antworten

• 29. Aug 2020 - 16:36

Wobei, es geht um der Zeile:
fn = fn.replace( QRegExp( "[" + QRegExp::escape( "\/:*?\"<>|" ) + "]" ), "_" ); //FAT/NTFS

Habe mal etwas getestet. Im Anhang ein Screenshot davon.
Bei A gibt es Probleme (wohl wegen der Interpretation des '/', weil das unmaskiert ein Pfadbestandteil ist). '<>|' halte ich unter Linux unmaskiert ebenfalls für kritisch, da I/O-Umleitungen.
Bei B wird er zwar angezeigt, läßt sich aber nicht speichern (klar, wenn man weiß was <> bewirkt).

Meiner Meinung nach ist das eh nicht sinnvoll. Das einzig wirklich brauchbare ist das Öffnen eines Fensters mit einem voreingestellten Pfad in dem man den Dateinamen einträgt. Wer das nicht vermag ist eh besser bedient, auf der Parkbank sitzend Vögel zu beobachten und schöngeistigen Dingen zu frönen.

Anhang Größe
Test_Filename.png 107.63 KB

Antworten

• 29. Aug 2020 - 19:17

Ich weiß. Zumindest sagt das die Codezeile aus.
Bei meinem Screenshot unter A sieht man, das dem nicht so ist.
"Titel_\/:" wird irgendwie mit Pfadangaben oder so versucht zu interpretieren (ist wohl Linuxspezifisch),
der * wird übernommen und aus ?"<>| wird %3F%22%3C%3E%7C und der Rest wieder normal.
Ich vermute, die Slashs und der Doppelpunkt haben diese Ausgabe provoziert (Hint: URLs). Irgendetwas interpretiert da nochmal um.
Bei B hat er nichts ersetzt.
QChar(0x..) holt sich, wenn ich das jetzt richtig glaube, das Zeichen, was unter dem symkey gemappt ist und replace ersetzt bei true das Zeichen mit dem vorgegebenen String. Jetzt wird aber durch Verwendung von z.B. UTF-8 das Zeichen nochmal umgemappt und QChar liefert ein anderes Zeichen als im String liegt und dadurch kommt es nicht mehr zur Ersetzung. Unter Windows mit der Verwendung von Codepages scheint das zu funktionieren, mit xmodmap nicht mehr.
Kann aber auch sein, das ich QChar() mit der Wirkweise eines anderen Befehls verwechsle. Ist schon 15 - 20 Jahre her, wo ich mich damit rumgeschlagen habe, noch dazu in anderen Programmiersprachen.

Antworten

• 10. Sep 2020 - 16:16

Habe da gerade zufällig etwas Interessantes diesbezüglich entdeckt: Bei "Speichern als..." unterbleibt das Umwandeln sowohl von Leerzeichen als auch Umlauten. Ist doch interessant! Oder?

Antworten

• 10. Sep 2020 - 18:02

Tatsächlich.
Auf die Idee, bei einer neu erstellten Datei auf 'Speichern' zu drücken kam ich nicht. Ich nutze wohl schon zu lange Computer.
Auch die Sonderzeichen "\/:*?\<>|" werden da ersetzt.
Jetzt verstehe ich auch den Gedanken hinter dem Code. Ich vermute, früher hat er gleich gespeichert, ohne den Dialog anzuzeigen und deswegen die unterschiedliche Behandlung zwischen "Speichern" und "Speichern unter".
@kuwitt: Du hast sicherlich genau wie ich immer "Speichern unter" verwendet.

Antworten

• 10. Sep 2020 - 19:01

Korrekt ;-). Mit Strg+S findet tatsächlich auch hier die Ersetzung statt. Bei Sonderzeichen finde ich dies auch weniger störend (außer vielleicht bei "?" oder "&), bei Umlauten oder "ß" schon eher. Aber ist eher ästhetischer Natur und stört nicht wirklich den Arbeitsfluss.
Ich frage mich gerade, bei welchen Zeichen es immer noch Kompatibilitätsprobleme gibt - gefühlt musste man früher viel öfter Dateinamen umbenennen, um ein und dieselbe Datei auf verschiedenen Betriebssystemen zu nutzen - und wie andere Programme damit umgehen (z.B. "LibreOffice", "Gimp", "Scribus", "Inkscape",...), so dass es vielleicht eine bessere Lösung dafür gibt.

Antworten

Do you still have an unanswered question? Please log in first to post your question.