LPC strings come in two flavors: As byte sequences and as unicode
strings. For both types almost the full range of string operations
is available, but the types are not to be mixed. So for example
you cannot add a byte sequence to an unicode string or vice versa.
Byte sequences can store only bytes (values from 0 to 255),
but unicode strings can store the full unicode character set
(values from 0 to 1114111).
There are two conversion functions to convert between byte sequences
and unicode strings: to_text() which will return a unicode string,
and to_bytes() which returns a byte sequence. Both take either
a string or an array, and when converting between bytes and unicode
also the name of the encoding (to be) used for the byte sequence.
-- File handling --
When a file is accessed either by compiling, read_file(), write_file()
(not read_bytes() or write_bytes(), or when an explicit encoding was
given), the master is asked via the driver hook H_FILE_ENCODING for
the encoding of the file. If none is given, 7 bit ASCII is assumed.
Whenever codes are encounted that are not valid in the given encoding
a compile or runtime error will be raised.
-- File names --
The filesystem encoding can be set with a call to
configure_driver(DC_FILESYSTEM_ENCODING, <encoding>). The default
encoding is derived from the LC_CTYPE environment setting.
If there is no environment setting (or it is set to the default
"C" locale), then UTF-8 is used.
-- Interactives --
Each interactive has its own encoding. It can be set with
configure_interactive(IC_ENCODING, <encoding>). The default is
"ISO-8859-1//TRANSLIT" which maps each incoming byte to the
first 256 unicode characters and uses transliteration to encode
characters that are not in this character set. If an input or
output character can not be converted to/from the configured
encoding it will be silently discarded.
-- ERQ / UDP --
Only byte sequences can be sent to the ERQ or via UDP,
and only byte sequences can be received from them.
-- Formatting --
The efuns sprintf() and terminal_colour() work not just on unicode
codepoints but on extended grapheme clusters. Those are several
unicode characters that will form a single user-perceived character.
These clusters will not be split by those efuns. Also those efuns
will try to guess the width of those characters and apply formatting
modifiers accordingly. But as this is dependent upon the client's
rendering of such characters it will never be perfect.
The grapheme cluster handling only applies to sprintf() and
terminal_colour(). Other efun and operators like sizeof(), explode()
and the index operator still work on single unicode codepoints and
thus allow to split such grapheme clusters. However the regular
expressions support \X to match a whole grapheme cluster. PCRE and
the traditional package differ in the handling of ANSI escape
sequences which the traditional package will treat also as a cluster.
Introduced in LDMud 3.6.
to_text(E), to_bytes(E), configure_driver(E), encodings(C)