web-dev-qa-db-fra.com

PHP erreurs d'analyse/de syntaxe; et comment les résoudre?

Tout le monde se heurte à 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 d'analyse PHP: erreur de syntaxe, '{' inattendu dans index.php à la ligne 20

Le symbole inattendu n'est pas toujours le véritable coupable. Mais le numéro de ligne donne une idée approximative du début de la recherche.

Regardez toujours le contexte code . L'erreur de syntaxe se cache souvent dans les ou mentionnés dans lignes de code précédentes . Comparez votre code avec des exemples de syntaxe du manuel.

Bien que tous les cas ne correspondent pas à l'autre. Il existe cependant quelques étapes générales pour résoudre les erreurs de syntaxe . Ces références résument les pièges courants:

Références étroitement liées:

Et:

Bien que Stack Overflow accueille également les codeurs débutants, il s’adresse principalement aux questions de programmation professionnelle.

  • Répondre aux erreurs de codage et aux erreurs de frappe de chacun est considéré comme hors sujet.
  • Veuillez donc prendre le temps de suivre les étapes basic avant de poster les demandes de correction de syntaxe.
  • Si vous devez toujours le faire, veuillez montrer votre propre initiative de résolution, vos tentatives de résolution et votre processus de réflexion sur ce qui semble ou pourrait être incorrect.

Si votre navigateur affiche des messages d'erreur tels que "SyntaxError: un caractère illégal", ce n'est pas réellement lié à php , mais une erreur de syntaxe javascript -.


Erreurs de syntaxe générées sur le code du fournisseur: Enfin, considérez que si l'erreur de syntaxe n'a pas été générée en modifiant votre base de code, mais après l'installation ou la mise à niveau d'un package fournisseur externe, cela pourrait être dû à PHP incompatibilité de version, alors vérifiez les exigences du fournisseur par rapport à la configuration de votre plate-forme.

580
mario

Quelles sont les erreurs de syntaxe?

PHP appartient aux langages de programmation style C et impératif . Il a des règles de grammaire rigides, qu’il ne peut pas récupérer lorsqu’il rencontre des symboles ou des identificateurs égaré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:

  • Utilisez un bon indentation de code ou adoptez un style de codage élevé. La lisibilité prévient les irrégularités.

  • Utilisez un IDE ou un éditeur pour PHP avec mise en évidence de la syntaxe . Ce qui aide aussi avec les parenthèses/l'équilibrage des crochets.

    Expected: semicolon

  • Lisez 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 se lit comme suit:

Erreur d'analyse: erreur de syntaxe, inattendu T_STRING , en attente ';' dans fichier.php sur ligne 217 ​​

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

Un moniker tel que T_STRING explique quel symbole l’analyseur/tokenizer n’a pas pu traiter. Ce n'est cependant pas nécessairement la cause de l'erreur de syntaxe.

Il est également important de regarder les lignes de code précédentes . Souvent, les erreurs de syntaxe ne sont que des accidents survenus plus tôt. Le numéro de ligne d'erreur correspond au moment où l'analyseur a renoncé de manière décisive à tout traiter.

Résoudre les erreurs de syntaxe

Il existe de nombreuses approches pour réduire et corriger les problèmes de syntaxe.

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

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

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

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

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

    • Si les blocs de code {} sont mal fermés ou imbriqués, vous devrez peut-être examiner encore plus le code source. Utilisez l'indentation de code appropriée pour simplifier cela.

  • Regardez la colorisation de la syntaxe !

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

    • Les opérateurs +-*/. doivent également être teintés distinctement. Sinon, ils pourraient être dans le mauvais contexte.

    • Si vous voyez que la colorisation des chaînes s'étend trop loin ou trop court, alors vous avez trouvé un marqueur de chaîne " ou ' de fermeture manquant ou non échappé.

    • Avoir deux caractères de ponctuation de même couleur l'un à côté de l'autre peut également être source de problèmes. Généralement, les opérateurs sont seuls s'il ne s'agit pas de ++, -- ou de parenthèses après un opérateur. Deux chaînes/identificateurs qui se suivent directement sont incorrects dans la plupart des contextes.

  • L'espace est votre ami . Suivez n’importe quel style de codage .

  • Casser les longues lignes temporairement.

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

    • Divisez les instructions ifcomplexes en conditions ifdistinctes ou imbriquées.

    • Au lieu de longues formules mathématiques ou 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 correct,
      2. Les parties sur lesquelles vous n'êtes pas sûr,
      3. Et les lignes dont se plaint l'analyseur.

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

  • Commentez le code incriminé.

    • Si vous ne pouvez pas isoler la source du problème, commencez à commenter (et supprimez donc 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 de plus près là.

    • Parfois, vous souhaitez supprimer temporairement des blocs complets de fonctions/méthodes. (En cas d'accolades inégalées et de code indenté à tort.)

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

  • En tant que nouveau venu, évitez certaines des constructions de syntaxe déroutantes.

    • L'opérateur de condition ? : ternaire peut compacter le code et est en effet utile. Mais cela ne facilite pas la lisibilité dans tous les cas. Préférez les instructions simples ifsans les inverser.

    • La syntaxe alternative de PHP (if:/elseif:/endif;) est commune aux modèles, mais peut-être moins facile à suivre que les blocs { code } normaux.

  • Les erreurs les plus courantes chez les nouveaux arrivants sont les suivantes:

    • Point-virgule manquant ; pour les instructions/lignes de terminaison.

    • Citations de chaînes incompatibles pour " ou ' et citations non échappées à l'intérieur.

    • Opérateurs oubliés, en particulier pour la concaténation de chaîne ..

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

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

    • Si vous faites disparaître un problème, mais que d'autres apparaissent dans le code ci-dessous, vous êtes généralement sur la bonne voie.

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

  • Restaurez une sauvegarde du code qui fonctionnait auparavant, si vous ne pouvez pas le réparer.

    • Adoptez un système de gestion de versions de code source. Vous pouvez toujours afficher un diffde la version brisée et de la dernière version opérationnelle. Ce qui pourrait être éclairant quant à la nature du problème de syntaxe.
  • Caractères Unicode égarés invisibles : Dans certains cas, vous devez tilisez un éditeur de texte ou un autre éditeur/visualiseur sur votre source. Certains problèmes ne peuvent pas être trouvés simplement en regardant votre code.

    • Essayez grep --color -P -n "\[\x80-\xFF\]" file.php en tant que première mesure permettant de rechercher des symboles non-ASCII.

    • En particulier, les nomenclatures, les espaces de largeur nulle ou les espaces insécables, et les guillemets intelligents peuvent régulièrement se retrouver dans le code source.

  • Vérifiez quels types de sauts de ligne sont enregistrés dans des fichiers.

    • PHP vient d'honorer \n nouvelles lignes, pas \r retour du chariot.

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

    • Il apparaît souvent comme un problème uniquement lorsque des commentaires // ou # sur une seule ligne sont utilisés. Les commentaires multilignes /*...*/ perturbent rarement l'analyseur lorsque les sauts de ligne sont ignorés.

  • Si votre erreur de syntaxe ne se transmet pas sur le Web : Il se peut que vous ayez une erreur de syntaxe sur votre ordinateur. Mais poster 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 un Unicode invisible invisible (voir ci-dessus). Vous pouvez facilement le savoir: copiez simplement votre code du formulaire Web dans votre éditeur de texte.

  • Vérifiez votre version de PHP . Toutes les constructions de syntaxe ne sont pas disponibles sur chaque serveur.

    • php -v pour l'interpréteur de ligne de commande

    • <?php phpinfo(); pour celui appelé via le serveur Web.


    Ce ne sont pas nécessairement les mêmes. En particulier lorsque vous travaillez avec des cadres, vous allez les faire correspondre.

  • N'utilisez pas mots-clés réservés de PHP comme identificateurs de fonctions/méthodes, de classes ou de constantes.

  • L'essai et l'erreur est votre dernier recours.

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

Autres guides:

Écran blanc de la mort

Si votre site Web est simplement vide, c'est généralement une erreur de syntaxe qui en est la cause. Activer leur affichage avec:

  • error_reporting = E_ALL
  • display_errors = 1

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

Il est trop tard pour l'activer dans le script interrompu, car PHP ne peut même pas interpréter/exécuter la première ligne. Une solution rapide consiste à créer un script wrapper, par exemple test.php:

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

Ensuite, appelez le code défaillant en accédant à ce script wrapper.

Cela permet également d'activer le error_log de PHP et de regarder dans votre error.log du serveur Web lorsqu'un script plante avec des réponses HTTP 500.

268
mario

Je pense que ce sujet est totalement sur-discuté/compliqué. Utiliser un IDE est LA méthode à utiliser pour éviter complètement les erreurs de syntaxe. Je dirais même que travailler sans IDE n’est pas très professionnel. Pourquoi? Parce que les IDE modernes vérifient votre syntaxe après chaque caractère que vous tapez. Lorsque vous codez et que votre ligne entière devient rouge, et qu'un grand message d'avertissement vous indique le type exact et la position exacte de l'erreur de syntaxe, vous n'avez pas besoin de chercher une autre solution.

Utiliser une vérification de syntaxe IDE signifie:

Vous ne rencontrerez (effectivement) plus jamais d'erreurs de syntaxe, simplement parce que vous les voyez correctement lors de la frappe. Sérieusement.

Excellents IDE avec vérification de la syntaxe (tous sont disponibles pour Linux, Windows et Mac):

  1. NetBeans [gratuit]
  2. PHPStorm [$ 199 USD]
  3. Eclipse with PHP plugin [gratuit]
  4. Sublime [$ 80 USD] (principalement un éditeur de texte, mais extensible avec des plugins, comme PHP Syntax Parser )
99
Sliq

T_VARIABLE inattendu

Un "inattendu T_VARIABLE" signifie qu'il existe un nom littéral $variable, qui ne rentre pas dans la structure d'expression/d'instruction actuelle.

purposefully abstract/inexact operator+$variable diagram

  1. Point-virgule manquant

    Il indique le plus souvent n point-virgule manquant dans la ligne précédente. Les affectations de variables suivant un énoncé sont un bon indicateur pour regarder:

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

    Un incident fréquent est concaténations de chaînes avec l'opérateur . oublié:

                                   ⇓
    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 facilite la lisibilité. Ce qui évite ces problèmes de syntaxe.

    L'interpolation de chaîne est une caractéristique essentielle du langage de script. Pas de honte à l'utiliser. Ignorez tout conseil de micro-optimisation relatif à la concaténation de la variable . étant plus rapide. Ce n'est pas le cas

  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 suppose ici si la variable aurait dû être ajoutée, soustraite ou comparée, etc.

  4. Des listes

    Idem 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 des listes de paramètres de fonctions:

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

    De manière équivalente, voyez-vous ceci avec les instructions listou globalou en l'absence d'un point-virgule ; dans une boucle forname__.

  5. Déclarations de classe

    Cette erreur d'analyse se produit également dans les déclarations de classe . Vous ne pouvez affecter que 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"];
    

    Unmatched } des accolades fermantes peuvent notamment mener ici. Si une méthode est terminée trop tôt (utilisez l'indentation appropriée!), Une variable parasite est généralement mal placée dans le corps de la déclaration de classe.

  6. Variables après les identificateurs

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

                 ⇓
    $this->myFunc$VAR();
    

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

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

  7. Parens manquants après la construction du langage

    Une frappe rapide peut conduire à oublier les parenthèses ouvrantes pour les instructions ifet foret foreachname__:

           ⇓
    foreach $array as $key) {
    

    Solution: ajoutez l'ouverture manquante ( entre l'instruction et la variable.

  8. Sinon, pas de conditions

         ⇓
    else ($var >= 0)
    

    Solution: supprimez les conditions de elseou utilisez elseifNAME _ .

  9. Besoin de crochets pour la fermeture

         ⇓
    function() uses $var {}
    

    Solution: Ajouter des crochets autour de $var.

  10. Espaces blancs invisibles

    Comme mentionné dans le référence de la réponse sur "Unicode invisible invisible" (tel qu'un espace insécable ), vous pouvez également voir cette erreur pour un code peu méfiant comme:

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

    C'est assez courant au début des fichiers et pour le code copié-collé. Vérifiez auprès d'un éditeur, si votre code ne semble pas contenir de problème de syntaxe.

Voir également

46
mario

T_CONSTANT_ENCAPSED_STRING inattendu
T_ENCAPSED_AND_WHITESPACE inattendu

Les noms compliqués T_CONSTANT_ENCAPSED_STRING et T_ENCAPSED_AND_WHITESPACE désignent des littéraux "string".

Ils sont utilisés dans différents contextes, mais les problèmes de syntaxe sont assez similaires. T_ENCAPSED… les avertissements se produisent dans un contexte de chaîne entre guillemets doubles, alors que T_CONSTANT… sont souvent égarés en clair PHP expressions ou déclarations.

  1. Interpolation de variable incorrecte

    Et cela revient le plus souvent pour une interpolation de variable PHP incorrecte:

                              ⇓     ⇓
    echo "Here comes a $wrong['array'] access";
    

    Il est indispensable de citer les clés de tableaux dans le contexte PHP. Mais dans les chaînes entre guillemets (ou HEREDOC), c'est une erreur. L'analyseur se plaint de la seule citation contenue 'string', car il y attend généralement un identificateur/clé littéral.

    Plus précisément, il est valide d'utiliser PHP2-style syntaxe simple entre guillemets pour les références de tableau:

    echo "This is only $valid[here] ...";
    

    Les tableaux imbriqués ou les références d'objet plus profondes requièrent toutefois la syntaxe expression de chaîne bouclée complexe :

    echo "Use {$array['as_usual']} with curly syntax.";
    

    En cas de doute, il est généralement plus sûr de l’utiliser. C'est souvent même considéré comme plus lisible. Et de meilleurs IDE utilisent en réalité une colorisation de syntaxe distincte pour cela.

  2. Concaténation manquante

    Si une chaîne suit une expression, mais manque d'une concaténation ou d'un autre opérateur, vous verrez alors PHP se plaindre du littéral de chaîne:

                           ⇓
    print "Hello " . WORLD  " !";
    

    Bien que cela soit évident pour vous et moi, PHP ne peut tout simplement pas deviner que la chaîne devait y être ajoutée.

  3. Des boîtiers de citation de chaîne déroutants

    La même erreur de syntaxe se produit lorsque délimiteurs de chaînes confondants . Une chaîne commençant par un seul ' ou un double " se termine également par le même.

                    ⇓
    print "<a href="' . $link . '">click here</a>";
          ⌞⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟
    

    Cet exemple a commencé par des guillemets doubles. Mais les guillemets étaient également destinés aux attributs HTML. L’opérateur de concaténation prévu à l’intérieur de celui-ci a toutefois été interprété comme faisant partie d’une deuxième chaîne entre guillemets simples.

    Astuce : paramétrez votre éditeur/IDE pour qu'il utilise une colorisation légèrement distincte pour les chaînes entre guillemets simples et doubles. (Dans la logique de l’application, il est également utile de préférer, par exemple, les chaînes entre guillemets doubles pour la sortie textuelle et les chaînes simples entre guillemets uniquement pour les valeurs de type constant.)

    Ceci est un bon exemple où vous ne devriez pas sortir de guillemets en premier lieu. Au lieu de cela, utilisez simplement \" s'échappe pour les citations d'attributs HTML:

    print "<a href=\"{$link}\">click here</a>";
    

    Bien que cela puisse également entraîner une confusion de la syntaxe, tous les meilleurs IDE/éditeurs aident à nouveau en colorisant différemment les guillemets.

  4. Citation d'ouverture manquante

    De manière équivalente sont ouverture oubliée "/' citations une recette pour des erreurs d’analyseur:

                   ⇓
     make_url(login', 'open');
    

    Ici, le ', ' deviendrait un littéral de chaîne après un mot nu, alors que login était manifestement un paramètre de chaîne.

  5. Listes de tableaux

    Si vous manquez une virgule , dans un bloc de création de tableau, l'analyseur verra deux chaînes consécutives:

    array(               ⇓
         "key" => "value"
         "next" => "....",
    );
    

    Notez que la dernière ligne peut toujours contenir une virgule supplémentaire, mais en ignorer une est intermédiaire. Ce qui est difficile à découvrir sans la coloration syntaxique.

  6. Listes de paramètres de fonction

    Même chose pour les appels de fonction :

                             ⇓
    myfunc(123, "text", "and"  "more")
    
  7. Fugue

    Une variation commune sont tout simplement des terminateurs de chaîne oubliés:

                                    ⇓
    mysql_evil("SELECT * FROM stuffs);
    print "'ok'";
          ⇑
    

    Ici PHP se plaint de deux littéraux de chaîne qui se suivent directement. Mais la vraie cause est bien sûr la chaîne précédente non fermée.

Voir aussi

32
mario

T_STRING inattendu

T_STRING est un peu impropre. Il ne fait pas référence à un "string" cité. Cela signifie qu'un identifiant brut a été rencontré. Cela peut aller de bare mots à restants CONSTANT ou noms de fonctions, chaînes sans guillemets ou tout texte brut.

  1. Chaînes mal citées

    Cette erreur de syntaxe est toutefois la plus courante pour les valeurs de chaîne mal citées. Toute citation " ou ' non échappée et errante 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 barres obliques inverses pour séparer les guillemets doubles \" ou les guillemets simples \', en fonction du type utilisé: string Enclosure .

    • 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 si vous souhaitez interpoler des variables, mais veillez à éviter les guillemets doubles littéraux ".
    • Pour une sortie plus longue, préférez plusieurs lignes echo/print au lieu de s'échapper avant et arrière. Mieux encore, considérons une section HEREDOC .

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

  2. Cordes non fermées

    Si vous [manquez pas un " de fermeture __ , une erreur de syntaxe se matérialisera généralement plus tard. Une chaîne non terminée consommera souvent un bit 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 simplement T_STRING littéral que l'analyseur peut alors contester. Une autre variante fréquente est un Unexpected '>' pour un code HTML littéral non cité.

  3. Citations de chaînes non programmées

    Si vous copiez et collez le code d'un blog ou d'un site Web, vous vous retrouvez parfois avec un code invalide. 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 d'un texte alphanumérique adjacent. Par exemple, ”these est interprété comme un identifiant constant. Mais tout littéral de texte suivant est alors considéré comme un mot nu/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 vue comme un identifiant brut:

           ⇓
    func1()
    function2();
    

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

  5. Balises ouvertes courtes et en-têtes <?xml 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érera pour lui-même. Il ne comprendra pas à quoi sert le xml errant. Ça va être interprété comme constant. Mais le version sera vu comme un autre littéral/constant. Et puisque l'analyseur ne peut pas comprendre deux valeurs littérales/valeurs ultérieures sans opérateur d'expression entre les deux, ce sera un échec de l'analyseur.

  6. Caractères Unicode invisibles

    Les symboles Unicode, tels que le espace insécable , sont une cause extrêmement hideuse d'erreurs de syntaxe. PHP autorise les caractères Unicode en tant que noms d'identifiant. Si vous recevez une plainte de l'analyseur T_STRING pour un code totalement suspect, tel que:

    <?php
        print 123;
    

    Vous devez sortir un autre éditeur de texte. Ou un hexeditor même. Ce qui ressemble à des espaces simples et à des lignes nouvelles peut contenir des constantes invisibles. Les IDE basés sur Java sont parfois inconscients d'une nomenclature UTF-8 modifiée, d'espaces de largeur nulle, de séparateurs de paragraphe, etc. Essayez de tout rééditer, de supprimer les espaces et d'y ajouter des espaces normaux.

    Vous pouvez le réduire en ajoutant des séparateurs d'instructions ; redondants à chaque début de ligne:

    <?php
        ;print 123;
    

    Le point-virgule ; supplémentaire convertira ici le caractère invisible précédent en une référence constante non définie (expression as statement). En retour, PHP génère un avis utile.

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

    Les variables en PHP sont représentées par un signe dollar suivi du nom de la variable.

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

    Il s'agit d'une erreur courante lorsque le code PHP était "traduit" à partir d'un code écrit dans un autre langage (C, Java, JavaScript, etc.). Dans de tels cas, une déclaration du type de variable (lorsque le code original était écrit dans un langage qui utilise des variables typées) pouvait également se faufiler et générer cette erreur.

  8. Guillemets échappés

    Si vous utilisez \ dans une chaîne, celle-ci a une signification particulière. Ceci s'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, celle-ci sera prise littéralement et non comme prévu, c’est-à-dire sous la forme d’une citation imprimable faisant partie de la chaîne et non de la chaîne. Cela se traduira généralement par une erreur d'analyse après l'ouverture de la chaîne suivante ou à la fin du script.

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

24
mario

Inattendu (

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

  1. Paramètres de déclaration de fonction

    Une occurrence plus rare pour cette erreur est en essayant d'utiliser des expressions comme paramètres de fonction par défaut . Ceci 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. Propriété par défaut

    Même chose pour les déclarations de membre de classe , 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 aussi Pourquoi les attributs PHP n'autorisent-ils pas les fonctions?

    Notez à nouveau que PHP 7 n'autorise que les expressions constantes var $xy = 1 + 2 +3;.

  3. Syntaxe JavaScript en PHP

    L'utilisation de JavaScript ou de la syntaxe de jQuery ne fonctionnera pas dans 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 se glissant dans le contexte de code PHP.

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

    isset() et empty() sont des langages intégrés et non des fonctions. Ils doivent accéder directement à une variable . Si, par inadvertance, vous ajoutez trop de paires de parenthèses, vous devez toutefois créer une expression:

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

    La même chose s'applique à toute construction de langage nécessitant un accès implicite à un nom de variable. Ces fonctions intégrées font partie de la grammaire linguistique et ne permettent donc pas de parenthèses supplémentaires décoratives.

    Les fonctions de niveau utilisateur qui nécessitent une référence de variable, mais obtiennent un résultat d'expression, entraînent des erreurs d'exécution.


Inattendu )

  1. Paramètre de fonction absente

    Vous ne pouvez pas utiliser de virgule pour la dernière fois dans un appel de fonction . PHP s'attend à une valeur et se plaint donc d'une parenthèse ) à fermeture anticipée.

                  ⇓
    callfunc(1, 2, );
    

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

  2. Expressions inachevées

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

                   ⇓
    $var = 2 * (1 + );
    

    Et si vous oubliez le code de fermeture ), vous obtiendrez une plainte à propos du point-virgule inattendu.

  3. Foreach comme constant

    Pour la variable oubliée $ les préfixes dans les instructions de contrôle , vous verrez:

                       ↓    ⇓
    foreach ($array as wrong) {
    

    PHP vous dit parfois qu'il s'attend à un :: à la place. Parce qu'une variable class :: $ aurait pu satisfaire l'expression attendue de la variable $.


Inattendu {

Les accolades { et } incluent des blocs de code. Et les erreurs de syntaxe les concernant indiquent généralement une imbrication incorrec.

  1. Sous-expressions sans correspondance dans un if

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

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

    Comptez vos parens ou utilisez un IDE qui vous aidera. De même, n'écrivez pas de code sans espaces. La lisibilité compte.

  2. {et} en contexte d'expression

    Vous ne pouvez pas utiliser d'accolades dans les expressions. Si vous confondez parenthèses et curlys, cela ne sera pas conforme à la grammaire linguistique:

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

    Il existe quelques exceptions à la construction d'identifiant, telles que la variable de portée locale ${references}.

  3. Variables variables ou expressions curly var

    C'est assez rare. Mais vous pouvez également obtenir { et } plaintes de l'analyseur pour des expressions de variable complexes:

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

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


Inattendu }

En obtenant une erreur "inattendu }", vous avez généralement fermé un bloc de code trop tôt.

  1. Dernière instruction dans un bloc de code

    Cela peut arriver pour toute expression non terminée.

    Et si la dernière ligne d’un bloc fonction/code n’a pas de fin ; point-virgule:

    function whatever() {
        doStuff()
    }            ⇧
    

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

  2. Imbrication de bloc non valide/oubliée {

    Vous verrez parfois cette erreur d'analyse 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, la if n'avait pas d'ouverture { accolade. Ainsi, le } de fermeture ci-dessous est devenu redondant. Et donc, la prochaine fermeture }, qui était destinée à la fonction, ne pouvait pas être associée à l'ouverture d'origine { accolade.

    Il est encore plus difficile de trouver de telles erreurs sans indentation de code appropriée. Utilisez un IDE et une correspondance entre crochets.


_ Inattendu {, attendant (

Les constructions de langage qui nécessitent un en-tête de condition/déclaration et un bloc de code déclenchent cette erreur.

  1. Listes de paramètres

    Par exemple , les fonctions mal déclarées sans liste de paramètres ne sont pas autorisées:

                     ⇓
    function whatever {
    }
    
  2. Conditions de la déclaration de contrôle

    Et vous ne pouvez pas non plus avoir un if sans condition .

      ⇓
    if {
    }
    

    Ce qui n'a pas de sens, évidemment. 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.

16
mario

Fin inattendue

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

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

Il s'agit presque toujours d'un accolade } manquant 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 une correspondance entre crochets pour savoir où le } est incorrect. Il existe des raccourcis clavier dans la plupart des IDE et des éditeurs de texte:

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

La plupart des IDE mettent également en surbrillance les accolades, les crochets et les parenthèses correspondants. Ce qui rend assez facile l'inspection de leur corrélation:

Bracket matching in an IDE

Expressions non terminées

Et une erreur Unexpected $end syntax/parser peut également se produire pour les expressions ou déclarations non terminées:

  • $var = func(1,?>EOF

Alors, regardez d'abord la fin des scripts. Un ; de fin est souvent redondant pour la dernière instruction d'un script PHP. Mais vous devriez en avoir un. C'est précisément parce que cela réduit les problèmes de syntaxe.

Marqueurs HEREDOC en retrait

Un autre événement courant apparaît avec les chaînes HEREDOC ou NOWDOC . Le marqueur de fin est ignoré avec les espaces, les onglets, 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ù "Inattendu $ end"). Pratiquement tous les IDE et les éditeurs mettant en évidence la syntaxe rendront ceci évident ou en avertiront.

Guillemets échappés

Si vous utilisez \ dans une chaîne, celle-ci a une signification particulière. Ceci s'appelle un " caractère d'échappement " et dit normalement à l'analyseur de prendre littéralement le caractère suivant.

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

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

Erreur très fréquente lors de la spécification de chemins dans Windows: "C:\xampp\htdocs\" est incorrect. Vous avez besoin de "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 instruction/code dans les modèles. Utiliser if: et else: et un endif; manquant, par exemple.

Voir également:

14
mario

T_IF inattendu 
Inattendu T_FOREACH 
T_FOR inattendu 
Inattendu T_WHILE 
T_DO inattendu 
Inattendu T_ECHO

Les constructions de contrôle telles que if, foreach, for, while, list, global, return, do, print, echo peuvent uniquement être utilisées comme des instructions. Ils résident généralement sur une ligne par eux-mêmes.

  1. Point-virgule; t'es où? 

    Assez universellement avez-vous manqué un point-virgule dans la ligne précédente si l'analyseur se plaint d'une instruction de contrôle:

                 ⇓
    $x = myfunc()
    if (true) {
    

    Solution: regardez dans la ligne précédente; ajouter un point-virgule.

  2. Déclarations de classe 

    Un autre emplacement où cela se produit est dans les déclarations de classe . Dans la section de classe, vous pouvez uniquement répertorier les initialisations de propriétés et les sections de méthodes. Aucun code ne peut y résider.

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

    De telles erreurs de syntaxe se matérialisent généralement pour { et } imbriqués de manière incorrecte. En particulier lorsque les blocs de code de fonction ont été fermés trop tôt.

  3. Déclarations dans un contexte d'expression 

    La plupart des constructions de langage peuvent ne peuvent être utilisées que comme des déclarations . Ils ne sont pas destinés à être placés dans d'autres expressions:

                       ⇓
    $var = array(1, 2, foreach($else as $_), 5, 6);
    

    De même, ne pouvez-vous pas utiliser une if dans des chaînes, des expressions mathématiques ou ailleurs:

                   ⇓
    print "Oh, " . if (true) { "you!" } . " won't work";
    // Use a ternary condition here instead, when versed enough.
    

    Pour incorporer spécifiquement des conditions de type if- dans une expression, vous souhaiterez souvent utiliser une évaluation ternaire ?: .

    Il en va de même pour for, while, global, echo et une moindre étendue list.

              ⇓
    echo 123, echo 567, "huh?";
    

    Alors que print() est un langage intégré qui peut être utilisé dans un contexte d'expression. (Mais cela fait rarement sens.)

  4. Mots-clés réservés en tant qu'identificateurs 

    Vous ne pouvez pas non plus utiliser do ou if et d'autres constructions de langage pour les fonctions définies par l'utilisateur ou les noms de classe. (Peut-être en PHP7. Mais même dans ce cas, cela ne serait pas conseillé.)

11
mario

T_IS_EQUAL inattendu 
Inattendu T_IS_GREATER_OR_EQUAL 
Inattendu T_IS_IDENTICAL 
Inattendu T_IS_NOT_EQUAL 
Inattendu T_IS_NOT_IDENTICAL 
Inattendu T_IS_SMALLER_OR_EQUAL 
Inattendu < 
Inattendu >

Les opérateurs de comparaison tels que ==, >=, ===, !=, <>, !== et <= ou < et > doivent être utilisés principalement dans des expressions telles que les expressions if. Si l'analyseur se plaint à leur sujet, cela signifie souvent que la syntaxe est incorrecte ou incorrecte () parens autour d'eux.

  1. Groupement de parens

    En particulier pour les instructions if avec comparaisons multiples, vous devez prendre soin de compter correctement les parenthèses ouvrantes et fermantes :

                            ⇓
    if (($foo < 7) && $bar) > 5 || $baz < 9) { ... }
                          ↑
    

    Ici, la condition if était déjà terminée par le )

    Une fois que vos comparaisons deviennent suffisamment complexes, il est souvent utile de les séparer en plusieurs constructions if et imbriquées.

  2. isset () purée avec comparaison

    Pitfal essaie de combiner isset() ou empty() avec des comparaisons:

                            ⇓
    if (empty($_POST["var"] == 1)) {
    

    Ou même:

                        ⇓
    if (isset($variable !== "value")) {
    

    Cela n’a aucun sens pour PHP, car isset et empty sont des constructions de langage qui acceptent uniquement les noms de variables. Comparer le résultat n'a pas de sens non plus, car la sortie est seulement/déjà un booléen.

  3. Confondre >= supérieur ou égal avec l'opérateur de tableau =>

    Les deux opérateurs se ressemblent un peu et se mélangent parfois:

             ⇓
    if ($var => 5) { ... }
    

    Vous devez seulement vous rappeler que cet opérateur de comparaison s'appelle "supérieur à ou égal" pour bien faire les choses.

    Voir aussi: Structure de l'instruction If dans PHP

  4. Rien à comparer

    Vous ne pouvez pas non plus combiner deux comparaisons si elles portent le même nom de variable:

                     ⇓
    if ($xyz > 5 and < 100)
    

    PHP ne peut pas en déduire que vous vouliez comparer à nouveau la variable initiale. Les expressions sont généralement associées en fonction de priorité de l'opérateur , de sorte qu'au moment où le < est vu, il ne reste qu'un résultat booléen de la variable d'origine.

    Voir aussi: T_IS_SMALLER_OR_EQUAL inattendu

  5. Chaînes de comparaison

    Vous ne pouvez pas comparer une variable avec une rangée d'opérateurs:

                      ⇓
     $reult = (5 < $x < 10);
    

    Cela doit être divisé en deux comparaisons, chacune avec $x.

    C’est en fait plus un cas d’expressions sur liste noire (en raison d’une associativité équivalente des opérateurs). C'est syntaxiquement valide dans quelques langages de style C, mais PHP ne l'interpréterait pas non plus comme une chaîne de comparaison attendue.

  6. > inattendu 
    < inattendu

    Les opérateurs supérieurs à > ou inférieurs à < n'ont pas de nom de tokenizer T_XXX personnalisé. Et même s’ils peuvent être égarés comme tous les autres, vous voyez souvent l’analyseur se plaindre d’eux pour des chaînes mal citées et un pureté HTML:

                            ⇓
    print "<a href='z">Hello</a>";
                     ↑
    

    Cela équivaut à une chaîne "<a href='z" comparée > à une constante littérale Hello puis à une autre comparaison <. Ou c'est du moins comment PHP le voit. La cause réelle et l'erreur de syntaxe étaient la chaîne prématurée " terminaison.

    Il n'est également pas possible d'imbriquer PHP balises de démarrage:

    <?php echo <?php my_func(); ?>
               ↑
    

Voir également:

10
mario

Inattendu '?'

Si vous essayez d'utiliser l'opérateur de fusion null ?? dans une version de PHP antérieure à PHP 7, vous obtiendrez cette erreur.

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

'' 'Inattendu, variable attendue

Une erreur similaire peut se produire pour les types nullable, comme dans:

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

Ce qui indique encore une fois une version PHP obsolète utilisée (la version CLI php -v ou le serveur Web lié à un phpinfo();).

6
John Conde

Inattendu '='

Cela peut être dû à des caractères non valides dans un nom de variable. Les noms de variables doivent suivent ces règles:

Les noms de variables suivent les mêmes règles que les autres étiquettes en PHP. Un nom de variable valide commence par une lettre ou un trait de soulignement, suivi d'un nombre quelconque de lettres, de chiffres ou de traits de soulignement. En tant qu’expression régulière, elle s’exprimerait ainsi: '[a-zA-Z_\x7f-\xff] [a-zA-Z0-9_\x7f-\xff] *'

2
John Conde

'Continuer' inattendu (T_CONTINUE)

continue est une déclaration (comme pour, ou si) et doit apparaître de manière autonome. Il ne peut pas être utilisé dans le cadre d'une expression. En partie parce que continue ne renvoie pas de valeur, mais dans une expression, chaque sous-expression doit donner une valeur afin que l'expression globale donne une valeur. C'est la différence entre une déclaration et une expression.

Cela signifie que continue ne peut pas être utilisé dans une instruction ternaire ou toute instruction nécessitant une valeur de retour.

'Pause' inattendue (T_BREAK)

Même chose pour break; bien sûr. Ce n'est pas non plus utilisable dans un contexte d'expression, mais une instruction stricte (au même niveau que foreach ou un bloc if).

'Retour' inattendu (T_RETURN)

Cela peut paraître plus surprenant pour return, mais il s’agit également d’un statement de niveau bloc. Il renvoie une valeur (ou NULL) à la portée/fonction supérieure, mais il n'est pas évalué en tant qu'expression. → C'est-à-dire: il n'y a aucun intérêt à faire return(return(false);; 

1
John Conde

'Fin en cours' inattendu (T_ENDWHILE)

La syntaxe utilise deux points - s'il n'y a pas de points, l'erreur ci-dessus se produira

<?php while($query->fetch()): ?>
 .... 
<?php endwhile; ?>

Une alternative à cette syntaxe consiste à utiliser des accolades

<?php while($query->fetch()) { ?>
  ....
<?php } ?>

http://php.net/manual/en/control-structures.while.php

0
mplungjan

Un message d'erreur commençant par Parse error: syntax error, unexpected ':' peut être provoqué par l'écriture par erreur d'une référence statique de classe Class::$Variable sous la forme Class:$Variable.

0
David Spector