W3C home > Mailing lists > Public > www-svg@w3.org > September 2003

Re: utf-8

From: Steve Schafer <steve@fenestra.com>
Date: Wed, 10 Sep 2003 13:06:34 -0400
To: www-svg@w3.org
Message-ID: <qcmulv4g713vgnebe9bbqi7s6tv1etljkh@4ax.com>

On Wed, 10 Sep 2003 17:42:38 +0200, sigler@bredband.no wrote:

>Okay, I feel stupid, I've purchased the utf-8 spec from iso, and they
>explain how to convert from utf-8 to ucs4, I'm afraid we're talking past one
>another. My question is simply: How can 4 bytes be represented in 2 bytes,
>it can't be done. what am I missing?

Unicode character values can range from U+0000 to U+10FFFF. To represent
these characters in an 8-bit encoding, you use UTF-8, which you already
know about. To represent those characters in a 16-bit encoding, you use
UTF-16, which works as follows:

* For character values between U+0000 and U+FFFF, the UTF-16 value is
just the same as the character value.

* For character values greater than U+FFFF, generate a "surrogate pair"
of UTF-16 values:

 H = ((V - 65536) div 1024) + 55296
 L = ((V - 65536) mod 1024) + 56320

or, in hex notation:

 H = ((V - 0x10000) div 0x400) + 0xD800
 L = ((V - 0x10000) mod 0x400) + 0xDC00

where V is the original character value, the "div" operation represents
integer division (throw away the fraction), and the "mod" operation
returns the remainder after integer division.

In this way, 4-byte character values are represented by a sequence of
two 2-byte UTF-16 values, H and L (H always comes first). Some examples:

 V          H        L
 U+010000   0xD800   0xDC00
 U+010001   0xD800   0xDC01
 ...
 U+0100FF   0xD800   0xDCFF
 U+010100   0xD800   0xDD00
 ...
 U+0103FF   0xD800   0xDFFF
 U+010400   0xD801   0xDC00
 U+010401   0xD801   0xDC01
 ...
 U+10FFFF   0xDBFF   0xDFFF

In case you're wondering about the Unicode characters in the range
U+D800 through U+DFFF (which overlaps the range used by the surrogates),
the answer is that they're aren't any Unicode characters in that
range--it's reserved for the surrogates.

There's one further complication: UTF-16 doesn't specify which byte
comes first within the pair of bytes that comprises a UTF-16 value. So
there are actually two flavors of UTF-16, UTF-16BE for "big-endian"
systems, in which the more significant byte comes first, and UTF-16LE
for "little-endian" systems, in which the less significant byte comes
first. But this complication only comes into play during byte-oriented
serializtion and un-serialization.

Note that the DOM specifes the use of UTF-16 to represent characters, so
the answer to your question about the DOM using only two bytes per
character is no. Yes, the DOM uses "16-bit units" to represent
characters, but for some characters (i.e., those above U+FFFF), two
16-bit units are required in order to represent one character. This is
explained in Section 1.1.5 of the DOM Core rec.

Steve Schafer
Fenestra Technologies Corp
http://www.fenestra.com/
Received on Wednesday, 10 September 2003 13:06:49 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:25 GMT