Ошибки синтаксиса PHP/синтаксиса; и как их решить?
Все сталкиваются с синтаксическими ошибками. Даже опытные программисты делают опечатки. Для новичков это всего лишь часть учебного процесса. Однако часто легко интерпретировать сообщения об ошибках, такие как:
Ошибка синтаксического анализа PHP: синтаксическая ошибка, неожиданное '{' в index.php в строке 20
Неожиданный символ не всегда настоящий преступник. Но номер строки дает приблизительное представление о том, с чего начать.
Всегда смотрите на контекст кода. Синтаксическая ошибка часто скрывается в упомянутых или в предыдущих строках кода. Сравните ваш код с примерами синтаксиса из руководства.
Хотя не каждый случай соответствует другому. Тем не менее, есть некоторые общие шаги для решения синтаксических ошибок. Эти ссылки суммировали общие подводные камни:
Тесно связанные ссылки:
А также:
В то время как Qaru также приветствует новичков, они в основном нацелены на вопросы профессионального программирования.
- Отвечать на все ошибки кодирования и узкие опечатки считается не по теме.
- Поэтому, пожалуйста, уделите время, чтобы выполнить основные шаги, прежде чем публиковать запросы на исправление синтаксиса.
- Если вам все еще нужно, пожалуйста, покажите свою собственную инициативу решения, предпринятые исправления и свой мыслительный процесс о том, что выглядит или может быть не так.
Если ваш браузер отображает сообщения об ошибках, такие как "SyntaxError: недопустимый символ", то это фактически не php -related, а javascript - синтаксическая ошибка.
Синтаксические ошибки, возникающие в коде поставщика. Наконец, учтите, что если синтаксическая ошибка возникла не при редактировании базы кода, а после установки или обновления пакета внешнего поставщика, это может быть связано с несовместимостью версии PHP, поэтому проверьте требования поставщика к настройке платформы.,
Ответы
Ответ 1
Каковы синтаксические ошибки?
PHP относится к С-стилю и императивным языкам программирования. У него есть жесткие правила грамматики, которые он не может восстановить при обнаружении неулокальных символов или идентификаторов. Это не может угадать ваши намерения кодирования.
Самые важные советы
Есть несколько основных мер предосторожности, которые вы всегда можете предпринять:
-
Используйте правильный отступ кода или используйте любой высокий стиль кодирования. Читаемость предотвращает неровности.
-
Используйте IDE или редактор для PHP с подсветкой синтаксиса. Что также помогает с скобками/балансировкой скобок.
-
Прочитайте справочник по языку и примеры в руководстве. Дважды, чтобы стать несколько опытным.
Как интерпретировать ошибки парсера
Типичное сообщение об ошибке синтаксиса гласит:
Ошибка разбора: синтаксическая ошибка, неожиданный T_STRING, ожидание ' ;
' в file.php в строке 217
Который перечисляет возможное местоположение синтаксической ошибки. Смотрите упомянутое имя файла и номер строки.
Прозвище, такие как T_STRING
объясняет, какой символ анализатор/токенизатор не удалось обработать, наконец. Однако это не обязательно является причиной синтаксической ошибки.
Важно также рассмотреть предыдущие строки кода. Часто синтаксические ошибки - это просто неудачи, случившиеся ранее. Номер строки ошибки - именно то, где анализатор окончательно отказался от обработки всего этого.
Решение синтаксических ошибок
Есть много подходов, чтобы сузить и исправить синтаксические ошибки.
-
Откройте указанный исходный файл. Посмотрите на упомянутую строку кода.
-
Для убегающих строк и неулокальных операторов, это обычно, где вы найдете виновника.
-
Прочитайте строку слева направо и представьте, что делает каждый символ.
-
Более регулярно вы должны смотреть и на предыдущие строки.
-
В частности, отсутствует ;
точки с запятой отсутствуют в конце предыдущей строки/оператора. (По крайней мере, со стилистической точки зрения.)
-
Если {
кодовые блоки }
неправильно закрыты или вложены, вам, возможно, придется изучить еще больше в исходном коде. Используйте правильный отступ кода, чтобы упростить это.
-
Посмотрите на синтаксис раскраски !
-
Строки, переменные и константы должны иметь разные цвета.
-
Операторы +-*/.
также должен быть отчетливо окрашен. В противном случае они могут быть в неправильном контексте.
-
Если вы видите, что раскрашивание строк распространяется слишком далеко или слишком коротко, значит, вы нашли неэкранированный или отсутствующий закрывающий "
или '
маркер строки.
-
Наличие двух одинаковых знаков препинания рядом друг с другом также может означать проблемы. Обычно операторы являются одинокими, если это не ++
, --
или круглые скобки после оператора. Две строки/идентификаторы, непосредственно следующие друг за другом, неверны в большинстве контекстов.
-
Пробел - твой друг. Следуйте любому стилю кодирования.
-
Временно разбить длинные очереди.
-
Вы можете свободно добавлять новые строки между операторами или константами и строками. Затем синтаксический анализатор конкретизирует номер строки для анализа ошибок. Вместо того, чтобы смотреть на очень длинный код, вы можете изолировать отсутствующий или неправильно расположенный синтаксический символ.
-
Разделите сложные операторы if
на отдельные или вложенные условия if
.
-
Вместо длинных математических формул или логических цепочек используйте временные переменные для упрощения кода. (Более читабельно = меньше ошибок.)
-
Добавьте новые строки между:
- Код, который вы можете легко определить как правильный,
- Части, в которых вы не уверены,
- И строки, на которые парсер жалуется.
Разделение длинных блоков кода действительно помогает определить источник синтаксических ошибок.
-
Закомментируйте оскорбительный код.
-
Если вы не можете изолировать источник проблемы, начните закомментировать (и, таким образом, временно удалить) блоки кода.
-
Как только вы избавились от ошибки синтаксического анализа, вы нашли источник проблемы. Посмотри внимательнее там.
-
Иногда вы хотите временно удалить завершенные функциональные/методические блоки. (В случае непревзойденных фигурных скобок и ошибочно с отступом кода.)
-
Если вы не можете решить проблему с синтаксисом, попробуйте переписать закомментированные разделы с нуля.
-
Как новичок, избегайте некоторых запутанных синтаксических конструкций.
-
Троичный ? :
? :
оператор условия может компактировать код и действительно полезен. Но это не помогает удобочитаемости во всех случаях. Предпочитаю простые операторы if
пока они не обращены
-
Альтернативный синтаксис PHP (if:
/elseif:
/endif;
) является общим для шаблонов, но, возможно, менее прост для понимания, чем обычные блоки {
code }
.
-
Наиболее распространенные ошибки новичка:
-
Пропущенные точки с запятой ;
для завершения операторов/строк.
-
Несоответствующие строковые кавычки для "
или '
и неэкранированные кавычки внутри.
-
Забытые операторы, в частности для строки .
конкатенации.
-
Несбалансированный (
скобки )
. Подсчитайте их в сообщенной строке. Есть ли их равное количество?
-
Не забывайте, что решение одной синтаксической проблемы может раскрыть следующую.
-
Если вы решите одну проблему, но в следующем коде появится другая, вы в основном на правильном пути.
-
Если после редактирования новой синтаксической ошибки появляется в той же строке, то ваша попытка изменения была неудачной. (Не всегда, хотя.)
-
Восстановите резервную копию ранее работающего кода, если вы не можете это исправить.
- Принять систему управления версиями исходного кода. Вы всегда можете посмотреть
diff
в сломанной и последней рабочей версии. Что может быть полезным для понимания проблемы синтаксиса.
-
Невидимые блуждающие символы Юникода: в некоторых случаях вам нужно использовать hexeditor или другой редактор/просмотрщик в вашем источнике. Некоторые проблемы не могут быть найдены только при просмотре вашего кода.
-
Попробуйте grep --color -P -n "\[\x80-\xFF\]" file.php
в качестве первой меры, чтобы найти не-ASCII символы.
-
В частности, спецификации, пробелы нулевой ширины или неразрывные пробелы и регулярные умные кавычки могут найти свой путь в исходный код.
-
Позаботьтесь о том, какой тип переносов строк сохраняется в файлах.
-
PHP только чтит \n переводы строк, а не \r возврат каретки.
-
Что иногда является проблемой для пользователей MacOS (даже в OS X для неправильно настроенных редакторов).
-
Часто проблема возникает только при использовании однострочных комментариев //
или #
. Многострочные комментарии /*...*/
редко мешают анализатору, когда /*...*/
игнорируются.
-
Если ваша синтаксическая ошибка не передается через Интернет: случается, что у вас есть синтаксическая ошибка на вашем компьютере. Но размещение того же самого файла в Интернете больше не демонстрирует его. Что может означать только одну из двух вещей:
-
Проверьте свою версию PHP. Не все синтаксические конструкции доступны на каждом сервере.
-
php -v
для интерпретатора командной строки
-
<?php phpinfo();
за тот, который вызывается через веб-сервер.
Это не обязательно то же самое. В частности, при работе с фреймворками вы будете их сопоставлять.
-
Не используйте зарезервированные ключевые слова PHP в качестве идентификаторов для функций/методов, классов или констант.
-
Метод проб и ошибок - ваше последнее средство.
Если ничего не помогает, вы всегда можете погуглить ваше сообщение об ошибке. Синтаксические символы не так легко найти (хотя переполнение стека индексируется SymbolHound). Поэтому может потребоваться просмотреть еще несколько страниц, прежде чем вы найдете что-то актуальное.
Дальнейшие руководства:
Белый экран смерти
Если ваш сайт просто пустой, то причиной обычно является синтаксическая ошибка. Включить их отображение с помощью:
-
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");
Затем вызовите ошибочный код, обратившись к этому сценарию оболочки.
Это также помогает включить PHP error_log
и заглянуть в ваш файл error.log
веб-сервера, когда сценарий дает сбой с ответами HTTP 500.
Ответ 2
Я думаю, что эта тема полностью перегружена/сложна. Использование IDE - это способ избежать ошибок синтаксиса. Я бы даже сказал, что работа без IDE является непрофессиональной. Зачем? Поскольку современные IDE проверяют ваш синтаксис после каждого вводимого вами символа. Когда вы кодируете, и вся ваша строка становится красной, и большое предупреждение показывает вам точный тип и точное положение синтаксической ошибки, тогда абсолютно нет необходимости искать другое решение.
Использование синтаксической проверки IDE означает:
Вы (эффективно) никогда не столкнетесь с синтаксическими ошибками снова, просто потому, что видите их правильно по мере ввода. Шутки в сторону.
Отличные IDE с проверкой синтаксиса (все они доступны для Linux, Windows и Mac):
- NetBeans [бесплатно]
- PHPStorm [$ 199 USD]
- Eclipse с плагином PHP [бесплатно]
- Sublime [$ 80 USD] (в основном текстовый редактор, но расширяемый с помощью плагинов, таких как PHP Syntax Parser)
Ответ 3
Неожиданный [
В эти дни, неожиданная [
скобка массива обычно рассматриваются на устаревшие версии 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 5.4, если вы действительно цепляетесь за более старые + более медленные версии PHP.
Другие причины для неожиданного [
синтаксические ошибки
Если это не несоответствие версии PHP, то это часто простая синтаксическая ошибка или ошибка синтаксиса новичка:
-
Вы не можете использовать объявления/выражения свойств массива в классах, даже в PHP 7.
protected $var["x"] = "Nope";
⇑
-
Путать [
с открывающимися фигурными скобками {
или круглыми скобками (
это распространенный недосмотр).
foreach [$a as $b)
⇑
Или даже:
function foobar[$a, $b, $c] {
⇑
-
Или пытаться разыменовать константы (до PHP 5.6) как массивы:
$var = const[123];
⇑
По крайней мере, PHP интерпретирует это const
как постоянное имя.
Если вы хотели получить доступ к переменной массива (что является типичной причиной здесь), то добавьте начальный $
sigil - так он станет $varname
.
-
Вы пытаетесь использовать global
ключевое слово для члена ассоциативного массива. Это неверный синтаксис:
global $var['key'];
Неожиданно ]
закрывающая квадратная скобка
Это несколько реже, но есть также синтаксические аварии с завершающим массивом ]
скобка.
-
Опять несоответствие с )
круглые скобки или }
фигурные скобки являются общими:
function foobar($a, $b, $c] {
⇑
-
Или пытаться завершить массив, где его нет:
$var = 2];
Что часто происходит в объявлениях многострочных и вложенных массивов.
$array = [1,[2,3],4,[5,6[7,[8],[9,10]],11],12]],15];
⇑
Если да, то использовать IDE для согласования кронштейна, чтобы найти преждевременное ]
закрытие массива. По крайней мере, используйте больше пробелов и новых строк, чтобы сузить его.
Ответ 4
Неожиданный T_VARIABLE
"Неожиданное T_VARIABLE
" означает, что существует буквальное имя $variable
, которое не вписывается в текущую структуру выражения/оператора.
-
Отсутствует точка с запятой
Это чаще всего указывает на отсутствующую точку с запятой в предыдущей строке. Переменные присваивания, следующие за выражением, являются хорошим показателем, на который следует обратить внимание:
⇓
func1()
$var = 1 + 2; # parse error in line +2
-
Конкатенация строк
Частые неудачи - это конкатенации строк с забытыми .
оператор:
⇓
print "Here comes the value: " $value;
Кстати, вы должны предпочесть строчную интерполяцию (базовые переменные в двойных кавычках), когда это помогает читаемости. Это позволяет избежать этих синтаксических проблем.
Строковая интерполяция - это основная функция языка сценариев. Не стыдно использовать его. Игнорируйте любую рекомендацию по микрооптимизации относительно переменной .
ускорение конкатенации. Не это.
-
Отсутствующие операторы выражения
Конечно, одна и та же проблема может возникнуть в других выражениях, например арифметических операций:
⇓
print 4 + 7 $var;
PHP не может угадать здесь, если переменная должна быть добавлена, вычтена или сравнена и т.д.
-
Списки
То же самое для списков синтаксиса, например, в массивах, где парсер также указывает ожидаемую запятую ,
например:
⇓
$var = array("1" => $val, $val2, $val3 $val4);
Или списки параметров функций:
⇓
function myfunc($param1, $param2 $param3, $param4)
Эквивалентно вы видите это со list
или global
утверждениями или при отсутствии ;
точка с запятой в цикле for
.
-
Объявления классов
Эта ошибка парсера также встречается в объявлениях классов. Вы можете назначать только статические константы, а не выражения. Таким образом, парсер жалуется на переменные в качестве назначенных данных:
class xyz { ⇓
var $value = $_GET["input"];
Непревзойденные }
закрывающиеся фигурные скобки могут, в частности, привести сюда. Если метод заканчивается слишком рано (используйте правильный отступ!), Тогда блуждающая переменная обычно неправильно помещается в тело объявления класса.
-
Переменные после идентификаторов
Вы также можете никогда не иметь переменную, следуя за идентификатором напрямую:
⇓
$this->myFunc$VAR();
Кстати, это распространенный пример, когда, возможно, предполагалось использовать переменные переменные. В этом случае поиск свойства переменной с помощью $this->{"myFunc$VAR"}();
например.
Имейте в виду, что использование переменных переменных должно быть исключением. Новички часто пытаются использовать их слишком случайно, даже когда массивы будут проще и более уместны.
-
Отсутствие парсов после языковых конструкций
Скорейшее типирование может привести к забытой открывающей скобке для операторов if
и for
и foreach
:
⇓
foreach $array as $key) {
Решение: добавьте недостающее открытие (
между оператором и переменной.
-
Else не ожидает условий
⇓
else ($var >= 0)
Решение. Удалите условия из else
или используйте elseif
.
-
Необходимые скобки для закрытия
⇓
function() uses $var {}
Решение. Добавьте скобки вокруг $var
.
-
Невидимые пробелы
Как упоминалось в справочном ответе "Невидимый бездомный Юникод" (например, неразрывное пространство), вы также можете увидеть эту ошибку для ничего не подозревающего кода:
<?php
⇐
$var = new PDO(...);
Это довольно распространено в начале файлов и для копирования и вставки кода. Проверьте с помощью шестнадцатеричного кода, если ваш код визуально не содержит синтаксическую проблему.
Смотрите также
Ответ 5
Неожиданное 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.
-
Неверная переменная интерполяция
И это чаще всего встречается при некорректной интерполяции переменных 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 на самом деле используют для этого разную синтаксическую раскраску.
-
Отсутствует конкатенация
Если строка следует за выражением, но не имеет конкатенации или другого оператора, то вы увидите, что PHP жалуется на строковый литерал:
⇓
print "Hello " . WORLD " !";
Хотя это очевидно для вас и меня, PHP просто не может догадаться, что строка должна быть добавлена туда.
-
Сбивающие с толку строковые кавычки
Такая же синтаксическая ошибка возникает при смешивании строковых разделителей. Строка запускается один '
или двойной "
цитаты и заканчивается тем же.
⇓
print "<a href="' . $link . '">click here</a>";
⌞⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟
Этот пример начинался с двойных кавычек. Но двойные кавычки также предназначались для атрибутов HTML. Предполагаемый оператор конкатенации внутри, однако, интерпретировался как часть второй строки в одинарных кавычках.
Совет. Установите редактор /IDE для использования слегка отличной раскраски для одиночных и двойных кавычек. (Это также помогает с логикой приложения, например, использовать двойные кавычки для текстового вывода и одиночные кавычки только для константоподобных значений.)
Это хороший пример, когда вы не должны выходить из двойных кавычек в первую очередь. Вместо этого просто используйте правильные \"
для атрибутов HTML-атрибутов":
print "<a href=\"{$link}\">click here</a>";
Хотя это также может привести к путанице в синтаксисе, все лучшие IDE/редакторы снова помогают раскрасить экранированные кавычки по-разному.
-
Отсутствует стартовая цитата
Эквивалентно забытое открытие "
/'
цитирует рецепт ошибок парсера:
⇓
make_url(login', 'open');
Здесь ', '
станет строковым литералом после голого слова, когда, очевидно, login
должен быть строковым параметром.
-
Списки массивов
Если вы пропустите ,
запятая в блоке создания массива, анализатор будет видеть две последовательные строки:
array( ⇓
"key" => "value"
"next" => "....",
);
Обратите внимание, что в последней строке всегда может содержаться дополнительная запятая, но игнорировать одно между ними непростительно. Это трудно обнаружить без подсветки синтаксиса.
-
Списки параметров функции
То же самое для вызовов функций:
⇓
myfunc(123, "text", "and" "more")
-
Беглые строки
Общим вариантом являются довольно просто забытые терминаторы строк:
⇓
mysql_evil("SELECT * FROM stuffs);
print "'ok'";
⇑
Здесь PHP жалуется на два строковых литерала, непосредственно следуя друг за другом. Но настоящая причина - незакрытая предыдущая строка, конечно.
Смотрите также
Ответ 6
Неожиданный T_STRING
T_STRING
немного неправильный. Это не относится к цитируемой "string"
. Это означает, что был обнаружен необработанный идентификатор. Это может варьироваться от bare
слов до оставшихся CONSTANT
или имен функций, забытых строк без кавычек или любого простого текста.
-
Ошибочные строки
Однако эта синтаксическая ошибка наиболее распространена для неверно цитируемых строковых значений. Любая неэкранированная и заблудшая "
или '
цитата образует недопустимое выражение:
⇓ ⇓
echo "<a href="http://example.com">click here</a>";
Подсветка синтаксиса сделает такие ошибки супер очевидными. Важно не забывать использовать обратную косую черту для экранирования \"
двойных кавычек" или \'
одинарных кавычек" - в зависимости от того, какая строка использовалась в качестве вложенной строки.
- Для удобства вы должны предпочесть внешние одинарные кавычки при выводе простого HTML с двойными кавычками внутри.
- Используйте строки в двойных кавычках, если вы хотите интерполировать переменные, но затем следите за экранированием буквальных
"
двойных кавычек". - Для более длинного вывода предпочитайте несколько строк
echo
/print
вместо экранирования входа и выхода. Еще лучше рассмотреть раздел HEREDOC.
Смотрите также В чем разница между одинарными и двойными кавычками в PHP? ,
-
Незакрытые строки
Если вы пропускаете закрытие "
то синтаксическая ошибка обычно возникает позже. Неопределенная строка часто потребляет немного кода до следующего предполагаемого строкового значения:
⇓
echo "Some text", $a_variable, "and some runaway string ;
success("finished");
⇯
Это не просто литерал T_STRING
которого парсер может протестовать. Другим частым вариантом является Unexpected '>'
для буквального HTML без кавычек.
-
Непрограммирующие строковые кавычки
Если вы копируете и вставляете код из блога или веб-сайта, у вас иногда получается неверный код. Типографские кавычки - это не то, что ожидает PHP:
$text = Something something.. + "these ain't quotes";
Типографские/умные кавычки являются символами Юникода. PHP рассматривает их как часть буквенно-цифрового текста. Например, "these
интерпретируются как постоянный идентификатор. Но любой последующий текстовый литерал затем рассматривается синтаксическим анализатором как голое слово /T_STRING".
-
Пропущенная точка с запятой; снова
Если у вас есть неопределенное выражение в предыдущих строках, то любой следующий оператор или языковая конструкция будет рассматриваться как необработанный идентификатор:
⇓
func1()
function2();
PHP просто не может знать, хотели ли вы запускать две функции за другой, или вы хотели умножить их результаты, добавить их, сравнить их или запустить только одну ||
или другой.
-
Короткие открытые теги и <?xml
заголовки в скриптах PHP
Это довольно необычно. Но если включены short_open_tags, вы не можете начать свои PHP-скрипты с объявления XML:
⇓
<?xml version="1.0"?>
PHP увидит <?
и вернуть его себе. Он не поймет, для чего предназначен блуждающий xml
. Это будет интерпретировано как константа. Но version
будет рассматриваться как еще один литерал/константа. А так как синтаксический анализатор не может иметь смысла двух последующих литералов/значений без оператора выражения между ними, это будет ошибкой синтаксического анализатора.
-
Невидимые символы Юникода
Наиболее отвратительной причиной синтаксических ошибок являются символы Юникода, такие как неразрывный пробел. PHP допускает использование символов Юникода в качестве имен идентификаторов. Если вы получили жалобу парсера T_STRING на совершенно неожиданный код, такой как:
<?php
print 123;
Вам нужно вырвать другой текстовый редактор. Или даже гекседитор. То, что здесь выглядит как простые пробелы и символы новой строки, может содержать невидимые константы. Основанные на Java IDE иногда забывают о спецификации UTF-8, искривленной внутри, пробелах нулевой ширины, разделителях абзацев и т.д. Попробуйте переопределить все, удалить пробелы и добавить в них нормальные пробелы.
Вы можете сузить это с добавлением избыточного ;
разделители операторов в начале каждой строки:
<?php
;print 123;
Экстра ;
точка с запятой здесь преобразует предыдущий невидимый символ в неопределенную ссылку на константу (выражение как выражение). Что, в свою очередь, заставляет PHP создавать полезное уведомление.
-
Знак "$" отсутствует перед именами переменных
Переменные в PHP представлены знаком доллара, за которым следует имя переменной.
Знак доллара ($
) - это символ, который обозначает идентификатор как имя переменной. Без этого символа идентификатор может быть ключевым словом языка или константой.
Это распространенная ошибка, когда код PHP был "переведен" из кода, написанного на другом языке (C, Java, JavaScript и т.д.). В таких случаях объявление типа переменной (когда исходный код был написан на языке, использующем типизированные переменные) также может ускользнуть и вызвать эту ошибку.
-
Избежавшие кавычки
Если вы используете \
в строке, это имеет особое значение. Это называется " Escape Character " и обычно говорит парсеру буквально брать следующий символ.
Пример: echo 'Jim said \'Hello\'';
напечатает Jim said 'hello'
Если вы избегаете закрывающей кавычки строки, закрывающая кавычка будет воспринята буквально, а не так, как предполагалось, то есть как печатная кавычка как часть строки, а не как закрывающая строка. Обычно это будет отображаться как ошибка синтаксического анализа после открытия следующей строки или в конце скрипта.
Очень распространенная ошибка при указании путей в Windows: "C:\xampp\htdocs\"
неверно. Вам нужен "C:\\xampp\\htdocs\\"
.
Ответ 7
Неожиданный (
Открывающиеся круглые скобки обычно следуют языковым конструкциям, таким как if
/foreach
/for
/array
/list
или запускают арифметическое выражение. Они синтаксически неверны после "strings"
, предыдущего ()
, одиночного $
и в некоторых типичных контекстах объявления.
-
Параметры объявления функции
Редкое появление этой ошибки пытается использовать выражения в качестве параметров функции по умолчанию. Это не поддерживается даже в PHP7:
function header_fallback($value, $expires = time() + 90000) {
Параметры в объявлении функции могут быть только литеральными значениями или постоянными выражениями. В отличие от функций invocations, где вы можете свободно использовать whatever(1+something()*2)
и т.д.
-
По умолчанию свойства класса
То же самое для деклараций членов класса, где допускаются только значения литерала/константы, а не выражения:
class xyz { ⇓
var $default = get_config("xyz_default");
Поместите такие вещи в конструктор. См. Также Почему атрибуты PHP не позволяют выполнять функции?
Снова отметим, что PHP 7 допускает только var $xy = 1 + 2 +3;
там постоянные выражения.
-
Синтаксис JavaScript в PHP
Использование синтаксиса JavaScript или jQuery не будет работать на PHP по понятным причинам:
<?php ⇓
print $(document).text();
Когда это происходит, оно обычно указывает на неисчерпаемую предыдущую строку; и буквальные <script>
разделы, попадающие в контекст кода PHP.
-
isset (()), пустой, ключ, следующий, текущий
И isset()
и empty()
являются языковыми встроенными, а не функциями. Им нужно получить доступ к переменной напрямую. Если вы слишком часто добавляете пару круглых скобок, вы должны создать выражение:
⇓
if (isset(($_GET["id"]))) {
То же самое относится к любой языковой конструкции, для которой требуется неявный доступ к имени переменной. Эти встроенные модули являются частью языковой грамматики, поэтому не допускают декоративных дополнительных круглых скобок.
Функции уровня пользователя, требующие ссылки на переменные -but, получают результат выражения passed-, вместо этого приводят к ошибкам во время выполнения.
Неожиданно )
-
Отсутствует параметр функции
Вы не можете запятнать запятую в вызове функции. PHP ожидает там ценности и, следовательно, жалуется на скорую скобки )
.
⇓
callfunc(1, 2, );
Конечная запятая допускается только в конструкциях array()
или list()
.
-
Неоконченные выражения
Если вы забудете что-то в арифметическом выражении, тогда парсер сдастся. Потому что как это может интерпретировать это:
⇓
$var = 2 * (1 + );
И если вы забыли закрыть )
, тогда вы получите жалобу на неожиданную точку с запятой.
-
Foreach как constant
Для забытых переменных $
префиксов в управляющих операциях вы увидите:
↓ ⇓
foreach ($array as wrong) {
PHP здесь иногда говорит вам, что он ожидал a ::
вместо этого. Поскольку переменная class :: $ могла удовлетворять ожидаемому выражению $ variable.
Неожиданный {
Кудрявые фигурные скобки {
и }
заключают блоки кода. И ошибки синтаксиса в отношении них обычно указывают на некорректное вложенность.
-
Непревзойденные подвыражения в if
Чаще всего неуравновешенные (
и )
являются причиной, если парсер жалуется на открытие курчавого {
появляется слишком рано. Простой пример:
⇓
if (($x == $y) && (2 == true) {
Подсчитайте свои parens или используйте IDE, которая помогает с этим. Также не пишите код без пробелов. Показатели удобочитаемости.
-
{и} в контексте выражения
Вы не можете использовать фигурные скобки в выражениях. Если вы путаете круглые скобки и кудри, это не будет соответствовать языковому грамматику:
⇓
$var = 5 * {7 + $x};
Для построения идентификатора существует несколько исключений, таких как локальная переменная области ${references}
.
-
Переменные переменные или фигурные выражения var
Это довольно редко. Но вы также можете получить {
и }
жалобы парсера на сложные выражения переменных:
⇓
print "Hello {$world[2{]} !";
Хотя есть более высокая вероятность неожиданного }
в таких контекстах.
Неожиданный }
При получении "неожиданную }
" ошибка, вы в основном закрыли блок кода слишком рано.
-
Последний оператор в кодовом блоке
Это может случиться для любого неисчерпаемого выражения.
И если в последней строке в блоке функции/кода отсутствует трейлинг ;
точка с запятой:
function whatever() {
doStuff()
} ⇧
Здесь синтаксический анализатор не может определить, хотите ли вы еще добавить + 25;
к результату функции или чему-то еще.
-
Недопустимое вложенность блоков/Забытое {
Иногда вы увидите эту ошибку парсера, когда блок кода был }
закрыт слишком рано или вы забыли открытие {
even:
function doStuff() {
if (true) ⇦
print "yes";
}
} ⇧
В вышеприведенном фрагменте, if
не было открытия {
фигурная скобка. Таким образом, закрытие }
одного ниже стало излишним. И поэтому следующее закрытие }
, которое предназначалось для функции, не было связано с первоначальным открытием {
фигурной скобки.
Такие ошибки еще труднее найти без правильного ввода кода. Используйте сопоставление IDE и скобок.
Неожиданный {
, ожидающий (
Языковые конструкции, для которых требуется заголовок условия/декларации и блок кода, вызовут эту ошибку.
-
Списки параметров
Например, недопустимые функции без списка параметров не разрешены:
⇓
function whatever {
}
-
Условия контрольной инструкции
И вы также не можете иметь, if
без условия.
⇓
if {
}
Очевидно, это не имеет смысла. То же самое для обычных подозреваемых, for
/foreach
, while
/do
и т.д.
Если у вас есть эта конкретная ошибка, вы определенно должны найти некоторые примеры руководства.
Ответ 8
Неожиданный конец $
Когда 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 - Джо: Ctrl G - Emacs: C-M-n - Vim: %
Большинство IDE также выделяют соответствующие фигурные скобки, скобки и круглые скобки. Это позволяет довольно легко проверить их соотношение:
Неограниченные выражения
И Unexpected $end
ошибка синтаксиса/парсера Unexpected $end
также может возникать для неиспользуемых выражений или операторов:
Итак, сначала посмотрите на конец скриптов. Конечный ;
часто избыточно для последнего оператора в любом скрипте PHP. Но у вас должен быть такой. Именно потому, что он сужает такие проблемы синтаксиса.
Отметные маркеры HEREDOC
Еще одно распространенное явление появляется в строках HEREDOC или NOWDOC. Конечный маркер игнорируется ведущими пробелами, вкладками и т. Д.:
print <<< END
Content...
Content....
END;
# ↑ terminator isn't exactly at the line start
Поэтому анализатор предполагает, что строка HEREDOC продолжается до конца файла (отсюда "Неожиданный конец $"). Практически все IDE и редакторы с подсветкой синтаксиса сделают это очевидным или предупредит об этом.
Исключенные котировочные знаки
Если вы используете \
в строке, это имеет особое значение. Это называется " Escape Character " и обычно говорит парсеру буквально воспринимать следующий символ.
Пример: echo 'Jim said \'Hello\'';
будет печатать Jim said 'hello'
Если вы избежите закрывающей цитаты строки, заключительная цитата будет взята буквально и не так, как предполагалось, то есть в качестве печатной цитаты как части строки, а не для закрытия строки. Это будет отображаться как ошибка разбора, обычно после открытия следующей строки или в конце скрипта.
Очень распространенная ошибка при указании путей в Windows: "C:\xampp\htdocs\"
неверна. Вам нужно "C:\\xampp\\htdocs\\"
.
Альтернативный синтаксис
Несколько реже вы можете увидеть эту синтаксическую ошибку при использовании альтернативного синтаксиса для операторов/блоков кода в шаблонах. Использование if:
и else:
и отсутствующий endif;
например.
Смотрите также:
Ответ 9
Неожиданный T_IF
Неожиданный T_ELSEIF
Неожиданный T_ELSE
Неожиданный T_ENDIF
Блоки условного управления if
, elseif
и else
имеют простую структуру. Когда вы сталкиваетесь с синтаксической ошибкой, скорее всего, это просто недопустимое вложение блоков → с отсутствующими фигурными скобками {
}
- или с одной слишком большой.
Отсутствует {
или }
из-за неправильного отступа
Несоответствующие скобки кода являются общими для менее хорошо отформатированного кода, такого как:
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/else и их кодовых блоков {
}
. Используйте IDE, чтобы увидеть, все ли они связаны.
if (true) {
if (false) {
…
}
elseif ($whatever) {
if ($something2) {
…
}
else {
…
}
}
else {
…
}
if (false) { // a second 'if' tree
…
}
else {
…
}
}
elseif (false) {
…
}
Любой двойной }
}
не просто закроет ветку, но и предыдущую структуру условий. Поэтому придерживайтесь одного стиля кодирования; не смешивать и сочетать во вложенных деревьях if/else.
Помимо последовательности здесь оказывается полезным избегать и длительных условий. Используйте временные переменные или функции, чтобы избежать нечитаемости if
-expressions.
IF
нельзя использовать в выражениях
Удивительно частая ошибка новичка - попытка использовать оператор if
в выражении, таком как оператор печати:
⇓
echo "<a href='" . if ($link == "example.org") { echo …
Что, конечно, неверно.
Вы можете использовать троичное условное выражение, но остерегайтесь влияния читабельности.
echo "<a href='" . ($link ? "http://yes" : "http://no") . "</a>";
В противном случае разбейте такие выходные структуры: используйте несколько if
и echo
s.
А еще лучше, используйте временные переменные и поместите свои условия перед:
if ($link) { $href = "yes"; } else { $href = "no"; }
echo "<a href='$href'>Link</a>";
Определение функций или методов для таких случаев также имеет смысл.
Блоки управления не возвращают "результаты"
Теперь это не так часто, но некоторые кодировщики даже пытаются трактовать if
так, как будто он может вернуть результат:
$var = if ($x == $y) { "true" };
Что структурно идентично использованию if
в конкатенации/выражении строк.
- Но управляющие структуры (если /foreach/while) не имеют "результата".
- Литеральная строка "true" также будет просто пустым утверждением.
Вам придется использовать назначение в блоке кода:
if ($x == $y) { $var = "true"; }
В качестве альтернативы можно прибегнуть к троичному сравнению ?:
.
Если в Если
Вы также не можете вкладывать if
в условие:
⇓
if ($x == true and (if $y != false)) { ... }
Что явно избыточно, потому что and
(или or
) уже позволяет сравнивать цепочки.
Забытые ;
точки с запятой
Еще раз: каждый блок управления должен быть оператором. Если предыдущий фрагмент кода не завершается точкой с запятой, то это гарантированная синтаксическая ошибка:
⇓
$var = 1 + 2 + 3
if (true) { … }
Кстати, последняя строка в кодовом блоке {…}
тоже нуждается в точке с запятой.
Точка с запятой слишком рано
Теперь, вероятно, неправильно обвинять конкретный стиль кодирования, поскольку эту ловушку слишком легко упустить из виду:
⇓
if ($x == 5);
{
$y = 7;
}
else ←
{
$x = -1;
}
Что происходит чаще, чем вы можете себе представить.
- Когда вы завершите выражение
if ()
с помощью ;
, оно выполнит оператор void. ;
становится пустым {}
самостоятельно!
- Таким образом, блок
{…}
отделен от if
и будет всегда работать.
- Таким образом,
else
больше не имел отношения к открытой конструкции if
,
вот почему это может привести к непредвиденной синтаксической ошибке T_ELSE.
Что также объясняет также тонкую вариацию этой синтаксической ошибки:
if ($x) { x_is_true(); }; else { something_else(); };
Где ;
после кодового блока {…}
завершает весь if
построить, разделив ветку else
синтаксически.
Не использовать блоки кода
Синтаксически разрешено пропускать фигурные скобки {
… }
для кодовых блоков в ветвях if
/elseif
/else
. К сожалению, это синтаксический стиль, очень распространенный для неверсированных кодеров. (По ложному предположению это было быстрее напечатать или прочитать).
Однако это очень вероятно, чтобы сбить синтаксис. Рано или поздно дополнительные операторы попадут в ветки if/else:
if (true)
$x = 5;
elseif (false)
$x = 6;
$y = 7; ←
else
$z = 0;
Но для фактического использования блоков кода вам нужно написать {
… }
их как таковые!
Даже опытные программисты избегают этого неослабного синтаксиса, или, по крайней мере, понимать это как исключительное исключение из правила.
Остальное /Elseif в неправильном порядке
Напоминаем себе, конечно, условный порядок.
if ($a) { … }
else { … }
elseif ($b) { … }
↑
У вас может быть столько elseif
, сколько вы хотите, но else
должно идти последним. Вот только как это.
Объявления класса
Как указано выше mentioned above, в объявлении класса нельзя использовать операторы управления:
class xyz {
if (true) {
function ($var) {}
}
Вы либо забыли определение функции, либо закрыли }
слишком рано в таких случаях.
Неожиданный T_ELSEIF/T_ELSE
При смешивании PHP и HTML закрывающий }
для if/elseif
должен находиться в том же блоке PHP <?php ?>
, что и следующий elseif/else
. Это приведет к ошибке, поскольку закрывающий }
для if
должен быть частью elseif
:
<?php if ($x) { ?>
html
<?php } ?>
<?php elseif ($y) { ?>
html
<?php } ?>
Правильная форма <?php } elseif
:
<?php if ($x) { ?>
html
<?php } elseif ($y) { ?>
html
<?php } ?>
Это более или менее вариант неправильного отступа - предположительно часто основанный на неправильных намерениях кодирования.
Вы не можете смешивать другие операторы между if
и elseif
/else
структурными токенами:
if (true) {
}
echo "in between"; ←
elseif (false) {
}
?> text <?php ←
else {
}
Либо может встречаться только в кодовых блоках {…}
, но не между токенами структуры управления.
- В любом случае это не имеет смысла. Не похоже, чтобы было какое-то неопределенное состояние, когда PHP переходил между ветвями
if
и else
.
- Вы должны будете решить, где операторы печати принадлежат/или если они должны повторяться в обеих ветвях.
Вы также не можете разделить if/else между различными структурами управления:
foreach ($array as $i) {
if ($i) { … }
}
else { … }
Не существует синтаксической связи между if
и else
. Лексическая область foreach
заканчивается в }
, поэтому нет смысла продолжать структуру if
.
T_ENDIF
Если к неожиданному T_ENDIF предъявляются претензии, вы используете альтернативный стиль синтаксиса if:
⋯ elseif:
⋯ else:
⋯ endif;
. О чем стоит подумать дважды.
Типичная ошибка - запутанная похожая на двоеточие :
точка с запятой ;
. (В "Точка с запятой слишком рано")
Поскольку в файлах шаблонов сложнее отслеживать отступы, тем больше при использовании альтернативного синтаксиса - возможно, ваш endif;
не соответствует ни одному if:
.
Использование } endif;
является удвоенным if
-terminator.
В то время как "неожиданный конец $" - это обычно цена за забытую фигурную скобку закрытия }
.
Назначение и сравнение
Итак, это не синтаксическая ошибка, но стоит упомянуть в этом контексте:
⇓
if ($x = true) { }
else { do_false(); }
Это не сравнение ==
/===
, а назначение =
. Это довольно тонко, и некоторые пользователи легко могут бесполезно редактировать целые блоки условий. Сначала следите за непреднамеренными заданиями - всякий раз, когда вы испытываете логическую ошибку/неправильное поведение.
Ответ 10
Неожиданный T_IF
Неожиданный T_FOREACH
Неожиданный T_FOR
Неожиданный T_WHILE
Неожиданный T_DO
Неожиданный T_ECHO
Управляющие конструкции, такие как if
, foreach
, for
, while
, list
, global
, return
, do
, print
, echo
могут использоваться только как заявления. Они обычно живут по одной линии.
-
Точка с запятой; где ты?
Довольно универсально, если вы пропустили точку с запятой в предыдущей строке, если парсер жалуется на инструкцию управления:
⇓
$x = myfunc()
if (true) {
Решение: просмотрите предыдущую строку; добавить точку с запятой.
-
Объявления классов
Другое место, где это происходит, в объявлениях классов. В разделе класса вы можете только перечислять инициализации свойств и разделы методов. Никакой код не может находиться там.
class xyz {
if (true) {}
foreach ($var) {}
Такие синтаксические ошибки обычно реализуются для неверно вложенных {
и }
. В частности, когда блоки кода функции закрылись слишком рано.
-
Выражения в контексте выражения
Большинство языковых конструкций могут использоваться только как утверждения. Они не предназначены для размещения внутри других выражений:
⇓
$var = array(1, 2, foreach($else as $_), 5, 6);
Аналогично, вы не можете использовать if
в строках, математических выражениях или в других местах:
⇓
print "Oh, " . if (true) { "you!" } . " won't work";
// Use a ternary condition here instead, when versed enough.
Для вложения if
-подобных условий в выражении специально вы часто хотите использовать трехмерную оценку ?:
.
То же самое относится к for
, while
, global
, echo
и меньшему расширению list
.
⇓
echo 123, echo 567, "huh?";
В то время как print()
- это встроенный язык, который может использоваться в контексте выражения. (Но редко имеет смысл.)
-
Зарезервированные ключевые слова как идентификаторы
Вы также не можете использовать do
или if
и другие языковые конструкции для пользовательских функций или имен классов. (Возможно, в PHP7. Но даже тогда было бы нецелесообразно.)
Ответ 11
Неожиданный T_IS_EQUAL
Неожиданный T_IS_GREATER_OR_EQUAL
Неожиданный T_IS_IDENTICAL
Неожиданный T_IS_NOT_EQUAL
Неожиданный T_IS_NOT_IDENTICAL
Неожиданный T_IS_SMALLER_OR_EQUAL
Неожиданный <
Неожиданный >
Операторы сравнения, такие как ==
, >=
, ===
, !=
, <>
, !==
и <=
или <
и >
в основном следует использовать только в выражениях, например, if
выражения. Если синтаксический анализатор жалуется на них, это часто означает неправильный paring или mismatched (
)
parens вокруг них.
-
Группировка Parens
В частности, для операторов if
с несколькими сравнениями вы должны позаботиться о правильном подсчете открывающей и закрывающей круглых скобок:
⇓
if (($foo < 7) && $bar) > 5 || $baz < 9) { ... }
↑
Здесь условие if
здесь уже было прервано )
После того, как ваши сравнения становятся достаточно сложными, что часто помогает разбить его на несколько и вложенных друг в друга, if
конструктов скорее.
-
isset(), измельченный при сравнении
Обычным новичком является то, что pitfal пытается совместить isset()
или empty()
со сравнением:
⇓
if (empty($_POST["var"] == 1)) {
Или даже:
⇓
if (isset($variable !== "value")) {
Это не имеет смысла для PHP, потому что isset
и empty
- это языковые конструкции, которые принимают только имена переменных. Не имеет смысла сравнивать результат либо потому, что вывод только/уже является логическим.
-
Confusion >=
больше или равно с =>
оператором массива
Оба оператора выглядят несколько схожими, поэтому их иногда путают:
⇓
if ($var => 5) { ... }
Вам нужно только помнить, что этот оператор сравнения называется "большим или равным", чтобы понять это правильно.
См. Также: Структура оператора if в PHP
-
Ничего не сравнится с
Вы также не можете комбинировать два сравнения, если они относятся к одному и тому же имени переменной:
⇓
if ($xyz > 5 and < 100)
PHP не может вывести, что вы хотели снова сравнить начальную переменную. Выражения, как правило, в паре в соответствии с оператором старшинства, так что к тому времени, когда <
видно, не было бы всего лишь логический результат слева от исходной переменной.
См. Также: неожиданный T_IS_SMALLER_OR_EQUAL
-
Цепи сравнения
Вы не можете сравнивать с переменной с рядом операторов:
⇓
$reult = (5 < $x < 10);
Это должно быть разбито на два сравнения, каждый против $x
.
На самом деле это больше относится к черным спискам (из-за эквивалентной операторной ассоциативности). Он синтаксически действителен в нескольких языках C-стиля, но PHP не будет интерпретировать его как ожидаемую цепочку сравнения.
-
Неожиданный >
Неожиданный <
Больше >
меньше или <
операторы не имеют пользовательский T_XXX
Tokenizer имени. И хотя они могут быть неуместными, как и все остальные, вы чаще всего видите, что парсер жалуется на них за неверно настроенные строки и вышитые HTML:
⇓
print "<a href='z">Hello</a>";
↑
Это составляет строка "<a href='z"
>
буквального постоянной Hello
, а затем другой <
сравнения. Или, по крайней мере, как это видит PHP. Фактическая причина и синтаксис ошибка была преждевременно строка "
окончание.
Также невозможно вставить теги запуска PHP:
<?php echo <?php my_func(); ?>
↑
Смотрите также:
Ответ 12
Неожиданный '?'
Если вы пытаетесь использовать оператор объединения нулей ??
в версии PHP до PHP 7 вы получите эту ошибку.
<?= $a ?? 2; // works in PHP 7+
<?= (!empty($a)) ? $a : 2; // All versions of PHP
Неожиданное "?", Ожидающая переменная
Аналогичная ошибка может возникать для типов, допускающих значение NULL, например:
function add(?int $sum): ?int {
Что опять же указывает на использование устаревшей версии PHP (либо CLI-версия php -v
либо веб-сервер ограничен одним phpinfo();
).
Ответ 13
Неожиданное T_LNUMBER
T_LNUMBER
относится к "длинному"/номеру.
-
Недопустимые имена переменных
В PHP и большинстве других языков программирования переменные не могут начинаться с числа. Первым символом должен быть алфавит или символ подчеркивания.
$1 // Bad
$_1 // Good
-
Довольно часто возникает вопрос о использовании preg_replace
-placeholders "$1"
в контексте PHP:
# ↓ ⇓ ↓
preg_replace("/#(\w+)/e", strtopupper($1) )
Если обратный вызов должен быть указан. (Теперь флаг /e
regex устарел, но иногда он иногда используется неправильно в preg_replace_callback
.)
-
То же ограничение идентификатора применяется к свойствам объекта, кстати.
↓
$json->0->value
-
Хотя токенизатор/парсер не разрешает буквенное значение $1
как имя переменной, можно использовать ${1}
или ${"1"}
. Который является синтаксическим обходным решением для нестандартных идентификаторов. (Лучше всего думать об этом как о локальном просмотре области. Но вообще: предпочитайте простые массивы для таких случаев!)
-
Любопытно, но очень не рекомендуется, парсер PHPs позволяет Unicode-идентификаторы; такой, что $➊
будет действительным. (В отличие от буква 1
).
-
Вход в массивный массив
Неожиданное долго также может возникнуть для объявлений массива - при отсутствии ,
запятые:
# ↓ ↓
$xy = array(1 2 3);
Или же вызовы функций и декларации и другие конструкции:
-
func(1, 2 3);
-
function xy($z 2);
-
for ($i=2 3<$z)
Так обычно бывает один из них ;
или ,
отсутствует для разделения списков или выражений.
-
Misquoted HTML
И опять же, неверные строки являются частым источником бродячих чисел:
# ↓ ↓
echo "<td colspan="3">something bad</td>";
Такие случаи следует рассматривать более или менее как неожиданные ошибки T_STRING.
-
Другие идентификаторы
Ни функции, ни классы, ни пространства имен не могут быть названы, начиная с номера:
↓
function 123shop() {
Совсем так же, как и для имен переменных.
Ответ 14
Неожиданный '='
Это может быть вызвано наличием недопустимых символов в имени переменной. Имена переменных должны соответствовать следующим правилам:
Имена переменных следуют тем же правилам, что и другие метки в PHP. Правильное имя переменной начинается с буквы или подчеркивания, за которой следует любое количество букв, цифр или символов подчеркивания. В качестве регулярного выражения оно выражается следующим образом: "[a-zA-Z_\x7f-\xff] [a-zA-Z0-9 _\x7f-\xff] * '
Ответ 15
Неожиданный "продолжить" (T_CONTINUE)
continue
- это утверждение (например, для или если) и должно выглядеть автономным. Он не может использоваться как часть выражения. Отчасти потому, что continue не возвращает значение, но в выражении каждое подвыражение должно приводить к некоторому значению, поэтому общее выражение приводит к значению. Это разница между выражением и выражением.
Это означает, что continue
не может использоваться в тройном заявлении или в любом заявлении, требующем возвращаемого значения.
Неожиданный "разрыв" (T_BREAK)
То же самое касается break;
конечно. Он также неприменим в контексте выражения, но строгий оператор (на том же уровне, что и foreach
или блок if
).
Неожиданное "возвращение" (T_RETURN)
Теперь это может быть более неожиданным для return
, но это также просто оператор уровня блока. Он возвращает значение (или NULL) для более высокой области/функции, но оно не оценивается как само выражение. → То есть: нет смысла делать return(return(false);;
Ответ 16
Неожиданный "конец" (T_ENDWHILE)
Синтаксис использует двоеточие - если двоеточие отсутствует, возникнет указанная выше ошибка.
<?php while($query->fetch()): ?>
....
<?php endwhile; ?>
Альтернативой этому синтаксису являются фигурные скобки:
<?php while($query->fetch()) { ?>
....
<?php } ?>
http://php.net/manual/en/control-structures.while.php
Ответ 17
Сообщение об ошибке, которое начинается Parse error: syntax error, unexpected ':'
может быть вызвано ошибочной записью статической ссылки на Class::$Variable
качестве Class:$Variable
.