Ошибка разбора синтаксическая ошибка неожиданный

Что такое синтаксические ошибки?

PHP принадлежит к языкам программирования C-стиля и императива . Он имеет жесткие правила грамматики, которые он не может восстановить после столкновения с неуместными символами или идентификаторами. Он не может угадать ваши намерения кодирования.

Самые важные советы

Есть несколько основных мер предосторожности, которые вы всегда можете предпринять:

• Используйте правильный отступ кода или используйте любой высокий стиль кодирования.
  Считываемость предотвращает нарушения.

• Используйте IDE или редактор для PHP с подсветкой синтаксиса .
  Что также помогает с балансировкой парсеров / кронштейнов.

  

• Прочтите ссылку на язык и примеры в руководстве.
  Дважды, чтобы стать достаточно опытным.

Как интерпретировать ошибки парсера?

Типичное сообщение с синтаксической ошибкой гласит:

Ошибка анализа: синтаксическая ошибка, неожиданный T_STRING , ожидающий ‘ ; ‘ в файле.php в строке 217

В котором перечислены возможные места синтаксической ошибки. См. Указанное имя файла и номер строки .

Прозвище, такое как T_STRING объясняет, какой символ синтаксический анализатор / токенизатор не смог обработать окончательно. Однако это не обязательно является причиной синтаксической ошибки.

Важно также изучить предыдущие строки кода . Часто синтаксические ошибки – это просто неудачи, которые произошли ранее. Номер строки ошибки – это то, где синтаксический анализатор окончательно отказался обрабатывать все это.

Устранение синтаксических ошибок

Существует множество подходов к сужению и исправлению синтаксических икота.

• Откройте указанный исходный файл. Посмотрите на указанную строку кода .

  • Для беглых строк и неуместных операторов это обычно означает, что вы находите виновника.

  • Прочтите строку слева направо и представьте, что делает каждый символ.

• Более регулярно вам нужно смотреть на предыдущие строки .

  • В частности, отсутствует ; точки с запятой отсутствуют в предыдущей строке end / statement. (По крайней мере, с стилистической точки зрения.)

  • Если { code blocks } неправильно закрыты или вложены, вам может потребоваться еще больше изучить исходный код. Для упрощения используйте надлежащий код .

• Посмотрите на раскраску синтаксиса !

  • Строки, переменные и константы должны иметь разные цвета.

  • Операторы +-*/. также должны быть тонированными. Иначе они могут оказаться в неправильном контексте.

  • Если вы видите, что раскраска строк слишком длинная или слишком короткая, вы обнаружите неэкранированный или отсутствующий закрывающий " или ' строковый маркер.

  • Наличие двух одинаковых символов пунктуации рядом друг с другом также может означать проблему. Обычно операторы одиноки, если это не ++ или -- или круглые скобки, следующие за оператором. Две строки / идентификаторы, которые непосредственно следуют друг за другом, являются неправильными в большинстве контекстов.

• Пробел – ваш друг .
  Следуйте любому стилю кодировки.

• Временно разбить длинные линии.

  • Вы можете свободно добавлять новые строки между операторами или константами и строками. Затем анализатор будет конкретизировать номер строки для ошибок синтаксического анализа. Вместо того, чтобы смотреть на очень длинный код, вы можете выделить отсутствующий или неуместный синтаксический символ.

  • Разделить сложные, if утверждения в разные или вложенные условия.

  • Вместо длинных математических формул или логических цепей используйте временные переменные для упрощения кода. (Более читаемый = меньше ошибок.)

  • Добавьте новые строки между:

    1. Код, который вы можете легко идентифицировать как правильный,
    2. Части, о которых вы не знаете,
    3. И строки, на которые жалуется парсер.

    Разделение длинных блоков кода действительно помогает найти происхождение ошибок синтаксиса.

• Прокомментируйте код нарушения.

  • Если вы не можете изолировать источник проблемы, начните комментировать (и тем самым временно удалить) блоки кода.

  • Как только вы избавитесь от ошибки синтаксического анализа, вы обнаружили источник проблем. Посмотрите внимательно.

  • Иногда вы хотите временно удалить полные блоки функций / методов. (В случае непревзойденных фигурных скобок и кода с неправильным отступом).

  • Если вы не можете решить проблему синтаксиса, попробуйте переписать разделы с комментариями с нуля .

• Поскольку новичок избегает некоторых запутанных конструкций синтаксиса.

  • Тройной ? : ? : оператор условия может компактный код и действительно полезен. Но во всех случаях это не способствует удобочитаемости. Предпочитайте простые выражения, if показаны.

  • Альтернативный синтаксис PHP ( if: / elseif: / endif; ) является общим для шаблонов, но, возможно, менее прост в использовании, чем обычные { code } блоки.

• Наиболее распространенными ошибками новичка являются:

  • Отсутствуют точки с запятой ; для завершающих операторов / строк.

  • Неправильные строковые кавычки для " или ' и неэксклюзивных кавычек внутри.

  • Забытые операторы, в частности, для строки . конкатенации.

  • Несбалансированный ( круглые скобки ) . Подсчитайте их в строке отчета. Есть ли их равное число?

• Не забывайте, что решение одной проблемы синтаксиса может выявить следующее.

  • Если вы сделаете одну проблему, уходите, но другой появляется в некотором коде ниже, вы в основном на правильном пути.

  • Если после редактирования новая синтаксическая ошибка возникает в той же строке, ваше попытка изменения может быть неудачной. (Не всегда, хотя.)

• Восстановите резервную копию ранее работающего кода, если вы не можете его исправить.

  • Принять систему управления версиями исходного кода. Вы всегда можете просмотреть diff сломанной и последней рабочей версии. Что может быть полезным для понимания проблемы синтаксиса.

