Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>A few years ago I moved our in-house mod_perl platform (~35k LOC) to UTF-8. Here are the things which we had to consider/change:</p> <ul> <li>despite the perl doc advice of 'only where necessary', go for using 'use utf8;' in every source file - it gives you consistency.</li> <li>convert your database to UTF-8 and ensure your DB config sets the connection charset to UTF-8 (in MySQL, watch out for field length issues with VARCHARs when doing this)</li> <li>use a recent version of DBI - older versions don't correctly set the utf8 flag on returned scalars</li> <li>use the Encode module, avoid using perl's built in utf8 functions unless you know exactly what data you're dealing with</li> <li>when reading UTF-8 files, specify the layer - <code>open($fh,"&lt;:utf8",$filename)</code></li> <li>on a RedHat-style OS (even 2008 releases) the included libraries won't like reading XML files stored in utf8 scalars - upgrade perl or just use the <code>:raw</code> layer</li> <li>in older perls (even 5.8.x versions) some older string functions can be unpredictable - eg. <code>$b=substr(lc($utf8string),0,2048)</code> fails randomly but <code>$a=lc($utf8string);$b=substr($a,0,2048)</code> works!</li> <li>remember to convert your input - eg. in a web app, incoming form data may need decoding</li> <li>ensure all dev staff know which way around the terms encode/decode are - a 'utf8 string' in perl is in /de/-coded form, a raw byte string containg utf8 data is /en/-coded</li> <li>handle your URLs properly - /en/-code a utf8 string into bytes and then do the %xx encoding to produce the ASCII form of the URL, and /de/-code it when reading it from mod_perl (eg. <code>$uri=utf_decode($r-&gt;uri())</code>)</li> <li>one more for web apps, remember the charset in the HTTP header overrides the charset specified with <code>&lt;meta&gt;</code></li> <li>I'm sure this one goes without saying - if you do any byte operations (eg. packet data, bitwise operations, even an MIME Content-Length header) make sure you're calculating with bytes and not chars</li> <li>make sure your developers know how to ensure their text editors are set to UTF-8 even if there's no BOM on a given file</li> <li>remember to ensure your revision control system (for google's benefit - subversion/svn) will correctly handle the files</li> <li>where possible, stick to ASCII for filenames and variable names - this avoids portability issues when moving code around or using different dev tools</li> </ul> <p>One more - this is the golden rule - <strong>don't just hack til it works, make sure you fully understand what's happening in a given en/decoding situation!</strong></p> <p>I'm sure you already had most of these sorted out but hopefully all that helps someone out there avoid the many hours debugging which we went through.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload