[AccessD] OT AJAX question

Hi Marty:

Thanks for the tip.

Jim

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly
Sent: Thursday, May 17, 2007 11:58 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] OT AJAX question

Just remember for international web apps  charset=iso-8859-1
will only work for the Americas and Western Europe, someone
from Russia whose Windows codepage is iso-8859-5 will get
funny looking characters due to wrong transliteration of characters.
So you might want to keep UTF-8 even though 3 bytes are
sent for every character representation.

I noticed that even Google Desktop Search Engine hadn't taken
this into consideration with their returned XML.

Jim Lawrence wrote:

>Hi Marty and anyone else interested:
>
>The solution to the AJAX invalidly encoded return data has been solved. It
>appears that any data returned from a source must have a header supplied.
>The caller reads this first and sets the configuration appropriately. 
>
>But that the first returning data (first line) must set the encoding. In
the
>event of an ASP server page the first line might be something like:
>
>Response.AddHeader "Content-type", "text/html; charset=iso-8859-1"
>
>...or PHP like:
>header("Content-type: text/html; charset=iso-8859-1");
>
>...or when any type of transaction takes place between a server and client
>an appropriate header must be supplied. When an ASP.Net server script is
>serving a PDF file: 
>
>Response.AddHeader("Content-Disposition", "inline;
filename=mydocument.pdf")
>
>..or initiate data Report:
>
>response.addheader("Content-Disposition", inline; filename=Report");
>
>... or set up for receiving XML data:
>
><?xml version="1.0" encoding="UTF-8"?>
>
>It all seems very obvious now. Hope this helps someone who is thinking of
>working with AJAX or extensively with Server/Client applications.
>
>Jim  
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly
>Sent: Thursday, May 10, 2007 1:18 PM
>To: Access Developers discussion and problem solving
>Subject: Re: [AccessD] OT AJAX question
>
>I would have to see the Javascript that is doing this
>
>Generally this would be set in the encoding parameter of the XML
>PI Processing instruction, there are about 30 of these some dependant
>on the Windows codepage. SQL Server or Access punts it out in UTF-8 even 
>without
>including a PI. There are ways to transliterate between encodings using ADO
>streams. It can also be determined by the BOM  marker at the start of 
>the file.
>
>In your case for Unicode encoding, you would want something like
>this XML PI
>
><?xml version="1.0" encoding="UTF-8"?>
>
>http://www.geocities.com/pmpg98_pt/CharacterEncoding.html
>http://support.microsoft.com/kb/q275883/
>
>
>XML Encodings
>
>MSXML supports all encodings that are supported by Microsoft Internet 
>Explorer.
>Internet Explorer's support depends on which language packs are installed
>on the computer; this information is stored under the following registry 
>key:
>HKEY_CLASSES_ROOT\MIME\Database\Charset
>
>xml example
>
><?xml version="1.0" encoding="ISO-8859-1"?>
><character>
>    <chr>í</chr>
></character>
><!-- ISO-8859-1 encoded (Windows Code Page 1252?) -->
><!-- It must have the correct encoding declaration -->
><!-- The special char will display correctly on system that suport that 
>codepage -->
>
>Jim Lawrence wrote:
>  
>
>>OT AJAX 
>>
>>Hi all:
>>
>>This question is totally off-topic but the list members here have an
>>incredible berth and depth of knowledge and I am sure someone will know or
>>know where to look.
>>
>>For anyone here that has worked with AJAX/XML by default the information
>>coming back from the server only supports 128 bit ASCII. That is great for
>>straight English but any other single byte language, 256 bits is a
minimum.
>>
>>Has anyone ran across a solution or knows where to find a solution? If so
>>many thanks is advance. (...have researched a number of potential
solutions
>>but have been unable to either get them to work or have them fall-over
with
>>one client or another.)
>>
>>Jim    
>>    
>>
-- 
Marty Connelly
Victoria, B.C.
Canada

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com