 |
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
Berkeley
Anmeldungsdatum: 13.05.2024 Beiträge: 101
|
Verfasst am: 11.08.2024, 19:52 Titel: PRINT unter Windows und Linux |
|
|
- PRINT benutzt unter Windows ja Codepage "OEM 850". Benutzt Linux automatisch UTF-8 ? Kann man die Codierung aus dem Programm raus ändern, ist es ggf. festgenagelt dass man sich auf Windows verlassen kann und was kann man sonst so tun ?
Ist ja irgendwie dumm... FBEdit benutzt auch eine andere Codierung; wenn man Text mit Umlauten ausgeben will... Und unter Linux kommt dann ja auch wieder Zeichenmüll raus. |
|
Nach oben |
|
 |
nemored

Anmeldungsdatum: 22.02.2007 Beiträge: 4710 Wohnort: ~/
|
Verfasst am: 11.08.2024, 23:52 Titel: |
|
|
Zitat: | - PRINT benutzt unter Windows ja Codepage "OEM 850" |
Schon das ist nicht so einfach. Wenn die Quellcode-Datei in Unicode mit BOM gespeichert ist, erscheinen die Zeichen in der Windows-Konsole auch in Unicode (ja, auch die Windows-Konsole hat vor ein paar Jahren gemerkt, dass es seit ein paar Jahrzehnten Unicode gibt).
Ich habe es nicht ausgetestet, aber soweit ich es beurteile, verwendet Windows Unicode, wenn es die Daten explizit als Unicode bekommt. FreeBASIC wiederum interpretiert den Datei-Inhalt nur dann als Unicode, wenn die BOM gesetzt ist. In der Linux-Konsole ist, wenn ich mich recht erinnere, die BOM egal. Ob nun das Unicode-Problem letztendlich aufgrund der Umsetzung durch FreeBASIC oder der nur partiellen Umsetzung durch Windows liegt, weiß ich nicht.
Aber probiere es mal mit BOM. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
 |
nemored

Anmeldungsdatum: 22.02.2007 Beiträge: 4710 Wohnort: ~/
|
Verfasst am: 12.08.2024, 14:52 Titel: |
|
|
Ach ja, ganz vergessen:
mit WCHR kannst du ein einzelnes Unicode-Zeichen ausgeben. Das mit der BOM ist nur wichtig, wenn die Unicode-(Nicht-ASCII-)Zeichen direkt im Quellcode stehen.
https://www.freebasic-portal.de/befehlsreferenz/wchr-143.html
https://www.freebasic.net/wiki/KeyPgWchr
Und dann unterstützt auch nicht jede Schriftart alle Unicode-Zeichen. Wie das mit der eingestellten Konsolenschriftart aussieht, musst du ausprobieren. (Allerdings sehe ich gerade, dass das im englischen Artikel dabeisteht.) _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
 |
Berkeley
Anmeldungsdatum: 13.05.2024 Beiträge: 101
|
Verfasst am: 12.08.2024, 17:42 Titel: |
|
|
BOM bringt schon mal null. Aber Microsoft überrascht mich auch nur seltenst positiv, obwohl ich nicht gerade die höchste Meinung von ihnen habe.
Ausgabe in UTF-16 funzt scheinbar. Microsoft kann schlicht kein UTF-8. Braucht also wieder mal nen Extracode... Zum Glück braucht's PRINT nur für ein paar Konsolenausgaben...
- Und was macht Linux ? |
|
Nach oben |
|
 |
nemored

Anmeldungsdatum: 22.02.2007 Beiträge: 4710 Wohnort: ~/
|
Verfasst am: 12.08.2024, 20:37 Titel: |
|
|
Soweit ich weiß, setzt Unix/Linux schon seit etwa 30 Jahren voll auf UTF-8.
Was intern genau passiert, kann ich nicht sagen, aber das Programm
gespeichert in UTF-8 ohne BOM erzeugt die richtige Ausgabe. Getestet unter Debian, fbc 1.09.0, aber was die Konsolenunterstützung anbelangt, unterscheiden sich die Linux-Distributionen wohl nicht so sehr.
Die Ausgabe funktioniert bei mir aber auch unter Windows, aber nur, wenn der Quelltext mit BOM gespeichert ist. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
 |
Berkeley
Anmeldungsdatum: 13.05.2024 Beiträge: 101
|
Verfasst am: 12.08.2024, 23:12 Titel: |
|
|
Ikes, wenn das stimmt, dann bestimmt der Compiler die richtige Codierung bei PRINT... Ich hab' die BOM an den Anfang meiner Strings gesetzt... Im Quelltext selbst benutz' ich eh praktisch nur ASCII, zumindest bei Releaseversionen.
Nachtrag, nach Tests: FbEdit kommt mit UTF-8 nicht klar, die BOM wird im Quelltext sichtbar ausgegeben. Beim Build kriegt der Compiler ein Problem mit Umlauten - weil FbEdit halt nicht auf UTF-8 kodiert, sondern offensichtlich ISO 8859. Unabhängig davon aber akzeptiert die Windowskonsole trotzdem kein UTF-8, dafür läuft sie auf ISO 8859, nicht mehr Codepage 850...
Grundsätzlich bin ich schon mal froh, wenn man sich drauf verlassen kann dass jede andere für mich relevante Zielplattform (Linux+Mac OS ) UTF-8 verwendet. |
|
Nach oben |
|
 |
nemored

