Umlaute, UTF-Standard vs. Apples Alleingang

Umlaute, UTF-Standard vs. Apples Alleingang

by Markus Feuerstack -
Number of replies: 9

Wo fange ich an, ich glaube generell habe ich die Ursache schon erodieren können und wüsste auch wo man ansetzen könnte es zu beheben.
Ein Umlaut als Beispiel.
Zeichen UTF-# UTF-Standard
ö 246 NFC
o 111 NFD
̈   776 NFD
Das Obere ist die Windows/Linux Variante, die unteren beiden ist wie Apple es macht. Das Ergebnis sieht (meist) gleich aus, aber da die Namen eben doch nicht die selben sind, kommt es an allen möglichen Stellen zu Problemen.
UTF setzt sich im Web durch, ASCII stirbt langsam aber sicher, doch Probleme durch Character Encoding bleiben *G. Windows und Linux konnten sich auf einen Standard einigen: NFC. Apple entschied sich aber für NFD, wohl damit sie ihre User gängeln können nur Apple-Elektronik kaufen, da es sonst zu eben genannten Problemen kommt.
Diese entstehen aber auch dann, wenn ein Professor von seinem Mac Dateien auf Moodle lädt und man diese dann auf seinen Nicht-Apple-PC herunterlädt. Das Kursmaterial enthält dank Wörter wie "Lösung" und Übung" relativ viele störungsverursachende Umlaute.
Könnten Sie es einrichten, dass Moodle hochgeladene Dateinamen automatisch in NFC konvertiert?
Die Anzeigefehler der Namen im Moodlekurs wurden vom Professor fürs erste von Hand behoben, sollten aber auch in Zukunft automatisch korrigiert werden. Das angehängte Bild zeigt wie es vorher aussah.

[...]

Edit: Auch im Forum werden die UTF-Zeichen in NFD falsch angezeigt.

(Bearbeitet von Martin Smaxwil - Originaleintrag am Dienstag, 28. Juli 2020, 16:04)

Attachment UTF_Bug.png
Tags:
In reply to Markus Feuerstack

Re: Umlaute, UTF-Standard vs. Apples Alleingang

by Martin Smaxwil -

Hallo Herr Feuerstack,

das ist ja ein interessanter Effekt. (Ich habe mal Ihren Beitrag etwas eingekürzt und das Attachment geändert, da dieser Support-Kurs und die Foren prinzipiell von Suchmaschinen gecrawlt werden können und es sich bei dem genannten betroffenen Kurs um einen nicht-öffentlichen Kurs handelt.)

Während wir uns auf die Suche nach den Ursachen machen, können Sie evtl. noch ein paar hilfreiche Infos nachliefern:

  • Welches OS, welchen Browser nutzen Sie?
  • Tritt der Fehler auch auf anderen Geräten auf (z.B. Smartphone, Tablet)?
  • Da bei Moodle die Bezeichnung der eigentlichen Datei und der Link auf der Kursseite unterschiedlich sein können: Betrifft der Fehler nur die Links oder auch die Dateinamen der verlinkten Datei?

Wenn ich weitere Infos zu diesem Phänomen habe, melde ich mich hier wieder smile

Gruß,
MS

In reply to Martin Smaxwil

Re: Umlaute, UTF-Standard vs. Apples Alleingang

by Markus Feuerstack -
Da habe ich mich wohl nicht klar ausgedrückt. Der Fehler tritt "überall" auf: Hier im Forum, bei hochgeladenen/heruntergeladenen Dateien und bei dem Namen der auf der Plattform für sie angezeigt wird.
Das Hauptproblem entsteht aber beim herunterladen, weil die Dateien dann im "falschen Format" sind. Deshalb würde es reichen die Namen dort zu normalisieren, das andere sieht halt nur etwas komisch aus.

Edit: Die Datei ist auch nach dem Download im falschen Format unter Linux Mint 18.
Dies bestätigt mein Postulat: Datei von Apple über Moodle zu NFC-Betriebssystemen (Win/Linux)

Edit: Im Vivaldi werden die Umlaute zwar richtig angezeigt, aber wenn man die Datei herunterlädt ist sie auch im falschen Format, wie beim Firefox.
Dies bestätigt weiter mein Postulat: Datei von Apple über Moodle zu NFC-Betriebssystemen (Win/Linux)
In reply to Martin Smaxwil

Re: Umlaute, UTF-Standard vs. Apples Alleingang

by Markus Feuerstack -
Vivaldi 3.1.1929.48 (Stable channel) (32-bit)
Trotz Update, bleibt der Download im falschen Format.

Win7, Min Browser 1.14.1 (Chromium 80.0)
Auch hier im falschen Format.

Somit tritt der Fehler wohl immer dann auf, wenn jemand von einem NFD nutzenden Betriebssystem (Apple) etwas in Moodle packt. Moodle gibt es dann einfach genau so formatiert weiter wie es es bekommen hat. Was dann aber bei NFC-Betriebssystemen (Win/Linux) nicht gut ankommt. Somit wäre die Lösung, Eingaben von Apple vor dem Speichern zu normalisieren.
In reply to Markus Feuerstack

Re: Umlaute, UTF-Standard vs. Apples Alleingang

by Markus Feuerstack -
Unvorteilhaft, Sie haben alles entfernt auch die Zeichen, also hier nochmal zum testen ohne den Rest:
NFC: äöü (Windows/Linux)
NFD: ö ä (Apple)
Edit: Bild angehängt wie es bei mir aussieht: die Punkte sind leicht neben den Buchstaben; Win7 Firefox 68.1 ESR 
Edit: weiteres Bild angehängt wie es bei mir aussieht. dort werden sie korrekt angezeigt; Win7 Vivaldi 2.10 32bit stable
Edit: IphoneSE korrekt mit Firefox 27.0
Edit: wird korrekt angezeigt bei: Linux Mint 18, Firefox 78 32bit
Edit: Naja was heißt korrekt, de facto ist es ja das falsche Format für Win/Linux, da ist es gut dass Firefox sie unter Windows leicht verschoben anzeigt, weil man dann direkt einen Hinweis bekommt woran es dran liegt.
Attachment Untitled.png
Attachment vivaldi.png
In reply to Markus Feuerstack

Re: Umlaute, UTF-Standard vs. Apples Alleingang

by Martin Smaxwil -

Vielleicht "unvorteilhaft", aber notwendig. Zurück auf der Sachebene haben wir das "Problem" nachstellen und (teilweise) reproduzieren können. Ich versuche mal, die beiden Bereiche "Darstellung" und "fehlerhafte Dateien" auseinanderzuhalten.

Die Darstellung scheint nur in speziellen OS/Browser-Kombinationen fehlerhaft zu sein. Die Textbeispiele aus dem Forum sehen in verschiedenen Browsern so aus:

Die von einem Mac (in UTF-8 NFD) erstellten Dateilinks sehen ebenso gut bzw. schlecht aus:


Von den mir zugänglichen Browsern (unter Windows 10) zeigt nur der (veraltete) Internet Explorer 11 das Phänomen - und scheinbar Ihr Win 7/Firefox 68 ESR. Android-Geräte mit Chrome und Firefox sowie iOS-Geräte mit Safari und Firefox zeigen die Probleme ebenfalls nicht.

Zwecks angemessener Anzeige kann ich Ihnen kurzfristig nur einen alternativen (evtl. aktuelleren) Browser empfehlen.

Bzgl. der fehlerhaften Dateien können wir den Effekt erst einmal nicht reproduzieren: Die eigentlichen Dateien sind in allen (!) Browsern herunterladbar, korrekt benannt (incl. Leerzeichen und Umlauten im Dateinamen) und auf den entsprechenden Geräten zu öffnen.

