MS has their object documented (wherein the property of.responseText shows its forced UTF8), but I've discovered that its the same for every browser (FF, Opera, etc). The only browser who supports the correct code-paging for the.responseText is Apple Safari.
If you maintain the charset in the XML document you retrieve with.responeXML (say shift-jis or whichever) - then the.responseXML object behaves accordingly and you can render non-UTF8 data. It was frustrating as heck to try and retrieve shift-jis with.responseText (declaring it in setHeaders, the page calling was shift-jis, and the page requested was shift-jis - but it all came up as utf-8, garbled). I lucked out finding that the.responseXML respects the codepage.
These days, I just use.responseXML exclusively, just to avoid that headache. Sure, sometimes when you do a callback - all you want is something small - say, "3" - and.responseXML requires valid XML (read: extra crap/elements wrapped around just to get a "3"), but it protects me from ever having to retrieve data that is of a different codepage.
I wrote a quick thing on it here:
http://zoobster.blogspot.com/
and on hiveminds:
http://www.hiveminds.org/phpBB/viewtopic.php?p=468 18
MS has their object documented (wherein the property of.responseText shows its forced UTF8), but I've discovered that its the same for every browser (FF, Opera, etc). The only browser who supports the correct code-paging for the.responseText is Apple Safari.
If you maintain the charset in the XML document you retrieve with.responeXML (say shift-jis or whichever) - then the.responseXML object behaves accordingly and you can render non-UTF8 data.
It was frustrating as heck to try and retrieve shift-jis with.responseText (declaring it in setHeaders, the page calling was shift-jis, and the page requested was shift-jis - but it all came up as utf-8, garbled). I lucked out finding that the.responseXML respects the codepage.
These days, I just use.responseXML exclusively, just to avoid that headache. Sure, sometimes when you do a callback - all you want is something small - say, "3" - and.responseXML requires valid XML (read: extra crap/elements wrapped around just to get a "3"), but it protects me from ever having to retrieve data that is of a different codepage.
In all versions of DOM compatible browsers (excepting Apple's Safari), the property.responseText is forced decoded at UTF-8 codepage. That means if you read in anything not UTF-8 (like SHIFT-JIS), it's garbled. Even if you explicitly try setting it otherwise, it's FORCED at UTF-8.
You have to rely on the X - the.responseXML to maintain codepage - it's the only property that keeps the original codepage set.
"... including (presumably) yesterday's posting on Slashdot. Regardless of any political bent in their coverage..."
Don't break your arm patting yourself on the back,/. (especially for (non-existent) vaporious accolades you (presumably) attribute to your (maybe) self.
....and you want fifty years of pension fund payments stored in an Access or MySQL database? No thank you.
The DATA itself is mutatable between ANY datasource. That's up to the DBA to manage. The programmability ot the data storage is what everyone's talking about here, not the data itself.
This is an absurdity. JAVA's dying, can't you see that? It runs slow everywhere, nobody wants to download a virtual machine to run it, and it's such an ugly hack on top of any operating system it sits on.
Slashdot Mirror
Oy, next time - I'll remember to put spaces in there, here it is formatted better:.
8 18
.responseText shows its forced UTF8), but I've discovered that its the same for every browser (FF, Opera, etc). The only browser who supports the correct code-paging for the .responseText is Apple Safari.
.responeXML (say shift-jis or whichever) - then the .responseXML object behaves accordingly and you can render non-UTF8 data. It was frustrating as heck to try and retrieve shift-jis with .responseText (declaring it in setHeaders, the page calling was shift-jis, and the page requested was shift-jis - but it all came up as utf-8, garbled). I lucked out finding that the .responseXML respects the codepage.
.responseXML exclusively, just to avoid that headache. Sure, sometimes when you do a callback - all you want is something small - say, "3" - and .responseXML requires valid XML (read: extra crap/elements wrapped around just to get a "3"), but it protects me from ever having to retrieve data that is of a different codepage.
I wrote a quick thing on it here:
http://zoobster.blogspot.com/
and on hiveminds:
http://www.hiveminds.org/phpBB/viewtopic.php?p=46
MS has their object documented (wherein the property of
If you maintain the charset in the XML document you retrieve with
These days, I just use
I wrote a quick thing on it here: http://zoobster.blogspot.com/ and on hiveminds: http://www.hiveminds.org/phpBB/viewtopic.php?p=468 18
MS has their object documented (wherein the property of .responseText shows its forced UTF8), but I've discovered that its the same for every browser (FF, Opera, etc). The only browser who supports the correct code-paging for the .responseText is Apple Safari.
If you maintain the charset in the XML document you retrieve with .responeXML (say shift-jis or whichever) - then the .responseXML object behaves accordingly and you can render non-UTF8 data.
It was frustrating as heck to try and retrieve shift-jis with .responseText (declaring it in setHeaders, the page calling was shift-jis, and the page requested was shift-jis - but it all came up as utf-8, garbled). I lucked out finding that the .responseXML respects the codepage.
These days, I just use .responseXML exclusively, just to avoid that headache. Sure, sometimes when you do a callback - all you want is something small - say, "3" - and .responseXML requires valid XML (read: extra crap/elements wrapped around just to get a "3"), but it protects me from ever having to retrieve data that is of a different codepage.
Actually, that's untrue.
.responseText is forced decoded at UTF-8 codepage. That means if you read in anything not UTF-8 (like SHIFT-JIS), it's garbled. Even if you explicitly try setting it otherwise, it's FORCED at UTF-8.
.responseXML to maintain codepage - it's the only property that keeps the original codepage set.
In all versions of DOM compatible browsers (excepting Apple's Safari), the property
You have to rely on the X - the
"... including (presumably) yesterday's posting on Slashdot. Regardless of any political bent in their coverage..." Don't break your arm patting yourself on the back, /. (especially for (non-existent) vaporious accolades you (presumably) attribute to your (maybe) self.
....and you want fifty years of pension fund payments stored in an Access or MySQL database? No thank you. The DATA itself is mutatable between ANY datasource. That's up to the DBA to manage. The programmability ot the data storage is what everyone's talking about here, not the data itself.
This is an absurdity. JAVA's dying, can't you see that? It runs slow everywhere, nobody wants to download a virtual machine to run it, and it's such an ugly hack on top of any operating system it sits on.
What the *!@#$^% does OSS have to do with FCC?
The site is craptacularly html-coded, too. This is just a ploy to get /.'d.
Why didn't the /.ers make a big stink about the break that 1.0.5 did?