Umm... well, there are standard CPAN routines for standard ASN.1 encoding and decoding, such as Convert::ASN1 but I see telltale signs that your data may not be quite the same format as the ASN.1 BER (see for example http://www.columbia.edu/~ariel/ssleay/layman.html for a description of how "real" ASN.1 works.)
You say there are many TLV's in the data files, but the beginning of your decoding example decodes 0d, a1, 0b... as de1, comp1, era1... indicating that these are entities that code as single individual bytes and not as TLV's. (If the 0d started a TLV the a1 after it would have to be the length field... except that its high order bit is set, so in ASN.1 BER it would really be just the first byte of a multibyte length field...)
So, as best as I can tell from your description, there seems to be a field missing in the data files that would tell you whether a particular value in the first byte indicates a single-byte entity, like 0d, or whether it is is the first byte of a multiple byte TLV, like 02. And it makes no sense for the entry "01 opcode length" to appear in the data file; any small integer can be a length. (Unless it means that if the opcode tag is 02, then the only possible length is 01...?)
I think your biggest single problem is that when you say "01 stands for 'abcd' and also in some other place it stands for 'cdfv' also" you need to be able to put into words exactly how that decision needs to be made, and you need to be able to locate all the information used to make that decision. Actually, formulas or tables might work better than words, but all the details need to be fully fleshed out.
You shouldn't be worrying too much about how to express the algorithm in Perl until you get that far. From that point, most of it should be fairly straightforward array manipulation. | [reply] |
I'm sorry, I can't help you with your project. I do have one small observation though,
I am unable to come up with an algorithm for the same as i am very new to Perl programming.
Algorithms are language independent.
In other words, your lack of Perl knowledge shouldn't stop you coming up with a solution, even if you cannot personally translate that solution into a Perl program.
Sometimes, knowing the idioms of a particular language can help, but equally, that knowledge can hinder.
| [reply] |
Algorithms are language independent.
That's perfectly true. But I also second Alan Perlis' claim that
A language that doesn't affect the way you think about programming, is not
worth knowing.
This is perhaps not terribly relevant here, but does constitute IMHO the starting point for an interesting meditation, the point being that although algorithms exist abstractly we're constantly concerned in their practical realization in some language or another and when doing so we're not interested in issues about e.g. the fact the algorithm is realizable in practice, some way or another, but specifically about how easy or difficult the particular language of choice will make doing so. Incidentally, this also pairs with my convincement that artistic creation (with which programming has an unremovable link, still IMHO) has not only to do with the abstract "idea", and that the medium on which it is to be made actual is more than a dumb substrate on which it is to be so to say, "transferred"; specifically, that the former has much to do with the struggle between the artist and the substrate itself, with its own charachteristics, be it some sort of material, a given format, or a programming language.
End of free flow of thought! ;-)
| [reply] |
First things first. CPAN can offer you some useful modules for parsing ASN.1 such as Convert::ASN1. This is not the entire answer though. You will have to convert your input text file into binary data before parsing. And I suggest you read a little more about ASN.1 such as www.w3.org and Wikipedia. | [reply] |
This smells a lot like homework... I'm more than willing to provide help to people who are learning Perl, but I won't help you do your homework.
| [reply] |
