> BTW, the temporary solution is to give a priority to each setting,
like
>
> 1. MBSTRG(internal_encoding)
> 2. SG(default_charset)
> 3. System's locale setting
>
> How about this option?
This sounds fine. This way people who compile php without mbstring
support can alter the default charset.
Edi
din
>
> - Original Message -
> From: "Moriyoshi Koizumi" <[EMAIL PROTECTED]>
> To: "Wez Furlong" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, October 17, 2002 7:48 AM
> Subject: Re: [PHP-DEV] [PATCH] Changing entity ch
, October 17, 2002 7:48 AM
Subject: Re: [PHP-DEV] [PATCH] Changing entity charset
handlinginext/standard/html.c
> Yep, as far as I read the archives, I haven't found any
discussions on the
> charset related backwards problems. So I wrote "*exactly* about
this
> issue".
>
>
Err, I suggest you read that patch again.
The default will be the mbstring.internal_charset
That's not the same thing!
--Wez.
On Thu, 17 Oct 2002, Yasuo Ohgaki wrote:
> Wez Furlong wrote:
> > Search for "htmlentities charset". Both myself and thies (and probably others
> > were discussing this
Wez Furlong wrote:
Err, I suggest you read that patch again.
The default will be the mbstring.internal_charset
That's not the same thing!
Since the guess code is in #if, PHP is changing
behavior without the patch according to the
compiled environment.
How about add current guess code if intern
At 11:31 17.10.2002, Yasuo Ohgaki wrote:
>Wez Furlong wrote:
>>Search for "htmlentities charset". Both myself and thies (and probably
>>others
>>were discussing this).
>>In short: there are many, many, many people who have scripts that rely
>>on htmlentities defaulting to iso-8859-1 (the documen
Wez Furlong wrote:
> Search for "htmlentities charset". Both myself and thies (and probably others
> were discussing this).
> In short: there are many, many, many people who have scripts that rely
> on htmlentities defaulting to iso-8859-1 (the documented default for ever).
With the patch, ISO 8
On 10/17/02, "Moriyoshi Koizumi" <[EMAIL PROTECTED]> wrote:
> Yep, as far as I read the archives, I haven't found any discussions on the
> charset related backwards problems. So I wrote "*exactly* about this
> issue".
Search for "htmlentities charset". Both myself and thies (and probably other
Yep, as far as I read the archives, I haven't found any discussions on the
charset related backwards problems. So I wrote "*exactly* about this
issue".
You may want to redirect me to bug #9392 (http://bugs.php.net/bug.php?id=9392), but it
doens't seem to help...
In addition, I found determini
Wez Furlong wrote:
> Search the archives for the discussion.
> phpinfo could determine the charset as your patch does at the start,
phpinfo() better not to detect charsets, since user are
using it to see variables' values. i.e. Variables may
contains different encoding var to var.
Applying htmle
Search the archives for the discussion.
phpinfo could determine the charset as your patch does at the start,
and then pass the info in php_escape_html_entities.
Seems easy to me.
--Wez.
On 10/16/02, "Moriyoshi Koizumi" <[EMAIL PROTECTED]> wrote:
> Wez Furlong <[EMAIL PROTECTED]> wrote:
> > Unfo
Wez Furlong <[EMAIL PROTECTED]> wrote:
> Unfortunately, we absolutely must remain 100% backwards compatible with
> htmlentities(), so this patch should not be applied.
Were there any discussions exactly about this issue? Though I have to see
some historical reason, however I don't understand why
Unfortunately, we absolutely must remain 100% backwards compatible with
htmlentities(), so this patch should not be applied.
However, I don't see a problem with making phpinfo determine the charset
and passing that on to the internal htmlentities function?
--Wez.
On Thu, 17 Oct 2002, Moriyoshi
Hi,
I know this may cause a potential BC problem, but I think htmlentities()
should be more consistent with mbstring modules.
The attached patch changes the behaviour of htmlentities() or its internal
counterparts, to take the character set of the characters as the value of
mbstring.internal_
14 matches
Mail list logo
