Jimmy, liest du eigentlich was du zitierst und schreibst ?
Akzent und Akzentzeichen
https://de.wikipedia.org/wiki/Akzent_(S ... n%20tragen.
Der Akut – Beispiel: é
Der wird auf der normalen 104 (Westeuropa / Deutschland) so eingegeben:
Zeichen ´ (Taste zwischen '?' und der 'Lösche letztes Zeichen', über dem 'ü' oder dem '*' ...
danach ein e ... und es erscheint
é
Wie auf einer alten Schreibmaschine, Nadel- oder Typendrucker, so - wie oben in deinem Text zitiert - gibt es auch im UNICODE Zeichensatz ein Zeichen, das
nur die ü Pünktchen enthält.
Dieses Zeichen verhält sich so wie das ´ ... oder wie man auf manchen alten Druckern erst ein u gedruckt hat und dann ein "Zeichen zurück" Befehl kam und die Pünktchen drüber gedruckt hat (so einen hatte ich allerdings nie).
Genau das beschreibt dein englischer Text, der MAC nutzt ein 2 Byte Unicode Zeichen, das speziell für diese Pünktchen gemacht wurden.
Dieses 2 Byte Spezial Zeichen wird mit UTF-8 in eine 8 bit Zeichenfolge übersetzt, und beim Speichern wieder zu diesem 2 Byte Spezial Zeichen, das dann im Dateisystem als CHR$(168) gespeichert wird.
Nun muss man wie in meinem Beispiel, mit der UNICODE Struktur und den WSTRING Funktionen (siehe PowerBasic Code) arbeiten und die uns bekannten (oder möglichen) Sachen suchen:
sUml = CHR$(168) // das ist der spezielle Doppelte Punkt
Zeichentabelle
Arial MS UNICODE
ALT+0168 = ¨ = Diärese (Zeichensatz auf UNICODE)
"u"+sUml
"ü" // also aus der Kombination von 2 UNCODE Zeichen (4 Byte) eines machen (2 Byte), und das speichern, dann findet auch die normale Funktion das Zeichen wieder.
Und wegen der 4 / 2 Byte Strings für ein Zeichen, wird auch deutlich, warum es wichtig ist zu unterscheiden zwischen UNICODE Zeichen (2 Byte je Zeichen) und Transportcodierung (UTF-8, 1 bis x Byte je Zeichen), alles muss hier genau zur rechten Zeit richtig gemacht werden sonst kommt Schrott raus
Hierzu muss man eine Sprache verwenden,
die direkten Zugriff auf
WSTRING, die Struktur
DirData (in der UNICODE Variante, mit WSTRING in der Definition - wie in meinem Beispiel Code) und der Übersetzung von WString zu ANSI hat.
Xbase++ kann das nicht, aber man könnte eine DLL oder eine EXE mit einer Sprache schreiben, die damit umgehen kann und der man ein Verzeichnis übergibt, in dem dann die Dateinamen auf unsere ANSI Zeichen normalisiert (umbenennt).
C/C++ kann das auf jeden Fall, Delphi evtl. auch, HARBOUR sollte mit den richtigen Funktionen auch damit klar kommen. Man darf halt nur nicht zurück nach ANSI (intern) konvertieren, und keinesfalls OEM Zeichensatz, noch eine Konvertierung kann nicht gut gehen.
Nochmal es ist kein "abnormales" oder "anderes" UTF-8, sondern der Sender verwendet 2 UNICODE Zeichen statt dem einen Umlaut, logisch dass die UTF-8 Übersetzung diese beiden zurückliefert und speichert.
Windows kann damit umgehen, schließlich kann man die Datei mit dem Explorer umbenennen, im ZIP versenden und ich konnte sie mit dem Original Namen auch in Paint oder Phonobetrachter öffnen.
Wenn es dir reicht, eine solche EXE oder DLL zu bekommen, kann ich mal sehen ob ich die mit PowerBasic erstellen kann und ob der Aufruf klappt.
FixDir(cPfad+cMaske) => benennt alle Dateien auf deutsche Umlaute um.
ü ä ö Ü Ä Ö ... was ist mit einem ß, welche Zeichen sind noch problematisch ?
Therefore, the screen shows as if it were one character.
You need to find a way to convert UTF8 combined Characters into single UTF8 characters.
Diese Aussage ist richtig, wenn es einem gelingt Outlook dazu zu bewegen den erhaltenen UTF-8 (im MAC 2 Zeichen überschreiben) Zeichenstring in einen
Windows ANSI üblichen "ich nehme die Zeichen die ich habe als Umlaute als 1 Zeichen" vor dem Speichern zu übersetzen.
Wenn man aber den Namen nicht vor dem SaveAs() verbessern kann, überträgt Outlook die 2 Byte Zeichen eben in das Dateisystem und man muss mit Unicode wie beschrieben diese wieder umbenennen.
Das Problem stellt sich übrigens auch auf Webseiten, sobald man dort mehr als nur ASCII Zeichen verwenden darf.
Wäre es nicht nett, diese Verwechslung auch bei seiner Hausbank zu erleben, deren Namen zufällig mit Umlauten aus anderen Sprachen/Schreibweisen gespickt wo ganz anders hingeht aber immer noch gleich in der URL erscheint ...
Ich hoffe die lassen diesen Blödsinn.