Probleme mit deutschen Umlauten seit dem macOS Ventura 13.3 Update

Hallo slempert,

ich habe das gleiche Probleme festgestellt beim Dateinamen und habe festgestellt wenn ich die Umlaute im Dateinamen lösche und gleich wieder hinschreibe lässt sich die PDF Datei ganz normal öffnen wie vorher.

Das gleiche gilt für den Namen des Ordners wo sich die PDF Datei befindet, hat der Name des Ordners Umlaute lässt sich die PDF Datei darin nicht öffnen bis die Umlaute im Ordnername gelöscht und wieder hingeschrieben wurden. Alles sehr Merkwürdig!

Mittlerweile ist Ventura 13.3.1 erschienen aber das Problem besteht trotzdem! Irgendwie sehr schwach von Apple!

"Als zahlender und treuer Apple-Kunde, der sich die Zeit nimmt, einem Bug-Report einzustellen, empfinde ich es als Frechheit, mit der o.g. allgemeinen Nachricht ohne die Möglichkeit eines direkt Feedbacks einfach abgespeist zu werden. Wertschätzender Kundensupport sieht anders aus!"

das kann ich verstehen. Das feedback Formular ist für Rückmeldungen gedacht, aber nicht wirklich für Bug Reports geeignet.

Wenn man richtige Fehlerberichte mit Bildschirmfotos und Testdaten an Apple senden will, sollte man sich Zugriff auf den Feedback Assistenten beschaffen. Den bekommt man, wenn man sich einen Developer Account einrichtet oder am öffentlichen Beta Test Programm teilnimmt. Dann bekommt man ein Ticket für den Bug report, kann sehen, wieviele ähnliche Reports es gibt, und bekommt eine Rückmeldung, wenn der Fehler behoben worden ist.

Deine „richtigen“ Browser zeigen dieses Problem mit einiger Wahrscheinlichkeit nur deshalb nicht, weil die sich auch um Sachen kümmern, die eigentlich ein gut sortiertes Betriebssystem erledigen sollte. Und OS X „wie Steve es noch kannte“, war ordentlich sortiert: Probleme „mit ohne richtiger Normalisierung drin“ habe ich hier im Umfeld schon mehrere gesehen. Und zwar erst in dieser „jüngeren Zeit“, denn „früher einmal“™ habe ich mich ja noch mit „den Gläubigen vom heiligen Gnu“ amüsiert, indem ich denen zwei „offensichtlich identisch benannte Dateien“ in einem Verzeichnis hinterlassen habe. Heute ist das „hierzulande“ noch besser zu erreichen. Beispielsweise mit ausgewählten Dateien, die auf das vom Finder vorgeschlagene „Öffnen mit …“ lediglich ein schnödes „die Datei existiert nicht“ (o. ä.) provozieren.

Also: abgesehen davon, daß hinter einem Komma nur machmal ein „daß“ auftaucht, das (!) dann auch orthografisch richtig platziert ist … nein, an der Stelle habe ich Safari nicht ansatzweise in Verdacht.

Nachgehakt!

Da 13.4 hier, wenigstens bei den Namen von Objekten im Finder, Abhilfe zu schaffen scheint: hatte vielleicht jemand irgendwo etwas in dieser Art

herumliegen? Und wenn: was ist beim Update daraus geworden?

Seltsam!

Gut, wenn man jetzt wüßte, was da beim Update auf 13.4 wie genau geändert wurde – aber so muß man raten.

Hast Du beim Versuch, so einen Namen zu ändern, auch mal den kompletten Namen markiert und „am Stück“ geändert? (Wenn das funktioniert, dann darf der neue Name, würde ich vermuten, durchaus auch der alte sein, muß aber komplett neu eingegeben werden; nicht kopieren und einfügen!)

Und dann stellt sich natürlich die Frage, woher Dateien mit solchem Verhalten stammen. Eventuell aus Windows? Dann könnte es auch sein, daß es (in solcher Hinsicht) ein Update für diese Virtuelle Maschine bräuchte.

Hi slempert,

ich kann dein geschildertes Problem nicht bestätigen, zumindest das erste nicht. Egal ob der Dateiname ein Umlaut enthält oder das Verzeichnis. Hier sogar ein Beispiel mit Umlaut im Verzeichnis und im Dateiname:

Die Suchen in der Vorschau mit Umlauten funktioniert tatsächlich nicht. Es kommt der eingestellte Hinweis und es wird das Wort welches aber existiert nicht gefunden.

Ein vermeintlichen Bug solltest du aber nicht als (Produkt) Feedback senden, sondern hier: https://feedbackassistant.apple.com/ einreichen.

Demnach scheint Apple in macOS 13.3 wirklich etwas bzgl. der verwendeten Zeichenkodierung geändert zu haben. — Ja. Und, so mein Eindruck: da kochen viele mit an dieser Suppe, Salz wurde schon mehrfach in den Topf geworfen.

Sind hier Wissenschaftler anwesend? Zwar eher akademisch, aber wie viele Möglichkeiten bietet Unicode, um ein und das selbe Zeichen als Bytefolge abzubilden? Oder: was da wohl noch auf uns zukommt? Anzeichen dafür, daß es da ein paar Stellen gibt, an denen sich Auswirkungen zeigen, die darauf beruhen, habe ich jedenfalls schon auf meiner „Liste der üblichen Verdächtigen“.

Wobei, wenn ich es recht überlege: die Wurzel liegt vielleicht schon in der Entscheidung, OS X lediglich ein Namensverständnis der Geschmacksnote “case preserving” zu geben. Nicht, weil es das nicht auch besser könnte. Aber ausgerechnet die Systempartition (und in Folge dann auch viele Anwendungen) ist da eher dümmlich. Oh, man kann bzw. konnte OS X durchaus auf „achtsamen“ Partitionen installieren. Und je nach dem, wie man so arbeitet, kann es durchaus angenehm sein, wenn da in einem Verzeichnis die Dateien „Abc“, „aBc“ und „abC“ friedlich koexistieren. Es lief dann oft lange, ohne daß da was zu bemerken war. Wenn der Ärger dann aber einmal angefangen hat …

Randbemerkung zum Schluß: um Mitte der 90er-Jahre herum habe ich mir, damals ohne Angst, Revanche zu erfahren, manchen Linux-Fan(boy? Also manch ganz speziellen „Computer-Auskenner“) mit Dingen wie

mv Hö-Hö.txt Hö-Hö.txt

Schweiß auf die Stirn zu treiben. Aber heute ist „alt“ ja schon aus für Naturgesetze gehaltenen Design-Entscheidungen, deren Horizont (um damaligen Sprachgebrauch zu verwenden) „runde Ecken“ kaum überschreitet, nur doof.

Ich habe den Verdacht, daß  an der Normalisierung von Unicode-Zeichen herumgeschraubt hat und weiter herumschraubt. Allemal gibt es merkbare Unterschiede zu dem „wie es früher einmal war“. Jedenfalls sind mir „in der gute alten Zeit“ keine dementsprechenden Probleme untergekommen. Dafür tauchen diesbezüglich verdächtige Fragen usw. hier („seit iOS Ventura“?) öfter auf. Will sagen: da kommen sicher noch einige „Überraschungen“ auf uns zu, zu viele Köche verderben nicht nur den Brei sondern damit auch den Geschmack!

’tschuldigung, aber: Nein. Das ist nicht merkwürdig. Unicode bietet nun mal oft (nicht bei allen, aber ich möchte nicht zählen müssen!) mehrere, mindestens zwei, Möglichkeiten, ein (v. a. dargestelltes) Zeichen als Byte-Folge abzubilden. Eine kleine „Einführung“ dazu gab es ja schon „da oben“.

Und wenn man nun innerhalb eines Programmes (aus einer „Familie mit gleichen Vorstellungen dazu“), also beispielsweise dem Finder, so ein Dargestelltes Zeichen fassen kann (was ja z. B. bei dieser Schilderung eben nicht der Fall war bzw. ist) und es durch „das Gleiche“ ersetzt, dann platziert man da ja die/eine andere Bytefolge. Und zwar diejenige, die nach Ansicht dieser Anwendung (mittlerweile gerade bei Apple, Steve würde k…) die „einzig richtige“ ist. Weshalb dann die da passenden Anwendungen plötzlich „verstehen“ – und die Quelle mit den „falschen“ Darstellungen damit genau das selbe Problem hat, nur eben anders herum.

Schon wieder muß ich wiederholen: “the only problem with Apple is: they lost their taste. And I don’t mean this in a small way …”!

Ich habe das Problem auch unter Monterey (12.6.5) seit dem letzten Update. In meinem Fall ist es eine Kombination aus Browser und Desktopanwendung. Der Fehler tritt nur mit Safari auf. Mit r*chtigen Browsern (Chrome, Firefox) funktioniert alles. Ich vermute, dass es am Update des Safari-Browsers liegt.

Mein Workaround ist, den Dateinamen zu NFD zu normalisieren. Dann funktioniert es auch mit dem Safari.