User: Password:
|
|
Subscribe / Log in / New account

internationalisation

internationalisation

Posted Jun 2, 2006 2:33 UTC (Fri) by xoddam (subscriber, #2322)
In reply to: SQL injection vulnerabilities in PostgreSQL by dlang
Parent article: SQL injection vulnerabilities in PostgreSQL

> frankly I want software that doesn't require i18n to be turned on.

If the software supports internationalisation at all, then 'just ASCII
thanks' is one particular localisation, and there's nothing to switch
off. A little extra optimisation for this case wouldn't be a bad idea
though.

> processing multi-byte characters is slower then processing
> single byte characters (for a number of reasons).

UTF8 helps with this as long as the vast majority of your characters are
in the ASCII range. But UTF8 has its own minor performance headaches,
particularly in Eastern Asian locales where a 16-bit character is much
more convenient.

A significant annoyance and performance issue is when such things as
font-measuring have per-character primitive methods that take a UCS32
parameter, and the string must be expanded repeatedly to its individual
characters (or cached as an array of 32-bit values). Bringing the whole
UTF (8 or 16) string right down to the lowest level might eliminate some
of that overhead.

> that's why the world survived with ascii for so long

The world? For 'so long'? For how long exactly was the *American*
Standard the sole character set encoding in *any* non-English-language
environment? The earliest Japanese derivatives of ASCII began to be
*standardised* in 1969 (JIS C 6220), while the US computing community was
still worrying about converting between ASCII and ECBDIC.


(Log in to post comments)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds