Re: What "Unicode support" really means

Stas Malyshev wrote:

difficult. Like you Stas I can get away with 'English' names, but the major

problem I am seeing is not so much Function names, but simply keys in arrays. If one is working with current versions of databases that ARE using unicode for field names, then the key names for associative arrays need to handle unicode! Not really. As long as you don't mess with what DB returns, there's nothing to "handle". How often you need to transform the column name from the DB (beyond maybe simple concatenation to make foo.bar or foo.bar)? Practically never. However, DB returns are data, not identifiers. There's some confusion between them (i.e., some API may use $foo->bar to access column "bar") but this can be resolved by always providing data APIs that do not require full unicode in identifiers.

Associative data returned by modern databases provide unicode field names for the columns and even for tables. Trying to stop this progress in the database side by refusing to accept these names is not acceptable, so there would have to be some method of mapping the unicode names to something PHP can use internally? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk