I had just tried to get my drupal meetup_events module lit on a new site and ran into problems. I eventually narrowed them down to the fact that when you feed into meetup for the description of an event, the returned JSON has trasnformed that into some other (possibly unicode?) character. PHP's json_decode completely chokes on that. Remove the and life is fine.
I can fix this by just scrubbing the on the push, but I'm currious what's going on here, and if this is intended behavior in the json API.
On Tue, May 8, 2012 at 6:36 AM, Sean Dague <s...@dague.net> wrote:
> I had just tried to get my drupal meetup_events module lit on a new site
> and ran into problems. I eventually narrowed them down to the fact that
> when you feed into meetup for the description of an event, the
> returned JSON has trasnformed that into some other (possibly unicode?)
> character. PHP's json_decode completely chokes on that. Remove the
> and life is fine.
> I can fix this by just scrubbing the on the push, but I'm currious
> what's going on here, and if this is intended behavior in the json API.
Hi Sean,
Thanks for reporting this issue. Meetup has recently converted our default
character set encoding on the site to utf8. What you are most likely seeing
is a utf8 encoded variant of
You may notice that many of our API methods still return a the ISO-8859-1
character set encoding so we don't break apps that can't handle utf88.
When you specific a charset of utf8 explicitly we return that encoding. In
the example call below. You'll see spaces instead of question marks for
encoded spaces.
> Thanks for reporting this issue. Meetup has recently converted our
> default character set encoding on the site to utf8. What you are most
> likely seeing is a utf8 encoded variant of
> You may notice that many of our API methods still return a the
> ISO-8859-1 character set encoding so we don't break apps that can't
> handle utf88.
> When you specific a charset of utf8 explicitly we return that encoding.
> In the example call below. You'll see spaces instead of question marks
> for encoded spaces.
> Let us know if that helps resolve the situation you are in. We are
> working on a way to resolve this issue in the API. Thank you for your
> patience.
Haven't set any headers, and I'm getting the utf-8 return. Is the default handling with no header perhaps wrong? Should I force an Accept-Charset:ISO-8859-1 ?
On Tue, May 8, 2012 at 11:19 AM, Sean Dague <s...@dague.net> wrote:
> On 05/08/2012 11:07 AM, Doug Tangren wrote:
>> Hi Sean,
>> Thanks for reporting this issue. Meetup has recently converted our
>> default character set encoding on the site to utf8. What you are most
>> likely seeing is a utf8 encoded variant of
>> You may notice that many of our API methods still return a the
>> ISO-8859-1 character set encoding so we don't break apps that can't
>> handle utf88.
>> When you specific a charset of utf8 explicitly we return that encoding.
>> In the example call below. You'll see spaces instead of question marks
>> for encoded spaces.
>> Let us know if that helps resolve the situation you are in. We are
>> working on a way to resolve this issue in the API. Thank you for your
>> patience.
> Haven't set any headers, and I'm getting the utf-8 return. Is the default
> handling with no header perhaps wrong? Should I force an
> Accept-Charset:ISO-8859-1 ?
In this case you want the Accept-Charset header to be utf-8
> Haven't set any headers, and I'm getting the utf-8 return. Is the
> default handling with no header perhaps wrong? Should I force an
> Accept-Charset:ISO-8859-1 ?
> In this case you want the Accept-Charset header to be utf-8
We've launched a change related to this problem. Since nonbreaking space characters in iso-8859-1, though valid, have caused trouble for some JSON parsers, we're replacing them with plain spaces for that encoding. Responses in utf-8 will continue to include nonbreaking spaces and any other characters that make up the text.
On Tuesday, May 8, 2012 11:38:07 AM UTC-4, Sean wrote:
> On 05/08/2012 11:27 AM, Doug Tangren wrote: > > Haven't set any headers, and I'm getting the utf-8 return. Is the > > default handling with no header perhaps wrong? Should I force an > > Accept-Charset:ISO-8859-1 ?
> > In this case you want the Accept-Charset header to be utf-8
