Well, my own software tends not to use Unicode. Sometimes, it only uses ASCII. Sometimes, it doesn't care about character coding, as long as it is compatible wi

Well, my own software tends not to use Unicode. Sometimes, it only uses ASCII. Sometimes, it doesn't care about character coding, as long as it is compatible with principle of extended ASCII. Sometimes, it is a combination of the two (such as ASCII only for commands, but comments can include any characters that are compatible with principle of extended ASCII). In one case (VGMCK), it does parse UTF-8 in some contexts (such as #TITLE commands), but the only thing it does with the decoded data is to convert it to UTF-16, since the output format (VGM) contains UTF-16 text. A UTF-8 byte order mark at the beginning of the file is not acceptable, though. But I have thought of some mechanisms to declare character sets and character mapping, to determine which font is appropriate, etc. Unicode is a valid choice, but even if you select Unicode as your character set of use, you must specify the language code and the Unicode version. You can also specify more than one mapping, and custom mappings, for example if you are using CSUR to write in Klingon and English, then you can declare both Unicode and CSUR, together with the relevant version numbers. I thought of a similar mechanism for declaring character sets and character mapping for TAVERN32 (which doesn't exist yet, but it is meant to be an improved text adventure game VM having the advantages of both TAVERN and Glulx). One lump declares the character sets and character mapping, and can include fallbacks if wanted, so that if ASCII mappings are declared, then it can work with any implementation even if they do not know about that character set. The story file might also (optionally) include other lumps with bitmap fonts, so that also allows it to work even if the character set is unknown (as long as it can display graphics, which some implementations may be incapable of). However, in this case, the character mapping is also relevant for compression too, and not only for determining character sets. There is then the possibility that multiple codes will be mapped to the same ASCII character (or sequence of characters in ASCII or any other character set), avoiding the problem of compatibility.