Brian Swan has posted another in his series looking at connection options for the SQL Server driver for PHP. In his latest he looks at the "CharacterSet" setting, an easy way to define which encoding the remote database is using.

One thing that helped me understand the CharacterSet option was to realize that its name is a bit misleading (although it seems to be inline with other uses of CharacterSet or charset). It is used to specify the encoding of data that is being sent to the server, not the character set. With that in mind, the possible values for the option begin to make sense: SQLSRV_ENC_CHAR, SQLSRV_ENC_BINARY, and UTF-8.

He looks at each of these three options in more detail - SQLSRV_ENC_CHAR being the default, SQLSRV_ENC_BINARY when binary data is needed and UTF-8 when, obviously, you need UTF-8 data transfer between the client and server.

In this recent post to his blog Padraic Brady looks at the Zend Framework security releases that were made the other day - versions 1.9.7, 1.8.5 and 1.7.9 - to correct a number of security issues in each release. For those that are curious, you can find the full list of fixes here.

While an ongoing process, the initial [security] review focused on specific areas most likely to deal directly or indirectly with user input and the output of user sourced data. [...] The review also included an examination of all new components due to enter service with Zend Framework 1.10. This yielded a number of issues whose fixes will preempt their release into a stable version, and have been reported to the relevant lead developers.

Padraic mentions some of the things that were found and corrected in these security releases including the enforcement of a default character set throughout the framework (with new functions to help with keeping your data consistent) and several potential XSS vulnerabilities in components like the Zend_Json, Zend_Dojo_View_Helper_Editor and Zend_Filter_StripTags.

Kore Nordmann has published a new FAQ on some common questions he gets about character sets and content encoding.

After lots of questions recently on IRC about charsets and encodings, I decided to write up a FAQ about this. The FAQ can now be found in the article section of my website.

Questions answered include "What is the difference between unicode and UTF-8/UTF-16/...?" and "What does "multibyte charset/encoding" mean?" as well as topics like transliteration and character set support in PHP.

Nessa has posted a quick way to convert a database from whatever character set it's currently on over to UTF-8 with a handy PHP script.

When you're dealing with special characters in a database, you have to make sure that the charset and collation are dumped *with* the database, so that when you move it to another server the tables and data create properly. The biggest annoyance so far is converting tables back to UTF-8, as when this is done through the MySQL shell or phpmyadmin is had to be done table-by-table.

The script logs into the database and pulls all of the table information out (could be a lengthy list depending on the database) and runs an ALTER TABLE to change its character set to 'UTF8'.

Nessa has posted a quick way to convert a database from whatever character set it's currently on over to UTF-8 with a handy PHP script.

When you're dealing with special characters in a database, you have to make sure that the charset and collation are dumped *with* the database, so that when you move it to another server the tables and data create properly. The biggest annoyance so far is converting tables back to UTF-8, as when this is done through the MySQL shell or phpmyadmin is had to be done table-by-table.

The script logs into the database and pulls all of the table information out (could be a lengthy list depending on the database) and runs an ALTER TABLE to change its character set to 'UTF8'.

As mentioned by Ben Ramsey today, Maggie Nelson bumped into an issue in one of her applications with character sets and the incorrect storage/retrieval of information:

Even Oracle, which usually gets storing of data right on the money has had issues with character sets. [...] Needless to say, even when you *know* you set up your database correctly for supporting UTF8, the path to debug issues may be frustrating and full of red herrings.

She mentions the setup the application is using (NLS_CHARACTERSET AL32UTF8, NLS_NCHAR_CHARACTERSET AL16UTF16) but something wasn't right. The problem popped up when they tried to store Chinese characters into the database with the result of invalid data on a select.

After following several different leads, they finally came upon the culprit - the Apache process didn't have the access it needed to a directory in the ORACLE_HOME. In the end, it all only broke down into three easy steps to fix a very frustrating issue.

As mentioned by Ben Ramsey today, Maggie Nelson bumped into an issue in one of her applications with character sets and the incorrect storage/retrieval of information:

Even Oracle, which usually gets storing of data right on the money has had issues with character sets. [...] Needless to say, even when you *know* you set up your database correctly for supporting UTF8, the path to debug issues may be frustrating and full of red herrings.

She mentions the setup the application is using (NLS_CHARACTERSET AL32UTF8, NLS_NCHAR_CHARACTERSET AL16UTF16) but something wasn't right. The problem popped up when they tried to store Chinese characters into the database with the result of invalid data on a select.

After following several different leads, they finally came upon the culprit - the Apache process didn't have the access it needed to a directory in the ORACLE_HOME. In the end, it all only broke down into three easy steps to fix a very frustrating issue.

In a new post to his Oracle blog today, Christopher Jones has a handy tip to help you speed up your Oracle-using PHP scripts by as much as few seconds. The tip originally comes from Krishna Mohan.

What Krishna pointed out was that specifying the client character set name as the optional fourth parameter to oci_pconnect() has a postive effect on performance. If you let the value default then PHP has to invoke code to determine what the client character set should be. This lookup may involve a potentially expensive environment check.

So, a speed increase might be as easy as adding another parameter to your scripts. Christopher includes an example to show where the value goes (in an oci_pconnect call).

Testing with the database and PHP both on my little old machine I was getting figures like 0.6 vs 2.7 seconds for 50,000 pconnect calls in the one script. I saw some other results that showed only a three-times difference.

In a new post to his Oracle blog today, Christopher Jones has a handy tip to help you speed up your Oracle-using PHP scripts by as much as few seconds. The tip originally comes from Krishna Mohan.

What Krishna pointed out was that specifying the client character set name as the optional fourth parameter to oci_pconnect() has a postive effect on performance. If you let the value default then PHP has to invoke code to determine what the client character set should be. This lookup may involve a potentially expensive environment check.

So, a speed increase might be as easy as adding another parameter to your scripts. Christopher includes an example to show where the value goes (in an oci_pconnect call).

Testing with the database and PHP both on my little old machine I was getting figures like 0.6 vs 2.7 seconds for 50,000 pconnect calls in the one script. I saw some other results that showed only a three-times difference.

On his blog today, Lorenzo Alberton Talks about DBMS and the character sets they support and issues a call for help for anyone interested to help them (on the PEAR::MDB2 project) set up proper character set support for each database.

We're working on PEAR::MDB2 charset and collation support. That means that we're in the process of figuring out what's the best way to set the charset in each DBMS, and how to make it portable and consistent through all of them.

I'll try to explain how the various DBMS implement charset settings first, then describe the MDB2 status-quo regarding charset support. Finally, we'd like to get some feedback to implement a better charset support in MDB2.

He lists out the types of character sets - client, connection, database/table/field, and result - explaining each of their roles in the average connection. He then breaks out the different databases into the different settings they support for the different character set types.

The call for help comes in with him asking anyone out there with experience and skill in these areas to get in touch and help out if they can. Contact information is in the post. You can also check out some of Lukas Smith's comments over on his blog too.