Parse TLV

Walking a generic Tag-Length-Value structure whose field widths you set yourself: protocol frames, binary log records, custom containers, smartcard-style records. It is not ASN.1 aware. Tags and lengths are read as plain fixed-width integers, so a DER file with multi-byte or high-tag-number encodings will not walk correctly here. Use Parse ASN.1 for DER.

Three. tagBytes and lengthBytes each take 1, 2 or 4 and both default to 1. littleEndian is off by default, meaning multi-byte tag and length fields are read big-endian, which is what most wire formats use. There is no offset option, so the walk always starts at byte 0; drop a leading header with Drop bytes first if your records do not start there.

Each line starts with the record's offset in hex, then the tag in hex padded to the tag width, then the decimal length, then a hex preview of the first 32 value bytes, then the same bytes as ASCII between pipes with non-printables as dots. Values longer than 32 bytes show the total length after the preview and an ellipsis in the ASCII column.

One of two reasons, and the line says which. Either the remaining bytes were too short for another tag and length header, reported as a count of trailing bytes at that offset, or a record declared a length longer than the bytes that remain, reported with the tag, the declared length and what was left. Both usually mean the field widths or the endianness are wrong, or the structure does not start at byte 0.

Because the first record did not parse with the widths you chose, and the message repeats them back as tag=1B, length=1B or whatever you set. Try the other widths, switch littleEndian on, and check with Hexdump whether the file starts with a header that has to be dropped first.

Yes, it stops after 5000 records and says so on the last line. Files that walk past that are usually the sign of a wrong width producing nonsense records, so read the first few lines carefully before trusting a long listing.