Allerdings scheint es so zu sein, dass im Falle eines Dateiuploads via Drag-and-Drop eines Kursverantwortlichen mit MacOS als Betriebssystem das für diesen Upload genutze JavaScript die Unicode-Normalisierung etwas anders handhabt, als bei anderen Upload-Möglichkeiten. Diese wirken sich allerdings prinzipiell nicht auf die Dateien aus.

Worin genau besteht denn der "Fehler" bzw. das "falsche Format" der Dateien? (Lässt sich nicht laden, lässt sich nicht speichern, lässt sich nicht öffnen, ...)

Beste Grüße,
MS

In reply to Markus Feuerstack

Re: Umlaute, UTF-Standard vs. Apples Alleingang

by Helge Wiethoff -
Hallo Herr Feuerstack,
interessantes Problem. Ist mir tatsächlich bis dato noch nicht untergekommen. Sofern ich http://unicode.org/reports/tr15/ aber richtig verstanden habe, spielt bei korrekter Unicode-Implementierung die Normalisierung keine Rolle. Da ich das Problem nur mit "legacy" Software reproduzieren kann, tendiere ich hier zu "bleibt wie es ist".
Falls Sie auf Ihrer OS/Browser Kombination bleiben (müssen), kommt vielleicht eine Konvertierung in Frage?
➜  Downloads convmv -f utf-8 -t utf-8 --nfc --notest  'Ma<0308>c hinzufu<0308>gen Datei.pdf'
mv "./Mäc hinzufügen Datei.pdf"	"./Mäc hinzufügen Datei.pdf"
Ready! I converted 1 files in 0 seconds.
Das kann auch mit rsync funktionieren falls ein smb-Share oder ähnliches die Ursache ist:
rsync -a --iconv=utf-8-mac,utf-8 localdir/ mynas:remotedir/
Viele Grüße
Helge Wiethoff
In reply to Helge Wiethoff

Re: Umlaute, UTF-Standard vs. Apples Alleingang

by Markus Feuerstack -
Auf den ersten Blick fallen die als NFD heruntergeladenen Dateien nicht auf, sehen ja gleich aus. Ich kann die Dateien auch mit allen OS-Browser-Kombinationen herunterladen und öffnen. Aber sowohl bei Windows als auch bei Linux liegen sie mir dann im originalen NFD vor.

Nur legacy?
Der Firefox-Browser ist Up-to-date, weil es das Extended Service Release ist. So muss man nicht immer wenn man den Browser öffnet warten bis er sich aktualisiert hat, bekommt aber dennoch die Sicherheitsrelevanten Updates. Das Problem besteht ja nicht nur im alten Win7, sondern auch unter Linux Mint 18 "supported until April 2021"
Zudem ist das Alter ja nie das Problem, sondern NFC vs NFD und Moodle stellt immer das originale (NFD) zum Download bereit.

Aufgrund von Covid-19, besteht der digitale Anteil des Studiums nicht mehr nur aus ein paar PDFs, die man mal eben auf einen USB-Stick kopiert. Dieses Semester (2BMB) schlug mit über 45GB in über 1100 Dateien allein von den Moodle-Kursen zu Buche. Zudem aktualisieren manche Professoren ihre Dateien. Des weiteren schalten manche Professoren Inhalte nur temporär frei. Somit ist es ratsam jeden Kurs mindestens einmal pro Woche zum überprüfen.

