moins,

folgendes Problem: ich habe da einige Dateien mit sogenannten OID (object identifier) aus SNMP-MIBs. Das sind so Zahlenketten, z.b. 1.3.6.7.3.23.1.2 etc.
Die wandelte ich in Binärform um, mit pack("C*",@zeichenketten). Dabei war jede Ziffer innerhalb jedes Elements von @zeichenketten ein INTEGER kleiner als 255. Daher konnte ich diesen Operator(?) C nehmen. Damals habe ich es vermasselt und nun kommt es. Eine neue MIB soll verarbeitet werden. Diese enthält jedoch INTEGER-Werte in ihren OID die größer als 255 sind. So müsste ich zum umwandeln den Operator "s" benutzen.
Ich habe nun festgestellt das Daten, die mit "C" encodiert wurden, mit "s" decodiert Blödsinn ergegeben.
Ich habe aber ein paar Dateien noch mit "C" decodiert und ein paar mit "s". Wenn ich die mir anzeigen lassen will, muss ich den Inahlt also decodieren, einmal mit "s", andernmal mit "C". Frage: gibt es da was, was automatisch erkennt, wie die Daten mal encodiert wurden, so dass man den Operator automatisch einstellen kann? Ich möchte nicht jede Datei manuell anfassen, um sie mit "s" umzuwandlen.

mordur+2008-09-30 11:48:52--

gibt es da was, was automatisch erkennt, wie die Daten mal encodiert wurden, so dass man den Operator automatisch einstellen kann? Ich möchte nicht jede Datei manuell anfassen, um sie mit "s" umzuwandlen.

Nein.
pack/unpack richtet sich nicht nach dem Inhalt, sondern dem Formatstring, den du angibst, um zu de-/kodieren.

schade

Wie soll denn Perl bei C* wissen wann welches interne Format vorliegt?
DU bist mit einem Denkfehler davon ausgangen, dass OIDs immer nur bis 255 Bit, also Octets, sind.

Es leigt in der Verantwortung der Programmierenden, pack und unpack richtig anzuwenden.

mordur+2008-09-30 11:48:52--

Das sind so Zahlenketten, z.b. 1.3.6.7.3.23.1.2 etc.
Die wandelte ich in Binärform um, mit pack("C*",@zeichenketten). Dabei war jede Ziffer innerhalb jedes Elements von @zeichenketten ein INTEGER kleiner als 255.

Oha, du schreibst ja selbst, dass es ein Integer (richtiger unsigned int) ist und kein Byte!

Du kannst binäre Daten nicht so einfach in ihre Zeichenkettenform zurück transformieren, schon wenn interne Daten mal als Bytes (8Bit) und mal als Words (16Bit) dargestellt werden.

Zudem können ja OIDs verschiedene Längen haben, da kann auch leider keine feste Länge zu Identifikation genommen werden.


Du musst wohl oder übel ein Skript schreiben, dass deine deine alten 8bit Daten in breitere 16bit oder 32bit umwandelt.


Darf eine Fragen, warum du die Daten in Binär gespeichert hast (wo das nur sehr bedingt portabel ist)?

Scheint mir, dass Du Dir nicht so ganz im Klaren darueber bist, was genau pack eigentlich tut und warum Du es benutzt. Vielleicht moechtest Du ja in Zukunft lieber Storable nehmen... oder einfach "join" und "split"? (Wobei ich jetzt nicht weiß, was OID sind und ob sie das Format brauchen... aber wenn egal ist, ob Du "C" oder "s" nimmst, scheint das Format ja recht frei wählbar zu sein.)

Mit "s" werden genau zwei Bytes pro Zahl gebraucht, mit "C" nur eines. Falls Du weisst, wie lang Deine Zahlenreihen sein sollen, kannst Du also anhand der Dateigrößen raten, wie Du sie entpacken musst. Außerdem kannst Du natürlich bei einer ungeraden Gesamtlänge in Bytes (abzüglich eventueller Zeilenumbrüche oder so) davon ausgehen, dass "C" verwendet wurde.

Wenn Du etwas über den Wertebereich weißt (zum Beispiel dass nie 0 vorkommt oder so etwas), kannst Du natürlich auch recht gut empirisch herausfinden, wie das Zeug zu entpacken ist.