Outlook Attachment mit Sonderzeichen

Alles was nicht wirklich Programmierung ist, aber auch nicht Plaudereien im Raucherraum

Moderator: Moderatoren

Benutzeravatar
Marcus Herz
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 221
Registriert: Mo, 16. Jan 2006 8:13
Wohnort: Allgäu
Hat sich bedankt: 1 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Outlook Attachment mit Sonderzeichen

Beitrag von Marcus Herz » Mo, 12. Okt 2020 10:03

Jetzt muss ich mich auch noch einklinken:
UTF-8 ist auch UNICODE,
Die W Funktionen in der C-API sind aber UTF-16
Gruß Marcus

Es gibt keine Grenzen, aber du kannst welche ziehen.

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15268
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 10 Mal
Danksagung erhalten: 7 Mal
Kontaktdaten:

Re: Outlook Attachment mit Sonderzeichen

Beitrag von brandelh » Mo, 12. Okt 2020 13:34

Hi,

ist eine Kodierung das Gleiche wie das 2 Byte Zeichen ?

... laut Wikipedia ist:
UTF-8 (Abkürzung für 8-Bit UCS Transformation Format, wobei UCS wiederum Universal Coded Character Set abkürzt)
ist die am weitesten verbreitete Kodierung für Unicode-Zeichen (Unicode und UCS sind praktisch identisch).
Eine Kodierung ist meiner Meinung nicht das Gleiche (==) sondern nur sinngemäß, es ist nur eine 8 Bit Transport Codierung damit man nicht für jedes Zeichen 2 Byte nutzen muss.

Wie auch immer man das oben nennt oder sieht - im Prinzip wissen wir was gemeint ist - entsteht dann das Problem, wenn man mit einem ANSI Programm den Namen sucht,
da diese Umsetzung auf andere Zeichen kommt als gespeichert wurden.
Würde das lokale Ansi "ü" aus einer z.B. Xbase++ Anwendung das gleiche UNICODE (UTF-16) ergeben, wie bei der obigen Transformation von UTF-8, dann würde kein Problem bestehen.
Die Dateinamen werden in UTF-16 mit 2 Byte je Zeichen gespeichert, Windows intern oder auch Outlook haben kein Problem mit dem ankommenden UTF-8 Namen und setzen den in UTF-16 (bei SaveAs ... denke ich mal) um.
Eventuell sendet aber auch Apple IOS ein anderes "ü" Zeichen in UTF-8, als wir unter ANSI -> UTF-8 unter Windows erzeugen würden.

Wie auch immer, es sind keine "versteckten Dateien" oder gar "Viren-Dateien" sondern schlicht und ergreifend muss man die in Unicode (WSTRING) suchen und umbenennen.
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12480
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 3 Mal
Danksagung erhalten: 5 Mal

Re: Outlook Attachment mit Sonderzeichen

Beitrag von AUGE_OHR » Mo, 12. Okt 2020 23:07

hi,

Danke für eure Antworten.
die Ursache scheint gefunden (Apple Einstellungen) so das von der Seite nichts mehr kommen sollte

nun ist "das" auch das Problem was weitere Arbeit verhindert.
wenn ich die Beispiel aus Outlook weiterleite werden die anscheint noch mal verändert

---
wenn ich 2 x UTF-8 String zum Encodieren eingebe erhalte ich eine "ähnliche" Optik

Code: Alles auswählen

U=CC=88berscha=CC=88tzung
=C3=9Cbersch=C3=A4tzung
https://www.webatic.com/quoted-printable-convertor

---
ich habe diese Info bekommen
I already know a little more. This UTF-8 format what you get from MAC is commonly called UTF-8-MAC and is based on a combination of characters, ie "overprinting" a special character on the previous one. Something like overwriting characters on a dot matrix printer, like O + BackSpace + ' = Ó

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.
es ist also gar kein "richtihges" UTF-8

---
das man solche Dateien mit Powerbasis bearbeiten kann ist gut, aber wie mit xBase :?:

