zuviel OEM ... ConvToOemCP( cOem )

Zugriff, Engines, Konvertierung. Von ADS über DBF bis zu SQL.

Moderator: Moderatoren

Antworten
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

zuviel OEM ... ConvToOemCP( cOem )

Beitrag von AUGE_OHR »

moin,

also jetzt beim test von ANSI/OEM bin ich in ein Problem gelaufen :
was macht man eigendlich wenn man einen OEM-String mit
cBad := ConvToOemCP( cOem ) behandelt hat und der nun
so in der DBF/FTP steht ?

ein ConvToAnsiCP( ConvToAnsiCP( cBad ) ) bringt nichts ...

gruss by OHR
Jimmy

Code: Alles auswählen


PROCEDURE Main
LOCAL cAnsi, cOem,cBad

   cAnsi := Chr(196)+Chr(228)+Chr(214)+Chr(246)+Chr(220)+Chr(252)
   cOem  := Chr(142)+Chr(132)+Chr(153)+Chr(148)+Chr(154)+Chr(129)


   SET ALTERNATE TO Oem_Oem.txt
   SET ALTERNATE ON

   ? "OEM"  , cOem
   ? "OEM"  , CHR_IST( cOem )
   ? ""
   ? "ANSI" , cAnsi
   ? "ANSI" , CHR_IST( cAnsi )
   ? ""
   ? "BAD OEM2OEM", cBad := ConvToOemCP(  cOem )
   ? "value", CHR_IST(cBad)
   ? ""
   ? ""
   ? "try 2x ConvToAnsiCP ", ConvToAnsiCP( ConvToAnsiCP( cBad ) )

   SET ALTERNATE TO
   SET ALTERNATE OFF

RETURN

PROCEDURE CHR_IST(cString)
LOCAL i

   FOR i = 1 TO 6
      ? ASC( SUBSTR(cString,i,1) )
   NEXT

RETURN

*
* eof
*
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag von andreas »

Hallo Jimmy,

was passiert, wenn du es noch ein mal mit ConvToOemCP( cOem ) behandelst?

Wenn es nicht hilft, dann musst du wohl die Codes von den falschen Zeichen ermitterln, und beim durchlaufen der Datenbank ersetzen.
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Hallo,

ich dachte auch, dass convtoansicp() die überflüssige Umsetzung zurücksetzen müsste, aber ich habe es eben probiert und dann wurde mir klar warum es nicht geht.

Code: Alles auswählen

äöü ÄÖÜ Test OEM - original in OEM
""_ ZTs Test OEM - nach ConvToOemCP(cOEM)
""_ ZTs Test OEM - nach ConvToAnsiCP(cBad)
wie man erkennen kann, werden aus dem OEM String mit ConvToOEMCP(cOEM) alle Umlaute zu normalen Zeichen, ""_ZTs wie sollte hier ein ConvToAnsiCP wieder was retten können, es gibt ja keine Umlaute in diesem String. Da die Zeichen wirklich normal sind, d.h. nicht unterscheidbar von gewünschten ZT""_ etc. kann man sie auch nicht automatisch ersetzen lassen.

Eventuell hilft ein Export in ein Textprogramm mit Rechtschreibkontrolle, aber auf jeden Fall muß ein Mensch den Fehler korrigieren.

PS wie sieht es mit einer Sicherungskopie aus, hast du eine ?
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Beitrag von AUGE_OHR »

hi,
brandelh hat geschrieben: ich dachte auch, dass convtoansicp() die überflüssige Umsetzung zurücksetzen müsste, aber ich habe es eben probiert und dann
wurde mir klar warum es nicht geht.

Code: Alles auswählen

äöü ÄÖÜ Test OEM - original in OEM
""_ ZTs Test OEM - nach ConvToOemCP(cOEM)
""_ ZTs Test OEM - nach ConvToAnsiCP(cBad)
wie man erkennen kann, werden aus dem OEM String mit ConvToOEMCP(cOEM) alle Umlaute zu normalen Zeichen, ""_ZTs wie sollte hier ein ConvToAnsiCP wieder was retten können, es gibt ja keine Umlaute in diesem String. Da die Zeichen wirklich normal sind, d.h. nicht unterscheidbar von gewünschten ZT""_ etc. kann man sie auch nicht automatisch ersetzen lassen.
genau das ist dass Problem was ich beim testen hatte.
brandelh hat geschrieben: PS wie sieht es mit einer Sicherungskopie aus, hast du eine ?
glücklicherweise war das nur ein Test, aber nun bin ich wenigstens
gewarnt das sowas nicht passieren darf weil nicht reversibel.

gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Beitrag von AUGE_OHR »

noch eine Frage : wenn man "puren" email code empfängt (mit XBsee)

wie kann man identifizieren ob es sich um eine 7-Bit, 8-Bit, Unicode,
OEM oder ANSi handelt ? (hoffe ich bringe hier nix durch einander)

gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Hallo Jimmy,

