PureBoard

Hi

Ich bin der Joe und neu hier, ich benutze PB schon seit 12 Jahren (und bin wahrscheinlich der letzte Mensch der noch jaPBe benutzt ^^) und das Unicode Zeugs hab ich nie benutzt & gebraucht (ausser unten in meiner Signatur) desshalb hab ich jetzt auch keine Ahnung wann es benutzt wird, wo, und wie es sich auswirkt !

Was ich weis: Mann konnte früher auf Unicode Exe generieren umstellen.

Geschätzte Auswirkungen:

1) Die executable ist dann größer (egal)
2) sollte ich ein File einlesen mit 1000 Zeilen, brauch ich doppelt so viel Ram oder nicht ? (sehr schlimm)
3) Es dauert dann länger die Datei einzulesen (schlimm)
4) Die unicode String Bearbeitung ist langsamer (schlimm)
5) Alter Beispiel Code der irgendwelche API's nutzt muss etwas angepasst werden (z.B Winsock Connection mit Timeout) (geht noch, bisschen Arbeit)
6) Die Verarbeitungsgeschwindigkeit&Reaktionszeit vieler Befehle ist langsamer oder nicht ? Wenn ja ! Auch sehr schlimm

Was ist wenn ich das #PB_Ascii Flag in ReadString benutze ist dann auch alles langsamer und braucht mehr Ram ?
Wird dann noch was umgewandelt von wegen Asci ti Unicode und der Compiler behandelt dann alles trotzdem intern als Unicode ?

Was genau bewirkt das PB jetzt Unicode only ist ? Einfach nur das es Dateien mit eigenartigen Zeichen im Dateinamen lesen & schreiben kann ?

Was war denn früher wenn mann ASCI eingestellt hatte, und z.B eine Txt Datei mit 400.000 Zeilen eingelesen hat, und dort zwischendurch mal eigenartige Zeichen vorgekommen sind ? wurden die dann bei der Verarbeitung einfach als ? abgetan ?
sprich aus blaXblub wurde bla?blub oder wurde aus blaXblub (das X steht für ein Unicode Zeichen) dann einfach blablub ? und in der Ausgabe dann das selbe, also entweder bla?blub oder blablub

Muss ich wenn ich eine TXT Datei einlese die komische Unicode Zeichen hat, dann auf UTF-8 stellen ? selbst wenn ich eine Unicode exe habe ? Was passiert wenn ich eine ASCI exe (mit alter PB Version nehme) dann auf UTF-8 stelle und dann ein File
mit Unicode Zeugs einlese ?

Das ist alles sehr verwirrend !

Es gibt den ASCI & Unicode Flag da wo mann auch das Thread Safe einstellen kann, daß die exe entsprechend generiert.
Dann noch dort wo Codepage (was ist das schon wieder ? das hab ich seit MS-DOS config.sys & autoexec.bat zeiten nicht mehr gesehen und verwendet) vorkommt (1200 Unicode) und dann noch in einzelnen Befehlen ?

1., 2., 3., 4. und 6. : Theorethisch, ja.

Ich bin auch kein Freund von "Hauptsache es ist für den Programmierer bequem. Soll sich der Anwender doch bessere Hardware kaufen.". Aber der Unterschied ist derart gering, dass Du ihn vernachlässigen kannst. Da gibt es meist an anderer Stelle mehr Optimierungspotential. Bei 5. solltest Du die Kehrseite der Medalie nicht vergessen. Es gibt auch Schnittstellen die kein ASCII mögen. Ich würde Dir empfehlen es nur noch da einzusetzen wo es wirklich sein muss.

Windows verwendet übrigens intern auch kein ASCII, sondern UTF-16 Little Endian als Kompromiss zwischen UTF-8 und UTF-32. UTF-8 hat jedoch den Vorteil, dass es rückwärtskompatibel zu ASCII ist. So lange nur entsprechende Zeichen verwendet werden lässt es sich aber in beide Richtungen für Schnittstellen verwenden, die eigentlich nur ASCII verstehen.

Kompiliere schon lange meine Programme in Unicode. Somit hatte ich mit einigen Funktionen mit Sonderzeichen keine Probleme mehr.
Wie Dateinamen und weiter mit der Einstellung ASCII oder OEM Zeichensätze.

Das Program braucht mehr Speicher für Strings. Sollte aber heut zu tage kein Problem sein. Viele Textdateien verwenden heute UTF8.
Diese lassen sich mit intern UNICODE (UCS-2) brauch besser verarbeiten.
Es muss nur noch darauf geachtet werden wie die Dateien geladen oder gespeichert werden. Zum Speichern würde ich UTF8 verwenden, da diese von allen aktuellen Programme ohne Probleme gelesen werden kann.

Die meisten API unterstützen schon seit langen Unicode (API FunctionW(...). Es gibt nur noch selten fälle wo ASCII verwendet wird.
Dazu gibt es aber eine neue Funktion ASCII bereit zu stellen. Ich denke auch nicht das die Geschwindigkeit so viel langsamer geworden ist.

Wie ich es sehe hat es mehr Vorteile als Nachteile Unicode zu verwenden

uweb hat geschrieben:1., 2., 3., 4. und 6. : Theorethisch, ja.
Ich bin auch kein Freund von "Hauptsache es ist für den Programmierer bequem. Soll sich der Anwender doch bessere Hardware kaufen.". Aber der Unterschied ist derart gering, dass Du ihn vernachlässigen kannst. Da gibt es meist an anderer Stelle mehr Optimierungspotential.
Bei 5. solltest Du die Kehrseite der Medalie nicht vergessen. Es gibt auch Schnittstellen die kein ASCII mögen. Ich würde Dir empfehlen es nur noch da einzusetzen wo es wirklich sein muss.
Windows verwendet übrigens intern auch kein ASCII, sondern UTF-16 Little Endian als Kompromiss zwischen UTF-8 und UTF-32.
UTF-8 ist rückwärtskompatibel zu ASCII.

Hallo

Ok aber selbst wenn Windows UTF-8 verwendet (was ist das schon wieder ? Wozu gibt es das ? Warum ist alles nicht einfach txt und gut is ? asci,unicode,utf-8/16 was jetzt ? )

Das Problem ist, daß ich schon mal txt Dateien hab mit 1 Million Zeilen (und immer noch ein 32 Bit OS) und da wirken
sich selbst 10% weniger Tempo und 10% mehr Ram Verbrauch dramatisch aus, vor allem wenn die Strings dann noch gefiltert & sortiert werden.

Ich hab PB vor allem immer verteidigt und vergöttert wegen dem hohen String Verarbeitungs Tempo und weil es nicht so'n Resource Hog ist, der massig Ram frisst, und wo sowas wie eine Garbage Collection nicht nötig ist. (vl sollten die von Mozilla mal ne anständige Sprache wie PB benutzen, dann würden ihre Browser endlich wieder sowas sie Speicherfreigabe können)

Aber mal vom Ram & Tempo abgesehen, die offenen Fragen

Was ist wenn ich das #PB_Ascii Flag in ReadString benutze ist dann auch alles langsamer und braucht mehr Ram ?
Wird dann noch was umgewandelt von wegen Asci ti Unicode und der Compiler behandelt dann alles trotzdem intern als Unicode ?

Was genau bewirkt das PB jetzt Unicode only ist ? Einfach nur das es Dateien mit eigenartigen Zeichen im Dateinamen lesen & schreiben kann ?

Was war denn früher wenn mann ASCI eingestellt hatte, und z.B eine Txt Datei mit 400.000 Zeilen eingelesen hat, und dort zwischendurch mal eigenartige Zeichen vorgekommen sind ? wurden die dann bei der Verarbeitung einfach als ? abgetan ?
sprich aus blaXblub wurde bla?blub oder wurde aus blaXblub (das X steht für ein Unicode Zeichen) dann einfach blablub ? und in der Ausgabe dann das selbe, also entweder bla?blub oder blablub

Muss ich wenn ich eine TXT Datei einlese die komische Unicode Zeichen hat, dann auf UTF-8 stellen ? selbst wenn ich eine Unicode exe habe ? Was passiert wenn ich eine ASCI exe (mit alter PB Version nehme) dann auf UTF-8 stelle und dann ein File
mit Unicode Zeugs einlese ?

Das ist alles sehr verwirrend !

Es gibt den ASCI & Unicode Flag da wo mann auch das Thread Safe einstellen kann, daß die exe entsprechend generiert.
Dann noch dort wo Codepage (was ist das schon wieder ? das hab ich seit MS-DOS config.sys & autoexec.bat zeiten nicht mehr gesehen und verwendet) vorkommt (1200 Unicode) und dann noch in einzelnen Befehlen ?

verwirren mich immer noch.
Ich möchte so wenig mehr ressourcen benutzen & so wenig speed wie möglich verlieren, desshalb muss ich wissen wann und wo
welches Flag gesetzt oder nicht gesetzt wird, wann es Sinn macht. Aber bei Funktionen die Flags haben, dann noch Dateien mit Codierungen ??? (also asci,unicode,utf-8 ?) und bei der executable selbst, wie soll ich da noch durch blicken ?

mk-soft hat geschrieben:Kompiliere schon lange meine Programme in Unicode. Somit hatte ich mit einigen Funktionen mit Sonderzeichen keine Probleme mehr.
Wie Dateinamen und weiter mit der Einstellung ASCII oder OEM Zeichensätze.

Das Program braucht mehr Speicher für Strings. Sollte aber heut zu tage kein Problem sein. Viele Textdateien verwenden heute UTF8.
Diese lassen sich mit intern UNICODE (UCS-2) brauch besser verarbeiten.
Es muss nur noch darauf geachtet werden wie die Dateien geladen oder gespeichert werden. Zum Speichern würde ich UTF8 verwenden, da diese von allen aktuellen Programme ohne Probleme gelesen werden kann.

Die meisten API unterstützen schon seit langen Unicode (API FunctionW(...). Es gibt nur noch selten fälle wo ASCII verwendet wird.
Dazu gibt es aber eine neue Funktion ASCII bereit zu stellen.

Code: Alles auswählen

*pASCII = Ascii("Hello world!")
;TODO
ShowMemoryViewer(*pASCII, 20)
FreeMemory(*pASCII)

Ich denke auch nicht das die Geschwindigkeit so viel langsamer geworden ist.

Wie ich es sehe hat es mehr Vorteile als Nachteile Unicode zu verwenden

Also ich bin noch nie auf Dateinamen die unicode erfordert haben (hab sie dann umbenannt und als Ausgabe
gibt es bei mir sowieso nur Dateien mit azAZ09 und . im Dateinamen) oder Situationen gestossen wo ich es gebraucht hab.

Du sagtest viele Text Dateien verwenden heute UTF-8, was ist die Standard Voreinstellung in PB gewesen bevor
Asci raugeflogen ist ?

In jaPBe steht oben Default(0) unter Codepage ? was wird unter Default(0) verwendet ? Asci ? oder Unicode ? oder womöglich
UTF-8 ?

Heist das, daß wenn ich eine txt Datei rausgebe, die ich mit absolute unveränderten Flags gespeichert habe (also ASCI Compile, keine Flags bei OpenFile,ReadString usw und Codepage Default(0) ) sie dann ein anderer öffnet dann ein Zeichen verändert, und dann speichert, mein Programm mit der Datei nichts mehr anfangen kann ? nur weil so'n Flag geändert wurde ?

ReadFile() und ReadString() verwenden UTF8 wenn Du nichts anderes angibst. Wegen der Rückwärtskompatibilität kannst Du damit ASCII-Dateien direkt lesen. Beim Schreiben macht es nur einen Unterschied wenn Du Zeichen verwendest die es in ASCII nicht gibt.

Hallo GlassJoe,

nun möchte ich auch mal deine Fragen etwas "für dich positiver" beantworten:

1) Die executable ist dann größer (egal)
Das ist richtig, aber ist dir ja wie du selbst sagst egal und spielt wirklich keine Rolle.

2) sollte ich ein File einlesen mit 1000 Zeilen, brauch ich doppelt so viel Ram oder nicht ? (sehr schlimm)
Das stimmt nicht! Wie du eine Datei in den RAM einließt bleibt dir überlassen. Wenn du die Datei (komplett) als ASCII in den RAM lesen willst, dann kannst du dafür ReadData nutzen und hast die Datei "ganz normal" als ASCII im RAM.
(in diesem kannst du dann auch teile der Datei als ASCII lesen und als String weiter verarbeiten)

