It’s not that fast because of extensive JavaScript usage, but it is exactly the thing I want. I have asked myself many times, why we developers do not use the current state of web technology for our own tools. Try it!

I am wondering whether there is a good consultant/consultant team in Germany which is specialized on attending an enlargement of a currently running, profitable PHP/MySQL-environment with tons of users. I am looking for something like OmniTI in Germany. No babbling, proofed success in the past, able to work with hitherto unknown components.

During my daily work I often heard discussions about how to handle charset properly. What a server must provide to handle charsets correctly, which configuration for Apache is needed, what options must be set in php.ini to make PHP correctly working, which functions should be avoided when using PHP, which locales must be used and so on. So I want to give a short overview how to sail around common problems in a LAMP-setup.

Kernel

Just to make sure the option CONFIG_NLS_UTF8 is set to y.

Environment

To make sure, newly created filenames are there in UTF-8 and in general VT-input is handled correctly, you have to choose a charset, which comes with an .UTF-8-suffix. For german feel free to choose de_DE.UTF-8. Make sure your glibc is provides this locales. To convert current names of files you can just use convmv. For a desktop you must also adjust the font and set a correct TTY-font but this could be ignored for a server which is just administrated via remote shell.

Webservers in general – focus on Apache

To make sure, the users input is UTF-8, the server has to deliver the correct Content-Type-header. Take a look at the output of wget -S http://usrportage.de, my weblog, which is hosted on Schokokeks.org, a properly configured server (sure!):

wget -S usrportage.de

—21:00:33—  http://usrportage.de/
           => `index.html’

Resolving usrportage.de… 87.106.4.7

Connecting to usrportage.de|87.106.4.7|:80… connected.

HTTP request sent, awaiting response…
  HTTP/1.1 200 OK
  Date: Thu, 13 Jul 2006 19:00:27 GMT
  Server: Apache
  X-Powered-By: PHP/5.1.4-pl0-gentoo with Hardening-Patch
  X-Blog: Serendipity
  Set-Cookie: PHPSESSID=9da2ded6522851ef8ddc3ebe7590b354; path=/
  Expires: Thu, 19 Nov 1981 08:52:00 GMT
  Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
  Pragma: no-cache
  X-Serendipity-InterfaceLang: de
  X-FreeTag-Count: Array
  Connection: close
  Content-Type: text/html; charset=UTF-8

Length: unspecified [text/html]


    [  <=>                                                              ] 65,557       250.71K/s

	
21:00:33 (250.19 KB/s) – `index.html’ saved [65557]

You see the header Content-Type: text/html; charset=UTF-8. (You can also the a bug in S9Y, which poorly casts an array, but anyway.) So your browser is notified, that it should send UTF-8 encoded data. That’s the whole secret. To configure Apache properly, make sure the directive AddDefaultCharset is set to UTF-8.

One thing at last: if you’re using AJAX-functions from Prototype for JavaScript-purposes, you have to reencode the string delivered by the AJAX-call. In PHP the following would work:

$string = utf8_encode( $_POST[‘key’] );

MySQL

Before transacting any data, make sure your connection charset is set to UTF-8:

SET NAMES utf8;

By the way: have I ever mentioned you should ever use mysql_real_escape_string() instead of mysql_escape_string()?

PHP

Just two rules: use mb_string-functions whereever it is possible, set the INI-setting default_charset to UTF-8 and – anyway – don’t use functions from the ereg-family also they have an mb_-Prefix. They aren’t binary-safe, that’s all you need to know.
Also make sure, your sources are UTF-8 encoded. Use iconv to correct those who are not.

Update

I forgot to mention, that the functions htmlentities(), html_entity_decode() and htmlspecialchars() does not reflect PHPs default_charset-directive but assumes iso-8859-15 as the default charset, which is pretty annoying and should be considered as a bug, from my point of view. So you need to pass UTF-8 as the third parameter to the function to make sure it will work properly with Unicode.

Assume I have the following stored procedure:

CREATE PROCEDURE addToList(IN string VARCHAR(128), IN tbl VARCHAR(128))
BEGIN
    DECLARE query TEXT;
    SET query = REPLACE( 'INSERT INTO __table__ SET string = ?', '__table__', tbl );
    PREPARE stmt FROM query;
    SET string = string;
    EXECUTE stmt USING string;
END;

This will sadly not work, because it is not possible to prepare a query from a variable. A workaround is to write an endless long CASE-construct, which is not elegant and not flexible. Do you have any idea how to solve this problem?

Falls mir jemand einen Gefallen tun möchte. Über dieses Buch würde ich mich sehr freuen.

Sometimes I feel like being one of the little who like PHP. But, one things which brings me to hell currently is the mysqli-extension. Not that it is not easy to use, there is one strange thing I’m fucked up with. If I read an Image-file via file_get_contents() and want to write it to a database, It’s sensible to use a BLOB-field. So far so fine. I guessed I have to do it this way:

$image_data = file_get_contents( "my_image.png" );
$database = new mysqli( "host", "user", "password" );
$database->select_db( "my_db" );
if( $statement = $database->prepare( "INSERT INTO my_table SET my_blob = ?" ) ) {
   <strong>$statement->bind_param( "b", $image_data );</strong>
   $statement->execute();
} else {
etc.

The important line is marked bold. It assignes my binary data as a BLOB to the placeholder »?« in mysqli::prepare(). So I guessed nothing wrong with it. But it seems to be wrong. If I use $statement->bind_param( "s", $image_data);, which means passing the value as a string, it works as expected. Is this a bug or can someone explain this strange behaviour to me?


Update
I embarrass myself in my bugtracker entry as too lazy to read the entire documentation. This example cleared things up.

I’m proud to provide a new Ejabberd-ebuild to our users. Ejabberd 1.1.1 comes with an important new feature: it supports MySQL natively. I fixed up PostgreSQL-issues in the ebuild and provide now the native drivers for MySQL and PostgreSQL Also I’m happy to mention that NU2M, the company which is involved in Mabber and for which I’m currently working for, is going to release some really interesting Jabber-components, especially for Ejabberd, during the next weeks.

Links

• BreakMyGentoo page
• BreakMyGentoo repository