The following assumes you have at least some understanding of what
Unicode and UTF-8 are.  Please see http://unicode.org if needed.

Since ReDIF-perl version 2.19 the parser is UTF-8 enabled.  All
internal data processing & validation happens in UTF-8, whether you
want it or not.  It is still assumed that by default ReDIF files are
in iso-latin-1 (iso-8859-1) encoding.  The data is taken as UTF-8 if
there is a valid UTF-8 Byte Order Mark (BOM) at the file start.

BOM is usually several bytes which represent a special Unicode
character.  In different encodings this happens differently, and that
gives the opportunity to detect the encoding if a valid BOM is
present.

The UTF-8 BOM is 3 bytes (hexadecimal): EF BB BF.  Place these 3 bytes
into the filestart, encode your data into UTF-8 and it will be
processable by ReDIF-perl.

If your data is in latin-based alphabet, it is likely to be correctly
representable in iso-latin-1 encoding.  In that case for all ReDIF
parser-based applications it should be indifferent in what encoding
you store your data.  If the application doesn't explicitly require
UTF-8, it will get it's usual latin-1.  If the application requests
UTF-8 output - it will get it.  

But UTF-8 is a Unicode encoding, and it allows unicode characters
which are not present in latin-1 (among many others, cyrillic
characters).  If your UTF-8 template includes at least a single
character outside latin-1 range, your template will not reach the
applications which don't know how to handle it (old applications).

The charsets conversions to and from utf-8 are processor intensive, so
one might be interested to know that it made ReDIF-perl run
significantly slower then it was before.  That is the price of
internationalization.
