意外的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属于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。

意想不到的:

1. PHP 8命名参数语法

Unexpected ':'， expected '，' or ')'

如果试图在PHP < 8的版本中使用PHP 8的新命名形参功能，将会出现以下错误:

$table->string(column:'Name');

解决方案:

将PHP版本升级到PHP 8.0.0或更高版本 不要使用命名参数(按照预期的顺序传递参数)

2. 裁剪类::分隔符

以“解析错误:语法错误，意外的‘:’”开头的错误消息可能是由于错误地将类静态引用class::$Variable写成class:$Variable而引起的。

对于VS Code的新手，如果你看到语法错误，检查你是否保存了文件。如果你有一个错误的语法，保存文件，然后在不保存的情况下修复语法，VS Code会继续显示错误。只有保存文件后，错误信息才会消失。

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

意想不到的“?”

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