意想不到的“?”

如果您试图使用<?PHP <?PHP这个错误将被返回*。

$var = 'hello '<?php echo 'world'; ?>;

*为PHP版本4.3.1,4.3.5——4.3.11 4.4.0——4.1.1 5.0.0——5.0.5 10/24/11——4.4.9 5.1.0——5.1.6 5.2.0——5.2.17 5.3.0——5.3.29 5.4.0 5.4.45,发送,5.5.38 5.6.0——5.6.40 7.0.0——7.0.33 7.1.0——7.1.33 7.2.0——7.2.34 7.3.0——7.3.31 7.4.0——7.4.24

如果您正在尝试使用空合并操作符??在php7之前的版本中，你会得到这个错误。

<?= $a ?? 2; // works in PHP 7+
<?= (!empty($a)) ? $a : 2; // All versions of PHP

意想不到的”?，期望变量

可空类型也会出现类似的错误，如下所示:

function add(?int $sum): ?int {

这再次表明使用了过时的PHP版本(CLI版本PHP -v或web服务器绑定的phpinfo();)。

意想不到的(

现在，在过时的PHP版本中经常可以看到意外的[array括号]。短数组语法从PHP >= 5.4开始可用。旧的安装只支持array()。

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

数组函数结果解引用同样不适用于旧的PHP版本:

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

这个错误在PHP中意味着什么?-“语法错误，意外的\[”显示了最常见和实用的解决方案。

不过，最好还是升级PHP安装。对于共享网络托管计划，首先要研究是否可以使用SetHandler php5 56-fcgi来启用新的运行时。

参见:

对函数result→进行解引用的PHP语法，从PHP 5.4开始可能 PHP语法错误，意外的“[” 数组的简写:是否存在像{}或[]这样的文字语法? PHP 5.3.10 vs PHP 5.5.3语法错误 数组()和[]的区别 PHP数组语法解析错误

顺便说一下，如果你对老版本和慢版本的PHP很感兴趣的话，还有预处理器和PHP 5.4语法下转换器。

导致意外语法错误的其他原因

如果不是PHP版本不匹配，那么通常是一个简单的拼写错误或新手语法错误:

You can't use array property declarations/expressions in classes, not even in PHP 7. protected $var["x"] = "Nope"; ⇑ Confusing [ with opening curly braces { or parentheses ( is a common oversight. foreach [$a as $b) ⇑ Or even: function foobar[$a, $b, $c] { ⇑ Or trying to dereference constants (before PHP 5.6) as arrays: $var = const[123]; ⇑ At least PHP interprets that const as a constant name. If you meant to access an array variable (which is the typical cause here), then add the leading $ sigil - so it becomes a $varname. You are trying to use the global keyword on a member of an associative array. This is not valid syntax: global $var['key'];

结束方括号

这种情况比较少见，但是终止数组[括号]也会出现语法错误。

同样，与)括号或}大括号不匹配是常见的: 函数foobar($a， $b， $c] { ⇑ 或者试图结束一个没有数组的数组: $var = 2]; 这通常发生在多行和嵌套数组声明中。 $数组=[1,2,3],4(5、6 (7 [8][9 10]],11),12]],15); ⇑ 如果是，请使用IDE进行括号匹配以查找任何过早的]数组闭包。至少使用更多的空格和换行来缩小范围。

语法错误是什么?

PHP属于c风格的命令式编程语言。它有严格的语法规则，当遇到错位的符号或标识符时，它无法恢复。它无法猜测你的编码意图。

最重要的建议

这里有一些你总是可以采取的基本预防措施:

使用适当的代码缩进，或采用任何高级的编码风格。 可读性可以防止不规则性。 使用带有语法高亮显示功能的IDE或PHP编辑器。 这也有助于括号/方括号平衡。 阅读手册中的语言参考和示例。 两次，达到一定程度的熟练。

如何解释解析器错误

典型的语法错误消息如下:

解析错误:语法错误，意外的T_STRING，期望在file.php第217行有';

它列出了语法错误的可能位置。请参阅提到的文件名和行号。

像T_STRING这样的别名解释了解析器/标记器最终不能处理哪个符号。然而，这并不一定是语法错误的原因。

查看之前的代码行也很重要。通常语法错误只是之前发生的意外。错误行号只是解析器最终放弃处理的地方。

解决语法错误

有许多方法可以缩小和修复语法问题。

