Das deutsche QBasic- und FreeBASIC-Forum

[kilix]

Nachdem alles was ich bisher programmiert habe - mit eurer großen Hilfe - funktioniert habe ich das nächste Problem zu dem ich bisher nichts wirklich brauchbares gefunden habe:
ich lese Date aus CSV-Dateien ein. In diesen Daten gibt es ein Fülle von namen und nicht wenige davon enthalten Umlaute.
Nun habe ich in diesen Thread

https://forum.qbasic.at/viewtopic.php?t=4652&highlight=umlaute

eine Funktion zur Konvertierung der Unlaute gefunden und dazu ein kleines Programm geschrieben mit dem ich ein Wort eingeben kann und das den/die Umlaute in diesem Wort konvertieren soll. Das macht es auch aber nicht so wie man es erwartet, nämlich z.B. Müller wird zu M?ller.
Irgendwie scheint das mit den Zeichencodes in DOS bzw Windows zu tun zu haben aber wie sich das verhält weiß ich nicht. Hier ist das Programm mit der abgekupferten Funktion:

[kilix]

Ich denke, ich hab gefunden was ich suche - im FB Tutorial. Nachdem ich Windows10 verwende habe ich

#INCLUDE "windows.bi"


EDIT: habe Text gestrichen, war ein Fehler von mir. Damit ist diese Frage geklärt!!
_________________
Grüße
kilix

[kilix]

Da habe ich mich leider zu früh gefreut den in meinem Programm werden die Umlaute zwar anders aber wieder nicht richtig übersetzt.
Ich habe am Beginn des Programmes das Include geschrieben:

#INCLUDE "windows.bi"

und in den Zeilen vor dem Print-Befehl:

CharToOem Sas2a, Sas2a
CharToOem Sas3a, Sas3a

aber das ist offenbar so nicht richtig
_________________
Grüße
kilix

[nemored]

Das Problem ist halt immer die Frage, welche Zeichenkodierung wo verwendet wird. ANSI wird uns wahrscheinlich noch eine lange Zeit Kopfschmerzen bereiten.

Mit den Umwandlungsfunktionen der windows.bi kenne ich mich nicht großartig aus; vor allem bleibt das Problem, woran die richtige ANSI-Codepage erkannt werden soll bzw. ob die Funktion das überhaupt leisten kann/will. Ich würde auf jeden Fall erst einmal versuchen, als Quellstring und Zielstring verschiedene Variablen zu verwenden, da ich nicht ausschließen kann, dass sich der Lese- und Schreibvorgang sonst gegenseitig in die Quere kommt.
Sas2a usw. müssen auf jeden Fall laut WinAPI Pointer sein (also nicht der String selbst). Bei den FB-internen Strings ist das STRPTR(zeichenkette) (nicht *zeichenkette !) Allerdings muss dann der Zielstring vorher schon in ausreichender Länge definiert sein ... am besten gar kein STRING verwenden, sondern ZSTRING PTR.

Wenn du es per Hand machen willst - abgesehen davon, dass man natürlich versuchen kann, die Codierung über das erzeugende Programm herauszufinden:
Mal ganz grundsätzlich könntest du einen eingelesenen String in seine einzelnen Zeichennummern zerlegen, um herauszufinden, welcher Buchstabe wie codiert wurde. ASCII-Zeichen sind einheitlich, interessant sind daher nur die Nummern > 127.

[nemored]

[kilix]

Die zeichencodierung ist offenbar ein schwieriges Problem vorallem auch weil das auf jedem Computer anders sein kann wenn eine andere Codierung eingestellt ist.
Zu Beginn des Threads habe ich eine Funktion hereinkopiert die offenbar ASCII-Codes umwandelt. Ich kann nur nicht erkennen wie diese Zahlenkolonnen zu deuten sind.
Im Augenblick bin ich da ziemlich ratlos.

Edit: ja, BBCode war deaktiviert
_________________
Grüße
kilix

[nemored]

Die gute Nachricht ist: FreeBASIC verwendet in der Konsole und im Grafikfenster zwar zwei verschiedene Codierungen, aber unabhängig vom Betriebssystem immer dieselben zwei(*). Die Codierung der eingelesenen Datei hängt davon ab, mit welchem Programm die Datei erstellt wurde; auch das ist dann in der Regel beim gleichen Programm immer gleich (wenn nicht der Benutzer die Möglichkeit nutzt, etwas anderes einzustellen).

Meine handgeschriebene Ersetzungsfunktion sieht so aus - der Eingabestring (in ersetzeUmlaute bei den einzelnen Aufrufen jeweils die linke CHR-Zeichenkette) ist dabei in UTF-8 und muss an die bei dir verwendete Formatierung angepasst werden. Der rechte CHR-Ausdruck ist dann das in FreeBASIC benötigte Zeichen im Grafikfenster.

