Move("FileToList",...)

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Unsere Datenschutzerklärung wurde aktualisiert. Mit der Nutzung unseres Forums akzeptierst Du unsere Datenschutzerklärung. Du bestätigst zudem, dass Du mindestens 16 Jahre alt bist.

    • Move("FileToList",...)

      Hallo Roland,
      Wäre es auch möglich, bei Move("FileToList", D) und Move("ListToFile", D)
      UTF8 und UNICODE zu berücksichtigen ?

      Etwa mit einem weiteren optionalen Parameter, der angibt, ob man
      eine Datei im UTF8 oder UNICODE - Format einlesen bzw. speichern
      möchte. Wird der Parameter weggelassen oder ist 0, dann normal,
      als ANSI wie bisher.

      Vielleicht wäre auch noch OEM machbar.
    • H.Brill schrieb:

      Wäre es auch möglich, bei Move("FileToList", D) und Move("ListToFile", D)
      UTF8 und UNICODE zu berücksichtigen ?
      Ich denke mal, ANSI und UTF8 sollten reichen ;-)
      UNICODE gibt es in verschiedenen Kodierungen von UTF16, UTC2 usw., die man aber für Kodierungen in Dateien kaum nutzt.
      ANSI ist der alte Standard und UTF8 ist der neue Standard für Dateien und nur für Dateien möchtest Du es ja nutzen. Wie es dann in Profan-Strings kodiert wird, ist ja ein ganz anderes Ding, wobei bis jetzt ja nur ANSI-Strings direkt unterstützt werden.
      Gruß Thomas
      „Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine
      davon in einer Katastrophe endet oder sonstwie unerwünschte
      Konsequenzen nach sich zieht, dann wird es jemand genau so machen.“ Murphys Gesetz
      ComputerInfo für PPF
    • UNICODE, zumindest das UTF16, ist immer noch aktuell.
      Auch die neuen windowseigenen Editoren bieten es ja
      noch an. Außerdem hat Roland vor nicht allzulanger
      Zeit ja die WideStrings bereit gestellt und auch die
      Bereichsfunktionen entsprechend erweitert.

      Ich habe hier mal ein Testcode :

      Quellcode

      1. Declare String datei
      2. Window 600, 400
      3. datei = "H:\Adressen.txt"
      4. Print Move("FileToListEx", datei, 2)
      5. Listbox$("Datei", 2)
      6. 'Waitkey
      7. End
      8. SubProc Move.FileToListEx
      9. Parameters String datei, Int CP
      10. ' CP = 1 -> UTF8 CP = 2 -> UNICODE CP = 0/keine Übergabe -> ANSI
      11. Declare Long bytes, gelesen, WideString z1, String z2, Memory bereich
      12. If %PCount = 2
      13. bytes = FileSize(datei)
      14. If bytes > 0
      15. Dim bereich, bytes
      16. Assign #1, datei
      17. OpenRW #1
      18. gelesen = BlockRead(#1, bereich, 0, bytes)
      19. Close #1
      20. Select CP
      21. CaseOf 1
      22. z1 = UTF8DEcode(String$(bereich, 0))
      23. CaseOf 2
      24. z1 = StringW$(bereich, 0)
      25. Otherwise
      26. z1 = String$(bereich, 0)
      27. EndSelect
      28. EndIf
      29. ElseIf %PCount = 1
      30. bytes = FileSize(datei)
      31. If bytes > 0
      32. Dim bereich, bytes
      33. Assign #1, datei
      34. OpenRW #1
      35. gelesen = BlockRead(#1, bereich, 0, bytes)
      36. Close #1
      37. z1 = String$(bereich, 0)
      38. EndIf
      39. EndIf
      40. Dispose bereich
      41. ClearList
      42. Move("StrToList", z1, Chr$(13) + Chr$(10))
      43. Return (GetCount(0) - 1)
      44. EndProc
      Alles anzeigen

      Die Textdatei wurde mit dem Windows-Editor in den 3 Kodierungen je als
      Datei erstellt. Einziger Fehler, den ich noch nicht gefunden habe, ist bei
      UTF8. Da kommt als erstes Zeichen bei der ersten Zeile ein '?'.


      Bei WideString(Bereich, 0) funktioniert es nicht.


      Wie gesagt, eingebaut wäre sowas schon besser.

    • Es geht nicht um "Aktuell", es geht darum, das UTF16 kein unbedingt geeignetes Format für Dateien ist. Im Speicher hat es eher was zu suchen, da man es schneller Manipulieren kann. Da wird dann eher der File in UTF8 on the fly nach UTF16 in den Speicher übertragen, was so gut wie keine Zeit kostet. Das macht dann eher Sinn.

      Speichern in UTF8:
      xml, json, sqlite ...

      Speichern in UTF16:
      nichts bekannt :-D , aber manch einer tuts, weil er es eben kann.

      Für Dateien ist UTF16 also vollkommen unwichtig. Für literale Strings wird es normalerweise konvertiert beim einlesen in den Speicher.

      Aber das überlassen wird dann lieber Roland, ist ja seine Sprache!
      Gruß Thomas
      „Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine
      davon in einer Katastrophe endet oder sonstwie unerwünschte
      Konsequenzen nach sich zieht, dann wird es jemand genau so machen.“ Murphys Gesetz
      ComputerInfo für PPF
    • Na ja, UTF16-LE wird halt leider von Windows am Leben gehalten (sind ja deren WideStrings).

      Ich wollte UTF8 weil es bei Unix und Mac halt Standard ist.
      Ein Großteil der Internetseiten ist auch schon darauf ausgerichtet.

      Und die Ausrede: Zu langsam
      zieht auch nicht mehr. Erstens gibt es bereits Routinen,
      die die Bitmasken prüfen und so den Start von Zeichenfolgen erkennen.

      Zum anderen kann man für Strings einen Descriptor-Block verwenden.
      In dem speichert man den Typ (Ansi/Utf8/Utf16), die Adresse und die Länge.
      XProfan muß Adr. u. Länge ja auch speichern.
      Programmieren, das spannendste Detektivspiel der Welt.