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

Question

Tout le monde rencontre des erreurs de syntaxe. Même les programmeurs expérimentés font des fautes de frappe. Pour les nouveaux venus, 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 sur la ligne 20

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

Regardez toujours le contexte du code . L'erreur de syntaxe se cache souvent dans la mention ou sur lignes de code précédentes . Comparez votre code aux exemples de syntaxe du manuel.

Bien que tous les cas ne correspondent pas les uns aux autres. Pourtant, il y a des étapes générales pour résoudre les erreurs de syntaxe . Cette référence résume les pièges les plus courants :

• T_STRING inattendu

• Inattendu T_VARIABLE
  Unexpected '$varname' (T_VARIABLE)

• Inattendu T_CONSTANT_ENCAPSED_STRING
  Inattendu T_ENCAPSED_ET_WHITESPACE

• Fin inattendue

• Inattendu T_FUNCTION

• Inattendu {
  Inattendu }
  Inattendu (
  Inattendu )

• Inattendu [
  Inattendu ]

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

• Inattendu T_LNUMBER

• Inattendu ?

• Continuation inattendue (T_CONTINUE)
  Continuation inattendue (T_BREAK)
  Continuation inattendue (T_RETURN)

• Un "=" inattendu

• T_INLINE_HTML inattendu

• Inattendu T_PAAMAYIM_NEKUDOTAYIM

• Inattendu T_OBJECT_OPERATOR

• Inattendu T_DOUBLE_ARROW

• Inattendu T_SL

• Inattendu T_BOOLEAN_OR
  Inattendu T_BOOLEAN_AND

• Inattendu T_IS_EQUAL
  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 >

• Inattendu T_NS_SEPARATOR

• Caractère inattendu dans l'entrée : ' \ ' (ASCII=92) state=1

• Public non attendu (T_PUBLIC)
  Inattendu 'private' (T_PRIVATE)
  Protection inattendue (T_PROTECTED)
  Un "final" inattendu (T_FINAL)

• Inattendu T_STATIC

• Inattendu T_CLASS

• Utilisation inattendue (T_USE)

• Inattendu T_DNUMBER

• Inattendu , (virgule)

• Unpexected . (période)

• Inattendu ; (point-virgule)

• Inattendu * (astérisque)

• Inattendu : (colon)

• Unxpected ':', expecting ',' or ')'.

• Inattendu & (call-time pass-by-reference)

• Inattendu .

Références étroitement liées :

