Hi!
This should really be fixed similar to the iconv //IGNORE flag - so
that bad characters are just replaced with '?'
Maybe using iconv is a way to go in your scenario?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTEC
This should really be fixed similar to the iconv //IGNORE flag - so
that bad characters are just replaced with '?'
We use it to render spam email summaries, and dont really care if the
encoding is incorrect, just as long as it shows something.
Throwing a warning without having a fix/workarou
On Tue, 5 Feb 2008, Richard Lynch wrote:
> On Sun, February 3, 2008 7:51 pm, Stanislav Malyshev wrote:
> >> Like I mentioned before (I think), it should not return an empty
> >> string of course because programmatically it's not possible to
> >> check for this. As most of our functions return fa
On Sun, February 3, 2008 7:51 pm, Stanislav Malyshev wrote:
>> Like I mentioned before (I think), it should not return an empty
>> string
>> of course because programmatically it's not possible to check for
>> this.
>> As most of our functions return false in those cases, so should this
>> function
On Sun, 3 Feb 2008, Stanislav Malyshev wrote:
> > Like I mentioned before (I think), it should not return an empty string of
> > course because programmatically it's not possible to check for this. As most
> > of our functions return false in those cases, so should this function.
>
> AFAIR false
Like I mentioned before (I think), it should not return an empty string
of course because programmatically it's not possible to check for this.
As most of our functions return false in those cases, so should this
function.
AFAIR false is not valid JSON, so it would break a lot of code. Also, I
On Fri, 25 Jan 2008, Stanislav Malyshev wrote:
> Hi!
>
> Right now, if json_encode sees wrong UTF-8 data, it just cuts the string in
> the middle, no error returned, no message produced. Example:
>
> var_dump(json_encode("ab\xE0"));
> var_dump(json_encode("ab\xE0\""));
>
> Both strings get cut
On Feb 1, 2008 9:06 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > Stupid question, who actually checks for E_* in his code at runtime
> > after having called such functions? Not me and I would hate to. It
> > sounds to me like a perfect exception use case. As this function can
>
> General p
Stupid question, who actually checks for E_* in his code at runtime
after having called such functions? Not me and I would hate to. It
sounds to me like a perfect exception use case. As this function can
General policy in PHP as far as I know is that non-OO functions do not
do exceptions.
re
On Feb 1, 2008 8:13 PM, Cristian Rodriguez <[EMAIL PROTECTED]> wrote:
> 2008/1/25, Stanislav Malyshev <[EMAIL PROTECTED]>:
>
> > Now this is an easy fix but would lead to bad strings silently converted
> > to empty strings. The question is - should we have an error there? If
> > so, which one - E_W
2008/1/25, Stanislav Malyshev <[EMAIL PROTECTED]>:
> Now this is an easy fix but would lead to bad strings silently converted
> to empty strings. The question is - should we have an error there? If
> so, which one - E_WARNING, E_NOTICE? I'm for E_WARNING.
Yes , E_WARNING is the right thing to hav
Hi!
Right now, if json_encode sees wrong UTF-8 data, it just cuts the string
in the middle, no error returned, no message produced. Example:
var_dump(json_encode("ab\xE0"));
var_dump(json_encode("ab\xE0\""));
Both strings get cut at "ab". I think it's not a good idea to just
silently cut the
12 matches
Mail list logo