• Невидимые бродячие символы юникода : в некоторых случаях вам нужно использовать hexeditor или другой редактор / просмотрщик на вашем источнике. Некоторые проблемы не могут быть найдены только с точки зрения вашего кода.

  • Попробуйте grep --color -P -n "[x80-xFF]" file.php качестве первого измерения, чтобы найти символы, отличные от ASCII.

  • В частности, спецификации, пробелы нулевой ширины или неразрывные пробелы, а также интеллектуальные кавычки, могут найти свой путь в исходный код.

• Позаботьтесь о том, какие типы строк будут сохранены в файлах.

  • PHP просто чтит n новых строк, а не r возвращает каретки.

  • Иногда это проблема для пользователей MacOS (даже для OS X для неверно настроенных редакторов).

  • Он часто возникает только как проблема при использовании однострочных // или # комментариев. Многострочные /*...*/ комментарии редко мешают парсеру, когда разрывы строк игнорируются.

• Если ваша синтаксическая ошибка не передается через Интернет :
  Бывает, что на вашем компьютере есть синтаксическая ошибка. Но публикация того же файла в Интернете больше не демонстрирует его. Что может означать только одно из двух:

  • Вы смотрите на неправильный файл!

  • Или ваш код содержал невидимый бездомный Unicode. (См. Выше)
    Вы можете легко узнать: просто скопируйте свой код из веб-формы в текстовый редактор.

• Проверьте свою версию PHP . Не все синтаксические конструкции доступны на каждом сервере.

• Не используйте зарезервированные ключевые слова PHP как идентификаторы для функций / методов, классов или констант.

• Trial-and-error – ваше последнее средство.

Если все остальное не удается, вы всегда можете отправить сообщение об ошибке. Символы синтаксиса не так легко найти (Stack Overflow сам индексируется SymbolHound, хотя). Поэтому перед тем, как найти что-то важное, вы можете просмотреть еще несколько страниц.

Дальнейшие руководства:

• Основы отладки PHP Дэвидом Скларом
• Исправление ошибок PHP от Джейсона Маккрири
• Ошибки PHP – 10 распространенных ошибок Марио Лурига
• Общие ошибки и решения PHP
• Устранение неполадок и исправление веб-сайта WordPress
• Руководство по сообщениям об ошибках PHP для дизайнеров – Smashing Magazine

Белый экран смерти

Если ваш сайт просто пуст, то, как правило, причиной является синтаксическая ошибка.
Включите их отображение:

• error_reporting = E_ALL
• display_errors = 1

В вашем php.ini вообще или через .htaccess для mod_php или даже .user.ini с настройками FastCGI.

Включение этого в сломанный скрипт слишком поздно, потому что PHP не может даже интерпретировать / запускать первую строку. Быстрое обходное решение создает сценарий оболочки, например test.php :

 <?php error_reporting(E_ALL); ini_set("display_errors", 1); include("./broken-script.php"); 

Затем вызовите неисправный код, обратившись к этому сценарию оболочки.

Он также помогает включить PHPs error_log и заглянуть в ваш webservers error.log при error.log сценария с ответами HTTP 500.

Я думаю, что эта тема полностью перегружена / сложна, использование IDE – это способ полностью избежать любых синтаксических ошибок. Я бы даже сказал, что работа без IDE является непрофессиональной. Зачем ? Поскольку современные IDE проверяют ваш синтаксис после каждого вводимого вами символа. Когда вы кодируете, и вся ваша строка становится красной, и большое предупреждение показывает вам точный тип и точное местоположение синтаксической ошибки, тогда нет абсолютно никакой необходимости искать другое решение.

Использование синтаксической проверки IDE означает:

Вы (эффективно) никогда не столкнетесь с синтаксическими ошибками снова, просто потому, что видите их правильно по мере ввода. Шутки в сторону.

Отличные IDE с проверкой синтаксиса (все они доступны для Linux, Win и Mac):

1. NetBeans [бесплатно]
2. PHPStorm [$ 199 USD]
3. Eclipse с плагином PHP [бесплатно]
4. Sublime [$ 80 USD] (в основном текстовый редактор, но расширяемый с помощью плагинов, таких как PHP Syntax Parser )

Неожиданные [

В наши дни неожиданная [ скобка массива обычно встречается на устаревших версиях PHP. Синтаксис короткого массива доступен с PHP > = 5.4 . Старые установки поддерживают только array() .

 $php53 = array(1, 2, 3); $php54 = [1, 2, 3]; ⇑ 

Функция разыменования функции массива также не доступна для старых версий PHP:

 $result = get_whatever()["key"]; ⇑ 

Ссылка. Что означает эта ошибка в PHP? – «Синтаксическая ошибка, неожиданная [ » показывает наиболее распространенные и практические обходные пути.

Хотя вам всегда лучше обновлять вашу установку PHP. Для общих планов SetHandler php56-fcgi первое исследование, если, например, SetHandler php56-fcgi можно использовать для включения более новой среды выполнения.

Смотрите также:

• Синтаксис PHP для функции функции разыменования → возможно с PHP 5.4
• PHP: синтаксическая ошибка, неожиданная ‘[‘
• Сокращение для массивов: существует литальный синтаксис, например {} или []?
• PHP 5.3.10 и ошибка синтаксиса PHP 5.5.3 неожиданно «[‘
• PHP Разница между array () и []
• Синтаксис синтаксиса PHP-массива Ошибка левой квадратной скобки «[»

Кстати, есть также препроцессоры и синтаксические down-преобразователи PHP 5.4, если вы действительно цепляетесь за более старые и медленные версии PHP.

Другие причины неожиданных [ синтаксических ошибок

Если это не рассогласование PHP-версии, то это часто случается с синтаксической ошибкой опечатки или новичка:

• Вы не можете использовать объявления / выражения свойств массива в классах , даже в PHP7.

   protected $var["x"] = "Nope"; ⇑ 

• Путаница [ с открытием фигурных скобок { или parens ( это общий надзор.

   foreach [$a as $b) ⇑ 

  Или даже:

   function foobar[$a, $b, $c] { ⇑ 

• Или пытаемся разыменовать константы (до PHP 5.6) как массивы:

   $var = const[123]; ⇑ 

  По крайней мере, PHP интерпретирует const как постоянное имя.

  Если вы хотите получить доступ к переменной массива (что является типичной причиной здесь), добавьте старшую $ sigil, поэтому она станет $varname .

Неожиданный ] закрывающий квадратный кронштейн

Это несколько реже, но есть также синтаксические аварии с завершающим массивом ] .

• Опять же несоответствие с ) скобками или фигурными фигурными скобками распространены:

   function foobar($a, $b, $c] { ⇑ 

• Или пытаемся закончить массив, где его нет:

   $var = 2]; 

  Это часто встречается в объявлениях с несколькими строками и вложенными массивами.

   $array = [1,[2,3],4,[5,6[7,[8],[9,10]],11],12]],15]; ⇑ 

  Если это так, используйте IDE для сопоставления скобок, чтобы найти какое-либо преждевременное закрытие массива. По крайней мере, используйте большее расстояние и новые строки, чтобы сузить его.

Неожиданный T_VARIABLE

«Неожиданное T_VARIABLE » означает, что существует буквальное имя $variable , которое не вписывается в текущую структуру выражений / операторов.

1. Отсутствует точка с запятой

   Это чаще всего указывает на отсутствующую точку с запятой в предыдущей строке. Переменные присваивания, следующие за заявлением, являются хорошим показателем, на который следует обратить внимание:

     ⇓ func1() $var = 1 + 2; # parse error in line +2 

2. Конкатенация строк

   Частые неудачи – это конкатенации строк с забытыми . оператор:

     ⇓ print "Here comes the value: " $value; 

   Кстати, вы должны предпочесть строчную интерполяцию (базовые переменные в двойных кавычках), когда это помогает читаемости. Это позволяет избежать этих синтаксических проблем.

   Строковая интерполяция – это основная функция языка сценариев . Не стыдно использовать его. Игнорируйте любую рекомендацию по микрооптимизации относительно переменной . ускорение конкатенации. Это не.

3. Отсутствующие операторы выражения

   Конечно, одна и та же проблема может возникнуть в других выражениях, например арифметических операций:

     ⇓ print 4 + 7 $var; 

   PHP не может угадать здесь, если переменная должна быть добавлена, вычтена или сравнена и т. Д.

4. Списки

   То же самое для списков синтаксиса, например, в массивах, где парсер также указывает ожидаемую запятую , например:

     ⇓ $var = array("1" => $val, $val2, $val3 $val4); 

   Или списки параметров функций:

     ⇓ function myfunc($param1, $param2 $param3, $param4) 

   Эквивалентно вы видите это со list или global утверждениями или при отсутствии ; точка с запятой в цикле for .

5. Объявления классов

   Эта ошибка парсера также встречается в объявлениях классов . Вы можете назначать только статические константы, а не выражения. Таким образом, парсер жалуется на переменные в качестве назначенных данных:

    class xyz { ⇓ var $value = $_GET["input"]; 

   Непревзойденные } закрывающиеся фигурные скобки могут, в частности, привести сюда. Если метод заканчивается слишком рано (используйте правильный отступ!), Тогда блуждающая переменная обычно неправильно помещается в тело объявления класса.

6. Переменные после идентификаторов

   Вы также можете никогда не иметь переменную, следуя за идентификатором напрямую:

     ⇓ $this->myFunc$VAR(); 

   Кстати, это распространенный пример, когда, возможно, предполагалось использовать переменные переменные . В этом случае поиск свойства переменной с $this->{"myFunc$VAR"}(); например.

   Имейте в виду, что использование переменных переменных должно быть исключением. Новички часто пытаются использовать их слишком случайно, даже когда массивы будут проще и более уместны.

7. Отсутствие парсов после языковых конструкций

   Скорейшее типирование может привести к забытой открывающей скобке для операторов if и for и foreach :

     ⇓ foreach $array as $key) { 

   Решение: добавьте недостающее открытие ( между оператором и переменной.

8. Else не ожидает условий

     ⇓ else ($var >= 0) 

   Решение. Удалите условия из else или используйте elseif .

9. Необходимые скобки для закрытия

     ⇓ function() uses $var {} 

   Решение. Добавьте скобки вокруг $var .

10. Невидимые пробелы

    Как упоминалось в справочном ответе «Невидимый бездомный Юникод» (например, неразрывное пространство ), вы также можете увидеть эту ошибку для ничего не подозревающего кода:

     <?php ⇐ $var = new PDO(...); 

    Это довольно распространено в начале файлов и для копирования и вставки кода. Проверьте с помощью шестнадцатеричного кода, если ваш код визуально не содержит синтаксическую проблему.

Смотрите также

• Поиск: неожиданный T_VARIABLE

Неожиданное T_CONSTANT_ENCAPSED_STRING
Неожиданный T_ENCAPSED_AND_WHITESPACE

T_CONSTANT_ENCAPSED_STRING имена T_CONSTANT_ENCAPSED_STRING и T_ENCAPSED_AND_WHITESPACE относятся к цитированным "string" литералам.

Они используются в разных контекстах, но проблема синтаксиса весьма схожа. T_ENCAPSED … предупреждения встречаются в контексте с двойной кавычкой строки, в то время как T_CONSTANT … строки часто сбиваются с помощью простых выражений или утверждений PHP.

1. Неверная переменная интерполяция

   И это чаще всего встречается при некорректной интерполяции переменных PHP:

     ⇓ ⇓ echo "Here comes a $wrong['array'] access"; 

   Цитирование ключей массивов является обязательным в контексте PHP. Но в двойных кавычках (или HEREDOC) это ошибка. Парсер жалуется на содержащуюся в одиночном кавычке 'string' , потому что обычно он ожидает там литерального идентификатора / ключа.

   Точнее, это справедливо для использования простого синтаксиса в стиле PHP2 в двойных кавычках для ссылок на массивы:

    echo "This is only $valid[here] ..."; 

   Вложенные массивы или более глубокие ссылки на объекты, однако, требуют синтаксиса сложного фигурного синтаксиса:

    echo "Use {$array['as_usual']} with curly syntax."; 

   Если вы не уверены, это обычно безопаснее использовать. Его часто считают более читаемым. И лучшие IDE на самом деле используют для этого разную синтаксическую раскраску.

2. Отсутствует конкатенация

   Если строка следует за выражением, но не имеет конкатенации или другого оператора, то вы увидите, что PHP жалуется на строковый литерал:

     ⇓ print "Hello " . WORLD " !"; 

   Хотя это очевидно для вас и меня, PHP просто не может догадаться, что строка должна быть добавлена ​​туда.

3. Сбивающие с толку строковые кавычки

   Такая же синтаксическая ошибка возникает при смешивании строковых разделителей . Строка, начинающаяся с одной или двух котировки, также заканчивается тем же.

     ⇓ print "<a href="' . $link . '">click here</a>"; ⌞⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟ 

   Этот пример начинался с двойных кавычек. Но двойные кавычки также предназначались для атрибутов HTML. Предполагаемый оператор конкатенации внутри, однако, интерпретировался как часть второй строки в одинарных кавычках.

   Совет . Установите редактор / IDE для использования слегка отличной раскраски для одиночных и двойных кавычек. (Это также помогает с логикой приложения, например, использовать двойные кавычки для текстового вывода и одиночные кавычки только для константоподобных значений.)

   Это хороший пример, когда вы не должны выходить из двойных кавычек в первую очередь. Вместо этого просто используйте правильные " для атрибутов HTML-атрибутов»:

    print "<a href="{$link}">click here</a>"; 

   Хотя это также может привести к путанице в синтаксисе, все лучшие IDE / редакторы снова помогают раскрасить экранированные кавычки по-разному.

4. Отсутствует стартовая цитата

   Эквивалентно забытое открытие " / ' цитирует рецепт ошибок парсера:

     ⇓ make_url(login', 'open'); 

   Здесь ', ' станет строковым литералом после голого слова, когда, очевидно, login должен быть строковым параметром.

5. Списки массивов

   Если вы пропустите запятую в блоке создания массива, синтаксический анализатор увидит две последовательные строки:

    array( ⇓ "key" => "value" "next" => "....", ); 

   Обратите внимание, что в последней строке всегда может содержаться дополнительная запятая, но игнорировать одно между ними непростительно. Это трудно обнаружить без подсветки синтаксиса.

6. Списки параметров функции

   То же самое для вызовов функций :

     ⇓ myfunc(123, "text", "and" "more") 

7. Беглые строки

   Общим вариантом являются довольно просто забытые терминаторы строк:

     ⇓ mysql_evil("SELECT * FROM stuffs); print "'ok'"; ⇑ 

   Здесь PHP жалуется на два строковых литерала, непосредственно следуя друг за другом. Но настоящая причина – незакрытая предыдущая строка, конечно.

Смотрите также

• Интерполяция (двойная кавычка) ассоциативных массивов в PHP
• PHP – синтаксическая ошибка, неожиданный T_CONSTANT_ENCAPSED_STRING
• Ошибка синтаксиса, неожиданный T_CONSTANT_ENCAPSED_STRING в PHP
• Неожиданная ошибка T_CONSTANT_ENCAPSED_STRING в SQL Query

Неожиданный конец $

Когда PHP говорит о «неожиданном $end », это означает, что ваш код закончился преждевременно. (Это сообщение немного вводит в заблуждение, когда принято буквально. Речь идет не о переменной с именем «end end», как иногда предполагают новички. Она относится к «концу файла», EOF .)

Причина. Небаланс { и } для кодовых блоков / и объявлений функций или классов.

Это почти всегда связано с отсутствующей фигурной скобкой, чтобы закрыть предыдущие блоки кода.

• Опять же, используйте правильные отступы, чтобы избежать таких проблем.

• Используйте IDE с привязкой к скобкам, чтобы узнать, где } .
  В большинстве IDE и текстовых редакторах есть сочетания клавиш:

  • Netbeans, PhpStorm, Komodo: Ctrl [ и Ctrl ]
  • Eclipse, Aptana: Ctrl Shift P
  • Atom, Sublime: Ctrl m – Zend Studio Ctrl M
  • Geany, Notepad ++: Ctrl B – Joe: Ctrl G – Emacs: CMn – Vim: %

Большинство IDE также выделяют соответствующие фигурные скобки, скобки и парсеры.
Это позволяет довольно легко проверить их соотношение:

Неограниченные выражения

И Unexpected $end ошибка синтаксиса / парсера Unexpected $end также может возникать для неиспользуемых выражений или операторов:

• $var = func(1,
?> EOF

Итак, сначала посмотрите на конец скриптов. Конечный ; часто избыточно для последнего оператора в любом скрипте PHP. Но у вас должен быть такой. Именно потому, что он сужает такие проблемы синтаксиса.

Отметные маркеры HEREDOC

Другое распространенное явление появляется с помощью строк HEREDOC или NOWDOC . Конечный маркер игнорируется ведущими пробелами / вкладками / etc .:

 print <<< END Content... Content.... END; # ↑ terminator isn't exactly at the line start 

Поэтому анализатор предполагает, что строка HEREDOC продолжается до конца файла (отсюда «Неожиданный конец $»). Практически все IDE и редакторы с подсветкой синтаксиса сделают это очевидным или предупредит об этом.

Альтернативный синтаксис

Несколько реже вы можете увидеть эту синтаксическую ошибку при использовании альтернативного синтаксиса для операторов / блоков кода в шаблонах. Использование if: и else: и отсутствующий endif; например.

Смотрите также:

• Ошибка синтаксиса PHP «неожиданный конец $ end»
• Ошибка анализа: ошибка синтаксиса, неожиданный конец файла в моем PHP-коде
• Синтаксис ошибки синтаксического анализа неожиданный конец файла php
• Ошибка PHP Parse: ошибка синтаксиса, неожиданный конец файла в представлении Codeigniter
• Ошибка анализа: синтаксическая ошибка, неожиданный конец файла (скрипт регистрации)
• «Ошибка анализа: синтаксическая ошибка, неожиданный конец $». Для моего назначения регистрации uni
• Исправление ошибок PHP: Ошибка PHP # 3: Неожиданный конец файла

Неожиданный T_STRING

T_STRING является немного неправильным. Он не относится к цитируемой "string" . Это означает, что был обнаружен необработанный идентификатор. Это может быть от bare слов до оставшихся CONSTANT или имен функций, забытых строк без кавычек или любого простого текста.

1. Неверные строки

   Однако эта синтаксическая ошибка является наиболее распространенной для неверных строк. Любая неопределенная и бродячая " или ' цитата образует недопустимое выражение:

     ⇓ ⇓ echo "<a href="http://example.com">click here</a>"; 

   Выделение синтаксиса сделает такие ошибки супер очевидными. Важно помнить об использовании обратных косых черт для экранирования " двойных кавычек» или ' одиночных кавычек», в зависимости от того, как использовался в качестве оболочки строки .

   • Для удобства вы должны предпочесть внешние одинарные кавычки при выводе простого HTML с двойными кавычками внутри.
   • Используйте двойные кавычки, если вы хотите интерполировать переменные, но затем следите за тем, чтобы избежать буквенных " двойных кавычек».
   • Для более длинного выхода предпочитайте несколько строк echo / print вместо вылета и выхода. Еще лучше рассмотрим раздел HEREDOC .

   См. Также В чем разница между строками с одним кавычком и двойными кавычками в PHP?

2. Незакрытые строки

   Если вы пропустите закрытие " тогда синтаксическая ошибка, как правило, будет реализована позже. Непривязанная строка будет часто потреблять бит кода до следующего предполагаемого значения строки:

     ⇓ echo "Some text", $a_variable, "and some runaway string ; success("finished"); ⇯ 

   Это не просто буквальный T_STRING который парсер может протестовать тогда. Еще одним частым изменением является Unexpected '>' для некотируемого буквального HTML.

3. Непрограммируемые строковые кавычки

   Если вы копируете и вставляете код из блога или веб-сайта, иногда вы получаете неверный код. Типографические котировки не соответствуют ожиданиям PHP:

    $text = 'Something something..' + ”these ain't quotes”; 

   Типографические / умные кавычки являются символами Юникода. PHP рассматривает их как часть смежного алфавитно-цифрового текста. Например, ”these интерпретируются как константный идентификатор. Но любой следующий текстовый литерал тогда рассматривается как bareword / T_STRING парсером.

4. Отсутствует точка с запятой; еще раз

   Если у вас есть неисчерпаемое выражение в предыдущих строках, любая следующая инструкция или языковая конструкция рассматривается как необработанный идентификатор:

     ⇓ func1() function2(); 

   PHP просто не может знать, хотите ли вы запустить две функции за другой, или если вы хотели бы умножить их результаты, добавить их, сравнить их или запустить только один || или другой.

5. Короткие открытые теги и заголовки <?xml в сценариях php

   Это довольно редко. Но если short_open_tags включены, то вы не можете начинать свои PHP-скрипты с объявления XML :

     ⇓ <?xml version="1.0"?> 

   PHP увидит <? и вернуть его для себя. Он не поймет, для чего предназначен бродячий xml . Он будет интерпретироваться как постоянный. Но version будет рассматриваться как еще один литерал / константа. И поскольку анализатор не может понять два последующих литерала / значения без оператора выражения между ними, это будет сбой парсера.

6. Невидимые символы Юникода

   Самой отвратительной причиной для синтаксических ошибок являются символы Юникода, такие как неразрывное пространство . PHP позволяет использовать символы Unicode в качестве имен идентификаторов. Если вы получаете жалобу на парсер T_STRING для совершенно невосприимчивого кода, например:

    <?php print 123; 

   Вам нужно вырвать другой текстовый редактор. Или даже гекседектор. То, что выглядит как простые пространства и новые строки здесь, может содержать невидимые константы. Java-IDE иногда не обращают внимания на спецификацию UTF-8, искаженные внутри, пространства с нулевой шириной, разделители абзацев и т. Д. Попытайтесь переиздать все, удалить пробелы и снова добавить обычные пробелы.

   Вы можете сузить его, добавив избыточность ; разделители операторов при каждом запуске линии:

    <?php ;print 123; 

   Дополнительный ; точка с запятой преобразует предыдущий невидимый символ в неопределенную константную ссылку (выражение как выражение). Это в свою очередь делает PHP полезным уведомлением.

Неожиданный (

Открывающиеся круглые скобки обычно следуют языковым конструкциям, таким как if / foreach / for / array / list или запускают арифметическое выражение. Они синтаксически неверны после "strings" , предыдущего () , одиночного $ и в некоторых типичных контекстах объявления.

1. Параметры объявления функции

   Более редкое появление этой ошибки пытается использовать выражения в качестве параметров функции по умолчанию . Это не поддерживается даже в PHP7:

    function header_fallback($value, $expires = time() + 90000) { 

   Параметры в объявлении функции могут быть только литеральными значениями или постоянными выражениями. В отличие от функций invocations, где вы можете свободно использовать whatever(1+something()*2) и т. Д.

2. По умолчанию свойства класса

   То же самое для деклараций членов класса , где допускаются только значения литерала / константы, а не выражения:

    class xyz { ⇓ var $default = get_config("xyz_default"); 

   Поместите такие вещи в конструктор.
   См. Также Почему атрибуты PHP не позволяют выполнять функции?

   Снова отметим, что PHP 7 разрешает только var $xy = 1 + 2 +3; там постоянные выражения.

3. Синтаксис Javascript в PHP

   Использование Javascript или синтаксиса jQuery не будет работать на PHP по понятным причинам:

    <?php ⇓ print $(document).text(); 

   Когда это происходит, оно обычно указывает на неисчерпаемую предыдущую строку; и буквальные <script> разделы, попадающие в контекст кода PHP.

4. isset(()), empty, key, next, current

   Both isset() and empty() are language built-ins, not functions. They need to access a variable directly . If you inadvertently add a pair of parentheses too much, then you’d create an expression however:

     ⇓ if (isset(($_GET["id"]))) { 

   Same applies to any language construct that requires implicit variable name access. These built-ins are part of the language grammer, therefore don’t permit decorative extra parens.

   User-level functions that require a variable reference -but get an expression result passed- lead to runtime errors instead.

Unexpected )

1. Absent function parameter

   You cannot have stray commas last in a function call . PHP expects a value there and thusly complains about an early closing ) parenthesis.

     ⇓ callfunc(1, 2, ); 

   A trailing comma is only allowed in array() or list() constructs.

2. Unfinished expressions

   If you forget something in an arithmetic expression, then the parser gives up. Because how should it possibly interpret that:

     ⇓ $var = 2 * (1 + ); 

   And if you forgot the closing ) even, then you’d get a complaint about the unexpected semicolon instead.

3. Foreach as constant

   For forgotten variable $ prefixes in control statements you will see:

     ↓ ⇓ foreach ($array as wrong) { 

   PHP here sometimes tells you it expected a :: instead. Because a class::$variable could have satisfied the expected $variable expression..

Unexpected {

Curly braces { and } enclose code blocks. And syntax errors about them usually indicate some incorrec nesting.

1. Unmatched subexpressions in an if

   Most commonly unbalanced ( and ) are the cause if the parser complains about the opening curly { appearing too early. Простой пример:

     ⇓ if (($x == $y) && (2 == true) { 

   Count your parens or use an IDE which helps with that. Also don’t write code without any spaces. Показатели удобочитаемости.

2. { and } in expression context

   You can’t use curly braces in expressions. If you confuse parentheses and curlys, it won’t comply to the language grammer:

     ⇓ $var = 5 * {7 + $x}; 

   There are a few exceptions for identifier construction, such as local scope variable ${references} .

3. Variable variables or curly var expressions

   This is pretty rare. But you might also get { and } parser complaints for complex variable expressions:

     ⇓ print "Hello {$world[2{]} !"; 

   Though there’s a higher likelihood for an unexpected } in such contexts.

Unexpected }

When getting an «unexpected } » error, you’ve mostly closed a code block too early.

1. Last statement in a code block

   It can happen for any unterminated expression.

   And if the last line in a function/code block lacks a trailing ; semicolon:

    function whatever() { doStuff() } ⇧ 

   Here the parser can’t tell if you perhaps still wanted to add + 25; to the function result or something else.

2. Invalid block nesting / Forgotten {

   You’ll sometimes see this parser error when a code block was } closed too early, or you forgot an opening { even:

    function doStuff() { if (true) ⇦ print "yes"; } } ⇧ 

   In above snippet the if didn’t have an opening { curly brace. Thus the closing } one below became redundant. And therefore the next closing } , which was intended for the function, was not associatable to the original opening { curly brace.

   Such errors are even harder to find without proper code indentation. Use an IDE and bracket matching.

Unexpected { , expecting (

Language constructs which require a condition/declaration header and a code block will trigger this error.

1. Parameter lists

   For example misdeclared functions without parameter list are not permitted:

     ⇓ function whatever { } 

2. Control statement conditions

   And you can’t likewise have an if without condition .

     ⇓ if { } 

   Which doesn’t make sense, obviously. Same thing for the usual suspects, for / foreach and while / do etc.

   If you’ve got this particular error, you definitely should look up some manual examples.

Unexpected T_IF
Unexpected T_ELSEIF
Unexpected T_ELSE
Unexpected T_ENDIF

Conditional control blocks if , elseif and else follow a simple structure. When you encounter a syntax error, it’s most likely just invalid block nesting → with missing { curly braces } – or one too many.

1. Missing { or } due to incorrect indentation

   Mismatched code braces are common to less well-formatted code such as:

    if((!($opt["uniQartz5.8"]!=$this->check58)) or (empty($_POST['poree']))) {if ($true) {echo"halp";} elseif((!$z)or%b){excSmthng(False,5.8)}elseif (False){ 

   If your code looks like this, start afresh! Otherwise it’s unfixable to you or anyone else. There’s no point in showcasing this on the internet to inquire for help.

   You will only be able to fix it, if you can visually follow the nested structure and relation of if/else conditionals and their { code blocks } . Use your IDE to see if they’re all paired.

    if (true) { if (false) { … } elseif ($whatever) { if ($something2) { … } else { … } } else { … } if (false) { // a second `if` tree … } else { … } } elseif (false) { … } 

   Any double } } will not just close a branch, but a previous condition structure. Therefore stick with one coding style; don’t mix and match in nested if/else trees.

   Apart from consistency here, it turns out helpful to avoid lengthy conditions too. Use temporary variables or functions to avoid unreadable if -expressions.

2. IF cannot be used in expressions

   A surprisingly frequent newcomer mistake is trying to use an if statement in an expression, such as a print statement:

     ⇓ echo "<a href='" . if ($link == "example.org") { echo … 

   Which is invalid of course.

   You can use a ternary conditional , but beware of readability impacts.

    echo "<a href='" . ($link ? "http://yes" : "http://no") . "</a>"; 

   Otherwise break such output constructs up: use multiple if s and echo s .
   Better yet, use temporary variables , and place your conditionals before:

    if ($link) { $href = "yes"; } else { $href = "no"; } echo "<a href='$href'>Link</a>"; 

   Defining functions or methods for such cases often makes sense too.

   Control blocks don’t return «results»

   Now this is less common, but a few coders even try to treat if as if it could return a result :

    $var = if ($x == $y) { "true" }; 

   Which is structurally identical to using if within a string concatenation / expression.

   • But control structures (if / foreach / while) don’t have a «result» .
   • The literal string «true» would also just be a void statement.

   You’ll have to use an assignment in the code block :

    if ($x == $y) { $var = "true"; } 

   Alternatively, resort to a ?: ternary comparison.

   If in If

   You cannot nest an if within a condition either:

     ⇓ if ($x == true and (if $y != false)) { ... } 

   Which is obviously redundant, because the and (or or ) already allows chaining comparisons.

3. Forgotton ; semicolons

   Once more: Each control block needs to be a statement. If the previous code piece isn’t terminated by a semicolon, then that’s a guaranteed syntax error:

     ⇓ $var = 1 + 2 + 3 if (true) { … } 

   Btw, the last line in a {…} code block needs a semicolon too.

4. Semicolon too early

   Now it’s probably wrong to blame a particular coding style, as this pitfall is too easy to overlook:

     ⇓ if ($x == 5); { $y = 7; } else ← { $x = -1; } 

   Which happens more often than you might imagine.

   • When you terminate the if () expression with ; it will execute a void statement. The ; becomes a an empty {} of its own!
   • The {…} block thus is detached from the if , and would always run.
   • So the else no longer had a relation to an open if construct, which is why this would lead to an Unexpected T_ELSE syntax error.

   Which also explains a likewise subtle variation of this syntax error:

    if ($x) { x_is_true(); }; else { something_else(); }; 

   Where the ; after the code block {…} terminates the whole if construct, severing the else branch syntactically.

5. Not using code blocks

   It’s syntactically allowed to omit curly braces { … } for code blocks in if / elseif / else branches. Which sadly is a syntax style very common to unversed coders. (Under the false assumption this was quicker to type or read).

   However that’s highly likely to trip up the syntax. Sooner or later additional statements will find their way into the if/else branches:

    if (true) $x = 5; elseif (false) $x = 6; $y = 7; ← else $z = 0; 

   But to actually use code blocks, you do have to write { … } them as such!

   Even seasoned programmers avoid this braceless syntax, or at least understand it as an exceptional exception to the rule.

6. Else / Elseif in wrong order

   One thing to remind yourself is the conditional order , of course.

    if ($a) { … } else { … } elseif ($b) { … } ↑ 

   You can have as many elseif s as you want, but else has to go last . That’s just how it is.

7. Class declarations

   As mentioned above , you can’t have control statements in a class declaration:

    class xyz { if (true) { function ($var) {} } 

   You either forgot a function definition, or closed one } too early in such cases.

8. Unexpected T_ELSEIF / T_ELSE

   This is more or less a variation of incorrect indentation – presumably often based on wrong coding intentions.
   You cannot mash other statements inbetween if and elseif / else structural tokens:

    if (true) { } echo "in between"; ← elseif (false) { } ?> text <?php ← else { } 

   Either can only occur in {…} code blocks, not in between control structure tokens.

   • This wouldn’t make sense anyway. It’s not like that there was some «undefined» state when PHP jumps between if and else branches.
   • You’ll have to make up your mind where print statements belong to / or if they need to be repeated in both branches.

   Nor can you part an if/else between different control structures:

    foreach ($array as $i) { if ($i) { … } } else { … } 

   There is no syntactic relation between the if and else . The foreach lexical scope ends at } , so there’s no point for the if structure to continue.

9. T_ENDIF

   If an unexpected T_ENDIF is complained about, you’re using the alternative syntax style if: ⋯ elseif: ⋯ else: ⋯ endif; , Which you should really think twice about.

   • A common pitfall is confusing the eerily similar : colon for a ; semicolon . (Covered in «Semicolon too early»)

   • As indentation is harder to track in template files, the more when using the alternative syntax – it’s plausible your endif; does not match any if: .

   • Using } endif; is a doubled if -terminator.

   While an «unexpected $end» is usually the price for a forgotten closing } curly brace.

10. Assignment vs. comparison

    So, this is not a syntax error, but worth mentioning in this context:

      ⇓ if ($x = true) { } else { do_false(); } 

    That’s not a == / === comparison, but an = assignment . This is rather subtle, and will easily lead some users to helplessly edit whole condition blocks. Watch out for unintended assignments first – whenver you experience a logic fault / misbeheviour.

Unexpected T_IS_EQUAL
Unexpected T_IS_GREATER_OR_EQUAL
Unexpected T_IS_IDENTICAL
Unexpected T_IS_NOT_EQUAL
Unexpected T_IS_NOT_IDENTICAL
Unexpected T_IS_SMALLER_OR_EQUAL
Unexpected <
Unexpected >

Comparison operators such as == , >= , === , != , <> , !== and <= or < and > mostly should be used just in expressions, such as if expressions. If the parser complains about them, then it often means incorrect paring or mismatched ( ) parens around them.

1. Parens grouping

   In particular for if statements with multiple comparisons you must take care to correctly count opening and closing parenthesis :

     ⇓ if (($foo < 7) && $bar) > 5 || $baz < 9) { ... } ↑ 

   Here the if condition here was already terminated by the )

   Once your comparisons become sufficiently complex it often helps to split it up into multiple and nested if constructs rather.

2. isset() mashed with comparing

   A common newcomer is pitfal is trying to combine isset() or empty() with comparisons:

     ⇓ if (empty($_POST["var"] == 1)) { 

   Or even:

     ⇓ if (isset($variable !== "value")) { 

   This doesn’t make sense to PHP, because isset and empty are language constructs that only accept variable names. It doesn’t make sense to compare the result either, because the output is only/already a boolean.

3. Confusing >= greater-or-equal with => array operator

   Both operators look somewhat similar, so they sometimes get mixed up:

     ⇓ if ($var => 5) { ... } 

   You only need to remember that this comparison operator is called » greater than or equal » to get it right.

   See also: If statement structure in PHP

4. Nothing to compare against

   You also can’t combine two comparisons if they pertain the same variable name:

     ⇓ if ($xyz > 5 and < 100) 

   PHP can’t deduce that you meant to compare the initial variable again. Expressions are usually paired according to operator precedence , so by the time the < is seen, there’d be only a boolean result left from the original variable.

   See also: unexpected T_IS_SMALLER_OR_EQUAL

5. Comparison chains

   You can’t compare against a variable with a row of operators:

     ⇓ $reult = (5 < $x < 10); 

   This has to be broken up into two comparisons, each against $x .

   This is actually more a case of blacklisted expressions (due to equivalent operator associativity). It’s syntactically valid in a few C-style languages, but PHP wouldn’t interpret it as expected comparison chain either.

6. Unexpected >
   Unexpected <

   The greater than > or less than < operators don’t have a custom T_XXX tokenizer name. And while they can be misplaced like all they others, you more often see the parser complain about them for misquoted strings and mashed HTML:

     ⇓ print "<a href='z">Hello</a>"; ↑ 

   This amounts to a string "<a href='z" being compared > to a literal constant Hello and then another < comparison. Or that’s at least how PHP sees it. The actual cause and syntax mistake was the premature string " termination.

Смотрите также:

• php unexpected T_IS_NOT_EQUAL error
• syntax error, unexpected T_IS_EQUAL
• Syntax error on return statement
• http://forums.phpfreaks.com/topic/96891-parse-error-syntax-error-unexpected-t-is-not-identical-expecting-or/

Unexpected T_IF
Unexpected T_FOREACH
Unexpected T_FOR
Unexpected T_WHILE
Unexpected T_DO
Unexpected T_ECHO

Control constructs such as if , foreach , for , while , list , global , return , do , print , echo may only be used as statements. They usually reside on a line by themselves.

1. Semicolon; where you at?

   Pretty universally have you missed a semicolon in the previous line if the parser complains about a control statement:

     ⇓ $x = myfunc() if (true) { 

   Solution: look into the previous line; add semicolon.

2. Class declarations

   Another location where this occurs is in class declarations . In the class section you can only list property initializations and method sections. No code may reside there.

    class xyz { if (true) {} foreach ($var) {} 

   Such syntax errors commonly materialize for incorrectly nested { and } . In particular when function code blocks got closed too early.

3. Statements in expression context

   Most language constructs can only be used as statements . They aren’t meant to be placed inside other expressions:

     ⇓ $var = array(1, 2, foreach($else as $_), 5, 6); 

   Likewise can’t you use an if in strings, math expressions or elsewhere:

     ⇓ print "Oh, " . if (true) { "you!" } . " won't work"; // Use a ternary condition here instead, when versed enough. 

   ^{For embedding if -like conditions in an expression specifically, you often want to use a ?: ternary evaluation .}

   The same applies to for , while , global , echo and a lesser extend list .

     ⇓ echo 123, echo 567, "huh?"; 

   Whereas print() is a language builtin that may be used in expression context. (But rarely makes sense.)

4. Reserved keywords as identifiers

   You also can’t use do or if and other language constructs for user-defined functions or class names. (Perhaps in PHP7. But even then it wouldn’t be advisable.)

Unexpected T_LNUMBER

IN PHP, and most other programming languages, variables cannot start with a number. The first character must be alphabetic or an underscore.

 $1 // bad $_1 // good