<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Fri, 09 Jan 2009 22:37:38 -0600</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[SitePoint PHP Blog: Character Encoding: Issues with Cultural Integration]]></title>
      <guid>http://www.phpdeveloper.org/news/10999</guid>
      <link>http://www.phpdeveloper.org/news/10999</link>
      <description><![CDATA[<p>
On the SitePoint PHP Blog <i>Troels Knak-Nielsen</i> points out some <a href="http://www.sitepoint.com/blogs/2008/09/10/issues-with-cultural-integration/">"cultural integration issues"</a> he's seen when it comes to character encoding in his PHP applications.
</p>
<blockquote>
The gold standard solution is to convert everything to utf-8. Since utf-8 covers the entire <a href="http://www.unicode.org/standard/WhatIsUnicode.html">unicode</a> range, it is capable of representing any character that latin1 can. Unfortunately, that's a lot easier to do from the outset, than with a big, running application. And even then, there may be third party code and extensions, which assume latin1. I'd much rather continue with latin1 being the default, and only jump through hoops at the few places where I actually need full utf-8 capacity.
</blockquote>
<p>
He came up with a (relatively) simple solution - keep the information encoded in the latin1 he already has but serve up the pages with a utf-8 format, embedding utf-8 inside the latin1 when needed. He gives the code for both, making use of output buffering and the utf8 encoding functions to make it all work.
</p>]]></description>
      <pubDate>Wed, 10 Sep 2008 12:07:06 -0500</pubDate>
    </item>
  </channel>
</rss>
