意外的T_CONSTANT_ENCAPSED_STRING意外的t_encapsed_and_空白

T_CONSTANT_ENCAPSED_STRING和T_ENCAPSED_AND_WHITESPACE是指带引号的“字符串”字面量。

它们在不同的上下文中使用，但语法问题非常相似。t_encaged…警告出现在双引号的字符串上下文中，而T_CONSTANT…字符串经常在普通PHP表达式或语句中出错。

Incorrect variable interpolation And it comes up most frequently for incorrect PHP variable interpolation: ⇓ ⇓ echo "Here comes a $wrong['array'] access"; Quoting arrays keys is a must in PHP context. But in double quoted strings (or HEREDOCs) this is a mistake. The parser complains about the contained single quoted 'string', because it usually expects a literal identifier / key there. More precisely it's valid to use PHP2-style simple syntax within double quotes for array references: echo "This is only $valid[here] ..."; Nested arrays or deeper object references however require the complex curly string expression syntax: echo "Use {$array['as_usual']} with curly syntax."; If unsure, this is commonly safer to use. It's often even considered more readable. And better IDEs actually use distinct syntax colorization for that. Missing concatenation If a string follows an expression, but lacks a concatenation or other operator, then you'll see PHP complain about the string literal: ⇓ print "Hello " . WORLD " !"; While it's obvious to you and me, PHP just can't guess that the string was meant to be appended there. Confusing string quote enclosures The same syntax error occurs when confounding string delimiters. A string started by a single ' or double " quote also ends with the same. ⇓ print "<a href="' . $link . '">click here</a>"; ⌞⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟ That example started with double quotes. But double quotes were also destined for the HTML attributes. The intended concatenation operator within however became interpreted as part of a second string in single quotes. Tip: Set your editor/IDE to use slightly distinct colorization for single and double quoted strings. (It also helps with application logic to prefer e.g. double quoted strings for textual output, and single quoted strings only for constant-like values.) This is a good example where you shouldn't break out of double quotes in the first place. Instead just use proper \" escapes for the HTML attributes´ quotes: print "<a href=\"{$link}\">click here</a>"; While this can also lead to syntax confusion, all better IDEs/editors again help by colorizing the escaped quotes differently. Missing opening quote Equivalently are forgotten opening "/' quotes a recipe for parser errors: ⇓ make_url(login', 'open'); Here the ', ' would become a string literal after a bareword, when obviously login was meant to be a string parameter. Array lists If you miss a , comma in an array creation block, the parser will see two consecutive strings: array( ⇓ "key" => "value" "next" => "....", ); Note that the last line may always contain an extra comma, but overlooking one in between is unforgivable. Which is hard to discover without syntax highlighting. Function parameter lists The same thing for function calls: ⇓ myfunc(123, "text", "and" "more") Runaway strings A common variation are quite simply forgotten string terminators: ⇓ mysql_evil("SELECT * FROM stuffs); print "'ok'"; ⇑ Here PHP complains about two string literals directly following each other. But the real cause is the unclosed previous string of course. HEREDOC indentation Prior PHP 7.3, the heredoc string end delimiter can't be prefixed with spaces: print <<< HTML <link..> HTML; ⇑ Solution: upgrade PHP or find a better hoster.

另请参阅

PHP中关联数组的插值(双引号字符串) 语法错误，意外的T_CONSTANT_ENCAPSED_STRING 语法错误，PHP中意外的T_CONSTANT_ENCAPSED_STRING SQL查询中出现意外的T_CONSTANT_ENCAPSED_STRING错误

意想不到的“?”

如果您试图使用<?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();)。

意想不到的T_LNUMBER

令牌T_LNUMBER指向一个“长”/ number。

Invalid variable names In PHP, and most other programming languages, variables cannot start with a number. The first character must be alphabetic or an underscore. $1 // Bad $_1 // Good Quite often comes up for using preg_replace-placeholders "$1" in PHP context: # ↓ ⇓ ↓ preg_replace("/#(\w+)/e", strtopupper($1) ) Where the callback should have been quoted. (Now the /e regex flag has been deprecated. But it's sometimes still misused in preg_replace_callback functions.) The same identifier constraint applies to object properties, btw. ↓ $json->0->value While the tokenizer/parser does not allow a literal $1 as variable name, one could use ${1} or ${"1"}. Which is a syntactic workaround for non-standard identifiers. (It's best to think of it as a local scope lookup. But generally: prefer plain arrays for such cases!) Amusingly, but very much not recommended, PHPs parser allows Unicode-identifiers; such that $➊ would be valid. (Unlike a literal 1). Stray array entry An unexpected long can also occur for array declarations - when missing , commas: # ↓ ↓ $xy = array(1 2 3); Or likewise function calls and declarations, and other constructs: func(1, 2 3); function xy($z 2); for ($i=2 3<$z) So usually there's one of ; or , missing for separating lists or expressions. Misquoted HTML And again, misquoted strings are a frequent source of stray numbers: # ↓ ↓ echo "<td colspan="3">something bad</td>"; Such cases should be treated more or less like Unexpected T_STRING errors. Other identifiers Neither functions, classes, nor namespaces can be named beginning with a number either: ↓ function 123shop() { Pretty much the same as for variable names.

意想不到的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.

语法错误是什么?

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。

意想不到的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