Alex Bosworth has compiled a list of “gotchas” that new AJAX developers seem to fall prey to on a regular basis. He has also posted the list on a wiki so that readers can contribute their own common AJAX pitfalls.
Among the list of gotchas was this gem that lends greater weight to my recent coverage of character encodings:
Ajax uses UTF-8. Normal forms are sent using the encoding of the parent page. Thus a SJIS encoded page will default to sending form content encoded in SJIS. Ajax submitted forms on the other hand will be sent as UTF-8. If for some strange reason, UTF-8 is not the character set of choice for the server, this will require a solution such as the server recognizing and translating UTF-8 responses to a desired character encoding.
For PHP developers especially, where limited out-of-the-box support for UTF-8 keeps many sites on single-byte character encodings, this issue could cause nasty surprises indeed. For example, if you want to add the ability to submit a form via AJAX and keep the standard submission method as a fallback, you could potentially end up having to support two different encodings for that submitted data!
Related posts:
- Are You Violating the Eolas Ajax Patent? It's true: Eolas has an Ajax patent and is filing...
- Gotchas in the Cloud: 4 Traps for the Unwary Before you farm out all your business systems to a...
- 10 Things to Check Before Using a CAPTCHA Hacking attempts and spam bots are your problem - not...
- Do Your Web Forms Suck? Most web forms suck—whether that's because of poor usability, a...
Another good reason to switch to UTF-8 as the default for every page you serve! It is surprising, though, that XMLHTTPRequest uses UTF-8 and not the default page encoding.
May 10th, 2006 at 12:23 pm
IMO, XMLHTTPRequest *should* use the default page encoding *or* fully support unicode.
This is *not* a feature AFAIK, it’s a lack of it.
May 10th, 2006 at 7:40 pm
We solved this problem in xajax (http://www.xajaxproject.org) by providing an automatic encoding conversion for incoming data (using either mb_string or iconv). A developer can just set the required encoding with one method call, and then xajax does the work under the hood.
I prefer using UTF-8 anyway, though, and even if PHP doesn’t totally support it yet, it works great if you’re careful.
May 11th, 2006 at 2:56 am
I was not aware that “Ajax uses UTF-8″ until now. Yet on a Big5 encoded website that I developed, the use of Ajax never caused any encoding issues (I have not utilised any encoding conversion techniques on the server side). Weird.
May 11th, 2006 at 1:24 pm
Come on you ajax coders give me a good reason to develop using ajax.
Point me to some sites that do something useful that couldnt be done more sensibly using php or any of a dozen other server side scripting languages.
I just can’t understand the rush to do things client side but then I’ve only been coding for 40 years so I can be rightly describes as a dinasaur.
May 11th, 2006 at 4:52 pm
Well Colin, I made an application where drop-down boxes would fill with entries from a database, depending on what was chosen in the previous drop-down box. And for that AJAX was very handy.
I believe GMail is driven by AJAX as well.
May 13th, 2006 at 4:56 am
@Colin: We have tables all over our site updating twice by the minute with prices from the power markets. When we used server-side scripting we sent out everything every time – HTML, CSS, JS and content. Now we only send content in an xml-file. It saves us tons of bandwidth and CPU.
In that sort of environment it makes great sense!
May 16th, 2006 at 1:27 am
Colin, I recently developed a store site that utilises a single page interface (http://www.techtoys.jp/store.php). I did this because the main page contains two flash apps that load a lot of graphic images and I wanted the user to be able to move about the site without having the flash apps reload from the start when the page was reloaded, losing their position within the apps.
May 16th, 2006 at 2:54 pm
gfdgdfgfdgAugust 23rd, 2006 at 6:28 pm