[drupal-devel] PHP string functions overloading for multibyte support

neil at civicspacelabs.org neil at civicspacelabs.org
Wed May 25 19:27:31 UTC 2005


On Wed, May 25, 2005 at 02:22:32PM +0200, Piotr Szotkowski wrote:
> 
> Gabor Hojtsy:
> 
> > Piotr Szotkowski:
> 
> >> What do you think about the whole idea of forcing this overload on
> >> Drupal? Is it feasible and I should pursuit the warning (and any other
> >> that follow), or should I simply drop this idea, as it will break Drupal
> >> and/or any popular modules anyway?
> > 
> > IMHO one should hunt down and fix the empty haystack errors.
> 
> I agree that these warning should be fixed anyway. I'd give them a go
> without any hesitation, but I'd like to know whether Drupal is fully
> UTF-8-aware and whether UTF-8 support is a requirement for the modules -
> i.e., whether my work would be useful in the end.

Drupal works with UTF-8 only. It is a requirement for contributed
modules as well; but, like other contributed module requirements, it is
a loose reequirement as there isn't a formal review process.

> Adding
> 
> php_value mbstring.func_overload 7
> php_value mbstring.internal_encoding UTF-8
> 
> affects everything just for CiviCRM's use, and if it's known that Drupal
> would break (in some non-obvious way, perhaps), or there's a popular
> module that could stop working when we're overloading all of the string
> manipulating functions under its feet then I'd rather concentrate on
> other solutions to my problem...

Since Drupal is meant to run on many platforms we can't depend on the
libraries we want being present. So Drupal has implemented specific
UTF-8 functionality as needed. For example, truncate_utf8() is
implemented using pure PHP and drupal_convert_to_utf8() is implemented
by attempting to use any of the potentially availiable libraries.

-Neil



More information about the drupal-devel mailing list