Download FLCL - User Manual

FLCL - User Manual
4.2.117
106 / 764
OBJECT ARMOR
SYNOPSIS
HELP:
PATH:
TYPE:
SYNTAX:
Activate ARMOR encoding and defines corresponding parameter
CONV.WRITE.BINARY.ENCODE.BASE32
OBJECT
ARMOR(HEADER=’str’,VERSION=’str’,COMMENT=’str’)
DESCRIPTION The ARMOR object activates ASCII armor encoding. Depending on the specified CHRSET, it may also use
EBCDIC encoding. ASCII armored data is Base64 encoded binary data followed by an optional checksum, surrounded by a
header and trailer. For this you can set the header, version and comment strings illustrated in the example below:
-----BEGIN header string----Version: version string
Comment: comment string
yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
vBSFjNSiVHsuAA==
=njUN
-----END header string-----
The header data is usually set by the previous component in a meaningful way. Therefore, we recommend not overwrite these
values, especially when using the PGP converter.
In general, it only makes sense to set the header data if none is set by another component (e.g. after reading binary). In this
case, the default header is the current data type BINARY/RECORD/TEXT/. . . , the version is the current FLAM version and the
comment the current default comment.
Applying ASCII armor on an XML file would yield a result similar to the example below:
-----BEGIN XML DATA----Version: FLAM: 5.1.8.10219
Comment: created with FLUCv5.1.8.10219 (www.flam.de)
Charset: UTF-8
PD94bWwgdmVyc2lvbj0iMS4wIj8+CjwhRE9DVFlQRSB0ZXN0IFsKPCFFTEVNRU5UIHRlc3Qg
KCNQQ0RBVEEpPgo8IUVOVElUWSBhYSAiJiMzNzt6ejsmYW1wO2FhOyI+CjwhRU5USVRZICUg
eHggIiYjMzc7eno7Ij4KPCFFTlRJVFkgJSB6eiAiPCFFTlRJVFkgdHJpY2t5ICYjMzQ7ZXJy
b3ItcHJvbmUmIzM0OyA+Ij4KPCFOT1RBVElPTiBub3RhdGlvbk5hbWUgU1lTVEVNICJzeXN0
ZW1JZCV6ejsmYW1wOyYjMzQ7Ij4KPCFOT1RBVElPTiBub3RhdGlvbk5hbWUgUFVCTElDICJw
dWJsaWNJZCIgInN5c3RlbUlkJiMzNDsiPgoleHg7CiV4eDsKXT4KPHRlc3Q+VGhpcyBzYW1w
bGUgc2hvd3MgYSAmdHJpY2t5OyBtZXRob2QuPC90ZXN0Pg==
-----END XML DATA-----
If you activate the ARMOR object and no line length is specified, then a default of 72 is used. ASCII armor can be applied to
block- or record- oriented data.
When reading, header and trailer are stripped away and the decoded data is passed to the next component. If no header is found,
only the decoding is done. To verify that trailer contains the same string used in the header, you must enable a switch.
The base encoding component also supports the optional CRC24 checksum for Base64 defined in RFC4880. For the other base
encoding schemas, CRC checksum lengths are used that match the respective block size.
The same XML example as above, but with a CRC24 checksum, looks like this:
-----BEGIN XML DATA----Version: FLAM: 5.1.8.10233
Comment: created with FLUCv5.1.8.10233 (www.flam.de)
Charset: UTF-8
PD94bWwgdmVyc2lvbj0iMS4wIj8+CjwhRE9DVFlQRSB0ZXN0IFsKPCFFTEVNRU5UIHRlc3Qg
KCNQQ0RBVEEpPgo8IUVOVElUWSBhYSAiJiMzNzt6ejsmYW1wO2FhOyI+CjwhRU5USVRZICUg