On PHPMaster.com today David Shirey has a written up a new tutorial introducing the ctype functions in PHP. This set of functions provides a handy way to more correctly check values to ensure they're valid (and contain what they should).

If you have a background in C, then you're probably already familiar with the character type functions because that is where they come from (don't forget that PHP is actually written in C). But if you're into Python, then it's only fair to point out that the PHP Ctype functions have absolutely nothing to do with the Python's ctypes library. It's just one of those tragic and totally unavoidable naming similarities.

He briefly explains how the functions work and at least one "gotcha" to watch out for if you're using them for input validation. He then goes through the list of the eleven ctype functions and briefly describes what they do. Some example code is also included showing how you can use them to validate a value based on the true/false return from the function call.

Gareth Heyes has another post to his site on the topic of "non-alpha PHP code", this time getting a bit more into the process and how his examples are parsed by PHP into more familiar functionality.

My first post on PHP non-alpha numeric code was a bit brief, in the excitement of the discovery I failed to detail in depth the process. I've decided to follow up with a tutorial and hopefully explain the process better for anyone wanting to learn or improve the technique. The basis of PHP non-alphanumeric code is to take advantage of the fact that PHP automatically converts Arrays into a string "Array" when using in a string context.

He includes some basic examples showing how, with just a combination of things like "+", "_" and "[" or "]" you can reproduce similar output to echoing out an array and use that "Array" output string to get to other strings (like the letter "B"). There's also a more lengthy example showing how to build up the string "print 1+1" and have it execute using this technique.

On the Refulz.com site they've posted the first part of a series about the basics of using special characters regular expressions (both in PHP and outside of it).

With this post, we continue to explore the Regular expressions. The first post of the Learning Regular Expression series introduced Regular Expressions. The first post covers the regular expression delimiters and the "i" pattern modifier. In the language of regular expression, there is a special meaning of certain characters.

In this article they show the use of characters like the caret, asterisk, dot and dollar symbol to modify your expressions to handle special cases, matching for more than one character and the start and end of strings.

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"

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