0.2.3 Release Notes

Note: version 0.2.3 fixes a couple of bugs in 0.2.2 relating to the new character encoding code. Otherwise, it's identical.

Package-wide Changes

xajax's character encoding mechanisms have been refactored for better out-of-the-box behavior and enhanced flexibility. Most existing applications using xajax will require no changes, but a few might need a couple of options changed. Here is how the new system works:

1. xajax defaults to UTF-8 across the board, which is good. The input via the browser's XMLHttpRequest object is ALWAYS going to be UTF-8 anyway.
2. If you set xajax's character encoding to something else, all response output will use that encoding (and a bug was fixed in 0.2.2 along these lines). However, the input will still be in UTF-8, so if you directly output the UTF-8 input using a custom encoding, there will be a big mismatch.
3. In order to fix this, use the decodeUTF8InputOn() method. xajax will then try a variety of means to convert the UTF-8 input to your custom encoding. It will try PHP's iconv extension, and if that isn't available it will try the mb_string extension. If that isn't available, it will try utf8_decode ONLY if the custom encoding is ISO-8859-1. Otherwise, it will trigger a notice (E_USER_NOTICE) explaining that the data couldn't be converted.
4. Another optional mechanism is converting special characters in the output to HTML entities (this happened by default in 0.2.1 which was a bad idea, so it will now be optional). Use the new outputEntitiesOn() method in the xajax class (and also individual xajaxResponse classes) if you want that to happen. This only works if the mb_string extension is available, otherwise a notice is triggered.

Also note that a new test was added to the tests folder called Character Encoding Test. You can set various options and do round-trip text testing to see how this stuff works.