Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

David Sklar:
Fixing Broken UTF-8
Aug 27, 2015 @ 10:48:29

David Sklar has a post to his site showing you how to fix broken UTF-8 characters in content being passed through the normal string functions.

When working on the i18n bits of Learning PHP 7, I had a problem. My example showing how plain string functions such as strtolower() and strtoupper() mangle multibyte UTF-8 characters was making the book formatting/rendering pipeline barf. The processing tools are expecing nicely formatted, valid, UTF-8 encoded HTMLBook files. It didn’t like the mangled invalid UTF-8 characters in my example output.

To fix this, I wrote the following function to replace invalid UTF-8 sequences with the Unicode Replacement Character (U+FFFD).

He includes the code for this method that walks through the string, character by character, and checks the bytes it contains to see how it needs to be translated. There's plenty of comments in it too, explaining what it's doing as it goes along.

tagged: fix broken utf8 character function example unicode replacement

Link: http://www.sklar.com/php/2015/08/25/fixing-broken-utf8/

Three Devs & A Maybe Podcast:
Understanding Character Sets and Encodings
May 14, 2014 @ 13:12:06

The Three Devs & A Maybe podcast (with hosts Michael Budd, Fraser Hart, Lewis Cains and Edd Mann) has posted their latest episode (#24) talking about character sets and encodings.

Having only just recently been bit by the character encoding issue again, we thought it would be a good time to bring it up on the podcast. Starting from the beginning with ASCII, we move on to discuss how 8-bit compatible machines brought way to the ISO-8859-* standards. This leads us on to Unicode, with the goal to develop a single character-set encoding standard that could support all of the world's scripts. Finally, we discuss the de-factor character encoding implementation used on the web today 'UTF-8', and reasons why this is the case.

Lots of different topics are mentioned including reversing a Unicode String in PHP using UTF-16BE/LE, portable UTF-8 and a YouTube video covering Pragmatic Unicode. You can listen to this new episode though the in-page player, by downloading the mp3 or subscribing to their feed.

tagged: threedevsandamaybe podcast ep24 unicode character set encoding utf8

Link: http://threedevsandamaybe.com/posts/understanding-character-sets-and-encodings/

Edd Mann:
Reversing a Unicode String in PHP using UTF-16BE/LE
May 12, 2014 @ 10:55:00

Edd Mann looks at an issue in his latest post that caused him problems in a recent project, reversing a Unicode string with UTF-16BE/LE.

Last week I was bit by the Unicode encoding issue when trying to naively manipulate a user's input using PHP's built-in string functions. PHP simply assumes that all characters are a single byte (octet) and the provided functions use this assumption when processing a string. [...] You should be aware that in 'Western Europe' we commonly only use the basic ASCII character-set (consisting of 7 bytes). This makes the transition to the popular 'UTF-8' Unicode representation almost seamless, as the two map one-to-one. I wish to however, discuss how to reverse a Unicode string (UTF-8) using a combination of endianness magic and the 'strrev' function.

He provides two different approaches to the problem. The first he calls the "naive" approach because it corrupts characters needing more than the two-byte representation. His second solution, the "endianness" method, converts the string to big-endian first (UTF-16) and then back to UTF-8 for more correct handling.

tagged: unicode string utf8 utf16 bigendian endian convert reverse string

Link: http://eddmann.com/posts/reversing-a-unicode-string-in-php-using-utf-16-be-le

SitePoint PHP Blog:
Bringing Unicode to PHP with Portable UTF-8
Sep 10, 2013 @ 11:19:05

On the SitePoint PHP blog there's a new tutorial showing you how to bring portable UT-8 support to PHP with the Portable-UTF8 library. UTF-8 handling has long been one thing desired in the core of PHP, but hasn't been introduced quite yet.

PHP’s lack of Unicode/multibyte support means that the standard string handling functions treat strings as a sequence of single-byte characters. In fact, the official manual defines a string in PHP as a “series of characters, where a character is the same as a byte.” PHP supports only 8-bit characters, while Unicode (and many other character sets) may require more than one byte to represent a character. This limitation of PHP affects almost all aspects of string manipulation, including (but not limited to) substring extraction, determining string lengths, string splitting, shuffling etc.

The article mentions some of the efforts in the past that have been made to try to introduce this functionality into the core, but was shelved at the time. Instead of waiting on this feature to be introduced, they show you how to use the library to do things like check for UTF-8 strings, "cleaning" the UTF-8 strings and do some validation on the string's contents.

tagged: unicode portable utf8 library tutorial

Link: http://www.sitepoint.com/bringing-unicode-to-php-with-portable-utf8/

Reddit.com:
Let's talk Character Encoding
Mar 15, 2012 @ 11:07:07

On Reddit.com there's a recent post with a growing discussion about character encodings in PHP applications (with some various recommendations).

I would rather not have to convert these weird characters to the HTML character entities, if possible. I'd rather be able to use these characters directly on the web page. If this is for some reason a bad idea, let me know. This might be more of a general web design question (i already posted it there), but I figured it is still appropriate to post here as well since PHP is used to pull an entry from the database, and I figured a lot of you here would know the answer to the question.

The general consensus is to use UTF8 in this case, but there's a few reminders for the poster too:

  • Don't forget to make the database UTF8 too
  • Be sure you're sending the right Content-Type for the UTF8 data
  • an link to an article about what "developers must know about unicode/charactersets"
tagged: character encoding advice reddit utf8 contenttype unicode

Link:

Nikita Popov's Blog:
htmlspecialchars() improvements in PHP 5.4
Jan 30, 2012 @ 09:55:24

In this new post to his blog Nikita Popov looks at an update that might have gotten lost in the shuffle of new features coming in PHP 5.4 - some updates to htmlspecialchars.

One set of changes that I think is particularly important was largely overlooked: For PHP 5.4 cataphract (Artefacto on StackOverflow) heroically rewrote large parts of htmlspecialchars thus fixing various quirks and adding some really nice new features. Here a quick summary of the most important changes: UTF-8 as the default charset, improved error handling (ENT_SUBSTITUTE) and Doctype handling (ENT_HTML401,...).

He goes into each of these three main features in a bit more detail, providing code to illustrate the improved error handling and the new flags for Doctype handling (covering HTML 4.01, HTML 5, XML 1 and XHTML).

tagged: htmlspecialchars improvement release doctype error utf8

Link:

Project:
Patchwork-UTF8 - UTF8 Support for PHP
Jan 27, 2012 @ 11:38:40

Nicolas Grekas has shared another tool that he's pulled out of his "Patchwork" framework to make it a stand-alone tool: the Patchwork-UTF8 helper that provides matching functions to those PHP already has for regular strings, but a little smarter to work with UTF8 correctly.

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).

