A decoder specifies how data arrives from a source. There are two basic types of decoders:

Simple decoders - Decode one or more external formats.
Constructed decoders - Coordinate the decoding between multiple simple or constructed decoders.

Simple Decoders

The syntax of a simple decoder is declared as follows:

decoder <name> : <decoder options>;

The decoder options are:

Option	Description
`in_map(<map name>)`	Specifies what in-maps to use. At least one is required.
`block_size(<size>)`	Specifies that this is a blocked format with specified block size.
`terminated_by(<terminator>)`	Specifies the block filler used. This option has no effect if `block_size` has not been specified.

The decoder may contain one or several in-maps, depending on whether it manages a single or multiple (mixed) record type. For multiple maps, the corresponding external records except the last one must support identification. The decoder tries each in_map in the specified order. The first one, for which the identification criteria are met, is used.

How the record identification is specified depends on the actual external record type. For example, sequential external records must use the identified_byoption while BER encoded records support identification by the standard tagging scheme.

Simple decoders may be given blocking information through the block_size and terminated_by constructs. The block_size parameter contains the size of a block and the terminated_by parameter specifies the start of a padding character.

Example - Simple decoder

decoder SimpleDecoder : in_map(Map1), in_map(Map2), 
    block_size(2048), terminated_by(0x00);

This decoder starts by reading the next byte and evaluates if it equals 0x00. Should it be 0x00, it jumps to the next even boundary of 2048 and repeats this procedure. If it is not 0x00, it evaluates the identification for both of the externals specified in Map1 and Map2 (in that order).

Constructed Decoders

A constructed decoder is defined in terms of a number of other simple or constructed decoders. They are used to specify the decoders to be used in sequence, for example to specify separate decoders managing header, trailer, and record information. For instance, three external record types (Rheader, Rudr, Rtrailer), with corresponding in_maps (Mheader, Mudr, and Mtrailer) and decoders (Dheader, Dudr, and Dtrailer).

The following constructed decoder specifies the header record to be decoded first. Then any number of UDR records are decoded, followed by a single trailer record.

Example - Constructed decoder

decoder TTFile {
    decoder Dheader;
    decoder Dudr *;
    decoder Dtrailer;
};

As can be seen, the constructed decoder does not (and cannot) have any decoder options.

The asterisk after Dudr indicates that zero or more entries can occur before a terminating trailer record. For such a sub-decoder, the constructed decoder switches to the next decoder when the sub-decoder cannot handle the input (as deduced by the identification criteria of the in_maps in the sub-decoder). In this case it means that the Dudr decoder must support identification logic, or the Dtrailer decoder is never reached (and the decoder aborts with an "Unexpected EOF" error).

This example could also have been supported with a simple decoder:

Example - Simple decoder

decoder TTFile : 
    in_map(Mheader), in_map(Mudr), in_map(Mtrailer);

The difference is that the order of header, UDR, and trailer would not be enforced for the simple decoder. The simple decoder also does not work if, for instance, the header does not support identification.

Browser not supported