Hello, Guest the thread was called489 times and contains 34 replays

last post from Retrofan at the

Encoding für einen C64-Markdown-Editor im Bitmap-Mode [aus: Neues OS/GUI]

  • Bei Bitmap ist man frei, [,,,] Und man hat alle 256 Character im Zeichensatz zur Verfügung. Nicht nur 100 + ein paar, wie im Charmode.

    ISO8859 hat lediglich 192 (IIRC) druckbare Zeichen. Wenn man wegen Reverse-Modus nur den halben C64-Zeichensatz nutzen will, definiert man rund 80-100 Zeichen fix wie in der ISO-Norm und eine Handvoll für GUI-Elemente falls nötig. Die restlichen X Zeichen werden dann on-the-fly während des Ladevorgangs belegt, wenn ein Text auch exotischere Zeichen aus dem ISO-Vorrat enthält als die 100, die wir sowieso unterstützen.


    Auf die Weise kann ich aus den 192 ISO8859-Zeichen bis zu 128 auf dem C64 darstellen. Das sollte reichen, wenn es nicht gerade um ASCII-Art geht.

    Wobei 40 Zeichen wirklich sehr wenig sind, vor allem bei den langen deutschen Wörtern (und vielleicht fehlender Worttrennung aufgrund fehlendem SHY-Zeichens).

    Keine Ahnung, das müsste man ausprobieren. Irgendwelche Einschränkungen wirst du immer haben - wenig Zeichen auf dem Schirm oder verminderte Lesbarkeit und Geschwindigkeit, die Tastatur ist schlecht, wenig Navigationstasten usw. Ein Buch würde ich auf dem C64 deswegen sowieso nicht schreiben wollen.

  • Auf die Weise kann ich aus den 192 ISO8859-Zeichen bis zu 128 auf dem C64 darstellen.

    Zum einen werden (neben den GUI-Zeichen) knapp 100 freie Chars nicht für Latin-9 (westeuropäisch) reichen (gerade mal die Hälfte), zum anderen besteht einfach ein Kompatibilitätsproblem, wenn nicht alle Zeichen belegt sind, wie im Standard vorgegeben. PC-Texteditoren kennen nun mal nicht "ISO-Latin-kripple", sondern erwarten eine vollständige Belegung.


    Übrigens kann man in den nicht druckbaren Zeichen der ISO-Belegung ganz wunderbar die Breitentabellen für die proportionalen Glyphen ablegen.


    Ein Buch würde ich auf dem C64 deswegen sowieso nicht schreiben wollen.

    Das wird niemand wollen und das ist auch nicht das Ziel. Das Ziel ist es, gerade bei kleinen Tasks (z.B. 1 Seite Markdown-Text) keinen unnötigen Ärger zu verursachen, denn gerade kleine Nickeligkeiten verhindert letztendlich die Nutzung, weil der Spaß kaputtgemacht wird.


    Perfekt wäre z.B. sowas wie Airdrop/Continuity, wo ich auf dem Handy einen Text oder eine Adresse oder ein Bild "kopiere" und auf einem anderen Gerät an der aktuellen Cursor-Stelle einfügen kann – einfach weil es in der Nähe steht.

  • Zum einen werden (neben den GUI-Zeichen) knapp 100 freie Chars nicht für Latin-9 (westeuropäisch) reichen (gerade mal die Hälfte)

    Wie viel Erfahrung mit ISO-8859 hast du denn? Sieh dir doch die zusätzlichen 96 Zeichen mal an, und überlege wie viel davon du gleichzeitig benötigst? Die 96 ASCII-Zeichen habe ich abgedeckt, von 96-Zeichen aus der ISO-Erweiterung kann ich ein (beliebiges) Drittel geichzeitig anzeigen.

    zum anderen besteht einfach ein Kompatibilitätsproblem, wenn nicht alle Zeichen belegt sind, wie im Standard vorgegeben. PC-Texteditoren kennen nun mal nicht "ISO-Latin-kripple", sondern erwarten eine vollständige Belegung.

    Das hast du falsch verstanden. Der Texteditor lädt einen ISO-8859-Text, in dem eine hochgestellte Zwei (Code 178) vorkommt, die in unseren bspw. 106 regulären Zeichen (ASCII plus Umlaute, Paragraph, Euro...) nicht vorkommt. Das merkt er bei der Text-Analyse nach dem Laden, weswegen er...

    1. ...festlegt, dass das erste "Wechselzeichen" in seinem Zeichensatz ab jetzt für Code 176 eingesetzt wird
    2. ...das Wechselzeichen so umdefiniert, dass es wie eine hochgestellte Zwei aussieht
    3. ...im gesamten Text den Code 178 durch den Code unseres ersten Wechselzeichens ersetzt.

    Das kann bzw. muss er bis zu 22 Mal machen, für alle Zeichen die nicht in seinem Standard-Zeichenvorrat enthalten sind. Vor dem Speichern macht er das wieder rückgängig, in dem er statt der Wechselzeichen wieder die ursprünglichen Codes in den Text schreibt und dann speichert.


    Kein Datenverlust, für den Nutzer komplett transparent. Und den Text, der mehr als 128 Zeichen aus ISO-8859 gleichzeitig nutzt, will ich erst mal sehen,

  • Wie viel Erfahrung mit ISO-8859 hast du denn?

    Ich habe schon einige Fonts mit ISO-8859-15 (Latin 9) Belegung gestaltet und gebaut. Was meinst du mit "Erfahrung"?


    Das merkt er bei der Text-Analyse nach dem Laden, weswegen er...
    ...festlegt, dass das erste "Wechselzeichen" in seinem Zeichensatz ab jetzt für Code 176 eingesetzt wird
    ...das Wechselzeichen so umdefiniert, dass es wie eine hochgestellte Zwei aussieht
    ...im gesamten Text den Code 178 durch den Code unseres ersten Wechselzeichens ersetzt.

    Das kann bzw. muss er bis zu 22 Mal machen, für alle Zeichen die nicht in seinem Standard-Zeichenvorrat enthalten sind.

    Ah ja. Und der Datei-Browser macht das dann auch für jeden Dateinamen, weil Sonderzeichen ja auch darin vorkommen können? Und das alles, weil du nicht mit standardisierten Encodings arbeiten kannst/willst? Warum einfach, wenn es auch kompliziert geht.


    Wie gesagt, das sind alles Probleme, die du hast, wenn du im Char-Mode verbleiben willst – und das ist nicht Thema dieses Threads. Hier reden wir über Bitmap-Darstellung und da können wir locker mit standardisierter ISO-Belegung arbeiten – kein Filtern oder Konvertieren nötig.


    [Posting-Split]

  • Ich habe schon einige Fonts mit ISO-8859-15 (Latin 9) Belegung gestaltet und gebaut. Was meinst du mit "Erfahrung"?

    Naja, mich wundert halt die Fixierung auf die vielen Zeichen, die man angeblich gleichzeitig darstellen können muss. 90% der zusätzlichen Zeichen in ISO-8859 sind nationale Sonderzeichen, von denen jeder Nutzer immer nur einen Bruchteil benötigt.

    Ah ja. Und der Datei-Browser macht das dann auch für jeden Dateinamen, weil Sonderzeichen ja auch darin vorkommen können? Und das alles, weil du nicht mit standardisierten Encodings arbeiten kannst/willst? Warum einfach, wenn es auch kompliziert geht.

    Ich weiß nicht, ob ich auf C64-Laufwerken mit Filenamen jenseits von ASCII/PETSCII arbeiten würde, da sind mir zu viele Fallstricke drin - bspw. Osteuropäer, die ein anderes ISO-Encoding nutzen. Oder FAT32-basierte SD/CF/etc.-Lösungen, die von ISO-Encoding keine Ahnung haben.


    Ganz abgesehen davon wäre eine wesentliche Aufgabe eines neuen Systems doch Datei-Verwaltung im weitesten Sinn (Starten, Kopieren, Umbenennen, Dir-Manipulation usw.), oder nicht? Da erst mal massive Inkompatibilität einzuführen indem ich für Dateinamen ein anderes Encoding benutze, halte ich für kontraproduktiv.

    Hier reden wir über Bitmap-Darstellung und da können wir locker mit standardisierter ISO-Belegung arbeiten – kein Filtern oder Konvertieren nötig.

    Windows hat noch nie ISO-8859 benutzt, und unter Linux (und vermutlich auch Mac OS) ist das Default-Encoding schon lange UTF-8. Wenn du nicht ausschließlich mit Amiga-Nutzern Textdateien teilen willst, wirst du um etwas Formaterkennung und Konvertierung so oder so nicht herumkommen.

  • Windows hat noch nie ISO-8859 benutzt

    Zum einen ist Windows Codepage 1252 sehr nah dran, zum anderen können auf meinem Rechner die Editoren die meisten bekannten Encodings lesen und speichern. Unicode basiert übrigens auf ISO-8859 und ist damit kompatibel. Wenn der C64 ISO-8859 verwenden würde, gäbe es sehr wenige Probleme bei der Zusammenarbeit mit aktuellen Systemen. Wenn man hingegen irgend etwas selber bastelt, wäre das Risiko deutlich höher und der ganze Kram wäre (wie schon von dir beschrieben) aufwändiger. Und wie gesagt – hier ist das keine Thema – bei Bitmap-Darstellung gibt es diesbezüglich kein Problem. Wenn du die Konvertier-Problematik also weiter besprechen willst, wäre dafür einer der Text-UI-Threads der richtige Ort – denn nur da gibt es das Problem.


    [Posting-Split]

  • Zum einen ist Windows Codepage 1252 sehr nah dran, zum anderen können auf meinem Rechner die Editoren die meisten bekannten Encodings lesen und speichern. Unicode basiert übrigens auf ISO-8859 und ist damit kompatibel.

    Unicode ist nicht mit ISO sondern mit ASCII kompatibel, alles außerhalb der ersten 128 Zeichen (also bspw. deutsche Umlaute) wird mit zwei oder mehr Bytes kodiert.


    1252 ist zwar sehr nah an ISO - aber der Euro ist eben anders kodiert. Und Gedankenstrich, Auslassungspunkte oder Filled Bullets sind ziemlich gängig bei Texten von Windows-Nutzern, genau wie die diversen zusätzlichen Anführungszeichen.

    Wenn du die Konvertier-Problematik also weiter besprechen willst, wäre dafür einer der Text-UI-Threads der richtige Ort – denn nur da gibt es das Problem.

    Angesprochen hast du diese Thematik, mehrfach. Ich weise lediglich auf Probleme hin, die es natürlich auch bei Bitmap-Darstellung gibt. Aber wenn dir das zu viel Realität ist, können wir ja wieder den Chat-Proxy diskutieren, der Multitasking simuliert in dem er meine Chat-Sitzung speichert und für mich in Abwesenheit protokolliert ;)

    github.com/mist64/final_cartridge allerdings kann es sein, dass sich der Copyright-Vermerk (Public Domain) auf den disassemblierten Quelltext bezieht, nicht auf den Original-Code.

    Danke. Allerdings lese ich auch so, dass das Original nicht frei ist: er erwähnt ja nicht dass er die Erlaubnis hätte. Außerdem macht Michael Steil mehrere solche Projekte, und GEOS 2.0 ist ganz sicher nicht freie Software.

  • Unicode ist nicht mit ISO sondern mit ASCII kompatibel

    AUCH (weil ASCII auch Teil von ISO ist). Der 2. Unicode Codeblock ist meines Erachtens ISO8859-kompatibel (Latin 1), der 1. enthält natürlich die ASCII-Zeichen.


    1252 ist zwar sehr nah an ISO - aber der Euro ist eben anders kodiert

    Wie gesagt, das ist egal, da man bei Text-Editoren das Encoding einstellen kann, zumindest bei meinen. Das Encoding des "Partner"-Systems ist relativ uninteressant, damit wird der C64 höchstens bei Dateinamen konfrontiert – und da willst du ja anscheinend ohnehin nur ASCII erlauben.


    Und wenn sich ein Programmierer findet und der auf dem C64 lieber CP 1252 statt ISO 8859-15 verwenden will – dann wäre mir das auch recht – und dank der Möglichkeit, die volle 8-Bit-Range verwenden zu können, wäre auch das bei Bitmap-Darstellung kein Problem. Ganz ohne Tricks und Schieberei.


    Angesprochen hast du diese Thematik, mehrfach.

    Jein – ich habe gesagt, dass man bei Bitmap-Darstellung Text zu 100% ISO-8859-kompatibel kodieren kann, weil man auf invertierte Zeichen verzichten kann. Und bei einem Char-Mode-UI geht das eben nicht. Punkt. Das ist nach wie vor Fakt und nicht diskutabel.


    Und da fängst du an, von irgendwelchem Konvertieren beim Einlesen zu erzählen – da man solche Tricks aber nunmal nur beim Char-Mode benötigt, um mit dem geringen Zeichenvorrat irgendwie hinzukommen, ist es hier OT. Es interessiert bei Bitmap schlicht nicht. Die Möglichkeit der vollständigen ISO-Unterstützung ist nach wie vor ein Vorteil bei der Bitmap-Darstellung, ob du das nun einsiehst oder nicht.


    Lass uns das Thema hier beenden. Die Sachlage ist klar, alles weitere ist ein Char-Mode-Thema, dass du gerne in einem der Text-UI-Threads besprechen kannst.


    können wir ja wieder den Chat-Proxy diskutieren

    Ja, das wäre immer noch sinnvoller. Wobei das eine nur App wäre, die nicht wirklich etwas mit dem OS oder dem GUI zu tun hat. Gerne können wir uns auch über den Online Schach Client, das SID-Radio oder das Taschenrechner-Widget unterhalten – das sind alles Ideen, deren konkrete Umsetzung noch in den Sternen steht. Wenn da ein logischer Fehler in der Beispiel-Anekdote stecken sollte – geschenkt, unwichtig – weil es im Kern um was ganz anderes ging.

  • Der 2. Unicode Codeblock ist meines Erachtens ISO8859-kompatibel (Latin 1), der 1. enthält natürlich die ASCII-Zeichen.

    UTF-8, also das Unicode-Encoding was ein Texteditor verarbeitet, ist nicht ISO kompatibel. Vereinfacht ausgedrückt funktioniert UTF-8 so: Ist das höchste Bit in einem Byte nicht gesetzt, ist es ASCII - das hat ja nur 7 Bit. Ist dieses Bit gesetzt ist das das Signal für die verarbeitende Software, dass jetzt ein Unicode-Zeichen kommt. Aufgrund der Menge an Unicode Zeichen werden dann mindestens zwei - bis maximal vier, glaube ich - Bytes genutzt, um festzulegen um welches Unicode-Zeichen es sich handelt.

    Wie gesagt, das ist egal, da man bei Text-Editoren das Encoding einstellen kann, zumindest bei meinen.

    Das Encoding des "Partner"-Systems ist relativ uninteressant, damit wird der C64 höchstens bei Dateinamen konfrontiert

    Das Encoding des Fremdsystems ist das Encoding, was Texteditoren im Normalfall benutzen. Ich kann das bei meinem Editor auch ändern, das ist aber bei simplen Texteditoren eher die Ausnahme als die Regel.


    Ich verstehe nicht, wonach du entscheidest, welche modernen Technologien dein Wunsch-OS beherrschen soll und in welchen Fällen die Daten auf einem Fremd-System aufbereitet werden müssen, bevor sie der C64 zu Gesicht bekommt. Bisher war doch die Philosophie, möglichst kompatibel mit der modernen Welt zu sein - notfalls, in dem man einen Großrechner unter dem Schreibtisch versteckt und den C64 nur noch als graphisches Terminal benutzt.


    Wenn ich also für WWW, Chat und das von dir angesprochene "Netzwerklaufwerk" einen Proxy benutze, damit ich ohne irgendwelche Verrenkungen mit meinem Windows/Android/etc.-Kosmos kompatibel bleibe, wieso diesen Anspruch und den dazugehörigen Ansatz bei Textdateien gleich wieder aufgeben? Wenn ich jetzt drüber nachdenke, hätte ich eigentlich eine Antwort der Sorte "Encoding ist egal, da solche Texte ja vom Netzlaufwerk geladen werden, und der Netzlaufwrks-Proxy das automatisch nach ISO-8859 konvertiert" o.ä. erwartet.

    Jein – ich habe gesagt, dass man bei Bitmap-Darstellung Text zu 100% ISO-8859-kompatibel kodieren kann, weil man auf invertierte Zeichen verzichten kann. Und bei einem Char-Mode-UI geht das eben nicht. Punkt. Das ist nach wie vor Fakt und nicht diskutabel.

    Du hattest behauptet, ISO-8859 hätte 256 Zeichen und nahegelegt, man sei verloren wenn man die nicht alle gleichzeitig darstellen kann. Beides ist falsch, das hatte ich richtig gestellt.

  • Aufgrund der Menge an Unicode Zeichen werden dann mindestens zwei - bis maximal vier, glaube ich - Bytes genutzt, um festzulegen um welches Unicode-Zeichen es sich handelt.

    Ich weiß, wie Unicode grundsätzlich funktioniert. Ich meinte mit "basiert" bzgl. ISO/Unicode nicht "code-kompatibel" sondern "historisch daraus entstanden". Und so war es mir mal erzählt worden.


    Edit: Aber um nochmal auf die konkrete Belegung zurück zu kommen: Die Zeichen-Belegungen 80 bis FF (also bis zum Ende von 8 Bit) sind nach kurzem Überfliegen meinerseits bei Unicode und ISO 8859-1 absolut identisch. Davor, weil Untermenge ASCII, ohnehin. Gehst du von einer anderen Tabelle als dieser hier aus? Zum einfachen Vergleich hier ISO-Latin 1.


    Ich verstehe nicht, wonach du entscheidest, welche modernen Technologien dein Wunsch-OS beherrschen soll und in welchen Fällen die Daten auf einem Fremd-System aufbereitet werden müssen, bevor sie der C64 zu Gesicht bekommt. Bisher war doch die Philosophie, möglichst kompatibel mit der modernen Welt zu sein - notfalls, in dem man einen Großrechner unter dem Schreibtisch versteckt und den C64 nur noch als graphisches Terminal benutzt.

    Hier ist wieder eine Stelle, wo du mich nicht richtig verstehen WILLST – was man an der Polemik im letzten Abschnitt erkennt. Erst einmal entscheide ich gar nichts, ich mache Vorschläge. Und die basieren u.a. darauf, dass eine Zusammenarbeit des C64 mit dem PC nicht unnötig verkompliziert wird (meines Erachtens eines der GEOS-Probleme), um die Verwendungs-Wahrscheinlichkeit zu erhöhen (übrigens nach wie vor eines der Kernziele).


    Eine (unter diversen) Lösung dafür ist, Texte möglichst leicht zwischen C64 und PC austauschen zu können. Und da moderne PCs schon seit einiger Zeit Mehr-Byte-Encodings verwenden, geht das natürlich nicht 1:1. Glücklicherweise werden aber auf PC und Mac in gängigen Text-Editoren immer noch alle möglichen 8-Bit-Encodings unterstützt. Warum also nicht einen aus diesem Repertoire verwenden? Ich hatte mich dann nach Durchsicht der (in macOS und meinen Lieblings-Editoren) vorhandenen Encodings für ISO 8859-15 entschieden. Im Gegensatz zu Microsoft CodePage ist ISO nicht proprietär, sondern ein internationaler Standard. Aber wenn ein Entwickler sich ein anderes 8-Bit-Encoding aussuchen will, ist mir das am Ende egal – wichtig ist die unkomplizierte Kompatibilität. Und die ist hiermit gegeben.


    Zu deinem letzten Satz: Gerade ich habe in diesem Thread immer dafür plädiert, den C64 nur moderat (eigentlich nur mit mehr Speicher, was keine neue Erfindung ist) aufzurüsten, um die Möglichkeiten zu erhöhen. Die Arbeit soll weiterhin vom 6510 mit 1 MHz erledigt werden. Mir zu unterstellen, ich wolle den C64 zum Terminal ("mit Großrechner unterm Tisch") degradieren, finde ich gelinde gesagt, eine Frechheit.



    Du hattest behauptet, ISO-8859 hätte 256 Zeichen

    Jetzt wirst du spitzfindig. ISO-8859 ist 8-Bit-codiert und hat damit 256 "Plätze" – man kann diese auch vollkommen korrekt als Zeichen bezeichnen, selbst wenn nicht alle druckbar sind (sondern mit Steuer-Zeichen belegt). Aber wenn man z.B. (mir ja egal) auf CP 1252 geht, sind davon mehr mit druckbaren Zeichen belegt. Es geht um die 8-Bit-Codierung, die man mit dem C64 nur komplett 1:1 und ohne Tricks unterstützen kann, wenn man auch dort alle 8 Bit für unterschiedliche Zeichen verwendet und nicht nur 7 (weil die Hälfte invers dargestellte, ansonsten identische, Zeichen sind), wie eigentlich immer in C64-Char-Mode-Anwendungen.


    Und um noch einen draufzusetzen: Die Zeichen, die z.B. in ISO 8859 mit nicht-druckbaren Zeichen belegt sind, sind ja quasi frei und können von uns (ohne die Kompatibilität zu gefährden) in Fonts mit besonderen C64-Sachen belegt werden. (Wir haben also keinen Mangel, wie im Char-Mode, sondern im Gegenteil – Überfluss). Ich hatte ja z.B. vorgeschlagen, in die ersten 32 Zeichen einige Schrift-Infos (Menü-Name, Größe, Schriftschnitt ...) und die proportionalen Breiten-Tabellen abzulegen. Und die weiteren 32 freien Zeichen könnte man z.B. mit einigen GUI-Elementen belegen, ähnlich wie es in GEM-Fonts auf dem Atari gemacht wird – nicht weil es zwingend nötig wäre aber man muss den Platz ja nicht verschwenden.


    ---


    Ich verstehe irgendwie nicht so ganz deinen Antrieb hier. Mir ist klar, dass du auf den Char-Mode abfährst, sonst hättest du dir nicht deinen "Text-Menü-Generator" erdacht. Aber was ist hier deine "Mission"? Willst du weiterhin darauf hinaus, dass der Bitmap-Mode ungeeignet wäre für eine C64-Oberfläche? Und zwar weil .... ja weil eigentlich was? (Weil 128 "fast schon" 200 ist? Oder weil feste 40 Zeichen für ALLES ausreichend sind? Und mehr als eine Hintergrundfarbe kein Mensch braucht?). Also, wenn du schon die ganze Zeit ohne Unterlass gegen die Grundrichtung der Thread-Idee redest – was willst du genau erreichen? Ein Umschwenken auf ein weiteres Text-UI, wie es sie "dutzendfach" gibt? Also Butter bei die Fische – was willst du eigentlich?

  • Bei einer internen Diskussion rund um dieses Thema (ja, nicht nur ich befasse mich weiterhin damit) ;) wurde ich noch auf einen weiteren Vorteil bei Schriftdarstellung im Bitmap-Mode hingewiesen. War mir zwar auch klar aber habe nie so explizit ausgesprochen: Man kann theoretisch zwischen beliebig vielen Zeichensätzen umschalten! Wenn einem also ein einziger Font nicht ausreicht (man denke an Dingbats, andere Schriftschnitte (normal, bold, kursiv) oder zwischendurch monospaced für Code-Schnipsel) kann man einfach einen weiteren Zeichensatz auf die gleiche RAM-Position laden (kein erhöhter Speicherbedarf) und daraus Zeichen verwenden. Das schon in die Bitmap geschriebene bleibt davon unbetroffen.


    Das ist nun nichts, was man wahrscheinlich "jeden Tag" brauchen würde – aber es ist doch ein Vorteil, den man bei einem Reader oder Editor nutzen könnte. Gerade auch bei Markdown gibt es ja die Möglichkeit, den "Quellcode" mit Markierungen anzuzeigen oder eben "gerendert", also die Markierungen umgesetzt. Von der Lesbarkeit und Struktur her kann es schon von Vorteil sein, "ausgezeichnete" Textstellen sofort als solche zu erkennen, statt nach Sternchen (z.B. für **bold**) zu suchen.


    Und sowas wäre im Bitmap-Mode ohne weiteres möglich – der Text-Renderer müsste halt nur an den entsprechenden Stellen einen anderen Font (aus dem erweiterten ROM oder RAM) nachladen.

  • Ich weiß, wie Unicode grundsätzlich funktioniert. Ich meinte mit "basiert" bzgl. ISO/Unicode nicht "code-kompatibel" sondern "historisch daraus entstanden". [...] Edit: Aber um nochmal auf die konkrete Belegung zurück zu kommen: Die Zeichen-Belegungen 80 bis FF (also bis zum Ende von 8 Bit) sind nach kurzem Überfliegen meinerseits bei Unicode und ISO 8859-1 absolut identisch.

    In irgendeiner Unicode-Page sind sie identisch, das mag sein (hab's nicht nachgeschaut). Ein Texteditor liest und schreibt aber eben nicht Unicode, sondern UTF-8 - und bei UTF-8 sind alle nicht-ASCII-Zeichen mit zwei oder mehr Bytes kodiert. Ich hatte die entsprechende Erläuterung aus Wikipedia bereits verlinkt.

    Hier ist wieder eine Stelle, wo du mich nicht richtig verstehen WILLST – was man an der Polemik im letzten Abschnitt erkennt. Erst einmal entscheide ich gar nichts, ich mache Vorschläge. Und die basieren u.a. darauf, dass eine Zusammenarbeit des C64 mit dem PC nicht unnötig verkompliziert wird.

    Ich werde versuchen, in Zukunft weniger flapsig zu formulieren - du wirst dann immer gleich so unangenehm bissig.


    Das war eine ernst gemeinte Frage, die du irgendwie nicht richtig verstanden hast. Du hast bisher immer Lösungen favorisiert, bei denen der C64 PC-Inhalte oder -Konzepte unverändert verarbeiten oder nachahmen soll: Proxies für WWW, Chat und Netzlaufwerke, eine GUI die möglichst modern aussieht usw.


    Ausgerechnet beim Texteditor brichst du mit diesem Ansatz aber - obwohl das hier mit vergleichsweise wenig Aufwand realisierbar ist, lehnst du eine Formaterkennung und -konvertierung ab. Das soll der Nutzer auf dem Fremdsystem erledigen und den Text erst im richtigen Encoding speichern, bevor er ihn an den C64 übergibt.


    Ich erkenne da auf den ersten Blick keine Linie, deswegen mich würde interessieren wieso du das mal so und mal so handhaben willst.

  • [Posting-Split]

    In irgendeiner Unicode-Page sind sie identisch, das mag sein (hab's nicht nachgeschaut). Ein Texteditor liest und schreibt aber eben nicht Unicode, sondern UTF-8 - und bei UTF-8 sind alle nicht-ASCII-Zeichen mit zwei oder mehr Bytes kodiert.

    Ich habe ja für dich nachgeschaut und es verlinkt. Bis zum Ende von 8 Bit (FF) ist Unicode mit Latin 1 identisch – genau, wie ich ursprünglich (ohne es zu prüfen) gesagt habe. Und nein, "ein" Editor schreibt und erwartet nicht ausschließlich UTF-8, sondern er kann (zumindest meine) verschiedene Encodings:



    Und auch MS Word erkennt sofort, dass es sich bei einem ISO8859-Text nicht um das übliche UTF-8 handelt und bietet verschiedene Optionen beim Einlesen an:



    Das ist nichts, was irgendwie ungewöhnlich wäre (nur weil du das vielleicht noch nicht brauchtest). Ich arbeite mit Texten unterschiedlicher Herkunft (z.B. Downloads bei Recherchen) und da bekommt man oftmals (vor allem ältere) Texte über ASCII hinaus, die in 8-Bit codiert sind. Das wäre bei einem Text, den ich vom C64 bekomme, also nichts unerwartetes. Und es ist auch nicht kompliziert, das Encoding korrekt einzustellen.


    Du hast bisher immer Lösungen favorisiert, bei denen der C64 PC-Inhalte oder -Konzepte unverändert verarbeiten oder nachahmen soll [...]

    Ausgerechnet beim Texteditor brichst du mit diesem Ansatz aber ...

    Nö. Auch hier favorisiere ich den Weg mit den wahrscheinlich geringsten Stolpersteinen. Dein Weg würde doch bedeutet, dass ich einen Text vom PC auch schon auf ein 8-Bit-Encoding umstellen müsste – oder willst du auf dem C64 wirklich direkt einen UTF-8-Text umwandeln? Und auf dem C64 führst du dann eine weitere Umwandlung durch, um in 7 Bit eine variable Untermenge des 8-Bit-Zeichensatzes darstellen zu können. Da habe ich dich doch richtig verstanden, oder?


    Und mein Weg lässt einfach einen fehlerträchtigen und ausbremsenden Schritt (auf dem C64) weg, weil er bei Bitmap-Darstellung unnötig ist – wir können ja einen kompletten 8-Bit-Zeichensatz (z.B. ISO Latin-9) darstellen und deshalb einen PC-Text direkt öffnen. Deswegen weiß ich immer noch nicht, was dein ganzes Konvertier-Problem in diesem Thread zu suchen hat.


    Aber du hast meine wichtigste Frage nicht beantwortet: Was willst du? So, wie ich dich (auch in anderen Threads) verstanden habe, favorisierst du für ein User-Interface die Char-Mode Darstellung gegenüber der Bitmap-Darstellung. Also was ist hier dein Begehr?

  • Ich habe ja für dich nachgeschaut und es verlinkt. Bis zum Ende von 8 Bit (FF) ist Unicode mit Latin 1 identisch

    Seufz, ich geb's auf. Ich hab dir jetzt drei Mal erklärt, dass Unicode und UTF-8 nicht das selbe sind, inklusive einem Link auf Wikipedia.


    Ich hänge mal zwei Textdateien an, der String "Ächz..." ein mal als ISO-8859, und ein mal als UTF-8. DU wirst feststellen, dass die zweite Datei ein Byte größer ist. In Hex-Darstellung sehen die beiden Dateien so aus:

    Code
    1. [email protected]:~/Temp$ xxd -b uft8.txt
    2. 00000000: 11000011 10000100 01100011 01101000 01111010 00101110 ..chz.
    3. 00000006: 00101110 00101110 00001010 ...
    4. [email protected]:~/Temp$ xxd -b iso8859.txt
    5. 00000000: 11000100 01100011 01101000 01111010 00101110 00101110 .chz..
    6. 00000006: 00101110 00001010 ..


    Nö. Auch hier favorisiere ich den Weg mit den wahrscheinlich geringsten Stolpersteinen. Dein Weg würde doch bedeutet, dass ich einen Text vom PC auch schon auf ein 8-Bit-Encoding umstellen müsste – oder willst du auf dem C64 wirklich direkt einen UTF-8-Text umwandeln?

    Ich halte es für machbar ISO-8859, 1252 und eine ISO-8859 entsprechende Untermenge von UTF-8 auf dem C64 zu erkennen und beim Laden/Speichern automatisch in die/von der lokalen Kodierung zu konvertieren, genau wie auf dem PC. Damit bliebe der Textaustausch in beide Richtungen für den Nutzer komplett transparent, und er muss sich um Codepages keinen Kopf machen - es sei denn, er nutzt Zeichen, die ISO-8859 (und damit der C64) nicht kann.

    Und auf dem C64 führst du dann eine weitere Umwandlung durch, um in 7 Bit eine variable Untermenge des 8-Bit-Zeichensatzes darstellen zu können. Da habe ich dich doch richtig verstanden, oder?

    Unter Umständen, ja. Nutzt der Texteditor einen eigenen Zeichensatz (egal ob im Bitmap- oder Textmodus) nehme ich eine 8-Bit-Kodierung, ansonsten halt 7 Bit. Ist aber von der Frage unabhängig, ob ich beim Laden/Speichern konvertieren soll.

    Deswegen weiß ich immer noch nicht, was dein ganzes Konvertier-Problem in diesem Thread zu suchen hat.

    Das hatte ich bereits erklärt. Unabhängig davon, welche Darstellung dein Texteditor nutzt, wirst du mit ISO-8859 nicht sehr weit kommen, da das nur beim Amiga das Default-Encoding ist. Einfache (sprich: vorinstallierte) Linux-Texteditoren lassen in der Regel keine Auswahl des Encodings zu, meine (limitierten) Erfahrungen mit Windows sagen mir dass es dort auch so ist. Der Nutzer müsste also u.U. einen anderen, mächtigeren Texteditor installieren, um Texte austauschen zu können. Und er muss über Codepages Bescheid wissen und manuell in der richtigen Kodierung speichern bevor ein Text zum C64 geht.


    Diese Probleme lassen sich m.E. vermeiden.

  • Ich hab dir jetzt drei Mal erklärt, dass Unicode und UTF-8 nicht das selbe sind

    Wir sprachen aber ursprünglich über Unicode, bis du dann thematisch abgebogen bist. Da kann ich auch nichts für. Du kannst ja erstmal zugeben, dass ich mit Unicode und Latin-1 recht hatte und du danach ein neues Fass aufgemacht hast. Hier nochmal unser Dialog:

    Unicode basiert übrigens auf ISO-8859 und ist damit kompatibel.

    Unicode ist nicht mit ISO sondern mit ASCII kompatibel, alles außerhalb der ersten 128 Zeichen (also bspw. deutsche Umlaute) wird mit zwei oder mehr Bytes kodiert.

    Und das stimmt NICHT!


    DU wirst feststellen, dass die zweite Datei ein Byte größer ist.

    Das wusste ich vorher. Wie gesagt, ich weiß grundsätzlich, wie Encoding mit einem oder mehreren Bytes funktioniert.


    Ich weiß aber immer noch nicht, warum ich den C64 mit UTF-8 quälen soll. Hier bin ich jetzt mal der Bremser, der meint, dass das die kleine Kiste evtl. überfordern könnte.


    Ich halte es für machbar ISO-8859, 1252 und eine ISO-8859 entsprechende Untermenge von UTF-8 auf dem C64 zu erkennen

    Um das nochmal genauer zu klären: Du meinst, du kannst auf dem C64 automatisch erkennen, welches 8-Bit-Encoding verwendet wird. Wie machst du das? Und du willst UTF-8-Text vom PC einlesen und dann z.B. die Umlaute in 1-Byte-Codierung umwandeln? Richtig?


    OK, wenn du das beides kannst, dann nehme ich den Konverter gerne auch für den Markdown-Editor des neuen C64-OS.


    Ansonsten bringt es nämlich nichts, weil alles andere (zumindest bei Zeichensätzen ohne platzverschwendende invertierte Zeichen) schon ohne Konvertierung out-of-the-box gehen würde.


    Der Nutzer müsste also u.U. einen anderen, mächtigeren Texteditor installieren

    Ja, so mächtige Texteditoren, wie mein kleiner kostenloser, mit dem ich Plaintext bearbeite. Oder den bei macOS mitgelieferten Mini-Editor. Ich gehe daher davon aus, dass auch Windows Notepad mit ISO 8859 umgehen kann. Deine Editoren können echt nicht mit unterschiedlichen Encodings umgehen? Ausgerechnet auf Linux, das ja eher so technisch daherkommt?

  • Das wusste ich vorher. Wie gesagt, ich weiß grundsätzlich, wie Encoding mit einem oder mehreren Bytes funktioniert.

    Du hast behauptet, dein ISO-8859-Texteditor könnte Unicode unverändert laden ("ist damit kompatibel"), nicht ich.

    Um das nochmal genauer zu klären: Du meinst, du kannst auf dem C64 automatisch erkennen, welches 8-Bit-Encoding verwendet wird. Wie machst du das? Und du willst UTF-8-Text vom PCeinlesen und dann z.B. die Umlaute in 1-Byte-Codierung umwandeln? Richtig?

    Ja, richtig. UTF-8 im Sinne von "nur UTF-8-Zeichen, die in unserer lokalen Codepage auch vorkommen". Ist jetzt nur Brainstorming, aber ungefähr so würde das aussehen:

    • nur 7-Bit-Werte: ASCII
    • auch 8-Bit Werte, aber immer paarweise, erster Wert beginnt binär mit "11", der zweite mit "10": UTF-8 -> Konvertierung der 8-Bit-Zeichenpaare, Warnung bei nicht unterstützten Zeichen. Gibt es Ketten mit drei oder vier 8-Bit-Werten, sind das nicht unterstützte Unicode-Zeichen (rate ich mal, müsste man überprüfen)
    • auch 8-Bit Werte, aber nur im Bereich 160-255: ISO-8859-15
    • auch 8-Bit-Werte, inklusive 128-159: CP-1252 -> Konvertierung der Zeichen 128-159, Warnung bei nicht unterstützten Zeichen, die konvertiert werden müssen

    An PETSCII hatte ich bisher noch gar nicht gedacht, das müsste man sich noch überlegen ob/wie man das erkennt. Da müsste man dann natürlich einen separaten Zeichensatz verwenden.

    Ja, so mächtige Texteditoren, wie mein kleiner kostenloser, mit dem ich Plaintext bearbeite. Oder den bei macOS mitgelieferten Mini-Editor. Ich gehe daher davon aus, dass auch Windows Notepad mit ISO 8859 umgehen kann. Deine Editoren können echt nicht mit unterschiedlichen Encodings umgehen? Ausgerechnet auf Linux, das ja eher so technisch daherkommt?

    Mein Editor kann das natürlich, weil ich es (und mehr) brauche. Die Standard-Editoren der diversen Linux-Desktop-Umgebungen können das aber nicht - zumindest nicht die drei oder vier, mit denen ich bisher zu tun hatte. Mein letzter Notepad-Kontakt ist mehr als ein Jahrzehnt her, aber Microsoft hat nie ISO-8859 unterstützt - die sind direkt von CP-1252 auf UTF-8 gewechselt.


    Solche vorinstallierten Editoren sind ja eher dazu gedacht, mal eine Readme-Datei zu lesen oder ein Batch-Skript zu bearbeiten. Es reicht völlig, wenn die das lokale Encoding unterstützen. Das ausgerechnet MacOS mit einem Editor kommt, der das kann, wundert mich. Aber vielleicht ist das noch wegen des Wechsels von Classic zu OS X - ich nehme an, dass Classic auch ISO o.ä. als Encoding benutzt hat.

  • Du hast behauptet, dein ISO-8859-Texteditor könnte Unicode unverändert laden ("ist damit kompatibel")

    Kannst du die Textstelle einmal verlinken, damit ich nicht den ganzen Thread nochmal durchgucken muss? Ich wüsste nicht, warum ich auf dem C64 Unicode lesen können wollte. Davon ab ist ISO 8859-1 und Unicode im 8-Bit-Bereich (also 00 bis FF) deckungsgleich, wie wir ja gemeinsam herausgefunden haben.


    Ist jetzt nur Brainstorming, aber ungefähr so würde das aussehen:

    Gefällt mir grundsätzlich. Wie gesagt, so einen Konverter nähme ich natürlich gerne für den Markdown-Editor, sollte der irgendwann Realität werden – Im OS selbst wird man ihn wohl eher nicht benötigen.


    Die Möglichkeit, Texte unterschiedlicher Encodings in einem Editor lesen und schreiben zu können (würdest du defaultmäßig auch UTF-8 speichern wollen, obwohl das auf dem C64 Platzverschwendung wäre?), sagt natürlich nichts darüber aus, wie das OS selbst seine Zeichen kodiert. Da bin ich natürlich weiterhin bei einem 8-Bit-Standard-Encoding, wie ISO 8859-15 (oder notfalls meinetwegen Windows 1252) – warum sollte man da was Neues erfinden.


    Die Standard-Editoren der diversen Linux-Desktop-Umgebungen können das aber nicht - zumindest nicht die drei oder vier, mit denen ich bisher zu tun hatte.

    Wie gesagt: Ich bin überrascht. In meinem Editor kann ich das (neben dem verwendeten Zeilenumbruch und der Textart) sogar in der Statuszeile am unteren Textrand jederzeit ändern.


    Mein letzter Notepad-Kontakt ist mehr als ein Jahrzehnt her, aber Microsoft hat nie ISO-8859 unterstützt

    Ich habe diesen Screenshot im Netz gefunden:



    Da ist zu erkennen, dass Notepad zumindest unterschiedliche Encodings (Menüpunkt: Encoding) unterstützt (und das Encoding auch am unteren Textrand anzeigt). Was sich in der Aufzählung hinter "more ..." verbirgt, kann ich leider nicht sagen. Aber schon bei den aufgeführten ist ja (zusätzlich zu UTF-8) Unicode dabei und wir wissen jetzt ja, dass im Falle eines ISO 8859-1-Textes damit alles korrekt angezeigt werden würde. Und mit ein wenig Glück verbirgt sich hinter "More ..." sogar noch (wie in den ganz simplen Mac-Editoren) CP1252 oder Latin-9 (ISO 8859-15).

  • [Posting-Split]

    UTF-8

    Ich bitte um Verzeihung, aber ich habe diese ganze Diskussion nicht verstanden.

    1.) Selbstverständlich können die gebräuchlichen Texteditoren unter Windows ISO-8859. Es ist in vielen Fällen sogar voreingestellt. Was Windows-Notepad kann oder auch nicht, ist völlig irrelevant. Gibt es überhaupt jemanden, der dieses Notepad verwendet?:gruebel

    2.) ISO-8859 ist schon seit Jahrzehnten der Standard bei der Textcodierung. Sämtliche Assembler und Compiler oder sonstwelche Entwicklungstools, die ich verwende, benutzen ISO-8859. Damit ist es problemlos möglich, in einem Programmtext folgende Zeilen zu schreiben:

    Code
    1. string: .byte 'äöüÄÖÜß', 0
    2. oder
    3. string_ausgeben("äöüÄÖÜß");

    Assembler und Compiler übernehmen den konstanten Zeichenstring, so wie er da im Texteditor steht, als 8-Bit-Codierung in den erzeugten Programmcode. Folglich muß man beim Crosscompilen oder Crossassemblieren für den C64 auch keine überflüssigen Verrenkungen machen, wenn man einfach einen ISO-8859-Zeichensatz verwendet.

    3.) UTF-8 ist nur die komprimierte Version von UTF-32. Mehr nicht. Und das auch nur in der Annahme, daß der größe Teil des Textes aus ASCII-Zeichen besteht. Die Verwendung von UTF-8 macht nur dann wirklich Sinn, wenn im Text gelegentlich Zeichen vorkommen, die nicht in ISO-8859 enthalten sind. Das ist in Euren Beispielen (Texteditor oder OS für den C64) ohnehin nicht der Fall, oder hat einer von Euch vor, Hangul oder Kanji zu unterstützen?

    4.) Für rein westeuropäische Texte ist ISO-8859 die seit Jahrzehnten einfachste und platzsparendste Codierung, und es gibt überhaupt keinen Grund, davon abzuweichen. Wozu sollte man für deutsche Umlaute zwei Bytes benötigen, wenn es auch mit nur einem geht? Das macht keinen Sinn.

    5.) Ob ein Texteditor irgendwelche Dateifilter anbietet zur Konvertierung, ist für das OS irrelevant. Schön, falls es einen solchen Texteditor geben sollte, aber was hat das mit dem OS und der GUI zu tun? Abgesehen davon muß der Editor die (westeuropäischen) Zeichen ja auch in eine Codierung umwandeln, die möglichst gepackt (mehr Text im Speicher) und einfach zu handhaben ist (ein Byte für jedes Zeichen und nicht 1 oder 2). Und welche Codierung wird solch ein Texteditor intern verwenden? Genau: ISO-8859.

    6.) Beim OS geht es um eine generelle Ausgabe von Text. Das bedeutet, daß als Grundlage eine Routine zur Verfügung gestellt wird, die jeweils ein Zeichen ausgibt. Dies ist mit UTF-8 nicht so einfach zu bewerkstelligen, da ein Zeichen aus mehreren Bytes bestehen kann. Die Zeichenroutine müßte über einen zusätzlichen globalen Status verfügen, der festhält, wieviele Bytes eines Zeichens bisher übertragen worden sind. Nicht gut.

    7.) Außerdem sollte ein OS eine Routine bereitstellen zur Ausgabe eines ganzen Strings. Der Ursprung dieser Strings kann dabei vielfältig sein. Zum Beispiel könnte es sich hierbei um den String einer oft gewünschten Programmiersprache handeln. Wie sind Strings in einer Programmiersprache normalerweise aufgebaut? Strings werden intern als Arrays behandelt mit Elementen gleicher Größe, um schnellen direkten Zugriff zu erhalten. Zwar wäre es auch möglich, Strings in der Programmiersprache als UTF-8 zu gestalten, dadurch würden aber simple Zeichenersetzungsfunktionen oder Stringoperationen wie LEFT$ und RIGHT$ unnötig verkompliziert. Zuletzt schwankt auch die maximale Anzahl der Zeichen in einer Stringvariablen in Abhängigkeit davon, ob 2 Byte-Zeichen vorhanden sind oder nicht. Eine Stringvariable kann so bei ASCII-Zeichen vielleicht 256 Zeichen aufnehmen, bei Verwendung von deutschen Umlauten jedoch im Extremfall nur noch die Hälfte. Kurz gesagt: UTF-8 eignet sich nicht für die Programmierung auf 8 Bit-Systemen. Da man aber in einem OS kaum alle Ausgaberoutinen doppelt schreiben möchte (UTF-8 und ISO-8859), fällt die Entscheidung leicht, von vornherein zu sagen, daß ISO-8859 der Zeichen-Standard ist.

    8.) Angenommen man würde - wie Du vorschlägst - einen Zeichensatz so handhaben, daß Sonderzeichen bei Bedarf gepatcht werden, so ist dies nicht nur mit einem Mehraufwand in der Programmierung verbunden, es braucht auch mehr Platz im Speicher, denn natürlich müssen die Zeichen, die gepatcht werden, ebenfalls in ihrer Originalversion irgendwo abgelegt sein, d. h. der vollständige (ISO-8859-)Zeichensatz befindet sich sowie im Speicher. Was gewinnt man also durch das Patchen? Nichts. Es könnte höchstens dann Sinn machen, wenn man ein auf Textmodus basiertes GUI-System schreiben will, doch darum geht es in diesem Thread nicht.

    9.) Man könnte es vielleicht auch so sehen: DIe Verwendung von Textmodus geht von einer anderen "Philosophie" aus als bei Bitmap.

    Textmodus entspricht einem Baukastensystem. Ein Entwickler kann sich aus vorgefertigten Bausteinen etwas zusammenbauen. Die festen Bausteine erleichtern zu Beginn die Entwicklung und sorgen für Geschwindigkeit in der Darstellung, kommen aber an schnell an ihre Grenzen, wenn es darum geht, kompliziertere Strukturen abzubilden.

    Bitmap hingegen entspricht einem leeren Blatt Papier. Man kann es zu allem Möglichen verwenden: eine schräge Linie ziehen, einen Kreis malen, bunte Icons, mehrere Schriftarten gleichzeitig usw. Dieses Mehr an Möglichkeiten erkauft man sich aber mit einem höheren Verbrauch an Speicherplatz und Programmieraufwand.

    Dieser Thread versucht nun auszuloten, wie man das leere Papier am besten bemalen kann, so daß Geschwindigkeit und Benutzerfreundlichkeit akzeptabel sind. Dazu gehört die Verwendung von ISO-8859 als Zeichencodierung, da sie platzsparend ist und alle wesentlichen im Rahmen eines C64-OS zu erwartenden Zeichen abdeckt. Daher verstehe ich - wie gesagt - die Diskussion darum nicht.

  • Ich wüsste nicht, warum ich auf dem C64 Unicode lesen können wollte. Davon ab ist ISO 8859-1 und Unicode im 8-Bit-Bereich (also 00 bis FF) deckungsgleich, wie wir ja gemeinsam herausgefunden haben.

    Nochmal: Es ist völlig unerheblich, ob irgendein Unicode-Block mit ISO-8859 deckungsgleich ist, da Unicode - im Gegensatz zu ISO - nur eine (gigantische) Codepage ist, aber kein Encoding. Das (meist)verwendete Encoding für Unicode ist UTF-8, und das ist nicht kompatibel zu ISO, zumindest nicht jenseits von ASCII.

    Die Möglichkeit, Texte unterschiedlicher Encodings in einem Editor lesen und schreiben zu können (würdest du defaultmäßig auch UTF-8 speichern wollen, obwohl das auf dem C64 Platzverschwendung wäre?), sagt natürlich nichts darüber aus, wie das OS selbst seine Zeichen kodiert. Da bin ich natürlich weiterhin bei einem 8-Bit-Standard-Encoding, wie ISO 8859-15 (oder notfalls meinetwegen Windows 1252) – warum sollte man da was Neues erfinden.

    Hm - was man als Standardformat verwenden würde, ist eine gute Frage. UTF-8 sicher nicht, weil die Texte ja auch lokal angezeigt werden sollen (Online-Hilfe, Programmdokumentation...), dann müsste man die Konvertiererei an diversen Stellen machen. Aber ISO-8859 oder CP-1252, das müsste man mal noch durchdenken Stolperstein ist in dieser Richtung (ISO→1252) glaube ich nur das Euro-Zeichen, also eventuell in dem Fall nachfragen...


    Das OS muss IMHO aus Kompatibilitätsgründen für sämtliche DOS-Aktivitäten auf jeden Fall Großbuchstaben-PETSCII anzeigen können. Dazu kommen einige ASCII-Zeichen, die in PETSCII fehlen (geschweifte Klammern, Tilde, Pipe) sowie die 96 Zusatzzeichen aus ISO-8859. Damit das alles in einen Zeichensatz passt wirst du sowieso tricksen müssen, ich gehe davon aus dass 3,4 oder fünf Zeichen weggestrichen werden müssen. Wie man das am besten auf die jeweiligen Text-Encodings mappt bzw. welches Encoding am wenigsten Klimmzüge (sprich: Zeichenersetzungen bei der String-Ausgabe) benötigt, müsste man mal ausprobieren. Reines ISO-8859 wird sich nicht 1:1 umsetzen lassen.

    Da ist zu erkennen, dass Notepad zumindest unterschiedliche Encodings (Menüpunkt: Encoding) unterstützt (und das Encoding auch am unteren Textrand anzeigt). Was sich in der Aufzählung hinter "more ..." verbirgt, kann ich leider nicht sagen.

    Er macht wohl 'ANSI' (CP-1252) und UTF-8.