[Ltru] [OT] Re: UTF-8

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> up to 11: [ & # x 1 0 F F F F ; ], although in practice nothing more 
>> than 10 will ever be required.
>
> My "7" was for a Latin-1 friendly UTF-4, not escape sequences:
>
> Hex. 86 91 90 9F 9F 9F 9F (lead byte + 6 hex. digits), in that form a 
> legacy text viewer or editor could display 191 visible Latin-1 
> characters as is, instead of "only" 95 ASCII for UTF-8.

First, you said UTF-8, not this.  Second, highly non-standard, but a fun 
thought experiment of the kind I used to indulge in.

I'm not sure why you chose 0x86 as your sequence introducer (U+0086 
START OF SELECTED AREA, or in Wnidows-1252, U+2020 DAGGER).  If all C1 
control bytes are available, you could make each sequence 1 byte shorter 
by marking the lead or trail byte specially:

81 90 9F 9F 9F 9F   <- lead byte 8x, all others 9x
81 80 8F 8F 8F 9F   <- trail byte 9x, all others 8x

"Terminal jockeys" such as Frank da Cruz (inventor of the Kermit 
protocol) would argue that C1 controls are also part of "Latin-1" and 
hence this format is still not Latin-1-friendly (a complaint that also 
used to be brought against UTF-8).

> Of course we can't use this for the registry, and we also won't try 
> BOCU-1.  But maybe IANA should offer a gzip-ped version.

BOCU-1 text tends to include a lot of bytes in the C1 range (0x80 
through 0x9F) and might not travel through e-mail very well.  And I 
still haven't received a clear answer about how patent-encumbered BOCU-1 
might be.

I like the gzip idea.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
RFC 4645  *  UTN #14

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru