<?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>Sun, 19 May 2013 03:06:32 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Ahmed Shreef's Blog: iconv misunderstands UTF-16 strings with no BOM]]></title>
      <guid>http://www.phpdeveloper.org/news/15035</guid>
      <link>http://www.phpdeveloper.org/news/15035</link>
      <description><![CDATA[<p>
<i>Ahmed Shreef</i> has <a href="http://shreef.com/2010/08/iconv-misunderstands-utf-16-strings-with-no-bom/">a recent post</a> to his blog about an issue he had converting UTF-16 strings over to UTF-8 with the <a href="http://php.net/iconv">iconv</a> functionality in PHP. Specifically, he ended up with "rubbish unreadable characters" after the conversion.
</p>
<blockquote>
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.
</blockquote>
<p>
In his example (a basic "Hello World" in Arabic) he notes that there's no <a href="http://en.wikipedia.org/wiki/Byte-order_mark">byte order mark</a> 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.
</p>]]></description>
      <pubDate>Fri, 27 Aug 2010 13:36:56 -0500</pubDate>
    </item>
  </channel>
</rss>
