Unicode, UTF-8, and Greek
James K. Lowden
jklowden at speakeasy.org
Fri Jul 13 22:57:34 EDT 2001
All,
For those whose eyes didn't glaze over when last we talked about Greek
characters and UTF-8 and Unicode and etc., I'm forwarding a message from
my friend Michael, who was born in Greece and is much too smart for his
own good.
I don't remember how our discussion was resolved, or even if indeed it
had a useful conclusion, but I found Michael's explication helpful. I
hope you do, too.
--jkl
Jim,
Unicode, UTF-8, different chinese encodings - we will soon long for the
days when all we had to worry about was ASCII to EBCDIC.
Most greek applications, win9x, NT, mac, unix etc, do not use unicode;
rather an 8 bit representation using characters 128-255 to map Greek.
The
problem is there are many such representations.
The most official one is ISO-8859-7 which is also known as ELOT 928 or
codepage 928. (ELOT is a Greek body similar to ANSI. Unix and Linux
systems almost always use that (According to the greek linux how-to
http://home.ichannel.gr/faq/Linux-greek-howto which you may find a bit
hard to read, but I'll be glad to translate the relevant portions)
M$ had to do things a bit different, ofcourse. Windows uses a set that
is
about 99% identical to 928, but the 1% difference is a frequently used
character (upper case A, punctuated). Argh. This is code page 1253.
Greek DOS applications simply use codepage 437 and depend on the user or
graphics card to have a Greek typeface. This is officially known as 737,
but there is no real support for 737 in any OS.
Macs use a prioprietary standard of their own.
Your Greek correspondent most certainly has a CP 928 or 1532
application.
If he is using NTEXT fields, then there should be an automatic
928->Unicode and Unicode->928 conversion, which may not be taking place
correctly due to a badly configured client (server configuration should
not be a problem). If he is using TEXT fields, then both client and
server
configuration is an issue; if the client is configured for a greek
codepage and the server defaulted to us-ascii, or v.v., things will
break,
since such a conversion would be lossy (characters 128-255 would get
junked, which appears to be the exact problem here).
Or, it could simply be a bug in the conversion routines.
I cannot imagine that this is a greek-only problem, these issues should
apply to all non-latin alphabet based languages...
Cheers,
Michael
More information about the FreeTDS
mailing list