Das lässt sich nimmermehr per Hand managen, also probiere ich dem Herr durch Programme zu werden. Die korrekte Unicode-Implementierung scheint noch auf sich warten zu lassen, denn da kommt es dann zu allen möglichen Problemen:
Man möchte natürlich nicht jede Woche alle Dateien nochmal downloaden und vergleichen, für den Fall dass sie nun neu/anders sind. Also nur Dateien downloaden die aktualisiert oder neu sind, ist denke ich auch in Ihrem Interesse die Serverlast klein zu halten. Aber dank Apples anderer Formatierung ist die Datei immer "neu" und wird so erneut heruntergeladen. Ein Konvertiert-Skript über den Ordner vor dem Download laufen zulassen, wie Sie es vorschlagen, macht es leider nur schlimmer. Denn die meisten Dateien in dem Kurs sind NFC, die dann "neu" heruntergeladen würden, weil die lokalen Versionen zu NFD konvertiert worden sind. Zur Zeit sind es "nur" 21 PDFs, aber wenn es in Zukunft auch "unkomprimierte" Videos werden... Es sei denn, man legt sich die Dateien mehrfach wie im Screenshot an. Aber das kann ja auch keine Dauerlösung sein. Dann beschwert sich aber das Backup-Programm, dass es nicht normalisierte Dateien gibt. Es würde sie zu NFC konvertieren, wenn sie nicht schon existierten würden. Selbst darf es dann nicht entscheiden, welches die Richtigen sind und wartet darauf, dass der User die Falschen von Hand löscht. Beim Integritätscheck kommt es dann auf Grund der mehrfach vorhandenen gleichen Dateien als NFC und NFD zu Hash-"Kollisionen". Eigentlich läuft das System perfekt bis auf Apples NFD-Dateien...

Da Sie es nur mit "legacy Software reproduzieren" konnten, bin ich gespannt was Sie mir zum Download, Integritätscheck und Backup für Win7/Linux empfehlen können, bevorzugt FOSS.
Attachment doppelte Dateien.png
In reply to Markus Feuerstack

Re: Umlaute, UTF-Standard vs. Apples Alleingang

by Helge Wiethoff -

Wie gesagt: Ich kann das Problem nur mit legacy Software reproduzieren. Das heißt aber natürlich nicht, dass es ausschließlich solche betrifft... Auch wenn ich Firefox 68.x ESR mit EOL in ca. 8 Wochen und Mint18 zumindest als "gut abgehangene" Software bezeichnen würde wink. Windows 7 mit Firefox 68.1 (oder war hier 68.11 gemeint?) ist aber definitiv legacy...

Ihre Darstellungsprobleme sollten, wenn überhaupt, nur in Dateinamen vorkommen. Innerhalb der hier bereitgestellten PDF-Dokumenten oder sogar in Videos sollte/kann es kein Problem sein!?

Zwei FOSS-Komponenten zum anpassen der Unicode-Normalisierung der Dateinamen habe ich Ihnen bereits genannt.

Grundsätzlich scheint moodle eine unterschiedliche Herangehensweise für die zwei Upload-Varianten zu haben. Bei Drag&Drop Upload wird NFD übernommen und bei "Material -> Datei hinzufügen" NFC. Erstellen Sie doch bitte einen Bug-Report unter https://tracker.moodle.org/. Sie können die Bug-ID gerne hier posten, dann kann ich ggf. im moodle-tracker dazu auch was schreiben.

Wir selbst werden aber keine nachträgliche Anpassung der Daten vornehmen. Siehe Prof. Dr. A. E. Brouwer: https://www.win.tue.nl/~aeb/linux/uc/nfc_vs_nfd.html

In reply to Helge Wiethoff

Re: Umlaute, UTF-Standard vs. Apples Alleingang

by Markus Feuerstack -

Im gelinkten Dokument steht: "There is no difference" und "In fact, Unicode declares that there is an equivalence relationship between decomposed and composed sequences, and conformant software should not treat canonically equivalent sequences, whether composed or decomposed or something inbetween, as different."
So sollte es natürlich sein. Nur ist das Mehraufwand zu implementieren und keiner macht es.

Moodle auch nicht! Wenn ich die Textdatei ein zweites mal uploaden möchte, erkennt er das Duplikat und schlägt ersetzen oder umbenennen vor. Bei den PDFs nicht, soviel zur "Canonical equivalence". Ja, in beiden Uploadvarianten.

Weiter lässt sich da noch finden: "Choose NFC if possible", da hält sich Moodle auch nicht dran.

Hat alles nichts mit Darstellungsproblemen oder legacy software zu tun. Aber es scheint ganz unten bei Ihnen auf der Prioritätenliste zu sein, somit werde ich mich nach anderen Lösungen umsehen.