Erreurs d'analyse et de syntaxe en PHP ; et comment les résoudre ?

Quelles sont les erreurs de syntaxe ?

PHP fait partie des langages de programmation de type [C][1] et [impératif][2]. Il possède des règles de grammaire rigides, dont il ne peut se remettre lorsqu'il rencontre des symboles ou des identifiants mal placés. Il ne peut pas deviner vos intentions de codage. !Définition de la fonction syntaxe abstraite][3]

Conseils les plus importants

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

• Utilisez une indentation de code appropriée, ou adoptez un style de codage noble. La lisibilité permet d'éviter les irrégularités.
• Utilisez un [IDE ou éditeur pour PHP][4] avec surlignage syntaxique. Ce qui aide également à équilibrer les parenthèses/racket. ! [Attendu : point-virgule] [5]
• Lisez [la référence du langage][6] et les exemples dans le manuel. Deux fois, pour devenir un peu compétent.

  Comment interpréter les erreurs d'analyseur syntaxique

  Un message d'erreur syntaxique typique se lit comme suit :

  Parse error : syntax error, unexpected T_STRING, expecting ';' in file.php on line 217 Qui liste l'emplacement possible d'une erreur de syntaxe. Voir le nom du fichier et le numéro de ligne mentionnés. Un [moniker][7] tel que T_STRING explique quel symbole le parser/tokenizer n'a finalement pas pu traiter. Cependant, ce n'est pas nécessairement la cause de l'erreur de syntaxe. Il est important d'examiner également les lignes de code précédentes. Souvent, les erreurs de syntaxe ne sont que des mésaventures qui se sont produites auparavant. Le numéro de la ligne d'erreur est simplement l'endroit où l'analyseur syntaxique a définitivement renoncé à 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 chaînes de caractères qui s'emballent et les opérateurs mal placés, c'est généralement là que vous trouverez le coupable.
  • Lisez la ligne de gauche à droite et imaginez ce que fait chaque symbole.
• Plus régulièrement, vous devez également examiner les lignes précédentes.
  • En particulier, il manque les points-virgules ; aux fins de lignes/états précédents. (Au moins du point de vue stylistique. )
  • Si les {blocs de code } sont incorrectement fermés ou imbriqués, vous pouvez avoir besoin d'investiguer encore plus haut dans le code source. Utilisez une indentation de code appropriée pour simplifier cela.
• Regardez la colorisation de la syntaxe !
  • Les chaînes de caractères, les variables et les constantes devraient toutes avoir des couleurs différentes.
  • Les opérateurs +-*/. devraient aussi avoir des couleurs distinctes. Sinon, ils pourraient être dans le mauvais contexte.
  • Si vous voyez que la colorisation des chaînes de caractères s'étend trop loin ou trop court, c'est que vous avez trouvé un marqueur de chaîne de caractères de fermeture " ou ' manquant.
  • La présence de deux caractères de ponctuation de même couleur l'un à côté de l'autre peut également être synonyme de problèmes. En général, les opérateurs sont seuls si ce n'est pas ++, --, ou des parenthèses qui suivent un opérateur. Deux chaînes de caractères/identifiants qui se suivent directement sont incorrects dans la plupart des contextes.
• Les espaces blancs sont vos amis. Suivez tout style de codage. Ne dérangeons pas les débutants avec PSR-x ici, cependant, K ? -->
• Coupez temporairement les longues lignes.
  • Vous pouvez librement ajouter des lignes de séparation entre les opérateurs ou les constantes et les chaînes de caractères. L'analyseur syntaxique concrétisera alors le numéro de ligne pour les erreurs d'analyse. Au lieu de regarder le code très long, vous pouvez isoler le symbole syntaxique manquant ou mal placé.
  • Divisez les instructions "if" complexes en conditions "if" distinctes ou imbriquées.
  • 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).
  • Ajoutez des sauts de ligne entre :
    1. Le code que vous pouvez facilement identifier comme étant correct,
    2. Les parties dont vous n'êtes pas sûr,
    3. Les lignes dont l'analyseur syntaxique se plaint.
       Partitionner de longs blocs de code aide vraiment à localiser l'origine des erreurs de syntaxe.
