g'day,
Thanks for explaining this with the proper terminology. The explanation
agrees with my understanding as received from others. I think too that
it can be read and thrown away -- but it should be handled.
ak
Chris Little wrote:
Troy A. Griffitts wrote:
My guess about the characters whi
UTF-8 is a stream of bytes, so it has no endianness. Big vs. little
endian indicates whether you store the bytes of a 2+ byte number
starting with the low- or high-order byte.
You can use a BOM in any Unicode encoding (UTF-7, UTF-8, UTF-16BE,
UTF-16LE, UTF-32BE, or UTF-32LE) since it encodes bo
UTF-8 has big and little endian byte orderings.
If there is no byte mark, it will be significant to use a particular
byte ordering (either little-endian or big-endian).
If there is a BOM, then it can be interrogated and the UTF can be
interpret in either fashion.
Even so, I think that it would be
Troy A. Griffitts wrote:
My guess about the characters which keep the .conf file from being
recognized... try adding a few newlines to the beginning of the file. I
would guess that XXX[Section Name] at the beginning is just causing our
.conf reader to not recognize the "Section Name".
The
Adrian,
This is great news!!! I'd love to see a screenshot if you could post
one somewhere. I've not succeeded in getting anything other than
latin-based languages to show up on the menus in Windows 2000.
My guess about the characters which keep the .conf file from being
recognized... try a
g'day,
Conf files converted to utf-8 do work for the UI. I ran into a problem
at first that prevented the files from being read properly. I'm using
TecKit, a program that can quickly convert files from code-page
encodings to various unicode formats. It places three characters at the
beginning o