[kilix]

Super danke! Erkenne einige Codes wieder die ich mir schon aus der Konsole und einer ASCII-Tabelle herausgesucht habe!
_________________
Grüße
kilix

[grindstone]

[kilix]

ich verstehe es nicht. meine aktive DOS Codepage ist 850
ich habe dieses programm geschrieben:

[grindstone]

[kilix]

Super, danke! Ja das hat funktioniert!!!
_________________
Grüße
kilix

[nemored]

Ich glaube auch nicht, dass das Problem in der Codepage der Ausgabe liegt, sondern in der Codepage der Eingabedatei.


edit: OK, hat sich wohl erledigt - um so besser. Ignoriert diesen Beitrag.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[kilix]

ja, danke, ich wußte nicht, dass es da Unterschiede gibt!
Aber jetzt ist es klar, ich danke euch!
_________________
Grüße
kilix

[kilix]

ich habe den Code von grindstone, der im Test funktioniert hat:

#Include Once "windows.bi" usw.

in ein Programm eingebaut, das Daten die zuvor aus einer CSV-Datei in eine Random-Datei übertragen wurden in der Konsole listet. Das hat wider Erwartung nicht funktioniert.

Dann habe ich auf die Funktion

ersetzeZeichenkette (von nemored, siehe frühere Antwort weiter oben)

geändert und das hat jetzt funktioniert.

Der Unterschied dieser Liste zu dem vorgenannten Test ist,
-dass im Test ein im Code gespeicherter Text und
- ein eingebener Text
beide mit Umlauten richtig dargestellt wurde.
Im Listprogramm wurde der Text aus einer Datei eingelesen. Scheinbar gibt es da auch noch Unterschiede aber letzlich hat es mit dem Code von nemored funktioniert. D.h. man muss, je nachdem woher der Text stammt andere Methoden für die Ersetzung von Umlauten anwenden.
_________________
Grüße
kilix

[kilix]

Das funktioniert richtig gut für diesen Fall! Ich habe noch 21 Ersetzungen ergänzt weil in den Spitznamen die verücktesten Sonderzeichen und alle möglichen Accents verwendet werden. Das hat für alle bis auf 2 Fälle gepasst. In diesen Fällen ist vor dem Sonderzeichen eine Leerstelle. Ich habe es mit chr(000) und chr(032) probiert aber es muss sich um ein anderes nicht druckbares Zeichen handeln. Aber das Sonderzeichen konnte ich (wie es sein sollte) o mit Accent grave umwandeln. Der einzige Schönheitsfehler ist die Leerstelle vor dem o die eigentlich nicht hingehört aber damit kann ich in diesem Fall leben.
So sieht die SUB jetzt aus:

[HorstD]

[kilix]

Hallo!
habe weiter an meinen Programmen gearbeitet, verwende nur jetzt im Sommer weniger Zeit dafür.
Nun habe ich wieder ein Problem mit Umlauten:
1) habe ausgewählte Daten von einer Binary-Datei in einen Array gespeichert
2) der Array ARR(x) enthält in allen Sätzen einen String (Stringaddition der ausgewählten Felder)
3) diese Felder werden mit Left, Mid, Right extrahiert und in der Console gelistet. Dabei werden Umlaute falsch dargestellt.
4) ich habe nun versucht diese Umlaute zu übersetzen. Dazu habe ich der Reihe nach die in diesem Thread gelisteten Möglichkeiten versucht.
Ergebnis: jede Funktion zeigt ein anderes falsches Ergebnis. Ich versuchte auch sowohl beim in die Tabelle speichern als auch beim lesen der Tabelle umzuwandeln, aber das funktioniert auch nicht. Dazu habe ich beim Speichern in die Tabelle die Funktion "ersetzeUmlaute" verwendet. Das funktioniert immer wenn ich Daten aus einer Datei einlese. Für das Auslesen aus der Tabelle habe ich "CharToOem" verwendet ( wie für Texte die ich im Programm verwende). Leider alles ohne Erfolg!
Auch die in diesem Thread von mir ganz oben verwendete Funktion "uANSI2ASCII" hat nichts gebracht.
Gibt es da noch mehr Möglichkeiten?

EDIT: Problem gelöst, war Fehler im Code!
_________________
Grüße
kilix

[hhr]

Manchmal ist Wstr nützlich:

[kilix]

Danke!
Mein Problem ist zwar gelöst aber diese Lösung sieht sehr interessant aus - habe sie in meine Sammlung, auf die ich immer wieder zurückkomme, gespeichert.
Möglicherweise habe ich schon eine Verwendung dafpr !?
_________________
Grüße
kilix