Open the mentioned source file. Look at the mentioned code line. For runaway strings and misplaced operators, this is usually where you find the culprit. Read the line left to right and imagine what each symbol does. More regularly you need to look at preceding lines as well. In particular, missing ; semicolons are missing at the previous line ends/statement. (At least from the stylistic viewpoint. ) If { code blocks } are incorrectly closed or nested, you may need to investigate even further up the source code. Use proper code indentation to simplify that. Look at the syntax colorization! Strings and variables and constants should all have different colors. Operators +-*/. should be tinted distinct as well. Else they might be in the wrong context. If you see string colorization extend too far or too short, then you have found an unescaped or missing closing " or ' string marker. Having two same-colored punctuation characters next to each other can also mean trouble. Usually, operators are lone if it's not ++, --, or parentheses following an operator. Two strings/identifiers directly following each other are incorrect in most contexts. Whitespace is your friend. Follow any coding style. Break up long lines temporarily. You can freely add newlines between operators or constants and strings. The parser will then concretize the line number for parsing errors. Instead of looking at the very lengthy code, you can isolate the missing or misplaced syntax symbol. Split up complex if statements into distinct or nested if conditions. Instead of lengthy math formulas or logic chains, use temporary variables to simplify the code. (More readable = fewer errors.) Add newlines between: The code you can easily identify as correct, The parts you're unsure about, And the lines which the parser complains about. Partitioning up long code blocks really helps to locate the origin of syntax errors. Comment out offending code. If you can't isolate the problem source, start to comment out (and thus temporarily remove) blocks of code. As soon as you got rid of the parsing error, you have found the problem source. Look more closely there. Sometimes you want to temporarily remove complete function/method blocks. (In case of unmatched curly braces and wrongly indented code.) When you can't resolve the syntax issue, try to rewrite the commented out sections from scratch. As a newcomer, avoid some of the confusing syntax constructs. The ternary ? : condition operator can compact code and is useful indeed. But it doesn't aid readability in all cases. Prefer plain if statements while unversed. PHP's alternative syntax (if:/elseif:/endif;) is common for templates, but arguably less easy to follow than normal { code } blocks. The most prevalent newcomer mistakes are: Missing semicolons ; for terminating statements/lines. Mismatched string quotes for " or ' and unescaped quotes within. Forgotten operators, in particular for the string . concatenation. Unbalanced ( parentheses ). Count them in the reported line. Are there an equal number of them? Don't forget that solving one syntax problem can uncover the next. If you make one issue go away, but other crops up in some code below, you're mostly on the right path. If after editing a new syntax error crops up in the same line, then your attempted change was possibly a failure. (Not always though.) Restore a backup of previously working code, if you can't fix it. Adopt a source code versioning system. You can always view a diff of the broken and last working version. Which might be enlightening as to what the syntax problem is. Invisible stray Unicode characters: In some cases, you need to use a hexeditor or different editor/viewer on your source. Some problems cannot be found just from looking at your code. Try grep --color -P -n "\[\x80-\xFF\]" file.php as the first measure to find non-ASCII symbols. In particular BOMs, zero-width spaces, or non-breaking spaces, and smart quotes regularly can find their way into the source code. Take care of which type of linebreaks are saved in files. PHP just honors \n newlines, not \r carriage returns. Which is occasionally an issue for MacOS users (even on OS  X for misconfigured editors). It often only surfaces as an issue when single-line // or # comments are used. Multiline /*...*/ comments do seldom disturb the parser when linebreaks get ignored. If your syntax error does not transmit over the web: It happens that you have a syntax error on your machine. But posting the very same file online does not exhibit it anymore. Which can only mean one of two things: You are looking at the wrong file! Or your code contained invisible stray Unicode (see above). You can easily find out: Just copy your code back from the web form into your text editor. Check your PHP version. Not all syntax constructs are available on every server. php -v for the command line interpreter <?php phpinfo(); for the one invoked through the webserver. Those aren't necessarily the same. In particular when working with frameworks, you will them to match up. Don't use PHP's reserved keywords as identifiers for functions/methods, classes or constants. Trial-and-error is your last resort.

如果所有这些都失败了，您总是可以谷歌您的错误消息。语法符号不那么容易搜索(Stack Overflow本身是由SymbolHound索引的)。因此，在你找到相关的东西之前，可能需要多看几页。

进一步指导:

PHP调试基础:David Sklar 修正PHP错误Jason McCreary PHP错误- Mario Lurig的10个常见错误 常见的PHP错误和解决方案 如何解决和修复你的WordPress网站 给设计师的PHP错误信息指南-粉碎杂志

白屏死机

如果你的网站是空白的，那么通常是语法错误造成的。 使用以下方法启用其显示:

error_reporting = E_ALL Display_errors = 1

在你的php.ini中，或者mod_php的。htaccess中， 甚至是带有FastCGI设置的。user.ini。

在破碎的脚本中启用它太晚了，因为PHP甚至不能解释/运行第一行。一个快速的解决方法是创建一个包装器脚本，比如test.php:

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