3) Es dauert dann länger die Datei einzulesen (schlimm)
Nein, mit ReadData gibt es keinerlei Änderung!

4) Die unicode String Bearbeitung ist langsamer (schlimm)
Dafür habe ich keinen Vergleich, aber selbst unter 32Bit wäre die Wortgröße (also die schnellste Art etwas zu bearbeiten) 4 Byte. Unicode und auch ASCII liegen mit 2 Byte bzw. 1 Byte weit daneben und benötigen ohne hin mehr "umrechnen", dann aber vermutlich etwas gleich viel.

5) Alter Beispiel Code der irgendwelche API's nutzt muss etwas angepasst werden (z.B Winsock Connection mit Timeout) (geht noch, bisschen Arbeit)
Das kann ich leider nicht "positiv" reden. Solche Arbeit hat man aber bei jederart von Weiterentwicklung.

6) Die Verarbeitungsgeschwindigkeit&Reaktionszeit vieler Befehle ist langsamer oder nicht ? Wenn ja ! Auch sehr schlimm
Wie schon in 4. diskutiert, sollte es egal sein. Beispiel:
Wenn eine Zeichen verglichen werden soll, dann muss entweder 1 Byte oder 2 Byte verglichen werden. Die Register in einer CPU arbeiten aber mit 4 Bytes (32bit) oder gar 8 Bytes (64bit). Es wird also immer ein Register benötigt und immer ein Takt.
Klar brauchst du bei einer Zeichenkette von 1000 Zeichen faktisch 2000 Bytes in Unicode die verglichen werden müssen, und in ASCII nur 1000 Byte, also wäre Unicode langsammer. Allerdings kannst du den String wie in 2 beschrieben als ASCII im RAM lagern und dort ebenfalls auf Byte-Ebene vergleichen.

