Edit report at https://bugs.php.net/bug.php?id=62562&edit=1
ID: 62562
Comment by: beat dot spahni at hotmail dot com
Reported by: magog dot the dot ogre at gmail dot com
Summary: preg_replace mangles UTF8 string - Windows only
Status: Analyzed
Type: Bug
Package: *Regular Expressions
Operating System: Windows x86
PHP Version: 5.3.14
Block user comment: N
Private report: N
New Comment:
Wahrscheinlich gibt es nicht bei MySQL. Siehe unten. Es funktioniert nicht.
Probably there is not with MySQL. See below. It does not function.
$dat1=">='20".date('y-m', $timestamp)."-01'"; // 2013-08-01
$dat2="<='20".date('y-m-t', $timestamp)."'"; // 2013-08-31
$sql = "SELECT * FROM $table where Datum ".$dat1." and Datum ".$dat2; // Es
klappt
nicht. Vielleicht gibt es nicht. Stimmt das? It does not work. Maybe there is
not.
Is this right?
$sql .= " order by Datum asc";
Previous Comments:
------------------------------------------------------------------------
[2013-03-10 23:19:25] magog dot the dot ogre at gmail dot com
I concur this is probably a Windows environment issue. Feel free to mark it
worksforme, withdrawn, etc.
I will try to get some time to run my own compilation on my system and I will
request it be reopened if I still have problems.
------------------------------------------------------------------------
[2012-07-22 20:36:57] paj...@php.net
It is set as analyzed, not resolved.
Can you try to compile PHP using the bundle PCRE instead of the system one
please?
------------------------------------------------------------------------
[2012-07-22 20:28:38] magog dot the dot ogre at gmail dot com
Just curious: why was this marked as solved?
------------------------------------------------------------------------
[2012-07-16 15:38:10] a...@php.net
Btw. the PCRE version reported by PHP is 8.12, but the current is 8.30. May be
a simple upgrade could solve this.
------------------------------------------------------------------------
[2012-07-16 15:19:54] a...@php.net
I've tested your PHP snippet on win7, but it's probably the same on any win.
The behaviour is as you describe. But there is another point. The string to be
matched is hardcoded into the script as UTF-8, if you open that file in the
ASCII mode, you'll see each byte, see here (saved to a file as teh BT ruinates
all the view) http://belsky.info/phpz/bugz/62562/62562_3.txt
Switch the encoding to UTF-8 in your browser and then to a non-multibyte one.
Another way to do that - open the file under linux with
vim -c 'set encoding=latin1' 62562_3.txt
In both cases one can see, that one byte is interpreted as a space. Combined
with no UTF-8 modifier the behaviour is expected, further more windows seems do
do it right :)
I've also debugged this under VS and it's definitely something coming back from
the PCRE itself. Here http://lxr.php.net/xref/PHP_5_4/ext/pcre/php_pcre.c#621
is count > 0, so matched is incremented and returned some when. Nevertheless it
could be a locale thing forcing PCRE to do UTF-8, but I actually don't see any
locale dependent places in PCRE. Trying to boot linux with C locale might repro
this there as well, I have no such mashines though.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=62562
--
Edit this bug report at https://bugs.php.net/bug.php?id=62562&edit=1
