Re: What "Unicode support" really means

On Sun, Mar 9, 2014 at 11:44 PM, Lester Caine <lester@lsces.co.uk> wrote: > I don't think those two necessarily go together. Personally I think that > making everything case sensitive is the first step to allowing Unicode > identifier names. Then it is easy to say that names simply match so that > 'normalization' is not a problem either! Just make strings with any > different set of bytes a different string. I'm totally not in favor of allowing Unicode identifiers and I see little gain in case sensitive names, it brings very little gains. >> That said, mbstring is not a good solution for handling variable content.. >> PHP >> needs to have proper Unicode support that doesn’t cause confusion and that >> allows people to write modern web apps that can handle Unicode text >> properly, >> without too much difficulty. At present we have a standard library of >> string >> functions which don’t necessarily work correctly with Unicode text. This >> has to >> change. > > > Yep - personally I don't use mbstring despite all web pages being UTF-8 and > have been or many years. I use the database to handle the difficult stuff > and then just pump 'clean' unicode down the pipe. > > The problem I am trying to untangle is the simple fact that database field > names are now unicode, and I need to disbale anything that tries to use them > for 'magic' purposes in PHP, I do not know any databases not supporting the "as" keyword in one way or another. But even then, it is not really a PHP problem. Even ORM can solve this relatively easily using the right conversions. > which is difficult since all the data is > returned as associative strings, and switching to numeric returns simply > pushes the problem elsewhere :( Also, while the database part of the Unicode support is important, we still did not solve the core problems... Cheers, Pierre