Tach!

Das vorliegende Problem kann sein, dass andere Whitespace-Zeichen an Stellen gestanden haben, an denen Leerzeichen hätten stehen sollen. Das hätte auch eine falsch platzierte BOM sein können.
How so? Die Meldung "Unexpected T_VARIABLE" besagt, dass der PHP-Interpreter ein $-Zeichen gefolgt von einem gültigen Bezeichner für eine Variable gefunden hat, das aber an einer Stelle, wo dieses Token nicht hätte vorkommen dürfen. Es wäre also IMO immer noch spannend zu wissen, was die vermeintliche PHP-Datei von fritz wirklich enthielt. Aber das werden wir wohl nicht mehr herausfinden.

Das schien mir bisher die plausibelste Vermutung zu sein. Weil du daran gezweifelt hast, hab ich das mal probiert. Ein NBSP zwischen <?php und echo führt dazu, dass PHP das <?php nicht mehr erkennt und den ganzen Code zur Ausgabe bringt (siehe Quelltextansicht des Browsers, denn der denkt sich am < begänne ein Tag, das man nicht ausgeben sondern interpretieren soll).

Ein NBSP zwischen echo und $variable bringt die vorliegende Fehlermeldung.

Er schrieb ja, dass er das aus einem HTML-Dokument im Browser herauskopiert habe. Klar, da kommen alle möglichen Formen von Whitespace in Frage, aber die würden für PHP nicht wie eine Variable aussehen.

Richtig. Das NBSP verlängert sozusagen das echo, so dass es kein Schlüsselwort mehr ist, sondern wie beispielsweise ein Funktionsname oder eine Konstante aussieht. Dann kommt da die Variable und es sieht am Ende wie bezeichner$variable aus, und das ist ab dem $ keine gültige Syntax mehr. An der Stelle darf keine Variable vorkommen, da hat das PHP Recht.

Der Regex für Funktionsnamen und Konstanten ist [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]* und das NBSP ist \xA0 oder \xC2\xA0, passt also in den Bereich \x7F bis \xFF und wird somit zum Bestandteil des Namens.

dedlfix.