Dan Sugalski <[EMAIL PROTECTED]> writes: > >Strings can be of three types--binary data, platform native, and UTF-32. >No, we are not messing around with UTF-8 or 16, nor are we messing with >EBCDIC, shift-JIS, or any of that stuff. I don't understand that in the light of supporting "platform native". That could easily be any of those as you note below. So what operations are supported on "platform native" strings? Are we at the mercy of locale's idea of upper/lower case, sort order etc.? >Strings can be stored internally >that way (and the native form might be one of them) but as far as the >interface is concerned we have only three. Yes, this does mean if we mess >with strings in UTF-8 format on a non-UTF-8 system they'll need to be fed >out in UTF-32. It's bigger, but we can deal. -- Nick Ing-Simmons
- Re: standard representations Bradley M. Kuhn
- Re: standard representations Andy Dougherty
- Re: standard representations Jarkko Hietaniemi
- Re: standard representations Dan Sugalski
- licensing issues (was Re: stan... Bradley M. Kuhn
- Re: standard representations Uri Guttman
- Re: standard representations Dan Sugalski
- Re: standard representations Dan Sugalski
- Re: standard representations Peter Buckingham
- Re: standard representations Dan Sugalski
- Re: standard representations Nick Ing-Simmons
- Re: standard representations Dan Sugalski
- Re: standard representations Benjamin Stuhl
- Re: standard representations Dan Sugalski
- Re: standard representations Andy Dougherty
- Re: standard representations Benjamin Stuhl
- Re: standard representations Dan Sugalski
- Re: standard representations Nicholas Clark
- Re: standard representations Nick Ing-Simmons
- Re: standard representations David Mitchell
- Re: standard representations Dan Sugalski