James Cohen has a recent post to his blog looking at a way you can avoid some of the character encoding problems in PHP that can come with working with multiple character sets.

Character sets can be confusing at the best of times. This post aims to explain the potential problems and suggest solutions. Although this is applied to PHP and a typical LAMP stack you can apply the same principles to any multi-tier stack.

He includes a "boring history" session (and recommends skipping if you just want the good stuff) that talks a bit about character sets and their history in computer system handling. All that said, he recommends using UTF-8 to ease your character encoding woes. He talks about configuring your editor to support it, making sure your browsers understand it and setting up your MySQL database connection to use it.

On WebReference.com there's a new tutorial posted about localizing your website by defining a character set to use for your content.

The process of making your applications/websites usable in many different locales is called internationalization, While customizing your code for different locales is called localization. Localization is the process of making your applications or websites local to where it is being viewed. For example, you can make a website more local to a particular place by converting its text to the predominate language of that location and by displaying the local time (e.g. German for people living in Germany or French for people living in France).

They show how to define constants that can be used in your application for the character set and language encoding. They use two major encodings - UTF-8 and ISO-8859-1 - in their examples of showing a sample "welcome" message in different languages. There's also a simple page to show you how to switch between languages if you'd like to give your visitors the option.

Kevin Schroeder has posted another excerpt from his "You Want to Do WHAT with PHP?" book to his blog today. This time it's from the third chapter that looks at character encodings like UTF-8 or ISO-8859-1.

I realized that while this 3.5-year PHP consultant knew Unicode, UTF-8, character encodings such as ISO-8859-1 or ISO-8859-7, I didn't understand them as well as I thought I had. With that I threw this chapter in the book. Knowing about character encoding is what many developers have. Not as many truly understand it. In this chapter I try to de-mystify character encoding as a whole.

The excerpt introduces character encoding and what it really is - a translation for the computer to be able to handle the human language. The problem comes in when multiple tools try to define the same sort of letters/chatacters in different ways. He gives an example of a "hello world" string in a normal ASCII format versus one from the EBCDIC format and how it would be rendered by an ASCII-understanding browser.

Sometimes getting back to the basics is a good thing. Alan Skorkin has done just that in his latest post looking at the basics of URLs including their structure and what characters are allowed (or are special).

Several people made a valid point in response to that post [about fundamentals in software development], in that it is often difficult to know what the fundamentals actually are (be they macro or micro level). So, I thought it would be a good idea to do an ongoing series of posts on some of the things that I consider to be fundamental - this post is the first installment.

He defines the structure of a URL (the scheme, host, port, etc), reserved characters and absolute versus relative URLs and how they're usually used.

Alan Skorkin has a recent post to his blog about a trouble that many WordPress users have come across in working with their content and the WP-Syntax plugin (for displaying code) - a special character escaping bug that escapes characters that don't need it.

Suffice to say, [WP-Syntax] does the job fine except for one very annoying issue. Whenever you have any kind of special characters in your code (which you inevitably do e.g. <, >, & etc.), these always render as their escaped representations.

It only happens with the WYSIWYG editor for writing content (which the tool's FAQ recommends turning off) but there's a better solution that Alan found - change a line of code in the plugin to use the htmlspecialchars_decode function to rid your install of this pesky escaping bug.

Evert Pot came across something strange in an application he was working with - the incorrect decoding of data coming back from an Ajax call POSTed back into the app.

Basically, data is coming into our PHP application through a Javascript's XMLHttpRequest (ajax). [...] Normally everything in the $_POST and $_GET arrays is already decoded, so when you're dealing with these arrays you don't really have to think about this. This time however, I was dealing with some non-latin unicode characters and for some reason they were never decoded and ended up in the database as raw url-encoded strings.

The issue was caused by the fact that the non-latin characters were handled differently on the byte level and that, because of the choice PHP makes on which of the unicode characters to use for spaces, he found that there were two options for handling strings - escape() and encodeURI().

On the Zend Developer Zone today Alexander Veremyev shares some helpful hints he discovered about the DOM XML extension for PHP that could come in handy when working with different character encodings.

I recently worked with PHP's DOM XML extension while working on Zend Framework's Zend_Search_Lucene HTML highlighting capabilities, and uncovered some undocumented features and issues with the extension in regards to character encoding. The information contained in this article should also apply to other libxml-based DOM implementations, as PHP's DOM extension simply wraps that library.

There's five different tips he shares:

• Internal document encoding is always UTF-8
• Input data is always treated as UTF-8
• Text nodes and CDATA are stored as UTF-8 without transformations
• Document encoding does not affect loading behavior
• Save/dumping operations and encoding

He describes each of the points and includes some sample code and XML to parse to help illustrate each.

PHPBuilder.com has the latest in their series looking at beginner level PHP and some of the core concepts that go with it ("The ABC's of PHP"). This latest tutorial looks at string and text handling.

In the last part of this series we looked at what a variable was in general. Today we'll be covering strings and text. We'll look at the contents those variables would typically hold.

Topics include the differences between single and double quotes, appending to a string and special characters (like line feeds and tabs). Code snippets are provided for each to help you visualize what they mean.

Rob Allen had a problem - he needed to get the "pound" (as in the British monetary unit) into his MySQL database. His database didn't seem to want to comply:

Everyone else probably already knows this stuff, but I hit an issue today to that took a while to sort out. Fortunately, some kind folks on IRC helped me, but as it's embarrassing to ask for help on the same issue twice, I'm writing down what I've learned! The problem: Get a £ character stored to MySQL, retrieved and then displayed without any weird characters in front of it using UTF8.

His solution? Make sure you're using UTF-8 everywhere, not just when trying to insert into the database - in the broser's headers (both going in and coming out) and in the MySQL database insert. He gives code examples for each including database examples for PDO and the Zend_Db component of the Zend Framework.

In the spirit of making the most out of the room you have Fererico Cargnelutti has pointed out a framework in a tweet (on Twitter) with some of the new PHP 5.3 additions - Twitto.

Twitto is the smallest and fastest PHP Web framework, and the first one to use the newest features of PHP 5.3. Packed in less than 140 characters, it fits in a tweet! Despite its size, Twitto is bundled with a default controller, is E_STRICT compliant, and generates an error if you try to access a controller that does not exist.

It was developed by Fabien Potencier (of symfony framework fame) as a part of the 140 Characters Webapp Challenge