然后通过访问这个包装器脚本调用失败的代码。

它还有助于启用PHP的error_log，并在脚本因HTTP 500响应而崩溃时查看web服务器的error.log。

意外的'continue' (T_CONTINUE)

Continue是一个语句(如for或if)，必须单独显示。它不能用作表达式的一部分。部分原因是continue不返回值，但在表达式中，每个子表达式都必须产生某个值，因此整个表达式都会产生一个值。这就是语句和表达式的区别。

这意味着continue不能用于三元语句或任何需要返回值的语句。

意外的“中断”(T_BREAK)

休息也是一样;当然可以。它也不能用于表达式上下文，而是一个严格语句(与foreach或if块处于同一级别)。

意外的“返回”(T_RETURN)

对于return来说，这可能更令人惊讶，但这也只是一个块级语句。它确实向更高的作用域/函数返回一个值(或NULL)，但它不作为表达式本身计算。→也就是说:return(return(false);;

意想不到的T_IF 意想不到的T_ELSEIF 意想不到的T_ELSE 意想不到的T_ENDIF

条件控件块if、elseif和else遵循一个简单的结构。当你遇到语法错误时，很可能只是无效的块嵌套→缺少{花括号}——或者多了一个。

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. 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 ifs and echos. 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. Forgotten ; 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. 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. 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. 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 elseifs as you want, but else has to go last. That's just how it is. 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. Unexpected T_ELSEIF / T_ELSE When mixing PHP and HTML, the closing } for an if/elseif must be in the same PHP block <?php ?> as the next elseif/else. This will generate an error as the closing } for the if needs to be part of the elseif: <?php if ($x) { ?> html <?php } ?> <?php elseif ($y) { ?> html <?php } ?> The correct form <?php } elseif: <?php if ($x) { ?> html <?php } elseif ($y) { ?> html <?php } ?> 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. 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. 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.

意想不到的T_VARIABLE

一个“意外的T_VARIABLE”意味着有一个字面的$变量名，它不适合当前表达式/语句结构。

Missing semicolon It most commonly indicates a missing semicolon in the previous line. Variable assignments following a statement are a good indicator where to look: ⇓ func1() $var = 1 + 2; # parse error in line +2 String concatenation A frequent mishap are string concatenations with forgotten . operator: ⇓ print "Here comes the value: " $value; Btw, you should prefer string interpolation (basic variables in double quotes) whenever that helps readability. Which avoids these syntax issues. String interpolation is a scripting language core feature. No shame in utilizing it. Ignore any micro-optimization advise about variable . concatenation being faster. It's not. Missing expression operators Of course the same issue can arise in other expressions, for instance arithmetic operations: ⇓ print 4 + 7 $var; PHP can't guess here if the variable should have been added, subtracted or compared etc. Lists Same for syntax lists, like in array populations, where the parser also indicates an expected comma , for example: ⇓ $var = array("1" => $val, $val2, $val3 $val4); Or functions parameter lists: ⇓ function myfunc($param1, $param2 $param3, $param4) Equivalently do you see this with list or global statements, or when lacking a ; semicolon in a for loop. Class declarations This parser error also occurs in class declarations. You can only assign static constants, not expressions. Thus the parser complains about variables as assigned data: class xyz { ⇓ var $value = $_GET["input"]; Unmatched } closing curly braces can in particular lead here. If a method is terminated too early (use proper indentation!), then a stray variable is commonly misplaced into the class declaration body. Variables after identifiers You can also never have a variable follow an identifier directly: ⇓ $this->myFunc$VAR(); Btw, this is a common example where the intention was to use variable variables perhaps. In this case a variable property lookup with $this->{"myFunc$VAR"}(); for example. Take in mind that using variable variables should be the exception. Newcomers often try to use them too casually, even when arrays would be simpler and more appropriate. Missing parentheses after language constructs Hasty typing may lead to forgotten opening or closing parenthesis for if and for and foreach statements: ⇓ foreach $array as $key) { Solution: add the missing opening ( between statement and variable. ⇓ if ($var = pdo_query($sql) { $result = … The curly { brace does not open the code block, without closing the if expression with the ) closing parenthesis first. Else does not expect conditions ⇓ else ($var >= 0) Solution: Remove the conditions from else or use elseif. Need brackets for closure ⇓ function() use $var {} Solution: Add brackets around $var. Invisible whitespace As mentioned in the reference answer on "Invisible stray Unicode" (such as a non-breaking space), you might also see this error for unsuspecting code like: <?php ⇐ $var = new PDO(...); It's rather prevalent in the start of files and for copy-and-pasted code. Check with a hexeditor, if your code does not visually appear to contain a syntax issue.

另请参阅

搜索:意外T_VARIABLE