Was ist wenn ich das #PB_Ascii Flag in ReadString benutze ist dann auch alles langsamer und braucht mehr Ram ?
Dieses Flag ist für das Dateiformat, nicht das RAM-Format!

In PureBasic gab es früher die Möglichkeit zwischen ASCII und Unicode Exe zu wählen. Dabei war das Format in der EXE oder im RAM gemeint! Unabhängig davon können Textdateien alle möglichen Formate habe (ASCII, UTF8, UTF16 usw.) die immer auch beachtet werden müssen.

uweb hat geschrieben:ReadFile() und ReadString() verwenden UTF8 wenn Du nichts anderes angibst. Wegen der Rückwärtskompatibilität kannst Du damit ASCII-Dateien direkt lesen. Beim Schreiben macht es nur einen Unterschied wenn Du Zeichen verwendest die es in ASCII nicht gibt.

Und wenn ich eine unicode exe hab, ist der Standard bei ReadFile() & ReadString() automatisch #PB_Unicode
statt UTF-8 ?

Ich frag mich grade ob ich alte Ascii kompilierte Tools von mir die massig Strings verarbeiten noch im Lese, Verarbeitungs & Schreib Speed optimieren könnte, indem ich #PB_Ascii erzwinge statt #PB_UTF8. Ascii ist banaler als UTF, je banaler desto schneller........so ist das bei vielen dingen in der Computerwelt

Ich versuche immer das maximale Tempo bei Lese,Schreib & String Operationen zu haben, selbst wenn etwas 2% mehr Leistung bringt ist das schon was tolles für mich

STARGÅTE hat geschrieben:Hallo GlassJoe,

nun möchte ich auch mal deine Fragen etwas "für dich positiver" beantworten:

1) Die executable ist dann größer (egal)
Das ist richtig, aber ist dir ja wie du selbst sagst egal und spielt wirklich keine Rolle.

2) sollte ich ein File einlesen mit 1000 Zeilen, brauch ich doppelt so viel Ram oder nicht ? (sehr schlimm)
Das stimmt nicht! Wie du eine Datei in den RAM einließt bleibt dir überlassen. Wenn du die Datei (komplett) als ASCII in den RAM lesen willst, dann kannst du dafür ReadData nutzen und hast die Datei "ganz normal" als ASCII im RAM.
(in diesem kannst du dann auch teile der Datei als ASCII lesen und als String weiter verarbeiten)

3) Es dauert dann länger die Datei einzulesen (schlimm)
Nein, mit ReadData gibt es keinerlei Änderung!

4) Die unicode String Bearbeitung ist langsamer (schlimm)
Dafür habe ich keinen Vergleich, aber selbst unter 32Bit wäre die Wortgröße (also die schnellste Art etwas zu bearbeiten) 4 Byte. Unicode und auch ASCII liegen mit 2 Byte bzw. 1 Byte weit daneben und benötigen ohne hin mehr "umrechnen", dann aber vermutlich etwas gleich viel.

5) Alter Beispiel Code der irgendwelche API's nutzt muss etwas angepasst werden (z.B Winsock Connection mit Timeout) (geht noch, bisschen Arbeit)
Das kann ich leider nicht "positiv" reden. Solche Arbeit hat man aber bei jederart von Weiterentwicklung.

