Also check out the sites of the IETF IDN WG
(http://www.ietf.org/html.charters/idn-
charter.html, and http://www.i-d-n.net/) for more information that you may
have
wished for.
Oops. Sorry, I only saw James's answer. You obviously read these. Well, I
hope my English horns pages were new
Also check out the sites of the IETF IDN WG
(http://www.ietf.org/html.charters/idn-charter.html, and
http://www.i-d-n.net/) for more information that you may have wished for.
Except on English horns, that is; but then you may want to visit
http://www.users.globalnet.co.uk/~gbrowne/geoff9.htm and
If you're interested in Osmanya, the following 7.5 MB file is
doubtless just what you are looking for. See
http://www.egt.ie/standards/iso10646/pdf/afkeenna-iyo-fartiisa.pdf
--
Michael Everson
Doug Ewell expostulated:
Now, upon visiting the Internet Drafts index once again, I see a
proliferation of ACEs, including schemes called BRACE and DUNCE. (I can't
tell from the spec whether DUNCE is intended as a joke or not, and I think
that says a lot.) The big question now is which
From: James [mailto:[EMAIL PROTECTED]]
There's already 2 Perl modules on CPAN that implement
ACE. These modules are already in use by ISPs for CJKV
iDNS registration. (One was packaged by me based on Paul Hoffman's
IMC code.) They are based on draft-ietf-idn-race-02.txt
So it seems
Mark Davis wrote:
You are correct about the published definitions. As I recall, though, we
were referring to UTF-FSS as UTF-8 in the UTC meetings before it was changed
to account for UTF-16.
In any event, I don't know whether Oracle was involved in those discussions
or not, or whether
Jianping,
It's a reasonable set of requirements you laid out. However,
with respect to this last paragraph, as Unicode 3.1 did not
exist when 8i was current, is it not unreasonable to insist
that users wanting to work with 3.1, or in particular supplementary
characters, first must upgrade?
There is one statement that appears to want to be framed:
Jianping Yang wrote:
[...] When Unicode
came to version 2.1, we found our AL24UTFFSS had trouble for 2.1 as Hangul's
reallocation, and we could not simply update AL24UTFFSS to 2.1 definition as it
would mess existing users' data in
Markus Scherer wrote:
This means that Oracle mis-implemented the UTF-8 standard as it was specified at
that time, starting at least with Unicode 2.0.
No, Oracle does not mis-implement the UTF-8 standard but only limit its support to BMP
only. Except the backward compatibility reason,
Toby,
I believe that Peoplesoft does not have a unique problem. A just say no to
UTF-8s attitude does not solve your problem or the problem of other
companies in your situation.
The problem that I see with the UTF-8s proposal is that it needs different
support than UTF-8.
What do UTF-8
10 matches
Mail list logo