• Que signifie cette erreur en PHP ? (erreurs d'exécution)
  • Erreur d'analyse : erreur de syntaxe, T_XXX inattendu
  • Erreur d'analyse : erreur de syntaxe, inattendu T_ENCAPSED_ET_WHITESPACE
  • Erreur d'analyse : erreur de syntaxe, T_VARIABLE inattendu.
• Que signifie ce symbole en PHP ? (jetons de langage)
• Ces “” intelligent ‘’ les citations ne signifient rien pour PHP

Et :

• Le site Manuel PHP sur php.net et ses différents jetons de langue
• Ou le site Wikipedia introduction à la syntaxe PHP .
• Et enfin, notre php tag-wiki bien sûr.

Si Stack Overflow accueille également les codeurs débutants, il s'adresse surtout aux questions de programmation professionnelle.

• Répondre aux erreurs de codage et aux fautes de frappe de chacun est considéré comme un hors-sujet.
• Veuillez donc prendre le temps de suivre le étapes de base avant de poster des demandes de correction syntaxique.
• Si vous devez toujours le faire, montrez votre propre initiative de résolution, vos tentatives de correction et votre processus de réflexion sur ce qui semble ou pourrait être faux.

Si votre navigateur affiche des messages d'erreur tels que "SyntaxError : illegal character" (erreur de syntaxe : caractère illégal). php -liés, mais un javascript - erreur de syntaxe .

---

Erreurs de syntaxe soulevées sur le code fournisseur : Enfin, si l'erreur de syntaxe n'est pas apparue en modifiant votre base de code, mais après l'installation ou la mise à niveau d'un paquet d'un fournisseur externe, elle peut être due à une incompatibilité de version de PHP. Vérifiez donc les exigences du fournisseur par rapport à la configuration de votre plate-forme.

Answer 1

Quelles sont les erreurs de syntaxe ?

PHP fait partie des Style C et impératif les langages de programmation. Il possède des règles de grammaire rigides, qu'il ne peut contourner lorsqu'il rencontre des symboles ou des identificateurs mal placés. Il ne peut pas deviner vos intentions de codage.

Les conseils les plus importants

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

• Utilisez le bon indentation du code ou d'adopter un style de codage noble. La lisibilité permet d'éviter les irrégularités.

• Utilisez un IDE ou éditeur pour PHP avec coloration syntaxique . Ce qui aide également à équilibrer les parenthèses/parenthèses.

  

• Lire la référence linguistique et des exemples dans le manuel. Deux fois, pour devenir quelque peu compétent.

Comment interpréter les erreurs d'analyse syntaxique

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

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

Qui énumère les possible l'emplacement d'une erreur de syntaxe. Voir la mention nom du fichier et numéro de ligne .

A moniker comme T_STRING explique quel symbole le parseur/tokenizer n'a pas pu traiter finalement. Cependant, ce n'est pas nécessairement la cause de l'erreur de syntaxe.

Il est important d'examiner lignes de code précédentes également. Souvent, les erreurs de syntaxe ne sont que des mésaventures qui se sont produites plus tôt. Le numéro de la ligne d'erreur est juste l'endroit où l'analyseur syntaxique a définitivement renoncé à tout traiter.

Résoudre les erreurs de syntaxe

Il existe de nombreuses approches pour identifier et corriger les problèmes de syntaxe.

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

  • Pour les chaînes de caractères qui s'emballent et les opérateurs mal placés, c'est généralement ici que vous trouverez 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 également.

  • En particulier, les manques ; les points-virgules manquent aux fins de ligne/déclaration précédentes. (Du moins du point de vue stylistique. )

  • Si { blocs de code } sont incorrectement fermés ou imbriqués, vous devrez peut-être chercher encore plus loin dans le code source. Utilisez les indentation du code pour simplifier cela.

• Regardez le colorisation de la syntaxe !

  • Les chaînes de caractères, les variables et les constantes devraient toutes avoir des couleurs différentes.

  • Opérateurs +-*/. devraient également être teintés de manière distincte. Sinon, ils pourraient être dans le mauvais contexte.

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

  • 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 s'il ne s'agit pas de ++ , -- ou des parenthèses après un opérateur. Deux chaînes de caractères/identifiants qui se suivent directement sont incorrects dans la plupart des contextes.

• L'espace blanc est votre ami . Suivez tout style de codage.

• Coupez temporairement les longues files d'attente.

  • Vous pouvez librement ajouter des nouvelles lignes entre les opérateurs ou les constantes et les chaînes de caractères. L'analyseur syntaxique concrétisera ensuite 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é.

  • Split up complex if en déclarations distinctes ou imbriquées 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).

  • Ajoutez 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 l'analyseur syntaxique se plaint.

    Partitionnement de longs blocs de code vraiment permet de localiser l'origine des erreurs de syntaxe.