ich meine pure eMail ist 127 Bit ASCII (Ansi gibt es nur unter Windows). Aber ich habe auch schon Umlaute erhalten, daher müssen die irgendwas dabei umsetzen. Ich glaube nicht, dass es ANSI emails gibt.
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Beitrag von Tom »

Hallo, Jimmy.

Die Info bekommst Du aus den Rohdaten der Mail, zum Beispiel:

Content-Type: text/plain;
charset="iso-8859-1"

Weiterführende Info:

http://de.wikipedia.org/wiki/ISO-8859-1
Herzlich,
Tom
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Beitrag von AUGE_OHR »

hi,
Tom hat geschrieben: Die Info bekommst Du aus den Rohdaten der Mail, zum Beispiel:

Content-Type: text/plain;
charset="iso-8859-1"

Weiterführende Info:

http://de.wikipedia.org/wiki/ISO-8859-1
ok danke. mal sehen ob ich das direkt mit XBsee extrahieren kann
oder wie ich sonst da ran komme ... muss mich da mal durchkämpfen.

... oder hat das jemand schon gemacht ?

gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Beitrag von AUGE_OHR »

hi,

ich hatte mal bei Alaska angefragt und vom "Chef" eine Antwort
wieder Steffen. Was du beschreibts ist insofern korrekt
als das folgendes gilt.

1.) OEM -> ANSI und ANSI -> OEM sind nicht orthogonal
also reversibel. Das hängt damit zusammen das es in OEM bzw.
ANSI jeweils Zeichen gibt die nicht abgebildet werden können
weil diese im jeweils anderen charset nicht enthalten sind.

2.) Ein Conv..... untersucht alle codepoints im string
also ASC(0) - ASC(255) und transformiert diese entsprechend.

Aus 1+2 folgt das was du festgestellt hast. Der String/die Zeichenkette
ist schliesslich ein array von bytes die codepoints definieren, die
Bedeutung des codepoints ergibt sich dann durch das gewählte charset.
tja "sehr sicher" ist das also nicht, sodas ich lieber zu meinen eigenen
Function greife. Die funktioniren zwar auch, aber ich muss für jedes
Sonderzeichen ein STRTRAN ausführen ... also 6x den String "anfassen".

geht das nicht "kompackter" ?

gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Hallo Jimmy,

die Konverter-Funktionen sind sicher, nur muss man vorher sicherstellen, welchen Zeichensatz man hat. Bei deinem eMail-Problem steht das ja - wie wir von Tom wissen - im Header und ist somit bekannt, bei anderem Text müsste man häufige Wörter mit Umlauten suchen oder den Anwender fragen um sicher zu gehen ob ANSI oder OEM vorliegt.

Das Problem liegt halt nunmal darin, dass ein chr(234) immer ein chr(234) ist, aber die zugehörige Anzeige ein Box-Zeichen, ein Umlaut oder sonst irgendwas sein kann. Wie bei so vielem wurde hier bei der Konzeption (Betriebssystem / Computer) vergessen, dass es auch noch andere Länder als die USA gibt. Alaska und Xbase++ müssen nun wie alle anderen Sprachen den Mist nun auf die Anwender abwälzen.

6 x STRTRAN aufzurufen ist in jedem Fall schneller, als jedes Zeichen einzeln auszutauschen ! Da ich bei meinen Indexen immer die Umlaute ausschalte, hatte ich bei der Erstellung der Funktion hier alles durchprobiert. Xbase ist bei Strings und Schleifenbearbeitung wegen der fehlenden LONG INT STRONG TYPE Unterstützung echt lahm, aber mit den StrTran() oder anderen Funktionen für ganze Strings kann man das locker ausgleichen ...
Gruß
Hubert
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Beitrag von Manfred »

Hi Hubert,
Da ich bei meinen Indexen immer die Umlaute ausschalte...
kann ich jetzt im Moment nicht so ganz verstehen...
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Hallo Manfred,

Ich indiziere Textfelder immer mit KeinUmlaut(FeldXYZ).
Dann suche ich mit dbseek(keinumlaut(cSuch)) etc.

Keinumlaut tauscht ä -> ae etc. und macht dann upper(), wobei die Länge am Schluß wieder auf den Anfangswert gesetzt wird.

Eine Suche nach 'Müller' findet also auch 'Mueller', das ganze mache ich mit einer Kette von StrTran() Anweisungen ...
Gruß
Hubert
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Beitrag von Manfred »

Hi Hubert,

so hatte ich mir das schon gedacht, aber welchen wirklichen Sinn macht das? Schließt Du damit echte, vorhersehbare Probleme aus?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Hallo Manfred,

wir suchen z.B. bei uns in Namensfeldern. Die Daten stammen oft noch vom Host oder älteren Mitarbeitern, welche äöü auf der Tastatur noch nicht gefunden haben ;-)
Mit Keinumlaut finde ich alle gültigen Schreibweisen.
Unter Clipper war sonst zusätzlich die Sortierung nicht so wie gewünscht.
Gruß
Hubert
Antworten