Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37998
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.46.30 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
        b=YtCuIqRyDhp9jAQFNJYH1R533tguSJk04HA+RYBsS8ddQFnIWVp+cKJiptHfTTMXCznlN9JzxlM+ey6S2gJtyhxoaNiftsiIhHFRbdqnvcSMKcc+886Uc5IFhXF2o08SzvL3+MkbpA4CE0/tpGjWx8q49umEaGHfWewQ+qVrVlE=
Message-ID: <e2e02fe0805291000i7fc60d0al99a663aefead512e@mail.gmail.com>
Date: Thu, 29 May 2008 10:00:36 -0700
To: "Edward Z. Yang" <edwardzyang@thewritingpot.com>
Cc: internals@lists.php.net
In-Reply-To: <8A.30.24593.DBF2E384@pb1.pair.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_21847_11609592.1212080436216"
References: <8A.30.24593.DBF2E384@pb1.pair.com>
Subject: Re: [PHP-DEV] Unicode and XML
From: chrisstocktonaz@gmail.com ("Chris Stockton")

------=_Part_21847_11609592.1212080436216
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I think that internal string handling so be very respective to the
specification as you said. Perhaps code points which are not valid for a
separate specification, protocol etc, the conversion should be done in the
functions dealing with those formats. Like if extension family xmlfoo does
not like null bytes or bom or high surrogates, whatever, then have
xmlfoo_strip_invalid (bad name too ;p).

-Chris

On Wed, May 28, 2008 at 9:23 PM, Edward Z. Yang <
edwardzyang@thewritingpot.com> wrote:

> In PHP 6, incoming user data will automatically be in (unicode) form.
> (That is, assuming that the JIT functionality for converting gets
> implemented).
>
> One of the implementation details I'd like to consider involves non-XML
> and/or non-SGML codepoints inside markup. As per the Unicode
> specification, it is perfectly valid for a Unicode string to contain the
> codepoints U+0000 (null byte), U+FFFF (non-character) and friends.
> However, it is not valid for an XML document to contain these
> characters; either of these will result in a fatal error.
>
> Classically, it was very difficult for PHP scripts to implement UTF-8
> support completely correctly. Many implementations check that the UTF-8
> is well-formed, but neglect to strip out null-bytes and the like. I
> consider validation/filtering against the XML char production (or
> perhaps even more restrictive, as that allows some control characters
> not allowed in HTML).
>
> How should we go about making this easy in PHP 6? Perhaps a web_encoding
> (terrible name, I know) function is in order?
> --
>  Edward Z. Yang                        GnuPG: 0x869C48DA
>  HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter
>  [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

------=_Part_21847_11609592.1212080436216--