6) Die Verarbeitungsgeschwindigkeit&Reaktionszeit vieler Befehle ist langsamer oder nicht ? Wenn ja ! Auch sehr schlimm
Wie schon in 4. diskutiert, sollte es egal sein. Beispiel:
Wenn eine Zeichen verglichen werden soll, dann muss entweder 1 Byte oder 2 Byte verglichen werden. Die Register in einer CPU arbeiten aber mit 4 Bytes (32bit) oder gar 8 Bytes (64bit). Es wird also immer ein Register benötigt und immer ein Takt.
Klar brauchst du bei einer Zeichenkette von 1000 Zeichen faktisch 2000 Bytes in Unicode die verglichen werden müssen, und in ASCII nur 1000 Byte, also wäre Unicode langsammer. Allerdings kannst du den String wie in 2 beschrieben als ASCII im RAM lagern und dort ebenfalls auf Byte-Ebene vergleichen.

Was ist wenn ich das #PB_Ascii Flag in ReadString benutze ist dann auch alles langsamer und braucht mehr Ram ?
Dieses Flag ist für das Dateiformat, nicht das RAM-Format!

In PureBasic gab es früher die Möglichkeit zwischen ASCII und Unicode Exe zu wählen. Dabei war das Format in der EXE oder im RAM gemeint! Unabhängig davon können Textdateien alle möglichen Formate habe (ASCII, UTF8, UTF16 usw.) die immer auch beachtet werden müssen.

Hi Stargate Danke für die Ausführliche Antwort.

Zu 2) Aber ist es nicht so das der PB Compiler dann trotzdem intern alles als Unicode verarbeitet ? weil jeder String Verarbeitungs Befehl die Asci Sache gar nicht mehr kennt/kann ? Sagen wir mal ich mache ReadData, dann wandel ich
das zu einem String um, der wird dann doch automatisch zu einem Unicode String umgewandelt oder nicht ? und falls nicht, dann vl bei sowas wie RemoveSring

Zu 3) Das wäre natürlich super, allerdings hab ich ja nicht mehr nur ein Befehl, sondern muss mehr
Dinge tun.

Mal grob beschrieben.

StringByteLength,AllocateMemory,ReadData,PeekS
statt einfach nur den optimierten ReadString Befehl

Zu 4) Ja aber die Masse machts Nur desshalb lege ich so viel Wert auf Speed & Ram Verbrauch. Hab oft die Erfahrung gemacht, daß Tools unter 32Bit Windows, die Strings Filtern nur zwischen 500&600MB Ram Verbrauch packen selbst wenn mann 4GB hat und massig frei (ja ich weis 32Bit Win kann nur 3GB davon nutzen )

Zu 5) Ist kein Problem für mich, ich freu mich immer wenn PB große Schritte macht. PB wird von so vielem schon seit jahren ausgebremst....durch Linux und Mac schätz ich mal.
Nur so kann ich es mir erklären das sowas nützliches wie ColumnHeader Events & welcher Eintrag im mehrspaltigen ListIconGadget angeklickt wurde (was bringt mir die Zeile alleine ? Zeile+Entry ist viel nützlicher) nicht schon seit jahren ab Werk in PB sind, und warum es zig Jahre gebraucht hat bis die Network Lib von PB endlich ein Timeout beherscht hat.
Bei Mac herscht Ordnung (oder ein Standard), aber die Unix/BSD, Linux Welt ist ein einziges Chaos an zig X11 Fenster Managern (fluxbox,openbox,icewm usw usw) Desktop Umgebungen (lxde,xfce,kde,gnome) und Programmbibliotheken (GTK,QT,tK,wXWidgets etc etc) und der eine kann das, und es muss so geschrieben werden, der andere das.

Zu 6) Auf Byte Ebene vergleichen ? hör auf mir Angst zu machen ich weiss gerade noch das ein Byte aus 8 Bit besteht (wenn ich mich richtig erinnere) bin ein totaler noob wenn es um register, bits & bytes geht

In PureBasic gab es früher die Möglichkeit zwischen ASCII und Unicode Exe zu wählen. Dabei war das Format in der EXE oder im RAM gemeint! Unabhängig davon können Textdateien alle möglichen Formate habe (ASCII, UTF8, UTF16 usw.) die immer auch beachtet werden müssen.

Wie meinst du das zwischen exe >oder< ram ?

Gehe ich in folgender Annahme richtig ?

