Question Erreurs d'analyse / syntaxe PHP; et comment les résoudre?


Tout le monde rencontre des erreurs de syntaxe. Même les programmeurs expérimentés font des fautes de frappe. Pour les nouveaux arrivants, cela fait partie du processus d'apprentissage. Cependant, il est souvent facile d'interpréter des messages d'erreur tels que:

Erreur PHP Parse: erreur de syntaxe, inattendu '{' dans index.php à la ligne 20

Le symbole inattendu n'est pas toujours le vrai coupable. Mais le numéro de ligne donne une idée approximative où commencer à chercher.

Toujours regarder le contexte du code. L’erreur de syntaxe se cache souvent dans le ou dans lignes de code précédentes. Comparez votre code avec les exemples de syntaxe du manuel.

Bien que tous les cas ne correspondent pas à l'autre. Pourtant il y en a étapes générales pour résoudre des erreurs de syntaxe. Ces références résument les pièges courants:

Références étroitement liées:

Et:

Tandis que Stack Overflow accueille également les codeurs débutants, il est principalement axé sur les questions de programmation professionnelle.

  • Répondre aux erreurs de codage de tout le monde et aux fautes de frappe étroites est considéré comme hors sujet.
  • Alors, s'il vous plaît, prenez le temps de suivre étapes de base, avant de poster des requêtes de correction de syntaxe.
  • Si vous devez le faire, veuillez montrer votre propre initiative de résolution, vos tentatives de correction et votre processus de réflexion sur ce qui semble ou pourrait être mauvais.

Si ton navigateur affiche des messages d'erreur tels que "SyntaxError: caractère illégal", alors ce n'est pas réellement -related, mais un -erreur de syntaxe.


502


origine


Réponses:


Quelles sont les erreurs de syntaxe?

PHP appartient à la Style C et impératif langages de programmation. Il a des règles grammaticales rigides, dont il ne peut pas se remettre lorsqu'il rencontre des symboles ou des identificateurs mal placés. Il ne peut pas deviner vos intentions de codage.

Function definition syntax abstract

Conseils les plus importants

Il y a quelques précautions de base que vous pouvez toujours prendre:

  • Utiliser le bon indentation de code, ou adopter un style de codage élevé. La lisibilité empêche les irrégularités.

  • Utilisez un IDE ou éditeur pour PHP avec coloration syntaxique. Ce qui aide également avec les parenthèses / l'équilibrage des crochets.

    Expected: semicolon

  • Lis la référence du langage et des exemples dans le manuel. Deux fois, pour devenir un peu compétent.

Comment interpréter les erreurs de l'analyseur

Un message d'erreur de syntaxe typique indique:

Erreur d'analyse: erreur de syntaxe, inattendue T_STRING, attendant ';' dans file.php sur ligne  217

Qui liste les possible emplacement d'une erreur de syntaxe. Voir le mentionné nom de fichier et numéro de ligne.

UNE moniker tel que T_STRING explique quel symbole le parseur / tokenizer n'a pas pu traiter finalement. Ce n'est pas nécessairement la cause de l'erreur de syntaxe.

Il est important de regarder dans lignes de code précédentes ainsi que. Souvent, les erreurs de syntaxe ne sont que des incidents survenus plus tôt. Le numéro de la ligne d'erreur est juste là où l'analyseur a renoncé de façon concluante pour tout traiter.

Résolution d'erreurs de syntaxe