ich kann unter harbour mit UTF8 arbeiten und "optisch" stimmt es auch.
auch wenn ich es an ShellExecute() übergebe funktioniert es aber nicht mit FOPEN() oder ShFileOperation() die wohl ANSI erwarten
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15268
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 10 Mal
Danksagung erhalten: 7 Mal
Kontaktdaten:

Re: Outlook Attachment mit Sonderzeichen

Beitrag von brandelh » Di, 13. Okt 2020 7:20

Jimmy, liest du eigentlich was du zitierst und schreibst ? :roll: :roll: :roll: :roll:

Akzent und Akzentzeichen :arrow: 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 :arrow: é :!:

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 :arrow: Zeichentabelle :arrow: Arial MS UNICODE :arrow: ALT+0168 = ¨ = Diärese (Zeichensatz auf UNICODE)
"u"+sUml :arrow: "ü" // 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 ... :oops:
Ich hoffe die lassen diesen Blödsinn.
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12480
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 3 Mal
Danksagung erhalten: 5 Mal

Re: Outlook Attachment mit Sonderzeichen

Beitrag von AUGE_OHR » Do, 15. Okt 2020 6:16

hi Hubert,

ich habe aber nicht CHR(168) sondern CHR(204). :-"

---

ich habe festgestellt das meine alte Outlook App solche Datein nicht abspeichern konnte und deshalb finde ich keine mit Everything nur die Demo Datei mit ALT-204 :D

ich prüfe in meine Xbase++ App nun ob das Zeichen 204 vorkommt und nehme es als Marker für STRTRAN()
allerdings passiert das nach dem Dekodieren der als UTF-8 "gekennzeichneten" MIME Inhaltes

nun habe ich für harbour eine neue Version bekommen die beim Decodieren von "UTF8-Mac" die Zeichen austauscht
Rot_Gruen.jpg
Rot_Gruen.jpg (25.78 KiB) 143 mal betrachtet
Ueberschaetzung.jpg
Ueberschaetzung.jpg (13.58 KiB) 143 mal betrachtet
das scheint nun zu funktionieren und ich kann keine "komischen" Zeichen in der CMD Box sehen. =D>

---

da ich nicht mehr Codepage GERMAN nehmen hatten die "A" Funktionen nicht mehr gearbeitet.
auch die ShFileOperation war meine "A" Version sodass ich UTF-8 konvertieren muss.

Code: Alles auswählen

   IF HMG_IsUTF8( cFile )
      cLoad := HMG_UNICODE_TO_ANSI( cFile )
   ELSE
      cLoad := cFile
   ENDIF
! Anmerkung : es sind meine "eigenen" API Function und nicht die von der Constribution.
während ich meine für 64 Bit (Parameter) und UTF8 erweitern muss ist das bei der Contribution schon längst geschehen.

damit ist das Thema für mich soweit erledigt und alles scheint so wie gewünscht zu funktionieren.
Danke für die Hilfe
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15268
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 10 Mal
Danksagung erhalten: 7 Mal
Kontaktdaten:

Re: Outlook Attachment mit Sonderzeichen

Beitrag von brandelh » Do, 15. Okt 2020 14:27

AUGE_OHR hat geschrieben:
Do, 15. Okt 2020 6:16
ich habe aber nicht CHR(168) sondern CHR(204). :-"
vermutlich hast du dann eine OEM Übersetzung drin, egal solange du nun eine Lösung hast :-)
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12480
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 3 Mal
Danksagung erhalten: 5 Mal

Re: Outlook Attachment mit Sonderzeichen

Beitrag von AUGE_OHR » Do, 15. Okt 2020 22:33

hi,

du hattest doch "das" gesucht
no_Nerv.jpg
no_Nerv.jpg (114.62 KiB) 109 mal betrachtet
wenn man das abschaltet kommt die Abfrage nicht mehr.
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15268
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 10 Mal
Danksagung erhalten: 7 Mal
Kontaktdaten:

Re: Outlook Attachment mit Sonderzeichen

Beitrag von brandelh » Fr, 16. Okt 2020 0:41

DANKE :D
Gruß
Hubert

Antworten