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

Groups > comp.lang.php > #6702

Re: strip_tags function

Followups directed to: comp.lang.php

Show all headers | View raw

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

Back to comp.lang.php | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

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

csiph-web