Hi, That's not exactly correct. Previously, content detection was performed in cases where a Content-type header was omitted (or incorrectly specified) from the feed response. However, this is an expensive operation, and has been removed from the new system rendering all gadgets (and fetching feeds, etc.). Feed requests which have a correctly specified Content-type (something like 'Content-Type: text/xml;charset=windows-1256') will still be parsed and returned properly by the API. Feeds that don't specify a Content-type will be returned as UTF-8 (the only place we still perform this check) or ISO-8859-1 otherwise.
The solution in this case is to talk to your feed provider, or use a more forgiving intermediary for your feed requests that will return content in UTF-8 or ISO-8859-1. Dan On Jun 25, 9:01 am, Kevin Sham <[email protected]> wrote: > Seems that the _IG_FetchContent call no longer automatically translate > all html / xml content to utf-8, as it used to. > > The only place that they still works is now the preview tab in the > Google Gadget Editor > > On Jun 10, 11:45 pm, ty <[email protected]> wrote: > > > Out of the blue, we started to experience a number of problems with > > fetching external content on our type-html gadgets that have been > > working OK in production for the last 6+ months. Issue is specific to > > iGoogle v2, everything seems to be fine on other google domains where > > v2 is still not introduced. We have the issue both in the Sandbox and > > google.com in production > > > We fetch external content with _IG_FetchContent from remote pages > > where the remote page's charset declaration is "windows-1254". The > > code we use is as follows: > > > 'Fetch External Content > > <script> > > function fetchURL() { > > var url = "http://www.example.com/page.php";; > > _IG_FetchContent(url, function(responseText) { > > _gel('content_div').innerHTML = responseText; > > }, { refreshInterval: (60 * 3) }); > > } > > <script> > > > 'Show External Content > > <div id="content_div"></div> > > > The gadget used to be able to fetch and display all content in proper > > encoding. Meanining, the gadget was looking exactly the way that the > > page.php was looking when viewed stand-one on a browser. > > > However, now the gadgets do not seem to honor the encoding set for the > > remote page.php and display content in their raw, ascii form (e.g. > > while the page.php's character set is set to display "þ" as "ş", the > > gadget now displays "þ"). > > > Adding "<meta http-equiv="Content-Type" content="text/html; > > charset=windows-1254">" to the gadget itself doesn't seem to help. > > > No recent changes on our part and this issue effects all of our > > gadgets so wondering if something else is going on with the API > > > Happy to post a link for one of the affected xml's if that helps. > > > Thanks --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "iGoogle Developer Forum" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Gadgets-API?hl=en -~----------~----~----~----~------~----~------~--~---
