On 6 Sep 2008, at 16:47, Owen Winkler wrote:
> There was a glitch in the Multibyte class today that got me thinking
> about using a PHP String class again.
Where "String" is Unicode or Binary? I'd rather call it one of those
two to make it clear what it is. I assume the former as the latter
causes no issues on PHP 5 apart from when mbstring.func_overload=1.
> Suppose you have a string 'stuff' that you want apply string
> manipulation functions to. You'd do this to it:
>
> $str = new String('stuff');
What about character set of the input? That would need a second
parameter, even if it defaulted to UTF-8.
> If you wanted to output the all uppercase version of the string, you'd
> do this:
>
> echo $str->toupper();
>
> Similar functions would exist for any of the standard string
> manipulation functions. By using these universally, we would route
> the
> string manipulation entirely through multibye-capable versions (if
> present) of the native string functions.
"[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.
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).
> The String class could also be used for Habari-style format filtering,
> which is something I've been planning for a while.
>
> You may be familiar with Habari's syntax of $post->content_out for
> filtering the content of a post upon output. Using the String class
> would let us make this look a bit more logical:
>
> echo $post->content->out; // for a whole post, autop filtered on out
>
> We could register filters against the String class for specific
> outputs,
> run the internal value of the String through the filter on demand.
>
> An additional bonus might be that we could chain these in the
> execution,
> so you might also be able to do:
>
> echo $post->content->out->more; // for a summary, also autop filtered
>
> How does this idea sound? (That last implementation might be tricky.)
Bear in mind you have to be careful with HTML. E.g., <a
href="foobar">foo</a> != <A HREF="FOOBAR">FOO</A> — they are different
paths. It would really need to be HTML specific.
--
Geoffrey Sneddon
<http://gsnedders.com/>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