tagged: utf8 support string patchwork framework helper mbstring iconv intl

Link:

Ahmed Shreef's Blog:
iconv misunderstands UTF-16 strings with no BOM
Aug 27, 2010 @ 13:36:56

Ahmed Shreef has a recent post to his blog about an issue he had converting UTF-16 strings over to UTF-8 with the iconv functionality in PHP. Specifically, he ended up with "rubbish unreadable characters" after the conversion.

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.

tagged: byteordermark bom iconv utf16 utf8 convert

Link:

Danne Lundqvist's Blog:
Detecting UTF BOM - byte order mark
Apr 29, 2010 @ 11:47:03

In a new post to his blog Danne Lundqvist looks at a common pitfall that could trip you up if you're not careful with your UTF-8 data - not looking for the UTF byte order mark that tells the application if it needs to be handled as UTF content.

One such thing is the occurrence of the UTF byte order mark, or BOM. [...] For UTF-8, especially on Windows, it has become more and more common to use it to indicate that the file is indeed UTF. Most text editors handle this well and you won’t ever see these bytes. As it should be.

He points out what could cause an issue - using strcmp or substr but it can be prevented by looking at and removing those first three bytes if needed. He includes a snippet of code that does just that.

tagged: byteordermark utf utf8 utf16 detect

Link:

Evert Pot's Blog:
basename() is locale-aware
Mar 30, 2010 @ 12:04:35

Evert Pot found out an interesting thing about the basename function in PHP - it's more than just a handy shortcut for paths, it's also locale aware.

It turns out basename does a bit more than just splicing the string at the last slash, because it's locale aware. In my case I was dealing with a multi-byte UTF-8 string. It took me quite some time figuring out what was going on, because I was testing from the console which had the en_US.UTF-8 locale, and the bug was appearing on Apache, which defaults to the C locale.

He includes an example snippet of code showing how it can work with both the default (well, for Apache anyway) of the "C" locale versus the "UTF-8" locale and return different results for the same urldecoded information.

tagged: basename locale utf8 urldecode

Link: