On 2021-01-07 11:00, Claude Pache wrote:
Le 6 janv. 2021 à 16:46, Nikita Popov a écrit :
On Sat, Dec 26, 2020 at 12:03 PM Craig Francis
wrote:
Hi,
Could htmlspecialchars() use ENT_QUOTES by default?
I recently worked on an example script, where I tried to keep it simple by
using
2020.03.08 16:08 Dan Ackroyd rašė:
> On Tue, 3 Mar 2020 at 22:17, Christoph M. Becker
> wrote:
>>
>> for more
>> general string functionality, it would be ext/mbstring.
>>
>> Thoughts?
>>
>
> Related to this discussion, please could someone remind me why the
> mbstring extension is an extension
2019.09.15 06:32 Mike Schinkel rašė:
> https://medium.com/@trungluongquang/why-python-is-popular-despite-being-super-slow-83a8320412a9
> 1. End-users just don’t care (about slower performance)
Which means that your code is running data processing and not interactive
user facing frontend. Put 10
2012.07.11 19:17, Stas Malyshev rašė:
Hi!
I don't think ASCII-only lowercasing is compatible to the allowed PHP
identifier characters used by class names and what else.
Right now we use tolower() which is system-dependent, locale-dependent
and doesn't really work with any character that
2012.07.11 23:07, Pierre Joye rašė:
hi,
On Wed, Jul 11, 2012 at 10:01 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
I'd to go with master only with this patch, not like it is a huge
issue either (% wised I mean).
It's a huge issue for people using these locales (PHP is unusable
2012.03.13 16:38 Richard Lynch rašė:
I'd have to agree with Stas that everybody should start passing in a
variable there, that can be set somewhere in a config, or, perhaps,
would DEFAULT to, e...
You do realize that suggestions on this thread and original bug reporter
failed to make
2012.03.06 23:03 Michael Morris rašė:
https://wiki.php.net/rfc/php_ini_bcmath_default
This is the only other RFC I've been rummaging around in my head but
hadn't brought up.
PHP has something similar with mbstring function overloading. If people
use both string and mbstring functions, they
2012.02.02 19:42 Reindl Harald rašė:
security is THE benefit for ALL users, especially in days where many
are running crap-code like Joomla/Wordpress with all sorts of plugins
throwing millions of warning if you run with E_ALL and E_STRCIT
E_STRICT throws notices on properly written code. It
2011.09.06 23:20 Ulf Wendel rašė:
Am 06.09.2011 21:33, schrieb Stas Malyshev:
Hi!
Any new PHP major release is about setting new directions. I, Andrey
and
Johannes, the guys maintaining ext/*mysql* recommend going mysqlnd
after
an incubation of some four years (5.3x series + dev time).
2011.09.04 12:13 Reindl Harald rašė:
Am 04.09.2011 06:37, schrieb Stas Malyshev:
Hi!
On 9/2/11 6:51 PM, Rasmus Lerdorf wrote:
Forget the failed tests. A new PHP release is about improving the
ecosystem. If the folks that maintain libmysql and mysqlnd suggest that
mysqlnd is more robust
2011.09.03 12:06 Lester Caine rašė:
New thread ...
My SUSE installs all have mysqlnd included in the core, As do other
Linux distributions. I think for much the same reason that the windows
builds do as well? The PHP development team have decided that
-without-mysqlnd is required to remove
2011.07.22 18:56 John Carter rašė:
Hi,
Are there any plans to make APC work in a similar way to Zend Guard et
al so that we could distribute cache/dump files instead of the php
source. Is this something that would be easy to add?
Brian is this what you're working on? (on disk cache from
2011.06.22 14:14 Reindl Harald rašė:
Am 22.06.2011 07:24, schrieb Tomas Kuliavas:
2011.06.21 23:27 Reindl Harald rašė:
i do not understand any word and miss a simple str_is_utf8()
Such function uses six lines in PHP.
so why do you not post them?
My lines are not public domain
2011.06.21 17:38 John Crenshaw rašė:
Pierre Joye wrote:
On Tue, Jun 21, 2011 at 1:33 PM, Lester Caineles...@lsces.co.uk
wrote:
Pierre Joye wrote:
It depended on ICU there, and I would be against making a core thing
in
PHP 5.x depend on ICU.
It can and should be done as part of intl,
2011.06.21 19:24 Reindl Harald rašė:
Am 21.06.2011 18:22, schrieb Ferenc Kovacs:
On Tue, Jun 21, 2011 at 6:14 PM, Reindl Harald
h.rei...@thelounge.netwrote:
Am 21.06.2011 17:55, schrieb Tomas Kuliavas:
They submit it in utf-8 only if your html form allows them to do that
or
they don't
2011.06.21 20:51 Reindl Harald rašė:
utf-8 is strict format. If you expect utf-8 and someone submits
something
else, you can tell that without any string function. You can verify
utf-8
strings in pcre. You can convert nbspace to regular space, if you want.
utf-8 does not have any byte
2011.06.20 21:38 Robert Eisele rašė:
I really like the ideas shared here. It's a thing of consideration that
array-functions should also work with strings. Maybe this would be the way
to go, but I'm more excited about the OOP implementation of TextIterator
and
ByteIterator, which solves the
2011.04.03 13:58 Tomas Brastavičius rašė:
Hi,
can somebody review the following patch:
http://bugs.php.net/bug.php?id=54369
I am willing the bug is fixed in the next PHP release and ready to do a
job if something is wrong with the patch.
Check url encoding documentation first.
2011.03.15 23:08 Olivier Hoareau rašė:
Hi Tomas !
Thanks for your proposals.
Create .deb package and make it dependent on PHP for Debian/Ubuntu.
Debian
has docs and tools that allow to do that. PHP is in standard
Debian/Ubuntu
software repository.
This solution does not provide me one
2011.03.15 22:09 Olivier Hoareau rašė:
Hi !
I would like to be able to distribute (freely) a single executable
(binary) containing :
- php binaries (v 5.3+)
- a php script already packaged as a .phar (1 Mb, requiring PHP 5.3+)
- additional (optional) compiled extensions
- php.ini
- all
2010.08.12 09:59 Lester Caine rašė:
Currently I am still working my way through the holes in PHP5.3.x which
is why
PHP5.2 is STILL the last stable release as far as my ( windows )
customer sites
are concerned. SO sensible debate on the next step forward IS more
important and
What's
2010.07.30 17:13 Pierre Joye rašė:
What make you think that c-client is dead? I have seen updates last
year and I know that the main developer still works and support this
library.
IMHO main developer works on Panda IMAP. Source code is not publicly
available
Such software could allow webmaster to reconfigure PHP without terminal
connection. Although some PHP configuration variables are not global and
can be changed without modifying global PHP settings. Zend sells software
which allows to change global PHP configuration in web browser (among
other
2010.06.05 21:18 Mike Willbanks rašė:
Tomas,
Such software could allow webmaster to reconfigure PHP without terminal
connection. Although some PHP configuration variables are not global and
can be changed without modifying global PHP settings. Zend sells
software
which allows to change
.
I wanted to controll php by a webfronted.
I currently have a problem with writing php vars into the ini file.
Many thanks for your input concerning the security problem.
Alexander
On Sat, Jun 5, 2010 at 12:21 PM, Tomas Kuliavas
to...@users.sourceforge.net wrote:
Such software could allow
2010.05.04 17:56 Derick Rethans rašė:
On Tue, 4 May 2010, Adam Harvey wrote:
The options are:
1. Apply Tomas's patch to make case-insensitive lookups
locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for
case-insensitive function/method name lookups for high-bit characters
in
2010.05.04 20:20 Tomas Kuliavas rašė:
2010.05.04 17:56 Derick Rethans rašė:
On Tue, 4 May 2010, Adam Harvey wrote:
The options are:
1. Apply Tomas's patch to make case-insensitive lookups
locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for
case-insensitive function/method
to deal with this. There's a patch linked in the bug from
Tomas Kuliavas and Marcus that fixes the problem by simply redefining
zend_tolower() to a simple locale-insensitive ASCII tolower()
function, which does fix the Turkish and Azeri locales.
As you illustrated in your post, fixing it for locales
Keryx Web rašė:
2. If so, what will happen to array access in strings that are de facto
Unicode? Will the more clunky mb_substr() be the only option?
What will happen to array access in unicode strings, if code wants to
access them in bytes? Will some backwards incompatible binary be the
2009.10.12 19:22 Mark Krenz rašė:
Just to clarify. You mean that with the changes you've made for
Unicode support in PHP 6, that current POSIX based ereg expressions will
not work the same?
Expressions didn't work 1,5 year ago.
http://bugs.php.net/bug.php?id=44923
Maybe current PHP6-dev
2009.10.12 20:55 Carl P. Corliss rašė:
Lukas Kahwe Smith wrote:
[snip]
On 12.10.2009, at 18:57, Mark Krenz wrote:
On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye
[pierre@gmail.com] said the following:
[snip]
But I'm willing to bet that the majority of people are using ereg, not
2009.09.10 11:17 Tony Marston rašė:
Tomas Kuliavas to...@users.sourceforge.net wrote in message
news:40100.4e3f9432.1252518200@avilys.eik.lt...
2009.09.09 19:12 Tony Marston rase:
I have reported this problem in http://bugs.php.net/bug.php?id=49238.
It
would appear that this option
2009.09.10 15:25 Tony Marston rašė:
There is no set_up_language() function, and what has SquirrelMail got to
do with PHP?
Unless you can point to some official documentation on the PHP web site
your advice is totally unsubstantiated and virtually worthless.
This advice is the only advice
2009.09.09 19:12 Tony Marston rašė:
I have reported this problem in http://bugs.php.net/bug.php?id=49238. It
would appear that this option, which was first made available in PHP
4.2.0,
has been silently dropped. Apparently the decision was made in order to
fix
2008 Gruodis 28, 11:41, Sek Kenan R Sulayman rašė:
Hey Folks!
I've been working with Zend Studio.
Since I've uninstalled the suite, PHP is exiting with:
Cannot find module (IP-MIB): At line 0 in (none)
Cannot find module (IF-MIB): At line 0 in (none)
Cannot find module (TCP-MIB): At line 0
Hello all,
Last week I submitted a bug report on the issue described below. The
response (also below) was that this is not a bug. I fail to see how it
could *not* be a bug given that strtotime is parsing an invalid date
into a seemingly-arbitrary and definitely-meaningless number, rather
Lester Caine schrieb:
That sounds like just the sort of edge case that Derick is suggesting
needs logging for fixing up. unicode_semantics=on is just another bodge
to to make it happen rather than a solution. I think I understand your
description, and to my eyes it looks like a unicode bug
PHP4, PHP5 and PHP6 unicode_semantics = off work same way.
No, they do not work in the same way.
I.e. we were trying to make PHP5 work in the same way PHP4 did as much as
we could, but that's not always possible.
In my case they do.
--
Tomas
--
PHP Internals - PHP Runtime Development
We've discussed this a few times in the past and it's time to make a
final decision about its removal.
I think most people have agreed that this is the way forward but no
one has produced a patch. I have a student working on unicode
conversion for the Google Summer of Code and this would
We've discussed this a few times in the past and it's time to make a
final decision about its removal.
I think most people have agreed that this is the way forward but no
one has produced a patch. I have a student working on unicode
conversion for the Google Summer of Code and this
As for validity, since locale mechanism has a bunch of fallbacks, I
understand the validity concept is a bit blurred. I.e. you can have
regexp
to check all the -'s or _'s are in place but beyond that it's kind of
hard
to know what the question is en_RU locale valid? means.
It is amazingly
If those application are written properly, they also have to check for
the existance of the functions even with current PHP version since it is
possible to disable them altogether. So it shouldn't matter if they're
removed for them.. ;)
Function is standard for PHP4-5. get_magic_quotes_gpc()
So I guess I'm -1: Restore them, always return false, and throw
E_DEPRECATED.
But this was about them being in PHP 6, not PHP 5..
If magic_quotes_* is gone, so should anything else even remotely related
to them be gone. You have to fix your code anyway for it to work in PHP
6 (or even 5)
On Thursday 07 February 2008, Lukas Kahwe Smith wrote:
On 07.02.2008, at 00:59, Pierre Joye wrote:
Hi Andi,
On Feb 7, 2008 12:56 AM, Andi Gutmans [EMAIL PROTECTED] wrote:
-1
Suggestion to enhance the suggestion: return false + emit E_STRICT
message (but I am also fine with pure
That part is completely different. That's at the display level.
Replacing it in the backend makes no sense to me. Don't use
utf8_decode. Use iconv() so you know what the heck is going on.
:)
iconv() will stop on conversion error and return partial string or empty
string. It will require
Instead of using simple sanitizing function users are forced to check
for errors. How good is that? It makes code complex or unreliable.
Explain me again how checking for errors makes code unreliable?
OR unreliable. If you check for errors, sanitizing code is complex. If you
don't check and
Should really theses functions discard the whole string for a single
incomplete sequence ?
I think since it is not possible to recover true content of the string,
it is ok to return failure value. Cutting it in random places or
ignoring problems doesn't seem a good idea - it might lead to
On 21 Jan 2008, at 14:38, Antony Dovgal wrote:
3) 2+ bigger codebase [1] (with lots of duplicates because we have to
do
same things in native and unicode modes);
From the cross-reference I assume you mean PHP's codebase. We still
need binary string support — Unicode is only suitable for
3) 2+ bigger codebase [1] (with lots of duplicates because we have to
do
same things in native and unicode modes);
From the cross-reference I assume you mean PHP's codebase. We still
need binary string support — Unicode is only suitable for textual
content. Images, for example, are binary
5) this is yet another reincarnation of ze1_compatibility switch.
Which is the worst mistake ever imo - If you wanted PHP 4 you would simply
use PHP 4. Now if you want PHP 5 just damn use PHP 5.
And if you don't control PHP version used by end user? Only bad in-house
apps are written for one
5) this is yet another reincarnation of ze1_compatibility switch.
Which is the worst mistake ever imo - If you wanted PHP 4 you would
simply
use PHP 4. Now if you want PHP 5 just damn use PHP 5.
And if you don't control PHP version used by end user? Only bad in-house
apps are written for
However, a ~couple months ago IBM gave permission to remove this
copyright (because the authors are listed as general contributors,
thus representing IBM) although we've not yet implemented this
removal. We did [temporary] remove it about six months ago but...
There is no requirement
On Fri, 23 Nov 2007, Rasmus Lerdorf wrote:
Marcus Boerger wrote:
Hello internals,
can we please officially announce the end of support for PHP 4*,
5.0.*,
5.1.* as 31st december 2007? Officially as in on the front of php.net.
We already set the EOL date for PHP 4. August 8, 2008.
A preliminary implementation of PHP taint support is available from
ftp://ftp.porcupine.org/pub/php/ This code is released under version
2.00 of the Zend license.
Below are fragments from the README file. For the full text please see
Tomas Kuliavas:
A preliminary implementation of PHP taint support is available from
ftp://ftp.porcupine.org/pub/php/ This code is released under version
2.00 of the Zend license.
Below are fragments from the README file. For the full text please see
ftp://ftp.porcupine.org/pub/php/php
Yes, remove any lines in your php.ini that reference those files.
Thanks for your response...
i have commented the mysql.so module in php.ini.. but i couldn't find
another two modules in php.ini...
which files are related to odbc.so and pdo_odbc.so modules??
Test your PHP setup. Create
I need some assistance gathering the information that might be most
helpful.
This week sometime I will grab a snapshot and install it. Normally I
install php via the FreeBSD ports collection. I am happy to build a
custom version but I would like to make sure that I do not overwrite
any
when developing a patch like this, it is more readable to do typical
min max notation to ease readability. That is change:
if (91 i i 64) {
To:
if (64 i i 91) {
the real issue here is that if we fix it this way we break other locales.
How they break? Do you want to support case
to the report marked as Wont
fix and don't spam the already huge database with one more report about
same issue.
--Jani
On Mon, 2007-09-03 at 14:16 +0300, Tomas Kuliavas wrote:
Hi,
Maybe somebody could provide good explanation why you can fix the issue
(http://bugs.php.net/bug.php?id=42526
Hi,
Maybe somebody could provide good explanation why you can fix the issue
(http://bugs.php.net/bug.php?id=42526). You can't claim that locale
insensitive tolower() breaks things, because your functions are locale
insensitive in some setups.
Now I can only see that PHP developers close bug
I'll add comments on 35050 and you will ignore it, because bug is not open.
You have patch on http://bugs.php.net/bug.php?id=35583. I understand why
it might have been rejected. Using mapping table to lowercase ascii is not
optimal solution.
I have other patch, but you are not free to use code
So what happened to the Open in OpenSource or is PHP now something
else now?
btw. 95% of Zend users propably don't need unicode but there are a lot
more people out there who can't really use PHP right now since it
doesn't have full unicode support. The percents pulled out of sleeve
would be
FINALLY we're getting somewhere. Now where to start removing all the
I don't see how we are getting somewhere - as before, there are people
for removing it and against removing it. Nothing changed, as far as I
see. Why suddenly should we start removing anything?
For some reason only totally
Hi,
If bug is tagged as 'No feedback' (18556) or 'Won't fix' (35050) and can
be reproduced in current PHP5 and PHP6, is it closed or open? Or maybe you
need other bug report?
--
Tomas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
If bug is tagged as 'No feedback' (18556) or 'Won't fix' (35050) and can
be reproduced in current PHP5 and PHP6, is it closed or open? Or maybe
you
need other bug report?
Wont fix means wont fix..and in this case 'no feedback' means also 'wont
fix'
since it's the same thing. New
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early
From the low end user perspective I think this would be great from
another POV. Let's imagine for a second that Wordpress will only work
with unicode semantics off and that phpBB will only work with the switch
on. What if someone would want to run both on a shared server?
from httpd.conf
50% increase sounds off base. But I did not bench php6 yet. When all
the new features are implemented, it will make more sense to work on
the performance problem. For now, it is simply premature.
If Moore's law stands for the coming years, this argument is moot anyway.
By the time PHP 6 is
But if you write:
$a = マニュアル;
echo $a[1];
Whoa.
That was weird...
It was just a bunch of question marks when I read it, and now it's a
bunch of symbols (variants on afz mostly) in my reply...
Your browser or operating system does not support Japanese symbols and
translation selected in
That sounds good in my ears.
Software that relys on old non-unicode behaviour must be written in a
way two handle non-unicode and Unicode behaviour in two different ways.
But for example a rewritten Squirrelmail that runs exlusively on PHP6
would be a good thing.
So you could write on your
Unicode code points can be defined with \u, but PHP6 breaks
existing octal and hex escape sequences.
I don't understand what this means...
I think I know...
I have code like this, somewhere:
if (preg_match(|[\xF0-\xFF]|, $data)){
$data = un_microsuck($data);
}
un_microsuck()
Unicode code points can be defined with \u, but PHP6 breaks
existing octal and hex escape sequences.
I don't understand what this means...
I think I know...
I have code like this, somewhere:
if (preg_match(|[\xF0-\xFF]|, $data)){
$data = un_microsuck($data);
}
un_microsuck()
Well, then I guess we have no choice but to declare official PHP 4
end-of-life
to be on 8:08:08 pm too :) Now we only need to choose a suitable
timezone :)
Well, for us using the 24 hr clock I'd say 8:08:08 am (ante meridiem) as
it otherwise will be 20:08:08 when we speak and write about
Unicode code points can be defined with \u, but PHP6 breaks existing
octal and hex escape sequences.
I don't understand what this means...
PHP6.0-200707060630
unicode.fallback_encoding = 'utf-8' = 'utf-8'
unicode.filesystem_encoding = no value = no value
unicode.http_input_encoding = 'utf-8'
--- test.php ---
?php
$string1 = ą;
$string2 = \xC4\x85;
var_dump($string1 == $string2)
How you expect one-character string to be equal to two-character string?
In PHP4/5 \xC4 and \x85 are not characters. They are bytes.
ą is in utf-8 (latin small letter a with ogonek, latin extended-a
Looks close to
http://www.nexen.net/chiffres_cles/phpversion/16987-php_stats_evolution_for_april_2007.php
Hello Vesselin,
what is the source of your numbers?
Best Regards,
Oliver
Vesselin Kenashkov schrieb:
-1
Because the majority of the installation (somebody two month ago in this
Hi,
I've tried to profile scripts with Zend Profiler (Zend Studio 5.5 Linux
trial on local host + Zend Platform 3.0.2 Linux trial on remote vmware
host) and noticed that script with include() call has higher load time. I
have't found explanation of performance differences between include and
It comes down to predicting the future. Whichever way we go, the
decision is going to be second-guessed. If we have critical mass for
a
clean BC break, then I am ok with it. For me personally it would make
things a bit easier, but I think it would be a long long time before
we
saw any
Unicode code points can be defined with \u, but PHP6 breaks existing
octal
and hex escape sequences.
What do you mean? Doesn't \x20 create U0020 character? Or you mean you'd
expect it to create just one-byte 0x20? Doesn't binary string do that?
Try higher than 0x7F values.
If I write \xA0,
Call to developers:
Create new versions of your apps/libraries which use new features of
language. Make your users interested in upgrading. If users want it,
hosting-owners will consider upgrades faster. It's all about
marketing ;)
It also depends on your marketing policy. PHP 5.2.1
It sounds like your libraries are definitely oriented towards working
with binary strings, rather than Unicode strings. So, I am not sure
why you have unicode.semantics turned on then. If you turn it off,
you will get backwards compatibility with PHP 5. And if you do that,
you can still
We are working on different code. You have code with some specific
character set and you can control all strings.
Tomas, stop arguing on this. As a library maintainer, I agree with you and
I don't understand where the
'killer feature' is (I heard that Yahoo China asked for it, or is it
No one is going to write code in their own native language and
distribute it worldwide.
How can you say that PHP6 Unicode support is not designed for
international environment? Have you even tried it?
Ok. International environment.
Do you have strtoupper|strtolower|strcasecmp functions
Pierre wrote:
On 6/19/07, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
But this is no different from writing code that will work on both PHP 5
and PHP 6. The only difference is that instead of checking for PHP 5
you will be checking for Unicode. Like I said, we don't want the
Unicode decision
On 19/06/07, Tomas Kuliavas [EMAIL PROTECTED] wrote:
I don't care about Unicode support, because it breaks things. I suspect
that PHP6 Unicode extension won't give me controls that I have in PHP5
and
PHP4 strings. PHP6 Unicode support is not designed for international
environment
During Derick's talk about PHP 6 at PHP Vikinger, I started to wonder
what exactly was the reasoning behind adding something like
unicode.semantics option. Derick didn't remember, neither did I.
Apparently it's another one of these register_globals or
magic_quotes_* directives we'll remove
- This feature doesn't bring BC - there will still be enough BC
breaks.
Name one, please. The idea is that there shouldn't be any, so if you
have found one, please file a bug.
Some might say removing register_globals, magic_quotes_*, etc. are BC
break.
If code is portable, it is coded
Hoepfully this project will learn something with the previuos
experiences ( PHP5 adoption anyone? ) and think in a reasoanble
backward compatibility policy.
This is a different story: From what I'm reading Unicode support is for
many people way more interesting than many things introduced
Recent versions of PHP5, has a binary string introducer.
echo strlen(b\xC4\x85);
I have already said to Stefan. It is not an option. I need backwards
compatibility. If older PHP versions fail with E_PARSE errors, I
can't use
it.
[EMAIL PROTECTED]:~$ php -r 'echo strlen(b\xC4\x85),
Recent versions of PHP5, has a binary string introducer.
echo strlen(b\xC4\x85);
I have already said to Stefan. It is not an option. I need backwards
compatibility. If older PHP versions fail with E_PARSE errors, I can't use
it.
I can't maintain two different library versions, because issue
Recent versions of PHP5, has a binary string introducer.
echo strlen(b\xC4\x85);
I have already said to Stefan. It is not an option. I need backwards
compatibility. If older PHP versions fail with E_PARSE errors, I can't
use it.
[EMAIL PROTECTED]:~$ php -r 'echo strlen(b\xC4\x85),
works fine here... (with php 5.2)
http://www.php.net/ChangeLog-5.php#5.2.1
- Added forward support for 'b' prefix in front of string literals.
(Andrei)
PHP 5.2.0
Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING in
test.php on line 5
PHP 4.1.2
Parse error: parse error,
Latin capital letter A with diaeresis is 00C4. Not C4.
Pay attention in maths, leading zeroes don't change a number.
they do, if it is not a number.
'00C4' + '0085' = '00C40085'
'C4' + '85' = 'C485'
'00C40085' != 'C485'
--
Tomas
--
PHP Internals - PHP Runtime Development Mailing List
0xC4 and 0x85 are hex codes for latin small letter a with ogonek in
utf-8. ą
?php
var_dump(ą == \xC4\x85);
echo ą\n;
echo \xC4\x85;
?
If script is written in utf-8, I expect bool(true) on var_dump() line.
var_dump(ą == b\xC4\x85);
This will give you what you want, if the script is
strlen(\xC4\x85) = 2. strlen((binary)\xC4\x85) = 4. Not good. It is
one character in utf-8.
I'm afraid I don't understand you again..
0xC4 and 0x85 are hex codes for latin small letter a with ogonek in utf-8. ą
?php
var_dump(ą == \xC4\x85);
echo ą\n;
echo \xC4\x85;
?
If script is written in
Disclaimer: I don't know much about the way unicode is implemented in
php, i have only used it a bit, but i believe i can clear some things
up here.
0xC4 and 0x85 are hex codes for latin small letter a with ogonek in
utf-8. ą
?php
var_dump(ą == \xC4\x85);
echo ą\n;
echo \xC4\x85;
?
Hi,
Could you make unicode.semantics configurable at PHP_INI_ALL level? Or
maybe PHP6 has string functions that are not unicode aware?
--
Tomas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
Could you make unicode.semantics configurable at PHP_INI_ALL level?
No.
Or maybe PHP6 has string functions that are not unicode aware?
All string functions are supposed to be able to work with both Unicode and
binary strings.
Unicode is just an addition, it doesn't mean that binary
SquirrelMail scripts are designed to work with binary strings. They will
have to deal with emails written in many different character sets. In
some
cases scripts must know string length in bytes and not in symbols. If
PHP
starts converting email body or message parts, strings won't match
And, if they don't, unfortunately, it will be one more reason not to
switch to PHP 6 :)
I hate to be the one to burst our bubble, but unicode is a killer
feature and PHP 6 will be adopted en masse, so if this isn't changed, it
will simply mean the death of userspace stream wrappers for
1 - 100 of 109 matches
Mail list logo
