Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53485
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=MR90zbPbY4/iH+Ibcoqv20tAui3HWC8z/cVzE91vhHjErDTZlc0K6n5PwXJCkuk0NT
         fuhGzuxwjRvld7OOR1+hJeMxpWiA+l5HdGTrFEoUaH3a6sRlLJxNUWhAKIAVaCRsmgHV
         k1Q4KqSJICiNfxVfHJwdcbD0++ghP21eYS3Zs=
MIME-Version: 1.0
In-Reply-To: <41269.5975f3c3.1308671739.nsm@avilys.eik.lt>
References: <BANLkTi=qbj_=dmNv__RN4LkDY4GgbTtGYQ@mail.gmail.com>
	<BANLkTiktU3Wau1d6DJt8NgKorBrZm1k=HA@mail.gmail.com>
	<A633CF2D7C7BED41B41F1E64F25507B806048849A2@MAILR001.mail.lan>
	<4DFF7A12.8060808@sugarcrm.com>
	<alpine.DEB.2.02.1106211152240.3774@whisky>
	<BANLkTikTRmc9k7dz3k2DH6LBiU3aA46LPA@mail.gmail.com>
	<4E00818C.7040201@lsces.co.uk>
	<BANLkTi=pKXghoh=9HVhT-uNVw9RaSgVTJg@mail.gmail.com>
	<4E008EA3.4000403@lsces.co.uk>
	<A633CF2D7C7BED41B41F1E64F25507B80604884A3D@MAILR001.mail.lan>
	<41269.5975f3c3.1308671739.nsm@avilys.eik.lt>
Date: Tue, 21 Jun 2011 19:05:59 +0300
Message-ID: <BANLkTikwf4ERg6097FojezNGhbu5mUKeUA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf3071cdcc22ac1c04a63b07a8
Subject: Re: RE: [PHP-DEV] foreach() for strings
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--20cf3071cdcc22ac1c04a63b07a8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

As a userland developer due to my geographical nature i have to work with 3
languages constantly - english, russian (cyryllic) and latvian (witch has
it's own share of non latin characters). I end up using utf-8 in every
project. And some give me a headake of dealing with text parsing. mb_string
covers just part of the functionality and can be turned off.

I personally think something has to be done about unicode handling in php
after 5.4 so that we have an official method of dealing with it in the core=
.
Probably it can be done in a namespace of its own and be new functionality
to witch people should migrate.

my 2 cents.
21.06.2011 17:56 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=
=B5=D0=BB=D1=8C "Tomas Kuliavas" <tokul@users.sourceforge.net>
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> 2011.06.21 17:38 John Crenshaw ra=C5=A1=C4=97:
>> Pierre Joye wrote:
>>> On Tue, Jun 21, 2011 at 1:33 PM, Lester Caine<lester@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, actually.
>>>>>
>>>>> But that's somehow unrelated to the proposal here, as it is about
>>>>> byte, not characters :)
>>>>
>>>> I believe this may be where some of the new niggles may be coming from=
?
>>>> With
>>>> browsers returning unicode, it may be that some of the 'extra'
>>>> characters
>>>> are being returned as multibyte rather than as single bytes? Such as
>>>> the
>>>> problem reported on the general list currently. How do we ensure that
>>>> we are
>>>> dealing with single byte character strings nowadays?
>>>
>>> As it has been stated numerous times in this thread and other, we do
>>> not do anything with multi bytes systems, unicode, etc. mbstring and
>>> intl do, but php's string as of now is all about bytes, array of bytes
>>> if I may describe them this way.
>>>
>>> And we can't change this behavior.
>>
>> This mindset is fundamentally broken. You can call it a byte array all
you
>> want, but the truth is that 99.999% of the time, when a developer is
using
>> a string they need it for characters, not for bytes, and characters are
>> not single byte. Even English users tend to submit Unicode range
>> characters at an alarming rate. If you're using a WYSIWYG editor, Chrome
>> will submit non-breaking-spaces as the actual UTF8 encoded character, no=
t
>> as an HTML encoded entity. Whether developers like it, or even know it,
>> supporting an extended universal character set is not really optional.
>
> They submit it in utf-8 only if your html form allows them to do that or
> they don't follow html specification and try to exploit your form. Set
> form input charset to iso-8859-1 and your nbspace will take only one byte=
.
>
> --
> Tomas
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--20cf3071cdcc22ac1c04a63b07a8--