As you know, all databases' escaping functions have encoding parameter.
PostgreSQL uses encoding parameter stored in db connection structure. This
is the reason why pg_escape_string() has optional database base connection
parameter for escaping.
On the whole any database access I'm doing with Firebird is done using
parameters which are handled in the database connection rather than having
to worry about many of these sorts of 'protections'. The result for me is
that I don't have to worry about many of the problems the more lax handling
of data in MySQL can create. But the more important thing here is that I've
not used a 'locale' other than UTF8 for websites for many years and so the
whole underlying structure needs fixing rather than trying to patch small
areas that are better handled by doing the job correctly in the first place!
We cannot force users to use Unicode for database/file/etc ;)
I'm not proposing use of locale, but new escape API that support multibyte
encoding.
My point Yasuo is that I think the reason this has been rejected is simply because there needs to be a more comprehensive review of how 'multi_byte' characters are handled? There needs to be at least some agreement moving forward if PHP should be made fully UTF-8 complaint or the alternative 'ASCII only' for code, so that perhaps 'mb_' SHOULD be the only way to handle multi byte strings? Short term fixes are just exacerbating the real problem? Also I don't see how the RFC addressed the problem anyway. While I use UTF-8 output exclusively I've not had to resort to mbstring extension to do so yet so would not even use the extra functions in normal production.