The PatchworkUtf8 class implements the quasi complete set of string functions that need UTF-8 grapheme clusters awareness. These functions are all static methods of the PatchworkUtf8 class. The best way to use them is to add a use PatchworkUtf8 as u; at the beginning of your files, then when UTF-8 awareness is required, prefix by u:: when calling them.

In the README for the tool he talks about the functions included in the current release that match PHP's string functions as well as some additional methods like "isUtf8", "bestFit" and "strtocasefold". It relies on the mbstring, iconv and intl extensions being installed, and if they aren't, it falls back to other functionality (list of those methods included).

While working on an application I ran across a huge bottleneck which I isolated down all the way to the use of the iconv_substr function. If you ever wonder which is better to use, [the benchmark code in the post[ should help your decision.

His results changed quite a bit from machine to machine (and OS/platform to OS/platform) but one statistic stood out on them all - the iconv_substr was slower than mb_substr method....by a lot in one case (about 2100000% slower).

I had a problem last week with converting UTF-16 encoded strings to UTF-8 using PHP's iconv library on a Linux server. my code worked fine on my machine but the same code resulted in a rubbish unreadable characters on our production server.

In his example (a basic "Hello World" in Arabic) he notes that there's no byte order mark on the string and, because of this, the iconv feature tries to guess if it's big-endian or little-endian. This guessing varies from machine to machine resulting in the inconsistencies he saw. The solution is to define the "to" and "from" for the conversion manually rather than letting it just guess.

Ever visited a blog, and noticed that each posting's overview only contained a hundred characters or so, which is then followed by '�'�'�? Ever wondered how to do that yourself? It's not quite as easy as you might think. What if character number 100 occurs in the middle of a word? Do you want to display half of a word on the page? Of course not. In this video tutorial, I'll show you how to compensate for this, as well as a host of other neat little things, like working with MySQL's LEFT() function, using PHP's strrpos, and substr, creating the beginning's of an actual blog, and more.

They show you how to use the MySQL LEFT() function, strrpos and substr to make creating these summary blocks of text simple.

Following up on my previous post about the differences between the mbstring and iconv international characters libraries (which resulted in a tentative conclusion that nobody knew anything about those differences), and particularly the comments by Nicola, we have combined forces (mostly efforts from Nicola, actually) to provide you with a little benchmarking, if that can help you decide.

His code for the test script is included (for you to gather your own results) and a full listing of his results comparing the effects of possible caching, running up to ten executions. You can download the text file that he ran the script on here.

There are thousands of services available on web who are presenting interesting as well as education information which you can really integrate in your web page or make a nice widget and let others use them seamlessly with their content delivery platforms. In this article I am going to show you how you can make a nice Today-in-History widget with the help of the data provided in Scopesys.

He wisely recommends that you check one thing first about the content you're grabbing - the copyright it carries with it. This could get you into big trouble down the line depending on whose content it is. The actual script is pretty simple - he defines some constants as markers for where things start and stop in the HTML and then uses strpos to get the locations for his substr call to grab the segments.

I was wondering today why use mbstring rather than iconv in Dokeos, and honestly I didn't remember exactly why I had chosen mbstring in the past, but finding information about the *differences* between the two. [...] Searching a bit more, I found a PPT presentation from Carlos Hoyos on Google.

Essentially, it boils down to how the library is integrated - mbstring is bundled and iconv is pulled from an external source. So, if you're looking for maximum portability, he recommends mbstring.

PHP scripts are typically stored under UTF-8 encoding to limit i18n headaches, while the console in which their output will be displayed is normally configured to some regional encoding, like IBM850 in Windows/XP French.

So we need a workaround...

He splits the process out into a few steps, each with its own explanation and code:

• Builtin tools
• Buffering
• Flushing
• PHP-GTK is not PHP for the Web
• Auto-flushing

After Rob's idea from yesterday about using XMLReader within XSLT I was wondering, how much of a slowdown calling PHP functions from XSLT is.

I wrote 4 different XSLT templates, which do a simple substring. One with the xslt function "substring", one with just calling the native PHP function "substr" and one with calling a user-defined function (which is also just calling "substr"). I called this 100 times (with one of those great recursive self-calling xslt-templates) and did call the "transformToXML" function a 100 times for each stylesheet. This means, we called the function 10'000 times for each benchmark run.

His bases the results off of a sample with no function call at all and, but running it through 100 times, came up with results that weren't all that surprising. In order of speed, the ranking (shortest time first) was: no call, xslt only, php native, and php userland. Using the PHP functions from inside of XSLT made the test quite a bit slower, but, as he notes, most users won't be running recursions of 100 each time they run a script.]]> Mon, 27 Mar 2006 06:55:47 -0600 http://www.phpdeveloper.org/news/4622 http://www.phpdeveloper.org/news/4622 Christian Stocker has a quick new post with a solution for those Mac users out there that would like to use the iconv extension with fink.

If you want to get the iconv extension properly running with PHP 5 and fink on OS X, you need the following configure option

--with-iconv=/sw/

and then it should work.

Hope that helps others, too.

And, apparently, it does - given the one comment below it so far that has a positive response... ]]> Fri, 06 Jan 2006 07:23:47 -0600