The output of the JBerd Flattener and Profiler is readable (not binary) text in UTF-8 format. The input BER data is inherently binary. So when JBerd prints the value of an input field it must necessarily reformat it.
The simplest format is a hex dump of the input data. If JBerd has no information on how to represent some input data, it will do this. For an example, and ASCII string representing a date could be rendered as the hex string 3139373130393137.
The next simplest is to use BER’s native encoding. This only works for data items that have universal tags. These universal tags indicate the format of the data. For example, any item with the tag “260”. The trailing zero indicates a universal tag, and 26 is the BER internal tag for VisibleString. Therefore JBerd knows to show the data as strings. This only works if data has been encoded as universal class.
*Lastly JBerd provides a means of overriding the above and forcing a different rendering. This is done by specifying a rendering in an alias file. For example, the date string shown above in hex could be rendered as the printable string 19710917, which is the printable representation of the hex data 3139373130393137.
JBerd uses the above rules in reverse priority order. That is, if an item has an override data type specified in an alias file then it will always attempt to render the data as that type. If there is no data type in an alias file, and the item has a universal tag (ends with 0) it will be rendered using BER's native rendering. Otherwise it will be rendered as hex.
The following are valid values that can be put into an alias file to instruct JBerd how to render a field.
Rendering | Description |
---|---|
HEX | This forces the default output of a hex dump. |
STRING | This forces a representation of the data assuming that it consists of ASCII characters. Non printing characters are shown as “?” |
BCD | This is very like HEX except that the individual hex digits in each byte are reversed. This is useful in some telecommunications protocols. See below for more information. |
NATIVE | This simply tells JBerd not to override and to use native rendering for universal tags, and HEX for everything else. |
REAL | Interpret the content of the field assuming it to be encoded as a REAL according to the rules in X.690 section 8.5 |
INTEGER | Interpret the content of the field assuming it to be encoded as a twos complement integer according to the rules in X.690 section 8.3 |
UTF8 | Interpret the content of the field assuming it to be a UTF-8 encoded string |
UTF16 | Interpret the content of the field assuming it to be a UTF-16 encoded string |
OBJECT_IDENTIFIER | Interpret the content of the field assuming it to be encoded as an Object Identifier according to the rules in X.690 section 8.19 |
BITSTRING | Interpret the content of the field assuming it to be encoded as a BitString according to the rules in X.690 section 8.6 Note that this is a complex format (the first byte contains special information). It is not simply a binary dump of the data. (Unlike HEX, which is a simple dump) |
To see how alias names and types are associated with BER data items see [Tags and Aliases]
For full documentation see Jberd.pdf