my gadget is reading a hong kong government webpage using _IG_FetchContent call http://www.weather.gov.hk/wxinfo/currwx/flwc.htm which has the content type set within the html: <meta http-equiv="Content-Type" content="text/html; charset=big5- hkscs">
_IG_FetchContent also does not parse the rss feed from the same site: http://rss.weather.gov.hk/rss/WeatherWarningSummary_big5.xml igoogle can still read the feed properly when directly adding it to the page I actually read it from the following old page that igooge used to have a feature to manually specify the encoding for parsing: http://www.programmer-club.com.tw/ShowSameTitleN/igoogle/86.html On 6月26日, 上午7時59分, "Dan (Google)" <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
