Problems to Solve Welcome Guest | Login or Register

I’m beginning to work with comet (an ajax-like technology that uses a single connection with multiple server pushes) and found this tutorial extremely helpful:
http://www.zeitoun.net/index.php?2007/06/22/46-how-to-implement-comet-with-php

However, I had to modify the code slightly to work with PHP 4, which doesn’t support json_encode. Instead I just returned the json array manually:

// return a json array
//$response = array();
//$response['msg']       = file_get_contents($filename);
//$response['timestamp'] = $currentmodif;
//echo json_encode($response);
echo "{&92;"msg&92;":&92;"" . file_get_contents($filename) . "&92;",&92;"timestamp&92;":" . $currentmodif . "}";
flush();

I don’t know enough french to navigate or comment on Zeitoun’s site so I thought I’d at least publish this here.

-edit-
Hmm, my code markup plugin seems to be deleting backslashes. I tried replacing them with &92; but they just look like &92;. So replace all &92;s above with \.

I spent way too much time on this, trying all sorts of solutions, for how easy it finally was to solve. I want to list everything I tried though first so others having this same problem might find this post.

I have a new programming gig. I was assigned a bug where the application we’re using generated a SOAP fault if a user pasted content from a Word doc into a form. The SOAP call specified ISO-8559-1 as the character set that it uses, and Word evidentially uses another character set. I tried changing the call to UTF-8 but it didn’t help.

Using ord() in PHP to get the character numbers of the bad characters, I detected that the nasty characters included chr(145), chr(146), chr(147), chr(148), chr(133), chr(150), chr(151), chr(210), chr(211), chr(128), chr(153), chr(156), and chr(157). These are the stupid “smart” or “balanced” quotation marks, left and right single and double quotes, em dashes, en dashes, and elipses (three dots …) .

However, I was unable to find and replace these characters using a variety of methods. It turned out the encoding from Word was in Windows-1252, which is a multibyte encoding that str_replace isn’t going to find when using chr().

I tried mb_check_encoding but it didn’t work, possibly because it wasn’t supported on my server. I tried iconv() but it kept giving me “illegal character” and “cannot convert encoding” errors. Frustratingly, iconv did not honor the //TRANSLIT and //IGNORE flags as documented on php.net, which were supposed to convert or ignore the bad characters automatically.

I did find a preg_replace function on the comments of iconv on php.net that stopped the soap faults by converting all bad characters to question marks, but the question marks wouldn’t have satisfied the client, and on continuous re-edits the question marks doubled and tripled themselves.

Finally, I found the answer here:
http://www.webmasterworld.com/php/3151831.htm
(BTW, when did they open up the webmasterworld forums again? They’ve been locked for like a year. Sweet!)
It turns out if you add an accept-charset=”UTF-8″ flag in your input form tag, the browser will do all the character conversions for you automatically before it even reaches the PHP, SOAP or Java. Even though my SOAP call was in ISO-8559-1, UTF-8 passes through fine and all of the weird word gremlins remain unchanged.

—–  ©®™…‘’“”

Sweet!