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"

SitePoint's PHPMaster.com site has a new tutorial today from Timothy Boronczky about handling file uploads in PHP. It's a pretty low-level introduction and is perfect for those new to PHP.

What do pictures in an online photo album, email attachments in a web-based mail client, and data files submitted to an online application for batch processing all have in common? They all rely on the ability to upload files across the Internet from the user’s web browser. Indeed, uploading files is an important feature of many of the sites and web-based applications we use on a daily basis. In this post, I show you how to add support for file uploads to your site using PHP.

He starts with the changes you might need to make to your php.ini configuration file (for allowing uploads and setting a temporary directory) and a basic "form" tag with the necessary "enctype" setting. The sample form includes a "file" type field that submits the file data to a waiting PHP script on the backend. The script looks for the submit (in the $_FILES superglobal) and, after doing some filtering on the name and content type, moves it to a new directory.

Continuing on from his previous articles on working with REST in Zend Framework applications (and making the endpoints for a web service) Matthew Weier O'Phinney has a new tutorial with the next logical step in the series, automatically responding to different content types in your application based on the content-type the client sends.

There's no reason you can't re-use your RESTful web service to support multiple formats. Zend Framework and PHP have plenty of tools to assist you in responding to different format requests, so don't limit yourself. With a small amount of work, you can make your controllers format agnostic, and ensure that you respond appropriately to different requests.

He talks about concerns you'll have to worry about when developing your service - grabbing teh raw input instead of the POST values (since most requests will be rawly POSTed) and what to pass that message to to decode it properly. In his example the Zend_Json and Zend_Config_Xml components make it simpler to handle the info and some code to get the results back into your script.

There's also some code for the other side of things - building the response and pushing it out to the correct views depending on the request content type, action and information.

With the recent stir caused by the new iPhone, it's only natural that developers are looking for easy ways to make their sites as compatible as possible with the mobile platform. The Symfony project has posted a guide to helping you make your apps optimized for mobile use.

symfony 1.1 introduces native support for different formats and mime-types. This means that the same model and controller can have different templates based on the requested format. The default format is still HTML but symfony supports several other formats out of the box as defined in the factories.yml file.

Using this system, it's easy to add new output formats by adding to the default layouts the framework comes equipped with. The Content-Type can be changed and layouts can be disabled as needed. This lets you make a custom definition just for use with the iPhone without a lot of hassle.

They also include an example of how to make one of these optimized layouts, including some iPhone "screenshots" of the resulting pages.

Matthew Turland has come across an "interesting bug" in PHP's stream wrappers functionality - some strange 404 or 500 HTTP errors in one of his scripts.

I wrote a small script a while back that's gained a surprising amount of popularity thanks to a plug from the site that it posts to. [...] I learned that this [connection from the script] could be done with streams, I attempted to implement it in that fashion, but ran into strange issues where I would get 404 or 500-level HTTP errors rather than the response I was expected.

He eventually found the bug related to his problem (in the 5.2.x branch) but happily notes that it has been corrected and will be patched in the upcoming 5.3 (and 6) branches.