[Catalyst] Re: ajax character encoding issue solved, but WHY?

[seasprocket at gmail.com]

On Sat, Jun 20, 2009 at 3:50 AM, Aristotle Pagaltzis <pagaltzis at gmx.de>wrot=
e:

> * seasprocket at gmail.com <seasprocket at gmail.com> [2009-06-19 06:30]:>
> > The problem was fixed by calling utf8::decode on the data prior
> > to sending back via ajax. BUT WHY?
>
> Looks like your code is broken and assumes bytes throughout; as
> long as all your data is UTF-8 you won=92t notice. Apparently the
> JSON serialiser is trying to produce UTF-8 output correctly by
> encoding the strings you pass it; since they=92re already encoded,
> you get double-encoding gremlins.


Thanks for your suggestion, but I'm pretty sure that the data is not getting
encoded twice. C::V::JSON tests the data before it encodes (
Encode::is_utf8() ) and only encodes if this test is true. This test only
passes if the data is decoded.

I have confirmed this by checking to see if Encode::encode is getting called
in C::V::JSON (it's not).

I agree something's broken, I just don't know what it is ... My suspicion is
that I don't really understand what's happening inside sqlite -- I assume
it's storing as UTF-8, but I don't really know what it's doing.



>
>
> Regards,
> --
> Aristotle Pagaltzis // <http://plasmasturm.org/>
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>



-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
http://www.bikewise.org

2People citizen's network for climate action: http://www.2people.org

Greater Seattle Climate Dialogues: http://www.climatedialogues.org
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090622/25827=
72f/attachment.htm