Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich erstelle Strings die nur Hexadezimalzeichen enthalten. Speichere ich diese Strings in Textdateien sind sie z.B. 40KB groß. Danach öffne ich einen Hexeditor, füge die Daten aus der Textdatei ein, speichere das Ganze als Hex-Datei. So ist die Datei nur noch halb so groß.
Kann ich die Daten auch gleich aus LabVIEW in solch eine Hex-Datei schreiben?
wenn du deinen Hex-String direkt speicherst, dann nutzt du nur die Hälfte des möglichen Informationsgehaltes deines Files. Hex-Zahl heißt ja 0-F (also 0-15dez), also 4 bit Information. Ein ASCII-Zeichen hat aber 8 bit Information.
Lösung also: Jeweils 2 Hex-Zeichen zu einer Einheit zusammenfassen (->8bit Informationsgehalt), diese dann in eine U8-Zahl wandeln und dann als Binär-String speichern.
MfG, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
' schrieb:wenn du deinen Hex-String direkt speicherst, dann nutzt du nur die Hälfte des möglichen Informationsgehaltes deines Files. Hex-Zahl heißt ja 0-F (also 0-15dez), also 4 bit Information. Ein ASCII-Zeichen hat aber 8 bit Information.
Lösung also: Jeweils 2 Hex-Zeichen zu einer Einheit zusammenfassen (->8bit Informationsgehalt), diese dann in eine U8-Zahl wandeln und dann als Binär-String speichern.
Ja, aber DRHoas wunderte sich ja, daß seine Hex-Dateien beim Abspeichern (wieder in Hex, und nicht als U8-Zahl) nur noch halb so groß sind. Eine Erklärung dafür könnte sein, daß die Zeichen ursprünglich das neumodische Unicode-Format hatten (16 bit pro Zeichen), dann aber im ASCII-Format (8bit pro Zeichen) abgespeichert wurden. Durch Umwandeln gemäß Deinem Vorschlag könnte man dann allerdings die Dateigröße noch mal halbieren.
' schrieb:Ja, aber DRHoas wunderte sich ja, daß seine Hex-Dateien beim Abspeichern (wieder in Hex, und nicht als U8-Zahl) nur noch halb so groß sind. Eine Erklärung dafür könnte sein, daß die Zeichen ursprünglich das neumodische Unicode-Format hatten (16 bit pro Zeichen), dann aber im ASCII-Format (8bit pro Zeichen) abgespeichert wurden. Durch Umwandeln gemäß Deinem Vorschlag könnte man dann allerdings die Dateigröße noch mal halbieren.
Hallo, Lucki,
das sehe ich aber anders. DRHoas hat doch zuerst aus LV einen HEX-String als lesbaren ASCII String (nicht irgendwie binär) abgespeichert. Dann hat er in einem HEX-Editor diesen ASCII-String eingesetzt. Und dann als HEX-Datei (also binär) abgespeichert. Dabei müsste der HEX-Editor die oben beschriebene Umsetzung vorgenommen haben, sprich 2 Hex-Zahlen entsprechen 1 Byte Information.
MfG, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
' schrieb:das sehe ich aber anders. DRHoas hat doch zuerst aus LV einen HEX-String als lesbaren ASCII String (nicht irgendwie binär) abgespeichert. Dann hat er in einem HEX-Editor diesen ASCII-String eingesetzt. Und dann als HEX-Datei (also binär) abgespeichert. Dabei müsste der HEX-Editor die oben beschriebene Umsetzung vorgenommen haben, sprich 2 Hex-Zahlen entsprechen 1 Byte Information.
Ja, aber was ist eigentlich ein "HEX-String" ? Ich bin davon ausgegangen, daß das ein ganz normaler ASCII-String ist, nur eben mit der Besonderheit, daß darin als reguläre Zeichen nur 0..9, A..F vorkommen. Ist das falsch? Und selbst wenn ja, dann ist vielleicht DRHoas in seiner Frage genau so von dieser falschen Definition ausgegangen wie ich, so daß wir uns auf gleicher Wellenlänge getroffen haben. Anders kann ich mir die Zustimmung von DRHoas zu meiner Antwort (die galt doch mir, oder zumindest auch?) nicht erklären.
Fest steht auch, daß LV - innovativ wie immer - das Unicode-Format favorisiert. Wenn die Datei dann mit einem normalen, d.h. "weniger innovativem" Texteditor bearbeitet wird, dann schrumpfen die 2 Byte pro Zeichen eben zu einem Byte pro Zeichen zusammen - also ein ganz normaler Vorgang,
Ich sehe das so:
Also ich dachte immer das der Compi nur mit 1 und 0 zurechtkommt, und da ist ein UTF8-Ascii Wert immer 8 Bit, egal ob ich den nun als Hex, Dez, Okt..) darstelle.
DRHoas schreibt : ich erstelle Strings die nur Hexadezimalzeichen enthalten...
Er schreibt/erstellt einen "Hex" String z.Bsp F0, dieser ist nun halt 2 Byte. (umschalten auf HEX ansicht)
Schreibe ich aber F0 als "dargestellten" Hexwert in die Datei ist er nur noch 1 Byte. (Hexwert F0 = string = ð)
Daher ist die Datei kleiner, meiner Meinung nach.
Unicode dachte ich wird im LabVIEW nur "aktiv" wenn das OS auch unicode ist (z.Bsp. LV-Japan), und so neumodisch ist das nun auch nicht.
Gruss
Roland
.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