• Commentaire le code en question.

  • 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, vous avez trouvé la source du problème. Regardez de plus près.

  • Parfois, vous souhaitez supprimer temporairement des blocs complets de fonctions/méthodes. (Dans le cas d'accolades non assorties et de code mal indenté).

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

• En tant que nouveau venu, évitez certaines constructions syntaxiques déroutantes.

  • Le ternaire ? : L'opérateur de condition peut compacter le code et est effectivement utile. Mais il ne facilite pas la lisibilité dans tous les cas. Préférez le simple if des déclarations alors qu'elles ne sont pas connues.

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

• Les erreurs les plus courantes des nouveaux arrivants sont :

  • Points-virgules manquants ; pour terminer les déclarations/lignes.

  • Des guillemets mal assortis pour la chaîne de caractères " ou ' et des guillemets non évidés à l'intérieur.

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

  • asymétrique ( parenthèses ) . Comptez-les dans la ligne signalée. Sont-ils en nombre égal ?

• N'oubliez pas que la résolution d'un problème de syntaxe peut faire apparaître le suivant.

  • Si vous faites disparaître un problème, mais qu'un autre réapparaît dans le code ci-dessous, vous êtes en grande partie sur la bonne voie.

  • Si, après modification, une nouvelle erreur de syntaxe apparaît sur la même ligne, votre tentative de modification a peut-être échoué. (Pas toujours cependant.)

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

  • Adopter un système de gestion des versions du code source. Vous pouvez toujours consulter une diff de la version cassée et de la dernière version fonctionnelle. Ce qui pourrait nous éclairer sur le 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 simplement en regardant votre code.

  • Essayez grep --color -P -n "\[\x80-\xFF\]" file.php 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.

• Prenez soin de ce qui type de rupture de ligne sont enregistrées dans des fichiers.

  • PHP honore juste \n les nouvelles lignes, pas \r les retours de chariot.

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

  • Souvent, le problème ne se pose que lorsqu'il s'agit d'une ligne unique. // ou # les commentaires sont utilisés. Multiline /*...*/ Les commentaires perturbent rarement l'analyseur syntaxique lorsque les sauts de ligne sont ignorés.

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

  • Vous regardez le mauvais fichier !

  • Ou votre code contenait un Unicode invisible (voir ci-dessus). Vous pouvez facilement le découvrir : Il suffit de recopier votre code du formulaire web dans votre éditeur de texte.

• Vérifiez votre Version de 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é par le serveur web.

  Ce ne sont pas nécessairement 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 comme identifiants de fonctions/méthodes, de classes ou de constantes.

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

Si tout le reste échoue, vous pouvez toujours google votre message d'erreur. Les symboles syntaxiques ne sont pas aussi faciles à rechercher (Stack Overflow lui-même est indexé par SymbolHound cependant). Il se peut donc que vous deviez parcourir quelques pages supplémentaires avant de trouver quelque chose de pertinent.

Autres guides :

• Les bases du débogage en PHP par David Sklar
• Correction des erreurs PHP par Jason McCreary
• Erreurs PHP - 10 erreurs courantes par Mario Lurig
• _Erreurs PHP courantes et solutions_
• Comment dépanner et réparer votre site Web WordPress
• Guide des messages d'erreur PHP pour les concepteurs - Magazine Smashing

É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 en général, ou via .htaccess pour mod_php, ou même .user.ini 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 enveloppant, par exemple 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 enveloppant.

Il permet également d'activer la fonction error_log et regarder dans votre du serveur web error.log quand un script se bloque avec des réponses HTTP 500.

Answer 2

Je pense que ce sujet est totalement surdiscuté/surcompliqué. L'utilisation d'un IDE est LA solution pour éviter toute erreur de syntaxe. Je dirais même que travailler sans un 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 toute votre ligne devient rouge, et qu'un grand avertissement vous indique le type exact et la position exacte de l'erreur de syntaxe, il n'y a absolument aucun besoin de chercher une autre solution.

L'utilisation d'un IDE de vérification de la syntaxe signifie :

Vous ne rencontrerez (pratiquement) plus jamais d'erreurs de syntaxe, tout simplement parce que vous les voyez au moment où vous tapez. Sérieusement.

Excellents IDE avec contrôle syntaxique (ils sont tous disponibles pour Linux, Windows et Mac) :

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

Answer 3

Inattendu T_VARIABLE

Un "imprévu T_VARIABLE " signifie qu'il y a un littéral $variable qui ne s'intègre pas dans la structure actuelle de l'expression/de l'énoncé.

1. Point-virgule manquant

   Il indique le plus souvent un point-virgule manquant 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;     # parse error in line +2

2. Concaténation de chaînes de caractères

   Les accidents les plus fréquents sont concaténations de chaînes de caractères avec oublié . opérateur :

    print "Here comes the value: "  $value;

   En fait, vous devriez préférer interpolation de chaînes de caractères (variables de base entre guillemets doubles) chaque fois que cela aide à la lisibilité. Ce qui permet d'éviter ces problèmes de syntaxe.

   L'interpolation des chaînes de caractères est une langage de script fonctionnalité de base. Il n'y a pas de honte à l'utiliser. Ignorez tous les conseils de micro-optimisation concernant les variables. . la concaténation étant plus rapide . Ce n'est pas le cas.

3. Opérateurs d'expression manquants

   Bien entendu, 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 devinez ici si la variable aurait dû ê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 aussi 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 cela avec list ou global ou en l'absence d'une ; point-virgule dans un for boucle.

5. Déclarations de classes

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

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

   Incomparable } Les accolades fermantes 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 pas non plus avoir une variable suit un identifiant 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 des parenthèses ouvrantes ou fermantes pour if et for et foreach déclarations :

    foreach $array as $key) {

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

    if ($var = pdo_query($sql) {
         $result = …

   Les boucles { n'ouvre pas le bloc de code, sans fermer l'accolade if avec l'expression ) la parenthèse fermante en premier.

8. Else n'attend pas de conditions

   else ($var >= 0)

   Solution : Supprimez les conditions de else ou utiliser elseif .

9. Besoin de crochets pour la fermeture

   function() use $var {}

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

10. Espaces blancs invisibles

    Comme mentionné dans le réponse de référence sur "Invisible stray Unicode" (comme une espace insécable ), vous pouvez également voir cette erreur pour un code non suspect comme :

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

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

Voir aussi

• Recherche : T_VARIABLE inattendu

Answer 4

Inattendu T_CONSTANT_ENCAPSED_STRING
Inattendu T_ENCAPSED_ET_WHITESPACE

Les noms difficiles à manier T_CONSTANT_ENCAPSED_STRING et T_ENCAPSED_AND_WHITESPACE se référer à la citation "string" littéraux .

Ils sont utilisés dans des contextes différents, mais la question de la syntaxe est assez similaire. T_ENCAPSED se produisent dans le contexte d'une chaîne de caractères doublement citée, alors que T_CONSTANT Les chaînes de caractères sont souvent égarées dans des expressions ou des déclarations PHP simples.

1. Interpolation incorrecte des variables

   Et cela se produit le plus souvent pour une interpolation incorrecte de la variable PHP :

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

   Citer les clés des tableaux est indispensable dans le contexte PHP. Mais dans les chaînes de caractères doublement citées (ou HEREDOCs), c'est une erreur. L'analyseur syntaxique se plaint du contenu de la chaîne entre guillemets. 'string' parce qu'il s'attend généralement à ce qu'un identifiant ou une clé littéral(e) s'y trouve.

   Plus précisément, il est possible d'utiliser le style PHP2. syntaxe simple entre guillemets pour les références de tableaux :

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

   Les tableaux imbriqués ou les références d'objets plus profondes requièrent cependant l'utilisation de la fonction expression complexe de chaîne de caractères bouclée la syntaxe :

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

   En cas de doute, il est généralement plus sûr de l'utiliser. Elle est même souvent considérée comme plus lisible. Les meilleurs IDE utilisent d'ailleurs une coloration syntaxique distincte pour cela.

2. Concaténation manquante

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

   print "Hello " . WORLD  " !";

   Bien que ce soit évident pour vous et moi, PHP ne peut tout simplement pas devinez que la chaîne de caractères devait être ajoutée à cet endroit.

3. Confusion des guillemets dans les chaînes de caractères

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

   print "<a href="' . $link . '">click here</a>";

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

   Conseil : Configurez votre éditeur/IDE pour utiliser une colorisation légèrement distincte pour les chaînes de caractères entre guillemets simples et doubles. (Il est également utile pour la logique de l'application de préférer, par exemple, les chaînes entre guillemets doubles pour la sortie textuelle, et les chaînes entre guillemets simples uniquement pour les valeurs de type constant).

   C'est un bon exemple pour lequel vous ne devriez pas sortir des guillemets en premier lieu. Au lieu de cela, utilisez simplement approprié \" s'échappe pour les guillemets des attributs HTML :

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

   Bien que cela puisse également entraîner une confusion syntaxique, tous les meilleurs IDE/éditeurs aident à nouveau en colorant différemment les guillemets échappés.

4. Citation d'ouverture manquante

   Les équivalents sont ouverture oubliée " / ' citations une recette pour les erreurs d'analyse syntaxique :

    make_url(login', 'open');

   Ici, le ', ' deviendrait une chaîne littérale après un mot nu, alors qu'évidemment login était censé être un paramètre de type chaîne.

5. Listes de tableaux

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

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

   Notez que la dernière ligne peut toujours contenir une virgule supplémentaire, mais qu'en oublier une entre les deux est impardonnable. Ce qui est difficile à découvrir sans coloration syntaxique.

6. Listes des paramètres des fonctions

   La même chose pour les appels de fonction :

   myfunc(123, "text", "and"  "more")

7. Cordes en fuite

   Une variation courante est tout simplement l'oubli des terminaisons de chaîne :

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

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

8. indentation HEREDOC

   Précédent PHP 7.3 le chaîne herédoc Le délimiteur de fin ne peut pas être préfixé par des espaces :

   print <<< HTML
       <link..>
       HTML;

   Solution : mettez à niveau PHP ou trouvez un meilleur hébergeur.

Voir aussi

• Interpolation (chaîne entre guillemets) de tableaux associatifs en PHP
• PHP - Erreur de syntaxe, inattendu T_CONSTANT_ENCAPSED_STRING
• Erreur de syntaxe, T_CONSTANT_ENCAPSED_STRING inattendue en PHP
• Erreur inattendue T_CONSTANT_ENCAPSED_STRING dans une requête SQL

Answer 5

Inattendu (

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

1. Paramètres de déclaration des fonctions

   Cette erreur est plus rare dans les cas suivants 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, pour lesquelles vous pouvez utiliser librement les paramètres de whatever(1+something()*2) etc.

2. Défauts des propriétés de classe

   Même chose pour déclarations des membres de la classe où seules les valeurs littérales/constantes sont autorisées, et non les expressions :

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

   Mettez ces choses dans le constructeur. Voir aussi Pourquoi les attributs PHP n'autorisent-ils pas les fonctions ?

   Encore une fois, notez 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 que la chaîne précédente n'est pas terminée ; et le littéral <script> des sections qui fuient dans le contexte du code PHP.

4. isset(()), empty, key, next, current

   Les deux sites isset() et empty() sont des modules intégrés au langage, et non des fonctions. Ils besoin d'accéder directement à une variable . Si vous ajoutez par inadvertance une paire de parenthèses en trop, vous créerez une expression cependant :

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

   Il en va de même pour toute construction du langage qui nécessite un accès implicite aux noms de variables. Ces constructions font partie de la grammaire du langage, et ne permettent donc pas d'ajouter des parenthèses décoratives.

   Les fonctions de niveau utilisateur qui nécessitent une référence à une variable - mais dont le résultat est une expression transmise - entraînent des erreurs d'exécution.

Inattendu )

1. Paramètre de fonction absent

   Vous ne pouvez pas avoir d'errants virgules en dernier dans un appel de fonction . PHP s'attend à une valeur ajoutée et se plaint donc d'une fermeture précoce. ) entre parenthèses.

   callfunc(1, 2, );

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

2. Expressions inachevées

   Si vous oubliez quelque chose dans une expression arithmétique, l'analyseur syntaxique abandonne. Parce que comment pourrait-il interpréter ça :

   $var = 2 * (1 + );

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

3. Foreach comme constant

   Pour variable oubliée $ préfixes dans les déclarations de contrôle vous verrez :

   foreach ($array as wrong) {

   PHP vous dit parfois qu'il attendait un :: à la place. Parce qu'une classe::$variable aurait pu satisfaire l'expression attendue $variable..

Inattendu {

Accolades bouclées { et } renferment des blocs de code. Et les erreurs de syntaxe les concernant indiquent généralement une imbrication incorrecte.

1. Les sous-expressions non concordantes dans un if

   Le plus souvent asymétrique ( et ) sont la cause d'une plainte de l'analyseur syntaxique au sujet de l'ouverture des boucles. { apparaissant trop tôt. Un exemple simple :

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

   Comptez vos parenthèses ou utilisez un IDE qui vous aide à le faire. N'écrivez pas non plus de code sans espace. La lisibilité compte.

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

   Vous ne pouvez pas utiliser d'accolades dans les expressions. Si vous confondez parenthèses et accolades, la grammaire du langage ne sera pas respectée :

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

   Il existe quelques exceptions pour la construction d'identifiants, comme les variables de portée locale. ${references} .

3. Variables ou expressions curly var

   C'est plutôt rare. Mais vous pouvez aussi obtenir { et } plaintes de l'analyseur syntaxique pour les expressions complexes de variables :

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

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

Inattendu }

Lorsque vous recevez un "message inattendu } "Vous avez fermé un bloc de code trop tôt.

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

   Cela peut se produire pour toute expression non terminée.

   Et si la dernière ligne d'une fonction ou d'un bloc de code n'est pas suivie de la mention ; point-virgule :

   function whatever() {
       doStuff()
   }            

   Ici, le parseur ne peut pas dire si vous voulez peut-être encore ajouter + 25; au résultat de la fonction ou à autre chose.

2. Emboîtement de blocs non valide / Oublié {

   Vous verrez parfois cette erreur d'analyseur lorsqu'un bloc de code a été } 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 d'ouverture { accolade. Ainsi, la fermeture } celle du dessous est devenue superflue. Et donc la fermeture suivante } qui était prévu pour la fonction, n'était pas associable à l'ouverture originale. { accolade en forme de boucle.

   De telles erreurs sont encore plus difficiles à trouver sans une indentation correcte du code. Utilisez un IDE et la correspondance des parenthèses.

Inattendu { en attendant (

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

1. Listes de paramètres

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

   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. La même chose pour les suspects habituels, for / foreach , while / do etc.

   Si vous obtenez cette erreur particulière, vous devez absolument rechercher des exemples manuels.