Outlook Attachment mit Sonderzeichen
Moderator: Moderatoren
- Marcus Herz
- 1000 working lines a day
- Beiträge: 861
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 39 Mal
- Danksagung erhalten: 197 Mal
- Kontaktdaten:
Re: Outlook Attachment mit Sonderzeichen
Jetzt muss ich mich auch noch einklinken:
UTF-8 ist auch UNICODE,
Die W Funktionen in der C-API sind aber UTF-16
UTF-8 ist auch UNICODE,
Die W Funktionen in der C-API sind aber UTF-16
Gruß Marcus
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Outlook Attachment mit Sonderzeichen
Hi,
ist eine Kodierung das Gleiche wie das 2 Byte Zeichen ?
... laut Wikipedia ist:
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.
ist eine Kodierung das Gleiche wie das 2 Byte Zeichen ?
... laut Wikipedia ist:
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.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).
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
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12911
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Outlook Attachment mit Sonderzeichen
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
https://www.webatic.com/quoted-printable-convertor
---
ich habe diese Info bekommen
---
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
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
---
ich habe diese Info bekommen
es ist also gar kein "richtihges" UTF-8I 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.
---
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
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Outlook Attachment mit Sonderzeichen
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 ?
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.
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 ?
Diese Aussage ist richtig, wenn es einem gelingt Outlook dazu zu bewegen den erhaltenen UTF-8 (im MAC 2 Zeichen überschreiben) Zeichenstring in einenTherefore, the screen shows as if it were one character.
You need to find a way to convert UTF8 combined Characters into single UTF8 characters.
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.
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12911
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Outlook Attachment mit Sonderzeichen
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
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 das scheint nun zu funktionieren und ich kann keine "komischen" Zeichen in der CMD Box sehen.
---
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.
! 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
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
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 das scheint nun zu funktionieren und ich kann keine "komischen" Zeichen in der CMD Box sehen.
---
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
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
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Outlook Attachment mit Sonderzeichen
vermutlich hast du dann eine OEM Übersetzung drin, egal solange du nun eine Lösung hast
Gruß
Hubert
Hubert