Exe = Ascii, String = Unicode
Keine Dateinamen mir komischen Zeichen verarbeitbar
Kein #PB_Unicode für Befehle wie PeekS, oder ReadString möglich, selbst wenn String keine Unicode Zeichen enthalten sollte.
Sollte der String Unicode Zeichen enthalten, wird dabei der String verfälscht.

Exe = Unicode, String = Ascii
Jeder Dateiname der nicht von Windows selbst eingeschränkt wird, kann verarbeitet werden
#PB_Unicode,#PB_Ascii, #PB_UTF8 gehen bei PeekS,ReadString etc
String wird nicht verfälscht, da Unicode abwärts Kompatibel ist ?

Und wenn ich eine unicode exe hab, ist der Standard bei ReadFile() & ReadString() automatisch #PB_Unicode
statt UTF-8 ?

Weiter habe ich jetzt nicht mehr gelesen, da wir uns im Kreis drehen. Deine Fragen wurden zumindest bis dahin von uns beantwortet und an der Stelle steige ich aus.
Wenn Du es nicht glaubst dann probiere es doch aus. Es gibt nichts gutes außer man tut es.
Du siehst Probleme wo es keine gibt.
Ich empfehle Dir dringend die Hilfe zu lesen, bei Allem was Du nicht verstehst zuerst erst einmal Google zu nutzen und wenn Du dann noch Fragen hast und stellst die Anworten zu berücksichtigen.
Die Basis für Informationsverarbeitung sind Informationen. Ohne neue Eingabe wird sich auch am Ergebnis nichts ändern. Das gilt nicht nur für die computergestützte Informationsverarbeitung.

PS
UTF-8 ist die am weitesten verbreitete Kodierung für Unicode-Zeichen! Diese Information ist sehr leicht zugänglich.
Vorsorglich:

ReadFile() und ReadString() verwenden UTF8 wenn Du nichts anderes angibst. Wegen der Rückwärtskompatibilität kannst Du damit ASCII-Dateien direkt lesen. Beim Schreiben macht es nur einen Unterschied wenn Du Zeichen verwendest die es in ASCII nicht gibt.

Das bezieht sich auf ASCII - nicht auf ANSI.

Ich möchte nicht erneut alle Frage beantworten, aber noch etwas zu Codepages sagen. Die stammen eigentlich aus der Zeit, zu der jedes Zeichen nur 8 Bit hatte, also vergleichbar zu ASCII.
In 8 Bit kann man nur 256 verschiedene Zeichen stecken. Ein Teil davon sind Steuerzeichen, ein Teil repräsentiert das lateinische Alphabet, ein Teil Umlaute, Zeichen mit Akzenten, usw. Aber das ist nur in der Codepage so, die wir hier bei uns kennen. Es gibt noch Codepages, bei denen an Stelle unserer Buchstaben ganz andere stehen, dazu gehören Kyrillisch, griechisch, Thai, Japanisch und viele mehr. Im Grunde wird jeder Wert zwischen 0 und 255 auf ein Zeichen gemappt, das auch wieder eine bestimmte Nummer hat, die man in der Schriftartendatei finden kann. Da man auf diese Weise niemals alle Zeichen der Sprachen auf der Welt unter einen Hut kriegen konnte ohne Codepages zu wechseln, gibt es eben UTF-8, Unicode und Konsorten.

Das Problem an UTF-8 ist, dass jedes Zeichen entweder 8, 16, 24 oder 32 Bit haben kann, man also aus der Bytelänge, die ein UTF-8-String im Speicher belegt, nicht sicher die Zeichenanzahl voraussagen kann. Gleichzeitig kann man mit UTF-8 im Gegensatz zu Unicode meist annähernd die Hälfte des Speichers sparen, weil Unicode immer 2 Bytes pro Zeichen belegt. Bei UTF-8 kommt es hierzulande seltener vor, dass ein Zeichen mehr als 1 Byte belegt. UTF-8 eignet sich deswegen sehr gut im Texte in Dateien zu speichern, weil dadurch nie zu viel gespeichert wird. Unicode eignet sich im RAM besonders gut, weil man jedes Zeichen direkt ansprechen kann, weil es immer aus 2 Bytes besteht.

Und jetzt erklär mal genau, was dein Programm tun muss. Ich bin sicher es gibt eine einfache Lösung, auch für dein veraltetes System. Im übrigens sind 1 Mio Zeilen ja nicht mal so viel. Wie lange sind die Zeilen denn überhaupt? Selbst bei 100 Zeichen pro Zeile verbraucht man damit ja nur 200 MB RAM bei Unicode.