Re: What "Unicode support" really means
| From: | Lester Caine | Date: | Thu, 06 Mar 2014 09:40:47 +0000 |
| Subject: | Re: What "Unicode support" really means | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-72968@lists.php.net to get a copy of this message | ||
Pierre Joye wrote:
One of the difficult areas in PHP is providing lists sorted in the order the client expects. Locale defines a different 'alphabet' in some cases even for the same language! Switching everything to Unicode eliminates one side of the difficulty since at least all the letters of the alphabet can exist at once and you don't need to know which codeset of 256 characters is being used? I've been 'spoiled' for a long time now since Firebird has always had the ability to handle 'collations' and would return data in the order required. Just select the right 'locale' ... It actually goes a step further since I believe it is the only database which will allow you to index fields on different collations in the same table, so one can quickly switch between different locales without having to close and reopen the database to select a new collation. Displaying a list of array keys 'in order' is one of the key areas that I see as a problem once one switches to fully supporting unicode, and so it's handling this 'locale' based ordering that is a sticking point? Does one limit these functions to an ASCII only collation? If the key names are direct from a database record that may not be so easy if the database is already unicode based? -- 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.ukComing into this 'area' is ordering of strings, which is where a particularlocale becomes important. But just what operations does that actually effect? Is it just a process that comes as part of the display conversion or is it more deeply embedded in the 'core'? Personally I already handle this via the database, since I only want the correct subset of data to display, but that is not a generic solution:( I do not understand the points behind these questions, sorry...