(New?) (Replay) XML headers do not escape special characters

[TGYoshi]

This image shows the XML header chunk of a replay:


The & symbol isn't escaped at all. As a result, "normal" XML parsing fails.

[Xymph]

That's a long-standing issue. That's why the XML parsing in my GBX Data Fetcher module escapes them beforehand:

Code: Select all

  protected function parseXMLstring()
  {
[...]
    // escape '&' characters unless already a known entity
    $xml = preg_replace('/&(?!(?:amp|quot|apos|lt|gt);)/', '&', $this->xml);
[...]
  }

[TGYoshi]

Well, that's just stupid then .

I suspect (or hope) < and > are escaped properly, so why not make sure & is escaped as well?

[The_Big_Boo]

I suspect (or hope) < and > are escaped properly, so why not make sure & is escaped as well?

They're actually not as you can notice in Xymph's regex (lt and gt are respectively < and >)

[TGYoshi]

I suspect (or hope) < and > are escaped properly, so why not make sure & is escaped as well?

They're actually not as you can notice in Xymph's regex (lt and gt are respectively < and >)

Doesn't it search for & without a lt/gt/.. behind it, then replace it?
So I suspect < and > is escaped, but & isn't for some stupid reason.

[Slig]

So I suspect < and > is escaped, but & isn't for some stupid reason.

Yes. The problem is that of course we can expect it to be corrected one day, but anyway to support existing replays you are anyway forced to handle it like it is actually (and so don't really care if it is corrected or not)

[TGYoshi]

The map's name got & escaped properly. zzz

Thanks for the regex anyway, that will probably be the 'solution' for this .

[Xymph]

Yes, special chars are properly escaped in other fields of the XML header, but not in all fields - like the zone. So the regex covers both situations indeed.