Anmeldungsdatum: 22.02.2007 Beiträge: 4710 Wohnort: ~/
|
Verfasst am: 13.08.2024, 08:57 Titel: |
|
|
Ich verwende Geany und bin damit äußerst zufrieden - ist halt ein Universaleditor und keine IDE spezifisch für FreeBASIC. Aber Codierungsumstellungen sind damit absolut problemlos.
Der Compiler bestimmt nicht das Verhalten von PRINT (naja, eigentlich schon ), sondern die Interpretation des Stringinhalts. Die BOM gibt dem Compiler zu verstehen, dass Strings als Unicode aufzufassen sind, in der durch die BOM festgelegten Codierung.
Ansonsten ist der richtige Datentyp der WSTRING, der von der Windowskonsole dann auch korrekt übernommen werden müsste - natürlich wieder wenn die Nicht-ASCII-Zeichen korrekt im WSTRING gelandet sind. Intern arbeitet FreeBASIC dann mit UTF-16 oder UTF-32, je nach Betriebssystem.
Und ja, durchaus möglich, dass Windows nur UTF-16 kann und kein UTF-8. Unicode ist halt noch sehr neu.  _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
 |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1283 Wohnort: Ruhrpott
|
Verfasst am: 13.08.2024, 22:53 Titel: |
|
|
Hallo!
Zu diesem Thema hatten wir vor einigen Jahren schon einmal einen Thread.
Vielleicht findest du da etwas, was dir weiterhilft.
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
 |
Matthias Gast
|
Verfasst am: 16.07.2025, 09:32 Titel: |
|
|
unter Linux benutzt PRINT normalerweise UTF-8, da das die Standard-Kodierung der meisten modernen Systeme ist. Windows nutzt oft OEM 850 oder andere Codepages, je nach Konsole. In vielen Programmiersprachen kannst du die Ausgabe-Kodierung explizit setzen, z.B. in Python über `encode()` oder in C++ mit entsprechenden Bibliotheken. Wenn du plattformübergreifend arbeiten willst, empfiehlt es sich, intern immer UTF-8 zu benutzen und die Konvertierung erst am Rand durchzuführen. Für Konsolenprogramme kannst du auch auf Libraries zurückgreifen, die Unicode besser unterstützen. |
|
Nach oben |
|
 |
Monika
Anmeldungsdatum: 03.07.2025 Beiträge: 9
|
Verfasst am: 16.10.2025, 17:44 Titel: |
|
|
Hallo! Unter Linux wird normalerweise UTF-8 verwendet, aber ältere Druckbefehle wie `lpr` oder Shell-Programme können auch andere Codierungen erwarten. Es ist also nicht garantiert, dass es ohne Anpassung klappt. Du kannst mit `iconv` Textdateien in die gewünschte Codierung umwandeln (zum Beispiel von UTF-8 nach ISO-8859-1). Für portablen Code empfiehlt sich, die Ausgabecodierung programmatisch festzulegen oder als Option einstellbar zu machen. Umlaute bleiben sonst leider ein Problem zwischen den Systemen. |
|
Nach oben |
|
 |
Berkeley
Anmeldungsdatum: 13.05.2024 Beiträge: 101
|
Verfasst am: 16.10.2025, 17:58 Titel: |
|
|
Ich hab' dafür meine UTF8-Bibliothek: https://www.freebasic-portal.de/downloads/bibliotheken/utf8-library-411.html, da ist auch Umwandlung von ISO/IEC 8859 drin, für die Windows-Konsole muss man "nur" in UTF-16 umwandeln.
Schaut bei mir so aus:
Code: |
SUB CONPRINTTEXT(BYVAL message AS STRING)
' text output to command prompt
DIM AS INTEGER i, j
DIM AS STRING pline
#IF DEFINED(__FB_WIN32__)
DIM AS WSTRING*82 wpline
#ENDIF
' check for linebreak code (13)
' put out line by line with PRINT => platform dependent linebreak code
i=INSTR(message, CHR(13))
IF i THEN
j=1
WHILE i
pline=MID(message, j, i-j)
' strings should be UTF-8 encoded, Windows demands UTF-16 for Unicode output
#IF DEFINED(__FB_WIN32__)
UTF8TOUTF16(pline, wpline, 82)
wpline=MID(wpline, 2) ' remove BOM
PRINT wpline
#ELSE
PRINT pline
#ENDIF
j=i+1
i=INSTR(j, message, CHR(13)) ' next linebreak
WEND
pline=MID(message, j)
#IF DEFINED(__FB_WIN32__)
UTF8TOUTF16(pline, wpline, 82)
wpline=MID(wpline, 2) ' remove BOM
PRINT wpline
#ELSE
PRINT pline
#ENDIF
ELSE
' put out single-line message
#IF DEFINED(__FB_WIN32__)
UTF8TOUTF16(message, wpline, 82)
wpline=MID(wpline, 2) ' remove BOM
PRINT wpline
#ELSE
PRINT message
#ENDIF
ENDIF
END SUB
|
Außerdem den "VT 2000"-Standard, der derzeit allerdings nur in RETROGRA implementiert ist und nur theoretisch auch UTF-16+32-Strings unterstützen würde. https://www.freebasic-portal.de/downloads/bibliotheken/retrogra-406.html - SO sollte allerdings IMO ein BASIC-PRINT-Befehl und Textkonsole/Terminal ausschauen. Eben mit PRINT AT und Textfarben.[/code] |
|
Nach oben |
|
 |
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|