Geoffrey Sneddon wrote:
>>
>> $str = new String('stuff');
>
> What about character set of the input? That would need a second
> parameter, even if it defaulted to UTF-8.
That could be an option, sure. It's something we might consider adding
a site-wide setting for, so that user-supplied data is assumed to be in
a certain character set without having to specify it everywhere.
I'm throwing out ideas at this point, just as it seems you are here. If
you have a better solution...
> "[I]f present" frightens me. If we just use the native string
> functions we can end up with radically different results. The exact
> behaviour of strtoupper()/strtolower() is undefined, and is noted as
> being locale dependant. This means in some locales bytes above 0x7F
> are upper-/lower-cased. In a locale that uses Windows-1252, on a
> string b"\xC3\xA9" (UTF-8 encoded U+00E9 LATIN SMALL LETTER E WITH
> ACUTE (é)), lowercasing it would result in"\xE3\xA9" (obviously, as a
> lowercase character, it should remain changed), a invalid UTF-8
> sequence.
Just to satisfy my curiosity, and realizing it might not be ultimately
correct, what is the occurrence of the scenario you've described? Does
having this happen 30% of the time? 80%? I mean to ask, with what
frequency do people supply é as data in Windows-1252 that results in an
invalid UTF-8 character sequence?
Sure, some effort should be made to make this work for as much as is
practical, but I'm getting the impression that there are edge cases
where the effort isn't worth the return.
> The basic options are to either require mbstring (whose exact
> behaviour is PHP version dependant (though unlike iconv not C-library
> dependant)), or to implement the exact behaviour in userland PHP. The
> latter is the solution I took for my Unicode class (in fact, it never
> uses mbstring to decode strings so I can make error handling user-
> configurable, as some things require fatal error handling, others rely
> on non-fatal error handling), and only uses native support on PHP 6
> (as this _is_ user-configurable).
Ok, your Unicode class is great. Can we use it in a String class? Or
did you have something else in mind?
Forcing our developers to become intimately familiar with Unicode just
to output some strings is not something I'm interested in. I think if
we can provide a reasonable abstraction that handles many important and
likely cases, then we're doing good, even if it has a few flaws. We can
even attempt to fix them as we progress.
Owen
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/habari-dev
-~----------~----~----~----~------~----~------~--~---
