Ошибки разбора/синтаксиса PHP; и как их решить?

Какие бывают синтаксические ошибки?

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

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

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

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

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

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

  Как интерпретировать ошибки синтаксического анализатора

  Типичное сообщение об ошибке синтаксиса выглядит следующим образом:

  Parse error: syntax error, unexpected T_STRING, expecting ';' in file.php on line 217. В котором перечислено возможное местоположение синтаксической ошибки. Смотрите упомянутые имя файла и номер строки. moniker, такой как T_STRING, объясняет, какой символ синтаксический анализатор/токенизатор не смог окончательно обработать. Однако это не обязательно причина синтаксической ошибки. Важно также просмотреть предыдущие строки кода. Часто синтаксические ошибки - это просто казусы, произошедшие ранее. Номер строки ошибки - это просто место, где синтаксический анализатор окончательно сдался, чтобы обработать все это.

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

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

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

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

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

  • В частности, пропущенные ; точки с запятой отсутствуют в конце предыдущей строки/заявления. (По крайней мере, со стилистической точки зрения. )
  • Если {блоки кода`` неправильно закрыты или вложены, вам, возможно, придется исследовать еще глубже в исходный код. Используйте правильное отступы кода, чтобы упростить эту задачу.

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

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

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

• Временно разбивайте длинные строки.

  • Вы можете свободно добавлять новые строки между операторами или константами и строками. Тогда парсер будет конкретизировать номер строки для выявления ошибок парсинга. Вместо того, чтобы просматривать очень длинный код, вы можете выделить пропущенный или неправильно поставленный синтаксический символ.
  • Разделяйте сложные утверждения if на отдельные или вложенные условия if.
  • Вместо длинных математических формул или логических цепочек используйте временные переменные для упрощения кода. (Больше читабельности = меньше ошибок).
  • Добавляйте новые строки между:
    1. Кодом, который вы можете легко идентифицировать как правильный,
    2. Частями, в которых вы не уверены,
    3. И строки, на которые парсер жалуется.
       Разбивка длинных блоков кода действительно помогает найти источник синтаксических ошибок.

• Выделите комментарием ошибочный код.

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

• Как новичок, избегайте некоторых непонятных синтаксических конструкций.

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

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

  • Отсутствие точки с запятой ; для завершения утверждений/строк.
  • Несоответствие строковых кавычек для " или ' и неэкранированные кавычки внутри.
  • Забытые операторы, в частности, для конкатенации строк ..
  • Несбалансированные (скобки). Посчитайте их в сообщаемой строке. Одинаковое ли их количество?

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

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

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

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

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

  • Попробуйте grep --color -P -n "\[\x80-\xFF\]" file.php в качестве первой меры для поиска не-ASCII символов.
  • В частности, BOM, пробелы нулевой ширины, или неперекрывающиеся пробелы, и умные кавычки регулярно могут попадать в исходный код.

• Следите за тем, какие типы перевода строки сохраняются в файлах.

  • PHP воспринимает только \n новые строки, а не \r возвраты каретки.
  • Что иногда является проблемой для пользователей MacOS (даже на OS  X для неправильно настроенных редакторов).
  • Часто это проявляется только при использовании однострочных //// или # комментариев. Многострочные /*...*/ комментарии редко беспокоят парсер, когда игнорируются переносы строк.

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

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

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

  • php -v для интерпретатора командной строки
  • <?php php phpinfo(); для интерпретатора, вызываемого через веб-сервер.
    Это 'не обязательно одно и то же. В частности, при работе с фреймворками они должны совпадать.

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

• Метод проб и ошибок - это ваше последнее средство. Если ничего не получается, вы всегда можете погуглить сообщение об ошибке. Синтаксические символы не так легко искать (хотя сам 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");

Затем вызовите сбойный код, обратившись к этому скрипту-обертке. Также полезно включить PHP's error_log и посмотреть в ваш веб-сервер's error.log, когда скрипт падает с ответами HTTP 500.

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

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

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

• Превосходные IDE с проверкой синтаксиса (все они доступны для Linux, Windows и Mac): *

1. NetBeans [бесплатно]
2. PHPStorm [$ 199 USD]
3. Eclipse с PHP Plugin [free]
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 можно использовать для включения более нового времени выполнения.

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

• Синтаксис PHP для результата функции разференции → возможен с PHP 5.4
• • https://stackoverflow.com/questions/19206928/php-syntax-error-unexpected*
• • https://stackoverflow.com/questions/4271874/shorthand-for-arrays-is-there-a-literal-syntax-like-or *
• • https://stackoverflow.com/questions/23565971/php-5-3-10-vs-php-5-5-3-syntax-error-unexpected*
• • https://stackoverflow.com/questions/17772534/php-array-square-brackets-and-array-difference*
• • https://stackoverflow.com/questions/11912233/php-array-syntax-parse-error-left-square-bracket*

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

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

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

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

  защищен $ var ["x"] = "Нет" ;
                uzo

• Смешение [ с открытием фигурных скобок { или скобок ( является общим упущением.

  foreach [$ a как $ b)
          uzo

  Или даже:

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

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

  $ var = const [123] ;
         uzo

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

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

• Вы пытаетесь использовать ключевое слово global для члена ассоциативного массива. Это недопустимый синтаксис:

  глобальный $ var ['key'] ;

& Лт; br / >

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

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

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

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

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

  $ var = 2] ;

  Что часто встречается в декларациях массивов multi-line и nested .

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

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

Неожиданная переменная T_VARIABLE

Ошибка "unexpected T_VARIABLE" означает, что имеется буквальное имя $variable, которое не вписывается в структуру текущего выражения/высказывания.

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

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

           ⇓
    func1()
    $var = 1 + 2; # ошибка разбора в строке +2

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

   Частым казусом являются конкатенации строк с забытым оператором .:

                                   ⇓
    print "Пришло значение: " $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() использует $var {}

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

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

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

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

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

См. также

• Поиск: unexpected T_VARIABLE

& Лт;!--ToDo: включить https://stackoverflow.com/a/13935532/345031, который лучше охватывает первый общий случай.-- >

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

Громоздкие имена T_CONSTANT_ENCAPSED_STRING и T_ENCAPSED_AND_WHITESPACE относятся к цитируемой " строке" литералы .

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

1. < h3 > Неправильная интерполяция переменных < / h3 >

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

                             回 全
   echo "Здесь идет $ неправильный ['array'] доступ" ;

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

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

   echo "Это всего лишь $ valid [здесь] ...«;

   Однако вложенные массивы или более глубокие ссылки на объекты требуют синтаксиса [сложного кудрявого строкового выражения](http://www.php.net/language.types.string#language.types.string.parsing#complex+curly + syntax):

   echo "Используйте {$ array ['as_usual']} с вьющимся синтаксисом.«;

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

2. < h3 > Отсутствует конкатенация < / h3 >

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

                          ,
   распечатать "Привет" . МИР " !«;

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

3. < h3 > Смущающие строковые кавычки < / h3 >

   Та же синтаксическая ошибка возникает, когда сводящие разделители строк. Строка, начатая одной цитатой ' или double ", также заканчивается той же.

                   ,
   распечатать "< a href =" ' . $ ссылка . "" > нажмите здесь < / a > ";
          ⁇ 

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

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

   Это хороший пример, когда вы не должны вырывать двойные кавычки. Вместо этого просто используйте propert \ " escapts для HTML атрибуты и # 180; кавычки

   распечатать "< a href = \" {$ link} \ "> нажмите здесь < / a >";

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

4. < h3 > Отсутствует вступительная цитата < / h3 >

   Эквивалентно забытые открывающие кавычки "/ `` рецепт для ошибок синтаксического анализатора:

                  ,
    make_url (логин, «открытый») ;

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

5. < h3 > Списки массивов < / h3 >

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

   массив (
        "ключ" = > «значение»
        «следующий» = > »....",
   );

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

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

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

                            ,
   myfunc (123, «текст», «и» «больше»)

7. < h3 > Беглые строки < / h3 >

   Распространенным вариантом являются просто забытые строковые терминаторы:

                                   ,
   mysql_evil ("ВЫБЕРИТЕ * ИЗ вещей" ;
   распечатать "'хорошо'";
         uzo

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

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

• https://stackoverflow.com/questions/4738850/interpolation-double-quoted-string-of-associative-arrays-in-php
• https://stackoverflow.com/questions/13565768/php-syntax-error-unexpected-t-constant-encifsed-string
• https://stackoverflow.com/questions/2719350/syntax-error-unexpected-t-constant-encifed-string-in-php
• https://stackoverflow.com/questions/5333823/unexpected-t-constant-encaped-string-error-in-sql-query

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

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

1. Неправильно процитированные строки

   Эта синтаксическая ошибка чаще всего встречается для неправильно закавыченных строковых значений. Любая неэкранированная кавычка `"` или `'` образует недопустимое выражение: ⇓ ⇓ echo "нажмите здесь"; Подсветка синтаксиса сделает такие ошибки очевидными. Важно помнить, что для экранирования `\"двойных кавычек'' или `\'одинарных кавычек - в зависимости от того, что было использовано в качестве [корпуса строки][1] - следует использовать обратные слэши. - Для удобства вы должны предпочесть внешние одинарные кавычки при выводе обычного HTML с двойными кавычками внутри. - Используйте строки с двойными кавычками, если вы хотите интерполировать переменные, но тогда следите за экранированием буквальных `"двойных кавычек''. - Для более длинного вывода предпочтите несколько строк `echo`/ `print` вместо экранирования входов и выходов. Еще лучше рассмотреть раздел [HEREDOC][2]. См. также *https://stackoverflow.com/questions/3446216/what-is-the-difference-between-single-quoted-and-double-quoted-strings-in-php*.

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

   Если вы [пропускаете закрывающую `"строку''][3], то синтаксическая ошибка обычно проявляется позже. Незавершенная строка часто будет занимать немного кода до следующего предполагаемого значения строки: ⇓ echo "Некоторый текст", $a_variable, "и некоторая убегающая строка ; success("finished"); ⇯ Это не только буквальные `T_STRING`, которые парсер может протестовать. Другой частой вариацией является [`Unexpected '>'`](https://stackoverflow.com/questions/6507796/troubleshooting-parse-error-unexpected-error) для нецитированного литерала HTML.

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

   Если вы *копируете и вставляете* код с блога или веб-сайта, то иногда в итоге получаете недопустимый код. [Типографские кавычки - это не то, что ожидает PHP][4]: $text = 'Something something something...' + "these ain't quotes"; Типографские/умные кавычки - это символы Юникода. PHP воспринимает их как часть примыкающего буквенно-цифрового текста. Например, `"these" интерпретируется как идентификатор константы. Но любой следующий за ним текстовый литерал воспринимается парсером как пустое слово/T_STRING.

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

   Если в предыдущих строках есть выражение без точки с запятой, то любое следующее утверждение или языковая конструкция воспринимается как необработанный идентификатор: ⇓ func1() function2(); PHP просто не может понять, хотели ли вы запустить две функции друг за другом, или вы хотели перемножить их результаты, сложить их, сравнить их, или запустить только одну `|||` или другую.

5. Короткие открытые теги и <?xml заголовки в PHP скриптах

   Это довольно редкое явление. Но если включены short_open_tags, то вы не можете'начинать свои PHP-скрипты [с XML-декларации][5]: ⇓ <?xml version="1.0"?> PHP увидит `<?` и присвоит его себе. Он не поймет, для чего предназначался этот "блуждающий" `xml`. Она будет интерпретирована как константа. Но `version` будет восприниматься как еще один литерал/константа. А поскольку парсер не может понять смысл двух последующих литералов/значений без оператора выражения между ними, это будет ошибкой парсера.

6. Невидимые символы Unicode

   Самой отвратительной причиной синтаксических ошибок являются символы Unicode, такие как [неразрывный пробел][6]. PHP допускает использование символов Unicode в качестве имен идентификаторов. Если вы получаете жалобу парсера T_STRING на совершенно не подозрительный код, например: <?php выведите 123; вам нужно достать другой текстовый редактор. Или даже hexeditor. То, что здесь выглядит как обычные пробелы и новые строки, может содержать невидимые константы. Java IDE иногда не обращают внимания на UTF-8 BOM, искаженный внутри, пробелы нулевой ширины, разделители абзацев и т.д. Попробуйте перередактировать все, удалить пробельные символы и добавить нормальные пробелы обратно. Вы можете сузить круг поиска, добавив лишние разделители `;` в начале каждой строки: <?php ;print 123; Лишняя точка с запятой `;` преобразует предшествующий невидимый символ в ссылку на неопределенную константу (выражение как утверждение). Что в свою очередь заставит PHP выдать полезное уведомление.

7. Отсутствие знака `$` перед именами переменных

   [Переменные в PHP][7] представлены знаком доллара, за которым следует имя переменной. Знак доллара (`$`) - это [знак отличия][8], который отмечает идентификатор как имя переменной. Без этого знака идентификатор может быть [ключевым словом языка][9] или [константой][10]. Это распространенная ошибка, когда код PHP был ["переведен" из кода, написанного на другом языке][11] (C, Java, JavaScript и т.д.). В таких случаях объявление типа переменной (если исходный код был написан на языке, использующем типизированные переменные) также может проскочить и выдать эту ошибку.

8. Сбежавшие кавычки

   Если вы используете `\` в строке, это имеет особое значение. Это называется "[Escape Character][12]" и обычно говорит синтаксическому анализатору, что следующий символ следует воспринимать буквально. Пример: `echo 'Jim said \'Hello\'';` выведет `Jim said 'hello'`. Если вы экранируете закрывающую кавычку строки, то закрывающая кавычка будет воспринята буквально, а не по назначению, т.е. как печатная кавычка, как часть строки, а не как закрытие строки. Это будет отображаться как ошибка разбора, обычно после открытия следующей строки или в конце скрипта. Очень распространенная ошибка при указании путей в Windows: `"C:\xampp\htdocs\"` неверно. Вам нужно `"C:\\\xampp\\htdocs\\"`.

Неожиданно (

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

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

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

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

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

2. < h3 > Свойства по умолчанию класса < / h3 >

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

   класс xyz {  回
       var $ default = get_config ("xyz_default") ;

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

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

3. < h3 > Синтаксис JavaScript в PHP < / h3 >

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

   & Лт;?php 
       print $ (документ) .text () ;

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

4. < h3 > isset (()), пустой, ключ, следующий, текущий < / h3 >

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

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

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

   Функции пользовательского уровня, для которых требуется ссылка на переменную, но вместо этого получают результат выражения passed-lead к ошибкам времени выполнения.

& Лт; br >

Неожиданно )

1. < h3 > Параметр отсутствующей функции < / h3 >

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

                 ,
   callfunc (1, 2,);

   Конечная запятая разрешена только в конструкциях array () или list ().

2. < h3 > Незавершенные выражения < / h3 >

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

                  ,
   $ var = 2 * (1 +) ;

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

3. < h3 > Преуспевать как < код > постоянный < / код > & Лт; / h3 >

   Для забытых префиксов $ в контрольных операторах вы увидите:

                      ↓ 全
   foreach ($ array как неправильный) {

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

& Лт; br >

Неожиданно {

Кудрявые скобки { и }включают блоки кода. И синтаксические ошибки о них обычно указывают на некоторое вложение incorrec.

1. < h3 > Несоответствующие подвыражения в if < / code > & Лт; / h3 >

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

                                 ,
   if (($ x == $ y) & & (2 == правда) {

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

2. < h3 > {и} в контексте выражения < / h3 >

   Вы не можете использовать фигурные скобки в выражениях. Если вы путаете скобки и кудрявые, это не будет соответствовать грамматике языка:

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

   Есть несколько исключений для построения идентификатора, таких как локальная переменная области действия $ {references}.

3. < h3 > Переменные переменные или кудрявые выражения var < / h3 >

   Это довольно редко. Но вы также можете получить жалобы синтаксического анализатора { и `} для сложных переменных:

                         ,
   распечатать "Hello {$ world [2 {]} !«;

   Хотя вероятность неожиданного }в таких условиях выше.