开发者

UTF-8 BOM in php response to mootools xmlhttprequest

开发者 https://www.devze.com 2023-01-01 22:24 出处:网络
I\'m writing my first little AJAX-enabled Joomla component. I\'m using mootools. I got a xmlhttprequest to contact my Joomla component, and the component returns a response - just plain text echoed by

I'm writing my first little AJAX-enabled Joomla component. I'm using mootools. I got a xmlhttprequest to contact my Joomla component, and the component returns a response - just plain text echoed by php, like

echo 'Hello World!';

It's all working fine, except wireshark tells me that the response is prepended with \357\273\277\357\273\277 when it gets read by the javascript on the client side. This shows up as a little square before the response in an alert box that the script shows.

I don't explicitly set the encoding on the xmlhttprequest; mootools docs say that it defaults to UTF8.

What's the right way to handle this? Should I be setting the encoding on the request? Mime type? Should the javascri开发者_开发百科pt get rid of it? I'm not planning to have any characters requiring UTF8 in the response, so using plain old ascii would be ok for me too.

Thanks


A UTF-8 BOM is generally not recommended. Byte-order cannot be reversed in UTF-8 so it serves little purpose other than to just inform the consuming source that the following content is, indeed, UTF-8 encoded.

I'd strip it either on the Joomla end (preferred) or with javascript.

Also, for whatever reason, it looks like you have a double BOM there.

This related question might help as well.


I'm using Microsoft Expression Web 3, and even though it was set to not add a BOM for php files, there was indeed a BOM at the beginning of php files. I used a hex editor to remove the BOM, and now Expression doesn't add a BOM anymore while saving.

I don't know why there was 2 BOMs in the xmlhttprequest response, but now they're both gone.

0

精彩评论

暂无评论...
验证码 换一张
取 消