Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #6664 > unrolled thread

strip_tags function

Back to article view | Back to comp.lang.php

Contents

  strip_tags function Tim Fardell <tim.fardell.all-your-clothes@virgin.net> - 2012-07-26 18:18 +0100
    Re: strip_tags function Tim Fardell <tim.fardell.all-your-clothes@virgin.net> - 2012-07-26 18:27 +0100
      Re: strip_tags function The Natural Philosopher <tnp@invalid.invalid> - 2012-07-26 19:24 +0100
        Re: strip_tags function Gregor Kofler <usenet@gregorkofler.com> - 2012-07-26 23:54 +0200
      Re: strip_tags function "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-07-27 08:25 +0200
      Re: strip_tags function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-07-27 11:52 +0200
        Re: strip_tags function Tim Fardell <tim.fardell.all-your-clothes@virgin.net> - 2012-07-27 18:25 +0100
          Re: strip_tags function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-07-28 12:42 +0200
            Re: strip_tags function Tim Fardell <tim.fardell.all-your-clothes@virgin.net> - 2012-07-31 20:17 +0100
              Re: strip_tags function Jerry Stuckle <jstucklex@attglobal.net> - 2012-07-31 15:30 -0400
                Re: strip_tags function Tim Fardell <tim.fardell.all-your-clothes@virgin.net> - 2012-07-31 20:37 +0100
                  Re: strip_tags function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-08-01 06:56 +0200
                  Re: strip_tags function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-08-01 07:15 +0200
              Re: strip_tags function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-08-01 06:49 +0200

#6664 — strip_tags function

Hello all! 

I'm very much a PHP beginner, so please bear with me :-)

I have a need to remove all HTML tags from a string, and rather than re-invent
the wheel, I thought I'd see if there was an existing function that could do
this. Superficially, strip_tags() appears to do exactly what I need. 

However, am I right in thinking that the strip_tags() function simply assumes
that any less-than character (<) occurring within a string is the beginning of a
tag? 

I hope I'm wrong, because that would be completely crap and useless :-)

-- 
Please remove all-your-clothes before replying. 

[toc] | [next] | [standalone]

#6665

On Thu, 26 Jul 2012 18:18:44 +0100, Tim Fardell
<tim.fardell.all-your-clothes@virgin.net> wrote:

>However, am I right in thinking that the strip_tags() function simply assumes
>that any less-than character (<) occurring within a string is the beginning of a
>tag? 
>
>I hope I'm wrong, because that would be completely crap and useless :-)

Apologies for following-up my own post, but I just realised the answer to my own
question. 

I think I am correct that strip_tags assumes any '<' character to be the
beginning of a tag - but this doesn't actually matter, since the input string
should be HTML encoded anyway, so all '<' characters should be escaped as '&lt;'
- so all actual '<' characters will indeed be tags :-)

So I wasn't wrong, but it's not as crap and useless as I thought! 
-- 
Please remove all-your-clothes before replying. 

[toc] | [prev] | [next] | [standalone]

#6666

Tim Fardell wrote:
> On Thu, 26 Jul 2012 18:18:44 +0100, Tim Fardell
> <tim.fardell.all-your-clothes@virgin.net> wrote:
> 
>> However, am I right in thinking that the strip_tags() function simply assumes
>> that any less-than character (<) occurring within a string is the beginning of a
>> tag? 
>>
>> I hope I'm wrong, because that would be completely crap and useless :-)
> 
> Apologies for following-up my own post, but I just realised the answer to my own
> question. 
> 
> I think I am correct that strip_tags assumes any '<' character to be the
> beginning of a tag - but this doesn't actually matter, since the input string
> should be HTML encoded anyway, so all '<' characters should be escaped as '&lt;'
> - so all actual '<' characters will indeed be tags :-)
> 
> So I wasn't wrong, but it's not as crap and useless as I thought! 
I was about to say 'so does your browser'

There is a function that only strips certain listed tags, but I cant 
remember what it is


-- 
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.

[toc] | [prev] | [next] | [standalone]

#6667

Am 2012-07-26 20:24, The Natural Philosopher meinte:
> Tim Fardell wrote:
>> On Thu, 26 Jul 2012 18:18:44 +0100, Tim Fardell
>> <tim.fardell.all-your-clothes@virgin.net> wrote:
>>
>>> However, am I right in thinking that the strip_tags() function simply
>>> assumes
>>> that any less-than character (<) occurring within a string is the
>>> beginning of a
>>> tag?
>>> I hope I'm wrong, because that would be completely crap and useless :-)
>>
>> Apologies for following-up my own post, but I just realised the answer
>> to my own
>> question.
>> I think I am correct that strip_tags assumes any '<' character to be the
>> beginning of a tag - but this doesn't actually matter, since the input
>> string
>> should be HTML encoded anyway, so all '<' characters should be escaped
>> as '&lt;'
>> - so all actual '<' characters will indeed be tags :-)
>>
>> So I wasn't wrong, but it's not as crap and useless as I thought!
> I was about to say 'so does your browser'
>
> There is a function that only strips certain listed tags, but I cant
> remember what it is

strip_tags? It's just the other way round: You have to supply the 
allowed tags.

Gregor

[toc] | [prev] | [next] | [standalone]

#6668

El 26/07/2012 19:27, Tim Fardell escribió/wrote:
> On Thu, 26 Jul 2012 18:18:44 +0100, Tim Fardell
> <tim.fardell.all-your-clothes@virgin.net> wrote:
>
>> However, am I right in thinking that the strip_tags() function simply assumes
>> that any less-than character (<) occurring within a string is the beginning of a
>> tag?
>>
>> I hope I'm wrong, because that would be completely crap and useless :-)
>
> Apologies for following-up my own post, but I just realised the answer to my own
> question.
>
> I think I am correct that strip_tags assumes any '<' character to be the
> beginning of a tag - but this doesn't actually matter, since the input string
> should be HTML encoded anyway, so all '<' characters should be escaped as '&lt;'
> - so all actual '<' characters will indeed be tags :-)
>
> So I wasn't wrong, but it's not as crap and useless as I thought!

As you've already noticed yourself, the strip_tags() function makes 
sense when applied to HTML. As such, I think it's good enough, though 
you won't get predictable results if the HTML is not valid (which is 
normally the same that happens with web browsers).

Sadly, it's pretty often used on plain text, leading to annoyances and 
data loss. Have you ever posted a comment on a programming web site, 
just to find out that your code snippets were ruined by the forum? There 
you are.


-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]

#6669

Tim Fardell wrote:

> On Thu, 26 Jul 2012 18:18:44 +0100, Tim Fardell
> <tim.fardell.all-your-clothes@virgin.net> wrote:
>> However, am I right in thinking that the strip_tags() function simply
>> assumes that any less-than character (<) occurring within a string is the
>> beginning of a tag?
>>
>> I hope I'm wrong, because that would be completely crap and useless :-)
> 
> […]
> I think I am correct that strip_tags assumes any '<' character to be the
> beginning of a tag - 

No, you are not.  The function, at least as of PHP 5.3.10, is context-
sensitive:

$ php -r "echo strip_tags('<a title=\'<\'>foo</a>');"
foo

> ut this doesn't actually matter, since the input string should be HTML
> encoded anyway, so all '<' characters should be escaped as '&lt;' - so all
> actual '<' characters will indeed be tags :-)

You are not making sense.  The *input* data should *never* be "HTML 
encoded".


PointedEars 
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#6677

On Fri, 27 Jul 2012 11:52:29 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Tim Fardell wrote:
>
>> On Thu, 26 Jul 2012 18:18:44 +0100, Tim Fardell
>> <tim.fardell.all-your-clothes@virgin.net> wrote:
>>> However, am I right in thinking that the strip_tags() function simply
>>> assumes that any less-than character (<) occurring within a string is the
>>> beginning of a tag?
>>>
>>> I hope I'm wrong, because that would be completely crap and useless :-)
>> 
>> […]
>> I think I am correct that strip_tags assumes any '<' character to be the
>> beginning of a tag - 
>
>No, you are not.  The function, at least as of PHP 5.3.10, is context-
>sensitive:
>
>$ php -r "echo strip_tags('<a title=\'<\'>foo</a>');"
>foo

Possibly true, but that example does not demonstrate it. Try: 

$ php -r "echo strip_tags('<a title=\'<\'>f<o<o</a>');"

Output should be 

f<o<o

Definitely doesn't work in PHP 5.3.3, and according to php.net the function
hasn't changed since 5.0.0. 

>> ut this doesn't actually matter, since the input string should be HTML
>> encoded anyway, so all '<' characters should be escaped as '&lt;' - so all
>> actual '<' characters will indeed be tags :-)
>
>You are not making sense.  The *input* data should *never* be "HTML 
>encoded".

Then I must have completely misunderstood something here. I thought the whole
point of strip_tags() was to remove all HTML tags from the input string.
Therefore the input has to be HTML or the function is pointless. 

Unless the idea is to remove rogue HTML tags from a plain text string, in which
case my original point about it assuming all < symbols are tags remains valid -
it's crap and useless for this. 
-- 
Please remove all-your-clothes before replying. 

[toc] | [prev] | [next] | [standalone]

#6679

Tim Fardell wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Tim Fardell wrote:
>>> On Thu, 26 Jul 2012 18:18:44 +0100, Tim Fardell
>>> <tim.fardell.all-your-clothes@virgin.net> wrote:
>>>> However, am I right in thinking that the strip_tags() function simply
>>>> assumes that any less-than character (<) occurring within a string is
>>>> the beginning of a tag?
>>>>
>>>> I hope I'm wrong, because that would be completely crap and useless :-)
>>> 
>>> […]
>>> I think I am correct that strip_tags assumes any '<' character to be the
>>> beginning of a tag -
>>
>> No, you are not.  The function, at least as of PHP 5.3.10, is context-
>> sensitive:
>>
>> $ php -r "echo strip_tags('<a title=\'<\'>foo</a>');"
>> foo
> 
> Possibly true,

What do you mean – "possibly"?  I tested it there.

> but that example does not demonstrate it.

But it does.  The `<' is not considered the beginning of a tag when in an 
attribute value (whose delimiters needed to be escaped here because the 
apostrophe was already used as PHP single-quoted string literal delimiter).  

This complies with the current HTML5 Working Draft parsing rules, which 
attempt to codify existing parser behavior in Web browsers:

<http://www.w3.org/TR/2012/WD-html5-20120329/tokenization.html#attribute-
value-single-quoted-state>

> Try:
> 
> $ php -r "echo strip_tags('<a title=\'<\'>f<o<o</a>');"
                                               ^
> Output should be
> 
> f<o<o

No, it should not.  The markup is syntactically invalid in the first place 
(an STAGO [1] may not be used within a tag outside of an attribute value; 
XML well-formedness even forbids it unescaped within an attribute value), so 
the outcome of tag-stripping is undefined.  As a result, the output in PHP 
5.3.10 is

f

because error-correction inserts the missing `>', and removes all tags from

<a title='<'>f<o><o></a>

(I am making an assumption here based on the behavior of existing markup 
parsers.)

> Definitely doesn't work in PHP 5.3.3, and according to php.net the
> function hasn't changed since 5.0.0.

It would be prudent if you learned about SGML-based markup languages before 
you attempted to pass on judgement on the correctness of their parsers.

>>> ut this doesn't actually matter, since the input string should be HTML
>>> encoded anyway, so all '<' characters should be escaped as '&lt;' - so
>>> all actual '<' characters will indeed be tags :-)
>>
>>You are not making sense.  The *input* data should *never* be "HTML
>>encoded".
> 
> Then I must have completely misunderstood something here. I thought the
> whole point of strip_tags() was to remove all HTML tags from the input
> string.

Yes, HTML *tags*.

> Therefore the input has to be HTML or the function is pointless.

You have defined "HTML-encoded" above to mean that "<" would be "&lt;".  
(Which is a common, and semantically correct definition of the term.)

So HTML-*encoded* strings are _not_ HTML *markup*; by definition, there are 
no tags in them.

> Unless the idea is to remove rogue HTML tags from a plain text string,

ISTM that is the general idea.  Some HTML elements (which consist of start 
tag, optional content and optional end tag, depending on the element type), 
are potentially detrimental to the expected display and functionality of a 
Web document.  For example, consider that people were allowed to use text-
formatting elements in a blog comment, but where not allowed to insert 
`script' elements (to avoid XSS) or `img' and `object' elements (to avoid 
reduction of loading speed and interference with other multimedia on the 
site); you would only list the text-formatting elements in the function's 
second parameter then.

Other people might want to remove HTML tags altogether, leaving only the 
text content of the document (fragment).

> in which case my original point about it assuming all < symbols are tags

The `<' character is an STAGO (STart Tag Open) delimiter in SGML-based 
markup languages.  It delimits a start tag on the left-hand side (a `>' 
character delimits it on the right-hand side).  Obviously, therefore it 
cannot be a tag itself.

> remains valid - it's crap and useless for this.

Evidently, you do not know what you are talking about.


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#6698

On Sat, 28 Jul 2012 12:42:59 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Tim Fardell wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Tim Fardell wrote:
>>>> On Thu, 26 Jul 2012 18:18:44 +0100, Tim Fardell
>>>> <tim.fardell.all-your-clothes@virgin.net> wrote:
>>>>> However, am I right in thinking that the strip_tags() function simply
>>>>> assumes that any less-than character (<) occurring within a string is
>>>>> the beginning of a tag?
>>>>>
>>>>> I hope I'm wrong, because that would be completely crap and useless :-)
>>>> 
>>>> [?]
>>>> I think I am correct that strip_tags assumes any '<' character to be the
>>>> beginning of a tag -
>>>
>>> No, you are not.  The function, at least as of PHP 5.3.10, is context-
>>> sensitive:
>>>
>>> $ php -r "echo strip_tags('<a title=\'<\'>foo</a>');"
>>> foo
>> 
>> Possibly true,
>
>What do you mean – "possibly"?  I tested it there.

By "possibly" I mean that what you say may well be true, and I do not dispute
that it is. All I am saying is that your example does not demonstrate it, and
thus does not prove it. 

>> but that example does not demonstrate it.
>
>But it does.  

No, it does not. A function that assumes every occurrence of the '<' character
is the beginning of a tag, and removes it and all text from it up to and
including the next '>' character in the string would yield exactly the same
output. You have not demonstrated context sensitivity. 

>> Try:
>> 
>> $ php -r "echo strip_tags('<a title=\'<\'>f<o<o</a>');"
>                                               ^
>> Output should be
>> 
>> f<o<o
>
>No, it should not.  

If the function is intended to be used to process plain unformatted ASCII text
and remove any unwanted HTML tags from it, then yes, it should. If the function
is intended to remove all HTML tags from an HTML document, then I agree it
should not. Which is what I said to start with in the followup to my original
post. 

>The markup is syntactically invalid in the first place 

What markup? If, as you suggest later on, and also implied in your previous
post, the input text is supposed to be plain, unformatted text, which may
unintentionally contains rogue HTML tags that should not be there, then the
input text is unlikely to be syntactically correct markup anyway. 

>> Definitely doesn't work in PHP 5.3.3, and according to php.net the
>> function hasn't changed since 5.0.0.
>
>It would be prudent if you learned about SGML-based markup languages before 
>you attempted to pass on judgement on the correctness of their parsers.

Actually I think what I have been saying all along is that the function behaves
correctly if the input text is HTML. I believe the function is supposed to take
correct HTML as input, in which case it works exactly as I would expect. 

>>>> ut this doesn't actually matter, since the input string should be HTML
>>>> encoded anyway, so all '<' characters should be escaped as '&lt;' - so
>>>> all actual '<' characters will indeed be tags :-)
>>>
>>>You are not making sense.  The *input* data should *never* be "HTML
>>>encoded".

Wait, didn't you just say the opposite? If the input is not HTML-encoded then it
is *critical* that any '<' character which does not form part of a tag is
ignored. It is not, as my example above proves. 

>> Then I must have completely misunderstood something here. I thought the
>> whole point of strip_tags() was to remove all HTML tags from the input
>> string.
>
>Yes, HTML *tags*.

Good, we agree on something. 

>> Therefore the input has to be HTML or the function is pointless.
>
>You have defined "HTML-encoded" above to mean that "<" would be "&lt;".  
>(Which is a common, and semantically correct definition of the term.)
>
>So HTML-*encoded* strings are _not_ HTML *markup*; by definition, there are 
>no tags in them.

Agreed again. 

>> Unless the idea is to remove rogue HTML tags from a plain text string,
>
>ISTM that is the general idea.  

Oh dear, we're going to start disagreeing again here. 

>Some HTML elements (which consist of start 
>tag, optional content and optional end tag, depending on the element type), 
>are potentially detrimental to the expected display and functionality of a 
>Web document.  For example, consider that people were allowed to use text-
>formatting elements in a blog comment, but where not allowed to insert 
>`script' elements (to avoid XSS) or `img' and `object' elements (to avoid 
>reduction of loading speed and interference with other multimedia on the 
>site); you would only list the text-formatting elements in the function's 
>second parameter then.
>
>Other people might want to remove HTML tags altogether, leaving only the 
>text content of the document (fragment).

OK, so given no parameters other than the input string, the behaviour of
strip_tags() is to remove all HTML tags from the input string. Correct? 

You have just said that you believe the input string should be plain text, i.e.
it *should* not contain any tags or formatting information of any kind, but may
contain rogue HTML tags which need to be removed. You also said that the input
string should *never* be HTML-encoded. Therefore, the input string could quite
easily contain '<' characters which are not part of HTML tags, as '<' is a
perfectly valid ASCII character. Therefore, by your reasoning, it is important
that any '<' character which does not form part of a tag is ignored. 

This is not the case. 

>> in which case my original point about it assuming all < symbols are tags
>
>The `<' character is an STAGO (STart Tag Open) delimiter in SGML-based 
>markup languages.  It delimits a start tag on the left-hand side (a `>' 
>character delimits it on the right-hand side).  Obviously, therefore it 
>cannot be a tag itself.

Sorry but that is extremely pedantic. I think it's obvious what I meant - Just
to clarify, I meant to say "...in which case my original point about it assuming
all < symbols *are the beginning of* tags..."

>> remains valid - it's crap and useless for this.
>
>Evidently, you do not know what you are talking about.

No need for rudeness is there? 

I think basically what I'm saying is that the strip_tags() function is great and
is really useful if its input text is correct HTML. 

I therefore believe this function is intended to take correct HTML as input. It
is therefore crap and useless if you pass it anything other than correct HTML,
which is what you seem to be disputing. 

-- 
Please remove all-your-clothes before replying. 

[toc] | [prev] | [next] | [standalone]

#6699

On 7/31/2012 3:17 PM, Tim Fardell wrote:
> On Sat, 28 Jul 2012 12:42:59 +0200, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
>

<snip>

>>>>
>>>> You are not making sense.  The *input* data should *never* be "HTML
>>>> encoded".
>
> Wait, didn't you just say the opposite? If the input is not HTML-encoded then it
> is *critical* that any '<' character which does not form part of a tag is
> ignored. It is not, as my example above proves.
>

Tim,

You should have stopped right here.  "Pointed Head" is a well known 
troll in several newsgroups.  He doesn't understand it is completely 
valid to have HTML encoded strings - for instance, when using cURL to 
retrieve a web page.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6700

On Tue, 31 Jul 2012 15:30:54 -0400, Jerry Stuckle <jstucklex@attglobal.net>
wrote:

>On 7/31/2012 3:17 PM, Tim Fardell wrote:
>> On Sat, 28 Jul 2012 12:42:59 +0200, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>>
>
><snip>
>
>>>>>
>>>>> You are not making sense.  The *input* data should *never* be "HTML
>>>>> encoded".
>>
>> Wait, didn't you just say the opposite? If the input is not HTML-encoded then it
>> is *critical* that any '<' character which does not form part of a tag is
>> ignored. It is not, as my example above proves.
>>
>
>Tim,
>
>You should have stopped right here.  "Pointed Head" is a well known 
>troll in several newsgroups.  He doesn't understand it is completely 
>valid to have HTML encoded strings - for instance, when using cURL to 
>retrieve a web page.

Ah - that explains it :-)

I did wonder to be honest, which is why I didn't reply for a couple of days, but
it got the better of me and I just *had* to respond in the end. 

I'll leave it there - apologies for feeding the troll. 
-- 
Please remove all-your-clothes before replying. 

[toc] | [prev] | [next] | [standalone]

#6703

Tim Fardell wrote:

> Jerry Stuckle wrote:
>>On 7/31/2012 3:17 PM, Tim Fardell wrote:
>>> On Sat, 28 Jul 2012 12:42:59 +0200, Thomas 'PointedEars' Lahn
>>> <PointedEars@web.de> wrote:
>>>>>> You are not making sense.  The *input* data should *never* be "HTML
>>>>>> encoded".
>>>
>>> Wait, didn't you just say the opposite? If the input is not HTML-encoded
>>> then it is *critical* that any '<' character which does not form part of
>>> a tag is ignored. It is not, as my example above proves.
>>
>>You should have stopped right here.  "Pointed Head" is a well known
>>troll in several newsgroups.  He doesn't understand it is completely
>>valid to have HTML encoded strings - for instance, when using cURL to
>>retrieve a web page.
> 
> Ah - that explains it :-)

Your misconceptions?

> I did wonder to be honest, which is why I didn't reply for a couple of
> days, but it got the better of me and I just *had* to respond in the end.

Which got you a constructive discussion in the end that you can *really* 
learn from, if you are willing.  Some people have jobs (which happen to be 
in this industry), and cannot always reply in time.
 
> I'll leave it there - apologies for feeding the troll.

If you are this naive to blindly believe the first "opinion" that comes 
along just because the topic turns out to be a little more complex than you 
expected, then you better leave here, indeed.


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#6705

Tim Fardell wrote:

> On Tue, 31 Jul 2012 15:30:54 -0400, Jerry Stuckle
>> […] it is completely valid to have HTML encoded strings - for instance,
>> when using cURL toretrieve a web page.

JFTR: Utter nonsense.  "HTML-encoded string" was (well-)defined *by the OP* 
as a string where "<a>…</a>" would become at least "&lt;a>…&lt;/a>".

If you use cURL to retrieve a "web page" (correct: a web _document_, like an 
HTML document), the input is always *markup*, like "<a>…</a>".  It may also 
include character references (`&#215') or character entitity references 
(`&lt;'), but it will contain at least one tag (because the "web page" would 
otherwise be useless).


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#6702

Tim Fardell wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Tim Fardell wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Tim Fardell wrote:
>>>>> On Thu, 26 Jul 2012 18:18:44 +0100, Tim Fardell
>>>>> <tim.fardell.all-your-clothes@virgin.net> wrote:
>>>>>> However, am I right in thinking that the strip_tags() function simply
>>>>>> assumes that any less-than character (<) occurring within a string is
>>>>>> the beginning of a tag?
>>>>>>
>>>>>> I hope I'm wrong, because that would be completely crap and useless
>>>>>> :-)
>>>>> 
>>>>> [?]
>>>>> I think I am correct that strip_tags assumes any '<' character to be
>>>>> the beginning of a tag -
>>>>
>>>> No, you are not.  The function, at least as of PHP 5.3.10, is context-
>>>> sensitive:
>>>>
>>>> $ php -r "echo strip_tags('<a title=\'<\'>foo</a>');"
>>>> foo
>>> 
>>> Possibly true,
>>
>> What do you mean – "possibly"?  I tested it there.
> 
> By "possibly" I mean that what you say may well be true, and I do not
> dispute that it is. All I am saying is that your example does not
> demonstrate it, and thus does not prove it.

A matter of interpretation.
 
>>> but that example does not demonstrate it.
>> But it does.
> 
> No, it does not. A function that assumes every occurrence of the '<'
> character is the beginning of a tag, and removes it and all text from it
> up to and including the next '>' character in the string would yield
> exactly the same output. You have not demonstrated context sensitivity.

An example that proves my point and applies to your now-clarified assumption 
can be easily created:

$ php -r "echo strip_tags('<a title=\'>\'>foo</a>');"
foo

If it would be as you assumed, then the output would have to be something 
similar to

'>foo

It is not.

>> The markup is syntactically invalid in the first place
> 
> What markup? If, as you suggest later on, and also implied in your
> previous post, the input text is supposed to be plain, unformatted text,
> which may unintentionally contains rogue HTML tags that should not be
> there, then the input text is unlikely to be syntactically correct markup
> anyway.

You still misunderstand.  The input is obviously supposed to be markup, 
containing tags; it needs to be parsed.

However, you have (well-)defined "HTML-encoded" as content where the "<" of 
tags would be replaced with "&lt;".  That would not be markup anymore as 
markup requires at least one tag.  (`&lt;' is _not_ a tag.)

>>> Definitely doesn't work in PHP 5.3.3, and according to php.net the
>>> function hasn't changed since 5.0.0.
>>
>>It would be prudent if you learned about SGML-based markup languages
>>before you attempted to pass on judgement on the correctness of their
>>parsers.
> 
> Actually I think what I have been saying all along is that the function
> behaves correctly if the input text is HTML.

No, you assumed the function would consider *all* `<'s to be a start of a 
tag, which it obviously does not.

> I believe the function is supposed to take correct HTML as input, in which
> case it works exactly as I would expect.

If "correct" means *syntactically* correct, then you are right.  However, 
that does not mean that the function could not process syntactically invalid 
markup correctly; the result just might not be what you expect, as there is 
no specified definition of correctness with regard to parsing syntactically 
invalid markup.

>>>>> ut this doesn't actually matter, since the input string should be HTML
>>>>> encoded anyway, so all '<' characters should be escaped as '&lt;' - so
>>>>> all actual '<' characters will indeed be tags :-)
>>>>
>>>>You are not making sense.  The *input* data should *never* be "HTML
>>>>encoded".
> 
> Wait, didn't you just say the opposite?

No, I did not.

>>> Then I must have completely misunderstood something here. I thought the
>>> whole point of strip_tags() was to remove all HTML tags from the input
>>> string.
>>
>>Yes, HTML *tags*.
> 
> Good, we agree on something.

But do you *really* know what a HTML tag is?  It sure does not look like 
that.

>>> Therefore the input has to be HTML or the function is pointless.
>>
>>You have defined "HTML-encoded" above to mean that "<" would be "&lt;".
>>(Which is a common, and semantically correct definition of the term.)
>>
>>So HTML-*encoded* strings are _not_ HTML *markup*; by definition, there
>>are no tags in them.
> 
> Agreed again.

So, AISB, *HTML-encoded strings* (which is a different animal than HTML 
markup) are not supposed to be the input to this function or any form of 
server-side PHP processing.  You should not get HTML-encoded strings from 
the client and you should not store HTML-encoded strings in your database.

Instead, you should store the plain markup, and HTML-encode it for output if 
necessary.  The best approach is, of course, not to store HTML markup at all 
in a database (data storage should be independent of output) but that is not 
always possible.

>>> Unless the idea is to remove rogue HTML tags from a plain text string,
>> ISTM that is the general idea.
> 
> Oh dear, we're going to start disagreeing again here.

Define: rogue HTML tags.

>> Some HTML elements (which consist of start tag, optional content and
>> optional end tag, depending on the element type), are potentially
>> detrimental to the expected display and functionality of a
>> Web document.  For example, consider that people were allowed to use
>> text-formatting elements in a blog comment, but where not allowed to
>> insert `script' elements (to avoid XSS) or `img' and `object' elements
>> (to avoid reduction of loading speed and interference with other
>> multimedia on the site); you would only list the text-formatting elements
>> in the function's second parameter then.
>>
>>Other people might want to remove HTML tags altogether, leaving only the
>>text content of the document (fragment).
> 
> OK, so given no parameters other than the input string, the behaviour of
> strip_tags() is to remove all HTML tags from the input string. Correct?

Correct.
 
> You have just said that you believe the input string should be plain text,

No, I did not.  You misunderstood, probably because you cannot tell what is 
a HTML tag or what you mean by "HTML-encoded string".

>>> in which case my original point about it assuming all < symbols are tags
>>
>>The `<' character is an STAGO (STart Tag Open) delimiter in SGML-based
>>markup languages.  It delimits a start tag on the left-hand side (a `>'
>>character delimits it on the right-hand side).  Obviously, therefore it
>>cannot be a tag itself.
> 
> Sorry but that is extremely pedantic.

That is a luser's attitude.  Correct and unambiguous terminology is 
paramount to understanding and learning.  `<' is _not_ a tag; it is a tag 
*delimiter*.

> I think it's obvious what I meant -

I do not think you know what you are talking about, so you are modifying 
your terminology as you go (like, "a tag is `<…>'", "a tag is &lt;", "a tag 
is `<'").  Of course, this is where misconceptions are created, very common 
in beginners.

> Just to clarify, I meant to say "...in which case my original point about
> it assuming all < symbols *are the beginning of* tags..."

ACK.

>>> remains valid - it's crap and useless for this.
>> Evidently, you do not know what you are talking about.
> 
> No need for rudeness is there?

Given your statements, it is a matter of fact.  (A fact that can be changed 
by you, and eventually *only* you.)  If you cannot deal with that, please 
stop wasting my time.

On a side note, you can tell a troll from a regular when you see the former 
contributing nothing but ad-hominem attack and misinformation.  Forged 
address headers are also a strong indication of a troll.  Any form of 
continued anti-social behavior, really.

-- 
PointedEars

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web