Il existe de nombreuses approches pour restreindre et corriger les hiccups de syntaxe.

  • Ouvrez le fichier source mentionné. Regardez le mentionné ligne de code.

    • Pour les cordes d'emballement et les opérateurs mal placés, c'est généralement là que vous trouvez le coupable.

    • Lisez la ligne de gauche à droite et imaginez ce que fait chaque symbole.

  • Plus régulièrement, vous devez regarder lignes précédentes ainsi que.

    • En particulier, manquant ; les points-virgules sont manquants à la fin de la ligne précédente / instruction. (Au moins du point de vue stylistique.)

    • Si { blocs de code } sont incorrectement fermés ou imbriqués, vous devrez peut-être rechercher encore plus loin le code source. Utiliser le bon indentation de code pour simplifier cela.

  • Regarde le coloration de la syntaxe!

    • Les chaînes, les variables et les constantes doivent toutes avoir des couleurs différentes.

    • Les opérateurs +-*/. devrait être teinté distinct aussi bien. Sinon, ils pourraient être dans le mauvais contexte.

    • Si vous voyez que la colorisation de la chaîne s'étend trop loin ou trop courte, alors vous avez trouvé une fermeture non échappée ou manquante " ou ' marqueur de chaîne.

    • Avoir deux caractères de ponctuation de même couleur l'un à côté de l'autre peut également signifier des ennuis. Habituellement, les opérateurs sont seuls si ce n'est pas ++, --ou entre parenthèses après un opérateur. Deux chaînes / identificateurs qui se suivent directement sont incorrects dans la plupart des contextes.

  • Whitespace est votre ami.  Suivre tout style de codage.  

  • Briser les longues lignes temporairement.

    • Vous pouvez librement ajouter des nouvelles lignes entre opérateurs ou constantes et chaînes. L'analyseur va ensuite concrétiser le numéro de ligne pour les erreurs d'analyse. Au lieu de regarder le code très long, vous pouvez isoler le symbole de syntaxe manquant ou mal placé.

    • Split complexe if déclarations en distincts ou imbriqués if conditions.

    • Au lieu de longues formules mathématiques ou de chaînes logiques, utilisez des variables temporaires pour simplifier le code. (Plus lisible = moins d'erreurs.)

    • Ajouter des nouvelles lignes entre:

      1. Le code que vous pouvez facilement identifier comme étant correct,
      2. Les parties dont vous n'êtes pas sûr,
      3. Et les lignes dont se plaint l'analyste.

      Partitionner des blocs de code longs vraiment aide à localiser l'origine des erreurs de syntaxe.

  • Commenter code incriminé.

    • Si vous ne pouvez pas isoler la source du problème, commencez à commenter (et donc à supprimer temporairement) les blocs de code.

    • Dès que vous vous êtes débarrassé de l'erreur d'analyse, vous avez trouvé la source du problème. Regardez plus attentivement là-bas.

    • Parfois, vous voulez supprimer temporairement les blocs complets de fonction / méthode. (En cas d'accolades inégalées et de code indenté incorrectement.)

    • Lorsque vous ne pouvez pas résoudre le problème de syntaxe, essayez de récrire les sections commentées à partir de rien.

  • En tant que nouveau venu, évitez certaines constructions syntaxiques qui prêtent à confusion.

    • Le ternaire ? : l'opérateur de condition peut compacter le code et est utile en effet. Mais cela ne facilite pas la lisibilité dans tous les cas. Préférez plaine if déclarations alors que non.

    • La syntaxe alternative de PHP (if:/elseif:/endif;) est commun pour les modèles, mais sans doute moins facile à suivre que la normale { code } des blocs.

  • Les erreurs les plus fréquentes chez les nouveaux arrivants sont:

    • Points-virgules manquants ; pour terminer les instructions / lignes.

    • Guillemets non concordants pour " ou ' et des citations sans échappements à l'intérieur.

    • Opérateurs oubliés, en particulier pour la chaîne . enchaînement.

    • Déséquilibré ( parenthèses ). Comptez-les dans la ligne signalée. Y en a-t-il un nombre égal?

  • N'oubliez pas que résoudre un problème de syntaxe peut révéler le suivant.

    • Si vous faites disparaître un problème, mais que d'autres recadrent dans un code ci-dessous, vous êtes pour la plupart sur la bonne voie.

    • Si, après avoir édité une nouvelle erreur de syntaxe, apparaît dans la même ligne, votre tentative de modification est peut-être un échec. (Pas toujours si.)

  • Restaurez une sauvegarde du code précédemment utilisé, si vous ne pouvez pas le réparer.

    • Adopter un système de versionnement de code source. Vous pouvez toujours voir un diff de la version brisée et dernière version. Ce qui pourrait être éclairant quant à ce que le problème de la syntaxe est.
  • Caractères Unicode parasites invisibles: Dans certains cas, vous devez utiliser un hexeditor ou éditeur / visionneur différent sur votre source. Certains problèmes ne peuvent pas être trouvés simplement en regardant votre code.

    • Essayer grep --color -P -n "\[\x80-\xFF\]" file.php comme première mesure pour trouver des symboles non-ASCII.

    • En particulier, les nomenclatures, les espaces sans largeur ou les espaces insécables, ainsi que les devis intelligents peuvent régulièrement trouver leur place dans le code source.

  • Prenez soin de qui type de sauts de ligne sont enregistrés dans des fichiers.

    • PHP juste les honneurs \ n newlines, pas \ r retours de chariot.

    • Ce qui est parfois un problème pour les utilisateurs de MacOS (même sous OS X pour les éditeurs mal configurés).

    • Il ne fait souvent surface que comme un problème quand une seule ligne // ou # les commentaires sont utilisés. Multiline /*...*/ les commentaires perturbent rarement l'analyseur lorsque les sauts de ligne sont ignorés.

  • Si ton erreur de syntaxe ne transmet pas sur le web:  Il arrive que vous ayez une erreur de syntaxe sur votre machine. Mais publier le même fichier en ligne ne l'expose plus. Ce qui ne peut signifier que deux choses:

    • Vous regardez le mauvais fichier!

    • Ou votre code contient invisible Unicode parasite (voir ci-dessus). Vous pouvez facilement découvrir: Il suffit de copier votre code à partir du formulaire Web dans votre éditeur de texte.

  • Vérifier votre Version PHP. Toutes les constructions syntaxiques ne sont pas disponibles sur tous les serveurs.

  • Ne pas utiliser Les mots-clés réservés de PHP comme identifiants pour les fonctions / méthodes, classes ou constantes.

  • Trial-and-error est votre dernier recours.

Si tout le reste échoue, vous pouvez toujours Google votre message d'erreur Les symboles de syntaxe ne sont pas aussi faciles à rechercher (Stack Overflow lui-même est indexé par SymbolHound bien que). Par conséquent, il peut prendre quelques pages de plus avant de trouver quelque chose de pertinent.

Autres guides:

Écran blanc de la mort

Si votre site Web est vide, une erreur de syntaxe en est la cause. Activer leur affichage avec:

  • error_reporting = E_ALL
  • display_errors = 1

Dans ton php.ini généralement, ou via .htaccess pour mod_php, ou même .user.ini avec les configurations FastCGI.

L'activer dans le script cassé est trop tard car PHP ne peut même pas interpréter / exécuter la première ligne. Une solution de contournement rapide crée un script wrapper, par exemple test.php:

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

Appelez ensuite le code défaillant en accédant à ce script d'encapsuleur.

Cela aide aussi à activer PHP error_log et regardez dans votre serveur web error.log quand un script se bloque avec les réponses HTTP 500.


228



Je pense que ce sujet est totalement surdiscuté / trop compliqué. L'utilisation d'un IDE est LE moyen d'éviter complètement les erreurs de syntaxe. Je dirais même que travailler sans IDE n'est pas du tout professionnel. Pourquoi? Parce que les IDE modernes vérifient votre syntaxe après chaque caractère que vous tapez. Lorsque vous codez et que toute votre ligne devient rouge, et qu'un gros avertissement vous indique le type exact et la position exacte de l'erreur de syntaxe, il n'y a absolument pas besoin de chercher une autre solution.

Utiliser un IDE de vérification de syntaxe signifie:

Vous ne rencontrerez (de manière efficace) jamais plus d'erreurs de syntaxe, simplement parce que vous les voyez correctement pendant que vous tapez. Sérieusement.

D'excellents IDE avec vérification de la syntaxe (tous disponibles pour Linux, Windows et Mac):

  1. NetBeans [gratuit]
  2. PHPStorm [199 USD]
  3. Éclipse avec Plugin PHP [gratuit]
  4. Sublime [$ 80 USD] (principalement un éditeur de texte, mais extensible avec des plugins, comme Parseur de syntaxe PHP)

96



Inattendu [

Ces jours-ci, l'inattendu [ Le support de tableau est souvent vu sur les versions PHP obsolètes. le syntaxe courte de tableau est disponible depuis PHP > = 5.4. Installations plus anciennes uniquement array().

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

Le déréférencement des résultats de la fonction tableau n'est pas non plus disponible pour les anciennes versions de PHP:

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

Référence - Que signifie cette erreur en PHP? - "Erreur de syntaxe, inattendue \[" montre les solutions de contournement les plus courantes et les plus pratiques.

Cependant, vous êtes toujours mieux de simplement mettre à jour votre installation PHP. Pour les plans d'hébergement Web partagés, une première recherche, par ex. SetHandler php56-fcgi peut être utilisé pour activer un environnement d'exécution plus récent.

Voir également:

BTW, il y a aussi des préprocesseurs et Convertisseurs de syntaxe PHP 5.4 si vous êtes vraiment accroché avec des versions plus anciennes et plus lentes de PHP.

Autres causes de Inattendu [ erreurs de syntaxe

Si ce n'est pas l'incompatibilité de la version PHP, c'est souvent une faute de frappe ou une erreur de syntaxe du nouveau venu:

  • Vous ne pouvez pas utiliser déclarations de propriétés de tableau / expressions dans les classes, pas même en PHP 7.

    protected $var["x"] = "Nope";
                  ⇑
    
  • Déroutant [ avec des accolades ouvrantes { ou entre parenthèses ( est un oubli commun.

    foreach [$a as $b)
            ⇑
    

    Ou même:

    function foobar[$a, $b, $c] {
                   ⇑
    
  • Ou essayer de déréférencer les constantes (avant PHP 5.6) en tant que tableaux:

    $var = const[123];
           ⇑
    

    Au moins, PHP interprète cela const comme un nom constant.

    Si vous vouliez accéder à une variable de tableau (qui est la cause typique ici), ajoutez le premier $sigil - donc ça devient un $varname.


Inattendu ]  fermeture crochet carré

C'est un peu plus rare, mais il y a aussi des accidents de syntaxe avec le tableau de terminaison ] support.

  • Encore une fois ) parenthèses ou } les accolades sont communes:

    function foobar($a, $b, $c] {
                              ⇑
    
  • Ou essayer de mettre fin à un tableau où il n'y en a pas:

    $var = 2];
    

    Ce qui se produit souvent dans multi-ligne et imbriqué déclarations de tableau.

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

    Si c'est le cas, utilisez votre EDI pour la correspondance des parenthèses pour trouver un fichier prématuré ] fermeture de tableau. À tout le moins utiliser plus d'espacement et de nouvelles lignes pour l'affiner.


46



T_VARIABLE inattendu

Un inattendu T_VARIABLE"signifie qu'il y a un littéral $variable name, qui ne correspond pas à la structure d'expression / déclaration en cours.

purposefully abstract/inexact operator+$variable diagram

  1. point-virgule manquant

    Il indique le plus souvent un point-virgule manquant dans la ligne précédente. Les affectations de variables suivant une déclaration sont un bon indicateur où regarder:

           ⇓
    func1()
    $var = 1 + 2;     # parse error in line +2
    
  2. Concaténation de chaîne

    Une mésaventure fréquente sont concaténations de chaînes avec oublié . opérateur:

                                   ⇓
    print "Here comes the value: "  $value;
    

    Btw, vous devriez préférer interpolation de chaîne (variables de base entre guillemets) chaque fois que cela aide la lisibilité. Ce qui évite ces problèmes de syntaxe.

    L'interpolation de chaînes est un langage de script caractéristique de base. Pas de honte à l'utiliser. Ignorer tout conseil de micro-optimisation sur la variable . concaténation étant plus rapide. Ce n'est pas.

  3. Opérateurs d'expression manquants

    Bien sûr, le même problème peut survenir dans d'autres expressions, par exemple les opérations arithmétiques:

               ⇓
    print 4 + 7 $var;
    

    PHP ne peut pas deviner ici si la variable aurait dû être ajoutée, soustraite ou comparée, etc.

  4. Listes

    Identique pour les listes de syntaxe, comme dans les populations de tableaux, où l'analyseur indique également une virgule attendue , par exemple:

                                          ⇓
    $var = array("1" => $val, $val2, $val3 $val4);
    

    Ou les listes de paramètres de fonctions:

                                    ⇓
    function myfunc($param1, $param2 $param3, $param4)
    

    De manière équivalente, voyez-vous cela avec list ou global déclarations, ou en l'absence d'un ; point-virgule dans un for boucle.

  5. Déclarations de classe

    Cette erreur de l'analyseur se produit également déclarations en classe. Vous pouvez uniquement affecter des constantes statiques, pas des expressions. Ainsi, l'analyseur se plaint des variables en tant que données assignées:

    class xyz {      ⇓
        var $value = $_GET["input"];
    

    Incomparable } la fermeture des accolades peut notamment conduire ici. Si une méthode est terminée trop tôt (utilisez une indentation correcte!), Une variable parasite est généralement mal placée dans le corps de la déclaration de classe.

  6. Variables après les identifiants

    Vous pouvez aussi ne jamais avoir une variable suit un identifiant directement:

                 ⇓
    $this->myFunc$VAR();
    

    BTW, ceci est un exemple commun où l'intention était d'utiliser variables variables peut-être. Dans ce cas, une recherche de propriété variable avec $this->{"myFunc$VAR"}(); par exemple.

    Gardez à l'esprit que l'utilisation de variables variables devrait être l'exception. Les nouveaux arrivants essaient souvent de les utiliser de manière désinvolte, même lorsque les tableaux seraient plus simples et plus appropriés.

  7. Parens manquants après la construction du langage

    Le typage hâtif peut entraîner une parenthèse ouvrante oubliée pour if et for et foreach déclarations:

           ⇓
    foreach $array as $key) {
    

    Solution: ajoutez l'ouverture manquante ( entre déclaration et variable.

  8. Sinon n'attend pas de conditions

         ⇓
    else ($var >= 0)
    

    Solution: Supprimer les conditions de else Ou utiliser elseif.

  9. Besoin de supports pour la fermeture

         ⇓
    function() uses $var {}
    

    Solution: Ajouter des parenthèses autour $var.

  10. Espace blanc invisible

    Comme mentionné dans le réponse de référence sur "Unicode invisible" (comme un Espace non-cassant), vous pouvez également voir cette erreur pour du code non méfiant comme:

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

    Il est plutôt répandu au début des fichiers et pour le code copié-collé. Vérifiez auprès d'un hexeditor, si votre code ne semble pas contenir de problème de syntaxe.

Voir également


40



T_CONSTANT_ENCAPSED_STRING inattendu
 T_ENCAPSED_AND_WHITESPACE inattendu

Les noms peu maniables T_CONSTANT_ENCAPSED_STRING et T_ENCAPSED_AND_WHITESPACE se référer à cité "string" littéraux


29



T_STRING inattendu

T_STRING est un peu un abus de langage. Il ne se réfère pas à un cité "string". Cela signifie qu'un identifiant brut a été rencontré. Cela peut aller de bare mots à gauche CONSTANT ou noms de fonctions, chaînes non cotées ou tout texte brut.

  1. Chaînes mal citées

    Cependant, cette erreur de syntaxe est la plus fréquente pour les valeurs de chaîne incorrectes. Tout échappé et errant " ou ' quote formera une expression non valide:

                   ⇓                  ⇓
     echo "<a href="http://example.com">click here</a>";
    

    La mise en évidence de la syntaxe rendra ces erreurs super évidentes. Il est important de ne pas oublier d'utiliser des antislashs pour s'échapper \" guillemets doubles, ou \' guillemets simples - selon lequel a été utilisé comme clôture de chaîne.

    • Pour plus de commodité, vous devriez préférer les guillemets simples externes lors de la sortie de HTML simple avec des guillemets doubles.
    • Utilisez des chaînes entre guillemets doubles si vous voulez interpoler des variables, mais attention à l'échappement littéral " double citation.
    • Pour une sortie plus longue, préférez plusieurs echo/print lignes au lieu de s'échapper et de sortir. Mieux encore envisager un HEREDOC section.

    Voir également Quelle est la différence entre les chaînes entre guillemets simples et entre guillemets doubles en PHP?.

  2. Chaînes non fermées

    Si vous manquer une fermeture " alors une erreur de syntaxe se matérialise généralement plus tard. Une chaîne non terminée consomme souvent un peu de code jusqu'à la prochaine valeur de chaîne souhaitée:

                                                           ⇓
    echo "Some text", $a_variable, "and some runaway string ;
    success("finished");
             ⇯
    

    Ce n'est pas juste littéral T_STRINGs que l'analyseur peut protester alors. Une autre variation fréquente est un Unexpected '>' pour le HTML littéral non cité.

  3. Citations de chaîne sans programmation

    Si vous copier et coller code à partir d'un blog ou d'un site Web, vous vous retrouvez parfois avec un code non valide. Les citations typographiques ne sont pas ce que PHP attend:

    $text = ’Something something..’ + ”these ain't quotes”;
    

    Les citations typographiques / intelligentes sont des symboles Unicode. PHP les traite comme faisant partie du texte alphanumérique adjacent. Par exemple ”these est interprété comme un identifiant constant. Mais tout littéral textuel suivant est alors vu comme un bareword / T_STRING par l'analyseur.

  4. Le point-virgule manquant; encore

    Si vous avez une expression non terminée dans les lignes précédentes, toute instruction ou construction de langage suivante est considérée comme un identifiant brut:

           ⇓
    func1()
    function2();
    

    PHP ne peut tout simplement pas savoir si vous vouliez exécuter deux fonctions après l'autre, ou si vous vouliez multiplier leurs résultats, les ajouter, les comparer ou ne les exécuter que || ou l'autre.

  5. Étiquettes ouvertes courtes et <?xml en-têtes dans les scripts PHP

    C'est plutôt rare. Mais si short_open_tags est activé, vous ne pouvez pas commencer vos scripts PHP avec une déclaration XML:

          ⇓
    <?xml version="1.0"?>
    

    PHP verra le <? et le récupérer pour lui-même. Il ne comprendra pas ce que le parasite xml était destiné à. Ça va être interprété comme constant. Mais le version sera vu comme un autre littéral / constant. Et comme l'analyseur ne peut pas donner de sens à deux littéraux / valeurs subséquents sans un opérateur d'expression entre eux, cela sera un échec d'analyse.

  6. Caractères Unicode invisibles

    Une cause la plus hideuse pour les erreurs de syntaxe sont les symboles Unicode, tels que le Espace non-cassant. PHP autorise les caractères Unicode comme noms d'identifiant. Si vous obtenez une réclamation de l'analyseur T_STRING pour un code non suspect, comme:

    <?php
        print 123;
    

    Vous devez sortir un autre éditeur de texte. Ou un hexeditor même. Ce qui ressemble à des espaces unis et des retours à la ligne peut contenir des constantes invisibles. Les EDI basés sur Java sont parfois inconscients d'une nomenclature UTF-8 tronquée, d'espaces de largeur nulle, de séparateurs de paragraphes, etc. Essayez de tout rééditer, supprimez les espaces et rajoutez des espaces normaux.

    Vous pouvez affiner avec ajouter redondant ; séparateurs d'instructions à chaque début de ligne:

    <?php
        ;print 123;
    

    L'extra ; Le point-virgule convertit ici le caractère invisible précédent en une référence constante indéfinie (expression en tant que déclaration). Ce qui fait en sorte que PHP produise un avis utile.

  7. Le signe `$` manquant devant les noms de variables

    Variables en PHP sont représentés par un signe dollar suivi du nom de la variable.

    Le signe du dollar ($) est un sigil qui marque l'identifiant comme nom d'une variable. Sans ce sceau, l'identifiant pourrait être un mot-clé de langue ou un constant.

    Ceci est une erreur courante lorsque le code PHP était "traduit" du code écrit dans une autre langue (C, Java, JavaScript, etc.). Dans de tels cas, une déclaration du type de variable (lorsque le code d'origine a été écrit dans un langage utilisant des variables typées) pourrait également sortir et générer cette erreur.

  8. Les guillemets échappés

    Si tu utilises \ dans une chaîne, elle a une signification particulière. C'est ce qu'on appelle un "Caractère d'échappement"et dit normalement à l'analyseur de prendre le prochain caractère littéralement.

    Exemple: echo 'Jim said \'Hello\''; imprimera Jim said 'hello'

    Si vous échappez à la citation de fermeture d'une chaîne, la citation de fermeture sera prise littéralement et non comme prévu, c'est-à-dire comme une citation imprimable faisant partie de la chaîne et ne fermera pas la chaîne. Cela s'affichera comme une erreur d'analyse généralement après l'ouverture de la chaîne suivante ou à la fin du script.

    Erreur très courante lors de la spécification de chemins dans Windows: "C:\xampp\htdocs\" est faux. Vous avez besoin "C:\\xampp\\htdocs\\".


20



Inattendu (

Les parenthèses ouvrantes suivent généralement des constructions de langage telles que if/foreach/for/array/list ou commencez une expression arithmétique. Ils sont syntaxiquement incorrects après "strings", Un précédent (), seul $, et dans certains contextes de déclaration typiques.

  1.  Paramètres de déclaration de fonction

    Un événement plus rare pour cette erreur est essayer d'utiliser des expressions comme paramètres de fonction par défaut. Ce n'est pas supporté, même en PHP7:

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

    Les paramètres d'une déclaration de fonction ne peuvent être que des valeurs littérales ou des expressions constantes. Contrairement aux invocations de fonctions, où vous pouvez utiliser librement whatever(1+something()*2) etc.

  2.  Valeurs par défaut de la propriété de classe

    Même chose pour déclarations des membres du groupe, où seules les valeurs littérales / constantes sont autorisées, pas les expressions:

    class xyz {                   ⇓
        var $default = get_config("xyz_default");
    

    Mettez de telles choses dans le constructeur. Voir également Pourquoi les attributs PHP n'autorisent-ils pas les fonctions?

    Notez à nouveau que PHP 7 ne permet que var $xy = 1 + 2 +3; expressions constantes là-bas.

  3.  Syntaxe JavaScript en PHP

    En utilisant JavaScript ou Syntaxe de jQuery ne fonctionnera pas en PHP pour des raisons évidentes:

    <?php      ⇓
        print $(document).text();
    

    Lorsque cela se produit, cela indique généralement une chaîne précédente non terminée; et littéral <script> sections qui fuient dans le contexte du code PHP.

  4.  isset (()), vide, clé, suivant, actuel

    Tous les deux isset() et empty() sont des langues intégrées, pas des fonctions. Ils besoin d'accéder directement à une variable. Si vous ajoutez trop par inadvertance une paire de parenthèses, vous créez une expression cependant:

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

    La même chose s'applique à toute construction de langage nécessitant un accès de nom de variable implicite. Ces built-ins font partie de la grammaire du langage, donc ne permettent pas de parenthèses supplémentaires décoratives.

    Les fonctions de niveau utilisateur qui requièrent une référence de variable, mais qui obtiennent un résultat d'expression réussi, entraînent plutôt des erreurs d'exécution.


Inattendu )

  1.  Paramètre de fonction absent

    Vous ne pouvez pas avoir errer les virgules durent dans un appel de fonction. PHP attend une valeur là-bas et se plaint donc d'une fermeture anticipée ) parenthèse.

                  ⇓
    callfunc(1, 2, );
    

    Une virgule de fin n'est autorisée que dans array() ou list() construit.

  2.  Expressions inachevées

    Si vous oubliez quelque chose dans une expression arithmétique, alors l'analyseur abandonne. Parce que comment devrait-il interpréter cela:

                   ⇓
    $var = 2 * (1 + );
    

    Et si vous avez oublié la fermeture ) même, alors vous obtiendriez une plainte au sujet du point-virgule inattendu à la place.

  3.  Foreach comme constant 

    Pour variable oubliée $ préfixes dans les instructions de contrôle tu verras:

                       ↓    ⇓
    foreach ($array as wrong) {
    

    PHP ici vous dit parfois qu'il s'attendait à un :: au lieu. Parce qu'une variable class :: $ aurait pu satisfaire l'expression de variable $ attendue.


Inattendu {

Accolades { et } joindre des blocs de code. Et les erreurs de syntaxe à leur sujet indiquent généralement une imbrication incorrec.

  1.  Sous-expressions inégalées dans un if 

    Le plus souvent déséquilibré ( et ) sont la cause si l'analyseur se plaint de l'ouverture bouclés { apparaissant trop tôt. Un exemple simple:

                                  ⇓
    if (($x == $y) && (2 == true) {
    

    Comptez vos parens ou utilisez un IDE qui aide avec cela. N'écrivez pas non plus de code sans espaces. La lisibilité compte.

  2.  {et} dans le contexte de l'expression

    Vous ne pouvez pas utiliser d'accolades dans les expressions. Si vous confondez les parenthèses et les curly, cela ne sera pas conforme au grammaire de la langue:

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

    Il existe quelques exceptions pour la construction de l'identifiant, comme la variable de portée locale ${references}.

  3.  Variables variables ou expressions de courbure var

    C'est assez rare. Mais vous pourriez aussi avoir { et } plaintes de l'analyseur pour les expressions de variables complexes:

                          ⇓
    print "Hello {$world[2{]} !";
    

    Bien qu'il y ait une probabilité plus élevée pour un imprévu } dans de tels contextes.


Inattendu }

Lorsque vous obtenez un "inattendu }"erreur, vous avez surtout fermé un bloc de code trop tôt.

  1.  Dernière déclaration dans un bloc de code

    Cela peut arriver pour n'importe quelle expression non terminée.

    Et si la dernière ligne dans un bloc fonction / code manque de fin ; point-virgule:

    function whatever() {
        doStuff()
    }            ⇧
    

    Ici, l'analyseur ne peut pas dire si vous vouliez peut-être toujours ajouter + 25; à la fonction résultat ou autre chose.

  2.  Invalid block nesting / Oublié { 

    Vous verrez parfois cette erreur d'analyseur lorsqu'un bloc de code était } fermé trop tôt ou vous avez oublié une ouverture { même:

    function doStuff() {
        if (true)    ⇦
            print "yes";
        }
    }   ⇧
    

    Dans l'extrait ci-dessus le if n'a pas eu une ouverture { accolade. Ainsi, la fermeture } l'un en dessous est devenu redondant. Et donc la prochaine fermeture }, qui était destiné à la fonction, n'était pas associé à l'ouverture d'origine { accolade.

    De telles erreurs sont encore plus difficiles à trouver sans indentation de code appropriée. Utilisez un IDE et une parenthèse de parenthèse.


Inattendu {, attendant (

Constructions de langage nécessitant un en-tête de condition / déclaration et un bloc de code déclenche cette erreur.

  1.  Liste de paramètres

    Par exemple Fonctions mal déclarées sans liste de paramètres ne sont pas autorisés:

                     ⇓
    function whatever {
    }
    
  2.  Conditions du relevé de contrôle

    Et vous ne pouvez pas avoir un if sans condition.

      ⇓
    if {
    }
    

    Ce qui n'a pas de sens, évidemment. La même chose pour les suspects habituels, for/foreach, while/do, etc.

    Si vous avez cette erreur particulière, vous devriez certainement rechercher des exemples manuels.


15



Fin inattendue

Quand PHP parle d'un "inattendu" $end", cela signifie que votre code s'est terminé prématurément. (Le message est un peu trompeur lorsqu'il est pris à la lettre. Il ne s'agit pas d'une variable nommée" $ end ", comme le supposent parfois les nouveaux venus. Il fait référence à la" fin du fichier " EOF.)

Cause: Déséquilibré { et } pour les blocs de code et les déclarations de fonction ou de classe.

Ses à peu près toujours à propos d'un manquant } accolade pour fermer les blocs de code précédents.

  • Encore une fois, utilisez l'indentation appropriée pour éviter de tels problèmes.

  • Utilisez un IDE avec correspondance des parenthèses, pour savoir où le } est mal.  Il existe des raccourcis clavier dans la plupart des IDE et des éditeurs de texte:

    • NetBeans, PhpStorm, Komodo: Ctrl[ et Ctrl]
    • Eclipse, Aptana: CtrlDécalageP
    • Atome, Sublime: Ctrlm - Studio Zend CtrlM
    • Geany, Notepad ++: CtrlB Joe: Ctrlg - Emacs: C-M-n - Vim: % 

La plupart des IDEs aussi surligner accolades, parenthèses et parenthèses correspondantes. Ce qui le rend assez facile à inspecter leur corrélation:

Bracket matching in an IDE

Expressions non terminées

Et Unexpected $end syntaxe / erreur d'analyse peut également se produire pour les expressions ou les instructions non terminées:

  • $var = func(1, ?>EOF

Alors, regardez d'abord la fin des scripts. Une fuite ; est souvent redondant pour la dernière instruction de tout script PHP. Mais toi devrait avoir un. Précisément parce qu'il réduit les problèmes de syntaxe.

Marqueurs HEREDOC en retrait

Une autre occurrence commune apparaît avec HEREDOC ou NOWDOC cordes. Le marqueur de terminaison est ignoré avec les espaces de début, les tabulations, etc.:

print <<< END
    Content...
    Content....
  END;
# ↑ terminator isn't exactly at the line start

Par conséquent, l'analyseur suppose que la chaîne HEREDOC continue jusqu'à la fin du fichier (d'où "Uneausse $ end"). Presque tous les IDE et les éditeurs mettant en évidence la syntaxe le rendront évident ou préviendront.

Les guillemets échappés

Si tu utilises \ dans une chaîne, elle a une signification particulière. C'est ce qu'on appelle un "Caractère d'échappement"et dit normalement à l'analyseur de prendre le prochain caractère littéralement.

Exemple: echo 'Jim said \'Hello\''; imprimera Jim said 'hello'

Si vous échappez à la citation de fermeture d'une chaîne, la citation de fermeture sera prise littéralement et non comme prévu, c'est-à-dire comme une citation imprimable faisant partie de la chaîne et ne fermera pas la chaîne. Cela s'affichera comme une erreur d'analyse généralement après l'ouverture de la chaîne suivante ou à la fin du script.

Erreur très courante lors de la spécification de chemins dans Windows: "C:\xampp\htdocs\" est faux. Vous avez besoin "C:\\xampp\\htdocs\\".

Syntaxe alternative

Un peu plus rare, vous pouvez voir cette erreur de syntaxe lorsque vous utilisez la syntaxe alternative pour les blocs d'instruction / code dans les modèles. En utilisant if: et else: et un disparu endif; par exemple.

Voir également:


14



T_IF inattendu
T_ELSEIF inattendu
T_ELSE inattendu
T_ENDIF inattendu

Blocs de contrôle conditionnel if, elseif et else suivre une structure simple. Lorsque vous rencontrez une erreur de syntaxe, il est très probable que l'imbrication de bloc non valide { accolades } - ou un de trop.

enter image description here

  1.  Disparu { ou } en raison d'une indentation incorrecte

    Les accolades de code incompatibles sont communes aux codes moins bien formatés tels que:

    if((!($opt["uniQartz5.8"]!=$this->check58)) or (empty($_POST['poree']))) {if
    ($true) {echo"halp";} elseif((!$z)or%b){excSmthng(False,5.8)}elseif (False){
    

    Si votre code ressemble à ceci, recommencez! Autrement, il est impossible à vous ou à quelqu'un d'autre de le faire. Il ne sert à rien de montrer cela sur internet pour demander de l'aide.

    Vous ne pourrez y remédier que si vous pouvez suivre visuellement la structure imbriquée et la relation entre les conditionnels if / else et leur { blocs de code }. Utilisez votre IDE pour voir s'ils sont tous appariés.

    if (true) {
         if (false) {
                  …
         }
         elseif ($whatever) {
             if ($something2) {
                 …
             } 
             else {
                 …
             }
         }
         else {
             …
         }
         if (false) {    //   a second `if` tree
             …
         }
         else {
             …
         }
    }
    elseif (false) {
        …
    }
    

    Tout double }  } ne fermera pas seulement une branche, mais une structure de condition précédente. Donc, rester avec un style de codage; ne pas mélanger et faire correspondre dans les arbres if / else imbriqués.

    En dehors de la cohérence ici, il s'avère utile d'éviter les longues conditions aussi. Utiliser des variables temporaires ou des fonctions pour éviter les illisibles if-expressions.

  2.   IF ne peut pas être utilisé dans les expressions

    Une erreur étonnamment fréquente de nouvel arrivant essaie d'utiliser un if déclaration dans une expression, telle qu'une instruction d'impression:

                       ⇓
    echo "<a href='" . if ($link == "example.org") { echo …
    

    Ce qui est invalide bien sûr.

    Vous pouvez utiliser un conditionnel ternaire, mais méfiez-vous des impacts de lisibilité.

    echo "<a href='" . ($link ? "http://yes" : "http://no") . "</a>";
    

    Sinon, décomposez cette sortie: utilisez plusieurs ifle sable echos.
    Mieux encore, utilisez variables temporaireset placez vos conditionnels avant:

    if ($link) { $href = "yes"; } else { $href = "no"; }
    echo "<a href='$href'>Link</a>";
    

    Définir des fonctions ou des méthodes pour de tels cas est souvent logique.

     Les blocs de contrôle ne renvoient pas de "résultats"

    Maintenant c'est moins commun, mais quelques codeurs essayent même de traiter if comme s'il pouvait retourner un résultat:

    $var = if ($x == $y) { "true" };
    

    Qui est structurellement identique à l'utilisation if dans une concaténation / expression de chaîne.

    • Mais Structures de contrôle (si / foreach / while) n'ont pas de "résultat".
    • La chaîne littérale "true" serait aussi une déclaration vide.

    Vous devrez utiliser une affectation dans le bloc de code:

    if ($x == $y) { $var = "true"; }
    

    Alternativement, recourir à un ?: comparaison ternaire.

     Si dans Si

    Toi ne peut pas imbriquer un if dans une condition soit:

                        ⇓
    if ($x == true and (if $y != false)) { ... }
    

    Ce qui est évidemment redondant, car le and (ou or) permet déjà des comparaisons en chaîne.

  3.  Forgotton ; points-virgules

    Encore une fois: chaque bloc de contrôle doit être une déclaration. Si le point de code précédent n'est pas terminé par un point-virgule, il s'agit d'une erreur de syntaxe garantie:

                    ⇓
    $var = 1 + 2 + 3
    if (true) { … }
    

    Btw, la dernière ligne d'un {…} le bloc de code a également besoin d'un point-virgule.

  4.  Point-virgule trop tôt

    Maintenant, il est probablement faux de blâmer un style de codage particulier, car cet écueil est trop facile à négliger:

                ⇓
    if ($x == 5);
    {
        $y = 7;
    }
    else           ←
    {
        $x = -1;    
    }
    

    Ce qui arrive plus souvent que vous ne l'imaginez.

    • Lorsque vous terminer le if () expression avec ; il va exécuter une déclaration vide. le ; devient un vide {} de sa propre!
    • le {…} bloc est ainsi détaché de la ifet courrait toujours.
    • Alors le else n'avait plus de relation avec un ouvert if construction, c'est pourquoi cela conduirait à une erreur de syntaxe T_ELSE inattendue.

    Ce qui explique aussi une variante également subtile de cette erreur de syntaxe:

    if ($x) { x_is_true(); }; else { something_else(); };
    

    Où le ; après le bloc de code {…} termine le tout if construire, couper le else branche syntaxiquement.

  5.  Ne pas utiliser de blocs de code

    Il est syntaxiquement autorisé à omettre les accolades {...} pour les blocs de code dans if/elseif/else branches. Ce qui est malheureusement un style de syntaxe très commun aux codeurs non (Sous la fausse hypothèse, cela a été plus rapide à taper ou à lire).

    Cependant, il est fort probable que la syntaxe soit dépassée. Tôt ou tard, les instructions supplémentaires trouveront leur chemin dans les branches if / else:

    if (true)
        $x = 5;
    elseif (false)
        $x = 6;
        $y = 7;     ←
    else
        $z = 0;
    

    Mais pour utiliser réellement des blocs de code, vous Avoir écrire {...} eux en tant que tels!

    Même les programmeurs chevronnés évitent cette syntaxe sans frein, ou du moins   comprendre comme une exception exceptionnelle à la règle.

  6. Elseif / Elseif dans le mauvais ordre

    Une chose à se rappeler est la ordre conditionnel, bien sûr.

    if ($a) { … }
    else { … }
    elseif ($b) { … }
    ↑
    

    Vous pouvez avoir autant elseifs comme vous voulez, mais else doit aller en dernier. C'est juste comme ça.

  7.  Déclarations de classe

    Comme mentionné ci-dessus, vous ne pouvez pas avoir d'instructions de contrôle dans une déclaration de classe:

    class xyz {
        if (true) {
            function ($var) {}
        }
    

    Toi non plus oublié une fonction définition, ou fermé } trop tôt dans de tels cas.

  8.  T_ELSEIF / T_ELSE inattendu

Lors du mélange PHP et HTML, la fermeture } pour un if/elseif doit être dans le même bloc PHP <?php ?> comme le prochain elseif/else. Cela générera une erreur comme la fermeture } pour le if doit faire partie de la elseif:

<?php if ($x) { ?>
    html
<?php } ?>
<?php elseif ($y) { ?>
    html
<?php } ?>

La forme correcte <?php } elseif:

<?php if ($x) { ?>
    html
<?php } elseif ($y) { ?>
    html
<?php } ?>

C'est plus ou moins une variation d'indentation incorrecte - vraisemblablement souvent basée sur de mauvaises intentions de codage.
    Vous ne pouvez pas masquer les autres instructions entre  if et elseif/else jetons structurels:

    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.
  <br><br>

Nor can you **part an if/else** between different control structures:

    foreach ($array as $i) {
        if ($i) { … }
    }
    else { … }

There is no [syntactic relation](https://stackoverflow.com/questions/567002/unexpected-t-elseif) between the `if` and `else`. The `foreach` lexical scope ends at `}`, so there's no point for the `if` structure to continue.
  1.  T_ENDIF

    Si vous vous plaignez d'un T_ENDIF inattendu, vous utilisez le style de syntaxe alternatif if: ⋯ elseif: ⋯ else: ⋯ endif;. Ce que vous devriez vraiment réfléchir à deux fois.

    • Un piège commun est confondant le étrangement similaire : deux points pour un ; point-virgule. (Couvert dans "Semicolon trop tôt")

    • Comme l'indentation est plus difficile à suivre dans les fichiers de modèles, plus vous utilisez la syntaxe alternative - il est plausible endif; ne correspond à aucun if:.

    • En utilisant } endif;  est un doublé  if-terminateur.  

    Alors qu'une «fin inattendue de $» est habituellement le prix pour une fermeture oubliée } accolade.

  2.  Affectation vs. comparaison

    Donc, ce n'est pas une erreur de syntaxe, mais il vaut la peine de mentionner dans ce contexte:

           ⇓
    if ($x = true) { }
    else { do_false(); }
    

    Ce n'est pas un ==/=== comparaison, mais un = affectation. Ceci est plutôt subtil, et conduira facilement certains utilisateurs à éditer en toute impunité des blocs de condition entiers. Faites attention aux affectations involontaires en premier - lorsque vous rencontrez une erreur de logique / mauvais fonctionnement.


13