• Commentez le code incriminé.
  • Si vous ne parvenez pas à isoler la source du problème, commencez à commenter (et donc à supprimer temporairement) des blocs de code.
  • Dès que vous vous êtes débarrassé de l'erreur d'analyse syntaxique, vous avez trouvé la source du problème. Examinez-la de plus près.
  • Parfois, vous souhaitez supprimer temporairement des blocs complets de fonctions/méthodes. (Dans le cas d'accolades non appariées et de code mal indenté).
  • Si vous ne parvenez 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 constructions syntaxiques déroutantes.
  • L'opérateur de condition ternaire ? : peut compacter le code et est effectivement utile. Mais il n&#8217aide pas à la lisibilité dans tous les cas. Préférez les instructions "if" simples lorsque vous n'avez pas d'informations.
  • La syntaxe alternative de PHP (if:/elseif:/endif;) est courante pour les modèles, mais sans doute moins facile à suivre que les blocs de {code}` normaux.
• Les erreurs les plus courantes commises par les nouveaux arrivants sont les suivantes :
  • Points-virgules manquants ; pour terminer les instructions/lignes.
  • Des guillemets de chaîne mal assortis pour " ou ' et des guillemets non encodés à l'intérieur.
  • Des opérateurs oubliés, en particulier pour la concaténation de chaînes de caractères ..
  • Des (parenthèses ) déséquilibrés. Comptez-les dans la ligne signalée. Y en a-t-il un nombre égal ?
• N&#8217oubliez pas que la résolution d&#8217un problème de syntaxe peut faire apparaître le suivant.
  • Si vous faites disparaître un problème, mais qu'un autre apparaît dans le code suivant, vous êtes en grande partie sur la bonne voie.
  • Si, après l'édition, une nouvelle erreur de syntaxe apparaît dans la même ligne, alors votre tentative de modification était probablement un échec. (Pas toujours cependant).
• Restaurez une sauvegarde du code qui fonctionnait précédemment, si vous ne pouvez pas le réparer.
  • Adoptez un système de gestion des versions du code source. Vous pouvez toujours voir un diff de la version cassée et de la dernière version fonctionnelle. Ce qui pourrait vous éclairer sur la nature du problème de syntaxe.
    
• Caractères Unicode parasites invisibles** : Dans certains cas, vous devez utiliser un éditeur hexadécimal ou un éditeur/visualisateur différent sur votre source. Certains problèmes ne peuvent pas être trouvés juste en regardant votre code.
  • Essayez [grep --color -P -n "\[\x80-\xFF\]&quot ; file.php][9] comme première mesure pour trouver les symboles non-ASCII.
  • En particulier, les nomenclatures, les espaces de largeur nulle, ou espaces insécables, et les guillemets intelligents peuvent régulièrement se retrouver dans le code source.
• Faites attention aux types de sauts de ligne enregistrés dans les fichiers.
  • PHP ne prend en compte que les \n nouvelles lignes, et non les \r retours de chariot.
  • Ce qui est occasionnellement un problème pour les utilisateurs de MacOS (même sur OS&nbsp ; X pour les éditeurs mal configurés).
  • Ce problème n'apparaît souvent que lorsque des commentaires // ou # d'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 arrive que vous ayez une erreur de syntaxe sur votre machine. Mais en postant le même fichier en ligne, vous ne la présentez plus. Ce qui ne peut signifier que deux choses :
  • Vous regardez le mauvais fichier !
  • Ou votre code contient un Unicode invisible (voir ci-dessus). Vous pouvez facilement le découvrir : Copiez simplement votre code depuis le formulaire web dans votre éditeur de texte.
• Vérifiez votre version PHP. Toutes les constructions syntaxiques ne sont pas disponibles sur tous les serveurs.
  • php -v pour l'interpréteur de ligne de commande
  • <?php phpinfo(); pour celui invoqué via le serveur web. Ce ne sont pas forcément les mêmes. En particulier, lorsque vous travaillez avec des frameworks, vous devez les faire correspondre.
• N'utilisez pas les [mots-clés réservés de PHP][10] comme identifiants de fonctions/méthodes, classes ou constantes.
• Les essais et les erreurs sont votre dernier recours. Si tout le reste échoue, vous pouvez toujours glober votre message d'erreur. Les symboles syntaxiques ne sont pas aussi faciles à rechercher (Stack Overflow lui-même est indexé par [SymbolHound][11]). Il peut donc être nécessaire de parcourir quelques pages supplémentaires avant de trouver quelque chose de pertinent. Autres guides :
• [PHP Debugging Basics][12] par David Sklar
• [Correction des erreurs PHP][13] par Jason McCreary
• [Erreurs PHP - 10 erreurs courantes][14] par Mario Lurig
• [Erreurs PHP courantes et solutions][15]
• [Comment dépanner et réparer votre site Web WordPress][16]
• [Un guide des messages d'erreur PHP pour les concepteurs][17] - Smashing Magazine

  Écran blanc de la mort

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

  • error_reporting = E_ALL
  • display_errors = 1. Dans votre [php.ini][18] en général, ou via [.htaccess][19] pour mod_php, ou même [.user.ini][20] avec des 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 rapide consiste à créer un script d'enveloppe, disons test.php :

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

Ensuite, invoquez le code défaillant en accédant à ce script enveloppe. Il est également utile d'activer le error_log de PHP et de consulter le error.log de votre [serveur web][21] lorsqu'un script se bloque avec des réponses HTTP 500. [1] : http://en.wikipedia.org/wiki/List_of_C-based_programming_languages [2] : http://en.wikipedia.org/wiki/Imperative_programming [3] : http://i.stack.imgur.com/jY6k7.gif [4] : http://en.wikipedia.org/wiki/List_of_PHP_editors [5] : http://i.stack.imgur.com/z2FBC.png [6] : http://www.php.net/langref [7] : http://php.net/tokens

[9] : https://stackoverflow.com/questions/3001177/how-do-i-grep-for-all-non-ascii-characters-in-unix [10] : http://www.php.net/reserved.keywords [11] : http://symbolhound.com/ [12] : http://www.onlamp.com/pub/a/php/2004/08/12/debuggingphp.html [13] : http://jason.pureconcepts.net/2013/05/fixing-php-errors/ [14] : http://www.phpreferencebook.com/misc/php-errors-common-mistakes/ [15] : http://coursesweb.net/php-mysql/common-php-errors-solution_t [16] : http://diythemes.com/thesis/troubleshoot-wordpress-website/ [17] : http://coding.smashingmagazine.com/2011/11/30/a-guide-to-php-error-messages-for-designers/ [18] : http://www.php.net/manual/en/configuration.file.php [19] : http://www.php.net/manual/en/configuration.changes.php [20] : http://php.net/manual/en/configuration.file.per-user.php [21] : http://www.cyberciti.biz/faq/apache-logs/

Unexpected T_VARIABLE

Un "unexpected T_VARIABLE&quot ; signifie qu&#8217il y a un nom littéral de $variable, qui ne s&#8217inscrit pas dans la structure actuelle de l&#8217expression/de l&#8217état.

!diagramme opérateur+$variable volontairement abstrait/inexact][1]

1. Point-virgule manquant

   Il indique le plus souvent [un point-virgule manquant] (https://stackoverflow.com/questions/9135784/syntax-error-unexpected-t-variable) dans la ligne précédente. Les affectations de variables qui suivent une instruction sont un bon indicateur de l'endroit où chercher :

           ⇓
    func1()
    $var = 1 + 2 ; # erreur d'analyse à la ligne +2

2. concaténation de chaînes

   Les [concaténations de chaînes] (https://stackoverflow.com/questions/14606145/php-syntax-error-unexpected-t-variable-expecting-or-on-line-29) avec l'opérateur . oublié sont une erreur fréquente :

                                   ⇓
    print "Voici la valeur : &quot ; $valeur ;

   En fait, il faut préférer les interpolations de chaînes de caractères (variables de base entre guillemets) quand cela aide à la lisibilité. Ce qui permet d'éviter ces problèmes de syntaxe.

   L'interpolation de chaînes est une fonctionnalité de base du langage de script. Il n'y a pas de honte à l'utiliser. Ignorez les conseils de micro-optimisation selon lesquels la concaténation de variables . est plus rapide. **Ce n'est pas le cas.

3. Opérateurs d'expression manquants

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

               ⇓
    print 4 + 7 $var ;

   PHP ne peut pas deviner si la variable doit être ajoutée, soustraite ou comparée, etc.

4. Listes

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

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

   Ou des listes de paramètres de fonctions :

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

   Vous pouvez également voir cela avec les instructions list ou global, ou lorsqu'il manque un point-virgule ; dans une boucle for.

5. Déclarations de classes

   Cette erreur d'analyse syntaxique se produit également [dans les déclarations de classes] (https://stackoverflow.com/questions/5122729/im-getting-a-syntax-error-unexpected-t-variable-error-i-dont-see-what-im). Vous ne pouvez affecter que des constantes statiques, pas des expressions. L'analyseur syntaxique se plaint donc des variables en tant que données assignées :

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

   Des accolades fermantes } non appariées peuvent en particulier mener ici. Si une méthode se termine trop tôt (utilisez une indentation correcte !), une variable perdue est souvent mal placée dans le corps de la déclaration de la classe.

6. Variables après les identifiants

   Vous ne pouvez jamais faire suivre une variable d'un identifiant (https://stackoverflow.com/questions/12194156/php-syntax-error-unexpected-t-variable) directement :

                 ⇓
    $this->myFunc$VAR() ;

   En fait, il s'agit d'un exemple courant 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.

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

7. Parenthèses manquantes après des constructions linguistiques

   Une saisie hâtive peut entraîner l'oubli de parenthèses ouvrantes pour les instructions "if", "for" et "foreach" :

           ⇓
    foreach $array as $key) {

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

8. Else ne s'attend pas à des conditions

         ⇓
    else ($var >= 0)

   Solution : Supprimez les conditions de else ou utilisez elseif.

9. Besoin de parenthèses pour la fermeture

         ⇓
    function() utilise $var {}

   Solution : Ajoutez des parenthèses autour de $var.

10. Espaces blancs invisibles

    Comme mentionné dans la réponse de référence sur "Invisible stray Unicode&quot ; (tel qu'un espace insécable), vous pouvez également voir cette erreur pour un code sans méfiance comme :

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

    C&#8217est plutôt répandu en début de fichiers et pour le code copié-collé. Vérifiez avec un éditeur hexadécimal, si votre code ne semble pas visuellement contenir un problème de syntaxe.

Voir aussi

• Search : unexpected T_VARIABLE](http://www.google.com/search?q=site:stackoverflow.com+php%20parse%20error%20unexpected#q=site:stackoverflow.com+php+parse+error+unexpected+T_VARIABLE)

[1] : http://i.stack.imgur.com/DCDkL.gif

Unexpected T_STRING

T_STRING est un peu un terme mal choisi. Il ne fait pas référence à une "string" entre guillemets. Il signifie qu'un identifiant brut a été rencontré. Il peut s'agir de mots bare, de restes de CONSTANT ou de noms de fonctions, de chaînes de caractères oubliées non citées, ou de n'importe quel texte brut.

1. Chaînes de caractères mal citées

   Cette erreur de syntaxe est toutefois plus fréquente pour les chaînes de caractères mal citées. Tout guillemet " "`" ou "'`" non encodé et errant formera une expression invalide : ⇓ ⇓ echo "click here" ; La coloration syntaxique rendra ces erreurs super évidentes. Il est important de ne pas oublier d'utiliser les barres obliques inversées pour échapper aux guillemets doubles ou aux guillemets simples, en fonction de ce qui a été utilisé comme [string enclosure][1]. - Pour des raisons de commodité, vous devriez préférer les guillemets simples externes lorsque vous produisez du HTML simple avec des guillemets doubles à l'intérieur. - Utilisez des chaînes entre guillemets doubles si vous voulez interpoler des variables, mais faites alors attention à l'échappement des guillemets doubles littéraux `"`. - Pour une sortie plus longue, préférez plusieurs lignes `echo`/`print` au lieu d'échapper les entrées et sorties. Mieux encore, envisagez une section [HEREDOC][2]. Voir aussi *https://stackoverflow.com/questions/3446216/what-is-the-difference-between-single-quoted-and-double-quoted-strings-in-php*.

2. Chaînes non fermées

   Si vous [oubliez d'insérer un `"`' final][3], une erreur de syntaxe se produit généralement par la suite. Une chaîne non terminée consommera souvent un peu de code jusqu'à la prochaine valeur de chaîne prévue : ⇓ echo "Some text" ;, $a_variable, "and some runaway string ; success("finished" ;); ⇯ Il n'y a pas que les `T_STRING` littérales que l'analyseur syntaxique peut protester alors. Une autre variation fréquente est un [`Unexpected '>'`](https://stackoverflow.com/questions/6507796/troubleshooting-parse-error-unexpected-error) pour un HTML littéral non cité.

3. Guillemets de chaîne non programmés

   Si vous *copiez et collez* le code d'un blog ou d'un site Web, vous vous retrouvez parfois avec un code invalide. [Les guillemets typographiques ne correspondent pas à ce que PHP attend : $text = 'Quelque chose quelque chose..' + "These ain't quotes" ; Les guillemets typographiques/intelligents sont des symboles Unicode. PHP les traite comme faisant partie d'un texte alphanumérique. Par exemple, `"these`" est interprété comme un identifiant constant. Mais tout texte littéral suivant est alors vu 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, alors toute déclaration ou construction linguistique suivante est considérée comme un identifiant brut : ⇓ func1() function2() ; PHP ne peut pas savoir si vous avez voulu exécuter deux fonctions l'une après l'autre, ou si vous avez voulu multiplier leurs résultats, les additionner, les comparer, ou n'exécuter qu'une `||` ou l'autre.

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

   C'est plutôt rare. Mais si les short_open_tags sont activés, alors vous ne pouvez pas commencer vos scripts PHP [par une déclaration XML][5] : ⇓ <?xml version="1.0"?> PHP verra le `<?` et le réclamera pour lui-même. Il ne comprendra pas à quoi est destiné le `xml` égaré. Il sera interprété comme une constante. Mais la `version` sera vue comme un autre littéral/constant. Et comme l'analyseur syntaxique ne peut pas donner de sens à deux valeurs littérales consécutives sans opérateur d'expression entre elles, ce sera un échec de l'analyse.
6. caractères Unicode invisibles Les symboles Unicode, tels que l'[espace insécable][6], sont la cause la plus fréquente d'erreurs de syntaxe. PHP autorise les caractères Unicode comme noms d'identifiants. Si vous obtenez une plainte de l'analyseur T_STRING pour un code totalement insoupçonnable comme : <?php imprimez 123 ; Vous devez sortir un autre éditeur de texte. Ou même un éditeur hexadécimal. Ce qui ressemble à de simples espaces et lignes de saut ici, peut contenir des constantes invisibles. Les IDE basés sur Java ne tiennent pas toujours compte d'une nomenclature UTF-8 tronquée, d'espaces de largeur nulle, de séparateurs de paragraphes, etc. Essayez de tout rééditer, de supprimer les espaces blancs et de réintroduire des espaces normaux. Vous pouvez réduire le problème en ajoutant des séparateurs d'instruction redondants ; à chaque début de ligne : <?php ;print 123 ; Le point-virgule supplémentaire ; ici convertira le caractère invisible précédent en une référence constante indéfinie (expression comme déclaration). Ce qui, en retour, permet à PHP de produire un avis utile.

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

   [Les variables en PHP][7] sont représentées par un signe dollar suivi du nom de la variable. Le signe dollar (`$`) est un [sigle][8] qui indique que l'identifiant est le nom d'une variable. Sans ce sigle, l'identifiant pourrait être un [mot-clé du langage][9] ou une [constante][10]. C'est une erreur courante lorsque le code PHP a été ["traduit" ; à partir d'un code écrit dans un autre langage][11] (C, Java, JavaScript, etc.). Dans de tels cas, une déclaration du type de la variable (lorsque le code original a été écrit dans un langage qui utilise des variables typées) peut également se faufiler et produire cette erreur.

8. Guillemets échappés

   Si vous utilisez des guillemets dans une chaîne de caractères, ils ont une signification particulière. Il s'agit d'un " ;[Caractère d'échappement][12]" ; qui indique normalement à l'analyseur syntaxique de prendre le caractère suivant littéralement. Exemple : `echo 'Jim a dit 'Bonjour'''`s'imprimera `Jim a dit 'Bonjour'``. Si vous échappez le guillemet fermant d'une chaîne, le guillemet fermant sera pris littéralement et non comme prévu, c'est-à-dire comme un guillemet imprimable faisant partie de la chaîne et ne fermant pas la chaîne. Cela se traduira par une erreur d'analyse, généralement après l'ouverture de la chaîne suivante ou à la fin du script. Erreur très fréquente lors de la spécification des chemins d'accès sous Windows : `"C:\xampp\htdocs\"` est incorrect. Vous avez besoin de `"C:\xampp\\\htdocs\\\"`. [1] : http://php.net/language.types.string [2] : http://php.net/heredoc [3] : https://stackoverflow.com/questions/13968629/php-parse-error-syntax-error-unexpected-t-string [4] : https://stackoverflow.com/questions/7762558/php-t-string-error [5] : https://stackoverflow.com/questions/4361750/why-when-add-xml-version-1-0-encoding-utf-8-to-web-page-dont-work-on-ho [6] : http://en.wikipedia.org/wiki/Non-breaking_space [7] : http://php.net/manual/en/language.variables.basics.php [8] : https://en.wikipedia.org/wiki/Sigil_(programmation informatique) [9] : http://php.net/manual/en/reserved.keywords.php [10] : http://php.net/manual/en/language.constants.php [12] : http://php.net/manual/en/regexp.reference.escape.php