PHP parse/syntax hataları; ve nasıl çözülür?

Sözdizimi hataları nelerdir?

PHP C-style ve imperative programlama dillerine aittir. Yanlış yerleştirilmiş semboller veya tanımlayıcılarla karşılaştığında kurtaramayacağı katı dilbilgisi kurallarına sahiptir. Kodlama niyetinizi tahmin edemez.

En önemli ipuçları

Her zaman alabileceğiniz birkaç temel önlem vardır:

• Uygun kod girintisi kullanın veya herhangi bir yüce kodlama stilini benimseyin. Okunabilirlik düzensizlikleri önler.
• Sözdizimi vurgulaması olan bir [**IDE veya PHP için editör]4 kullanın. Bu da parantez/ayraç dengelemesine yardımcı olur.
• Kılavuzdaki dil referansı ve örnekleri okuyun. Biraz yetkin olmak için iki kez.

  Ayrıştırıcı hataları nasıl yorumlanır

  Tipik bir sözdizimi hata mesajı şöyledir:

  Parse error: syntax error, unexpected T_STRING, expecting ';' in file.php on line 217 Bu da sözdizimi hatasının olası konumunu listeler. Bahsedilen dosya adı ve satır numarasına bakın. T_STRING` gibi bir moniker, ayrıştırıcının/tokenizerin en sonunda hangi sembolü işleyemediğini açıklar. Ancak, bu mutlaka sözdizimi hatasının nedeni değildir. Önceki kod satırlarına** da bakmak önemlidir. Genellikle sözdizimi hataları daha önce meydana gelen aksiliklerdir. Hata satırı numarası, ayrıştırıcının tümünü işlemekten kesin olarak vazgeçtiği yerdir.

  Sözdizimi hatalarını çözme

  Sözdizimi aksaklıklarını daraltmak ve düzeltmek için birçok yaklaşım vardır.

• Söz konusu kaynak dosyayı açın. Bahsedilen kod satırına bakın.
  • Kaçak dizeler ve yanlış yerleştirilmiş operatörler için, genellikle suçluyu bulacağınız yer burasıdır.
  • Satırı soldan sağa doğru okuyun ve her bir sembolün ne işe yaradığını hayal edin.
• Daha düzenli olarak önceki satırlara da bakmanız gerekir.
  • Özellikle, eksik ; noktalı virgüller önceki satır sonlarında/ifadelerinde eksiktir. (En azından biçimsel açıdan. )
  • Eğer {kod blokları } yanlış kapatılmış veya iç içe geçmişse, kaynak kodun daha da yukarısını araştırmanız gerekebilir. Bunu kolaylaştırmak için uygun kod girintisi kullanın.
• Sözdizimi renklendirmesine** bakın!
  • Dizeler, değişkenler ve sabitlerin hepsi farklı renklere sahip olmalıdır.
  • Operatörler +-*/. de farklı renklerde olmalıdır. Aksi takdirde yanlış bağlamda olabilirler.
  • Dizgi renklendirmesinin çok uzadığını veya çok kısaldığını görürseniz, yazılmamış veya eksik bir kapanış " veya ' dizgi işaretçisi buldunuz demektir.
  • Aynı renkli iki noktalama karakterinin yan yana olması da sorun anlamına gelebilir. Genellikle, bir işleci izleyen ++, -- veya parantez değilse işleçler yalnızdır. Birbirini doğrudan takip eden iki dizgi/tanımlayıcı çoğu bağlamda yanlıştır.
• Boşluk sizin arkadaşınızdır. Herhangi bir* kodlama stilini takip edin. Ancak burada yeni başlayanları PSR-x ile rahatsız etmeyelim, tamam mı? -->
• Uzun satırları geçici olarak ayırın.
  • Operatörler veya sabitler ve dizeler arasına serbestçe yeni satır ekleyebilirsiniz. Ayrıştırıcı daha sonra ayrıştırma hataları için satır numarasını somutlaştıracaktır. Çok uzun koda bakmak yerine, eksik veya yanlış yerleştirilmiş sözdizimi sembolünü izole edebilirsiniz.
  • Karmaşık if ifadelerini farklı veya iç içe if koşullarına bölün.
  • Uzun matematik formülleri veya mantık zincirleri yerine, kodu basitleştirmek için geçici değişkenler kullanın. (Daha okunabilir = daha az hata.)
  • Araya satırsonu ekleyin:
    1. Kolayca doğru olarak tanımlayabileceğiniz kod,
    2. Emin olmadığınız kısımlar,
    3. Ve ayrıştırıcının şikayet ettiği satırlar.
       Uzun kod bloklarını bölümlere ayırmak gerçekten sözdizimi hatalarının kaynağını bulmaya yardımcı olur.
• Hatalı kodu yorumlayın.
  • Sorunun kaynağını belirleyemiyorsanız, kod bloklarını yorumlamaya (ve böylece geçici olarak kaldırmaya) başlayın.
  • Ayrıştırma hatasından kurtulduğunuz anda, sorunun kaynağını bulmuşsunuz demektir. Oraya daha yakından bakın.
  • Bazen tüm fonksiyon/metot bloklarını geçici olarak kaldırmak isteyebilirsiniz. (Eşleşmeyen küme parantezleri ve yanlış girintili kod durumunda).
  • Sözdizimi sorununu çözemediğinizde, yorumlanan bölümleri sıfırdan yeniden yazmayı deneyin.
• Yeni başlayan biri olarak, bazı kafa karıştırıcı sözdizimi yapılarından kaçının.
  • Üçlü ? : koşul operatörü kodu sıkıştırabilir ve gerçekten yararlıdır. Ancak her durumda okunabilirliğe yardımcı olmaz. İncelenmemişken düz if ifadelerini tercih edin.
  • PHP39;nin alternatif sözdizimi (if:/elseif:/endif;) şablonlar için yaygındır, ancak normal{kod}` bloklarına göre takip edilmesi daha az kolaydır.
• En yaygın yeni gelen hatalar şunlardır:
  • İfadeleri/satırları sonlandırmak için eksik noktalı virgüller ;.
  • "veya'` için uyumsuz dize tırnakları ve içindeki tırnakların açılmaması.
  • Unutulan operatörler, özellikle de . dize birleştirmesi için.
  • Dengesiz (parantezler ). Bunları raporlanan satırda sayın. Eşit sayıda var mı?
• Bir sözdizimi sorununu çözmenin bir sonrakini ortaya çıkarabileceğini unutmayın.
  • Bir sorunu ortadan kaldırırsanız, ancak aşağıdaki bazı kodlarda başka bir sorun ortaya çıkarsa, çoğunlukla doğru yoldasınız demektir.
  • Düzenlemeden sonra aynı satırda yeni bir sözdizimi hatası ortaya çıkarsa, değişiklik girişiminiz muhtemelen başarısız olmuştur. (Her zaman değil ama.)
• Eğer düzeltemezseniz, daha önce çalışan kodun yedeğini geri yükleyin.
  • Bir kaynak kodu sürümleme sistemi benimseyin. Bozuk ve son çalışan sürümün diffini her zaman görüntüleyebilirsiniz. Bu, sözdizimi sorununun ne olduğu konusunda aydınlatıcı olabilir.
    
• Görünmeyen başıboş Unicode karakterleri: Bazı durumlarda, kaynağınızda hexeditor veya farklı bir editör/görüntüleyici kullanmanız gerekir. Bazı sorunlar sadece kodunuza bakarak bulunamaz.
  • ASCII olmayan sembolleri bulmak için ilk önlem olarak grep --color -P -n "\[\x80-\xFF\]" file.php deneyin.
  • Özellikle BOM'lar, sıfır genişlikli boşluklar veya kesilmeyen boşluklar ve akıllı tırnak işaretleri düzenli olarak kaynak koduna girebilir.
• Dosyalarda hangi tip satır kesmelerin kaydedildiğine dikkat edin.
  • PHP sadece \n yeni satırları onurlandırır, \r satır başlarını değil.
  • Bu, MacOS kullanıcıları için zaman zaman bir sorundur (yanlış yapılandırılmış editörler için OS  X'te bile).
  • Genellikle sadece tek satırlık // veya # yorumları kullanıldığında bir sorun olarak ortaya çıkar. Çok satırlı /*...*/ yorumları, satır sonları göz ardı edildiğinde ayrıştırıcıyı nadiren rahatsız eder.
• Eğer sözdizimi hatanız web üzerinden iletilmiyorsa: Makinenizde bir sözdizimi hatası olabilir. Ancak aynı dosyayı çevrimiçi olarak yayınlamak artık bunu göstermez. Bu sadece iki şeyden biri anlamına gelebilir:
  • Yanlış dosyaya bakıyorsunuz!
  • Ya da kodunuz görünmeyen başıboş Unicode içeriyor (yukarıya bakın). Bunu kolayca öğrenebilirsiniz: Kodunuzu web formundan metin düzenleyicinize geri kopyalayın.
• PHP sürümünüzü** kontrol edin. Tüm sözdizimi yapıları her sunucuda mevcut değildir.
  • Komut satırı yorumlayıcısı için php -v
  • Web sunucusu aracılığıyla çağrılan için <?php phpinfo();.
    Bunlar aynı olmak zorunda değildir. Özellikle çerçevelerle çalışırken, bunları eşleştirmeniz gerekir.
• Fonksiyonlar/yöntemler, sınıflar veya sabitler için tanımlayıcı olarak PHP'nin ayrılmış anahtar kelimelerini kullanmayın.
• Deneme-yanılma sizin son çarenizdir. Her şey başarısız olursa, hata mesajınızı her zaman google edebilirsiniz. Sözdizimi sembollerini aramak o kadar kolay değildir (Stack Overflow'un kendisi SymbolHound tarafından indekslenir). Bu nedenle, ilgili bir şey bulmadan önce birkaç sayfaya daha bakmanız gerekebilir. Diğer kılavuzlar:
• David Sklar tarafından PHP Hata Ayıklama Temelleri
• Jason McCreary tarafından PHP Hatalarını Düzeltme
• Mario Lurig tarafından PHP Hataları - 10 Yaygın Hata
• Yaygın PHP Hataları ve Çözümleri
• WordPress Web Sitenizde Nasıl Sorun Giderilir ve Onarılır
• Tasarımcılar İçin PHP Hata Mesajları Rehberi - Smashing Magazine

  Beyaz ölüm ekranı

  Web siteniz boşsa, bunun nedeni genellikle bir sözdizimi hatasıdır. İle görüntülenmelerini etkinleştirin:

  • error_reporting = E_ALL
  • display_errors = 1 Genel olarak php.ini dosyanızda veya mod_php için .htaccess aracılığıyla, veya hatta FastCGI kurulumları ile .user.ini. Bozuk betik içinde bunu etkinleştirmek çok geçtir çünkü PHP ilk satırı bile yorumlayamaz/çalıştıramaz. Hızlı bir çözüm, test.php gibi bir sarmalayıcı betik hazırlamaktır:

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

Ardından bu sarmalayıcı komut dosyasına erişerek başarısız olan kodu çağırın. Ayrıca PHP'nin error_log özelliğini etkinleştirmek ve bir betik HTTP 500 yanıtlarıyla çöktüğünde web sunucunuzun'error.log dosyasına bakmak da yardımcı olur.

Beklenmeyen T_VARIABLE

Bir "unexpected T_VARIABLE" mevcut ifade/ifade yapısına uymayan gerçek bir $variable adı olduğu anlamına gelir.

1. Eksik noktalı virgül

   Genellikle bir önceki satırda eksik noktalı virgül olduğunu gösterir. Bir ifadeyi takip eden değişken atamaları nereye bakılacağının iyi bir göstergesidir:

           ⇓
    func1()
    $var = 1 + 2; # +2 satırında ayrıştırma hatası

2. Dize birleştirme

   Sık karşılaşılan bir hata, unutulmuş . operatörü ile string concatenations:

                                   ⇓
    print "İşte değer geliyor: " $değer;

   Bu arada, okunabilirliğe yardımcı olacaksa string interpolation (çift tırnak içinde temel değişkenler) tercih etmelisiniz. Bu da bu sözdizimi sorunlarını önler.

   Dize enterpolasyonu bir komut dosyası dili temel özelliğidir. Kullanmakta utanılacak bir şey yok. Değişken . birleştirmenin daha hızlı olduğuna dair mikro optimizasyon tavsiyelerini dikkate almayın. **Öyle değil.

3. Eksik ifade operatörleri

   Elbette aynı sorun aritmetik işlemler gibi diğer ifadelerde de ortaya çıkabilir:

               ⇓
    print 4 + 7 $var;

   PHP burada değişkenin eklenip eklenmeyeceğini, çıkarılıp çıkarılmayacağını veya karşılaştırılıp karşılaştırılmayacağını tahmin edemez.

4. Listeler

   Dizi popülasyonlarında olduğu gibi, ayrıştırıcının örneğin beklenen bir virgül , belirttiği sözdizimi listeleri için de aynıdır:

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

   Veya fonksiyon parametre listeleri:

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

   Bunu list veya global deyimlerinde veya for döngüsünde ; noktalı virgül olmadığında da görebilirsiniz.

5. Sınıf bildirimleri

   Bu ayrıştırıcı hatası [sınıf bildirimlerinde] de meydana gelir (https://stackoverflow.com/questions/5122729/im-getting-a-syntax-error-unexpected-t-variable-error-i-dont-see-what-im). Sadece statik sabitler atayabilirsiniz, ifadeler atayamazsınız. Bu nedenle ayrıştırıcı, değişkenleri atanmış veri olarak şikayet eder:

    sınıf xyz { ⇓
        var $value = $_GET["input"];

   Eşleşmeyen } kapanış küme parantezleri özellikle buraya yol açabilir. Bir yöntem çok erken sonlandırılırsa (uygun girinti kullanın!), başıboş bir değişken genellikle sınıf bildirimi gövdesine yanlış yerleştirilir.

6. Tanımlayıcılardan sonra gelen değişkenler

   Ayrıca hiçbir zaman bir değişkenin bir tanımlayıcıyı takip etmesini doğrudan sağlayamazsınız:

                 ⇓
    $this->myFunc$VAR();

   Bu arada, bu, belki de değişken değişkenler kullanma niyetinin olduğu yaygın bir örnektir. Bu durumda, örneğin $this->{"myFunc$VAR"}(); ile bir değişken özellik araması.

   Değişken kullanmanın istisna olması gerektiğini aklınızda bulundurun. Yeni başlayanlar, dizilerin daha basit ve uygun olacağı durumlarda bile bunları genellikle çok gelişigüzel kullanmaya çalışırlar.

7. Dil yapılarından sonra eksik parantezler

   Aceleyle yazmak parantez açmanın unutulmasına neden olabilir ifveforveforeach` ifadeleri için:

           ⇓
    foreach $array as $key) {

   Çözüm: ifade ve değişken arasına eksik olan ( ifadesini ekleyin.

8. Else koşulları beklemiyor

         ⇓
    else ($var >= 0)

   Çözüm: elsekısmındaki koşulları kaldırın veya [elseif`](http://php.net/manual/en/control-structures.elseif.php) kullanın.

9. Kapatma için parantezlere ihtiyacınız var

         ⇓
    function() $var {} kullanır

   Çözüm: $var`ın etrafına parantez ekleyin.

10. Görünmez beyaz boşluk

    "Invisible stray Unicode" (non-breaking space gibi) hakkındaki referans cevap'da belirtildiği gibi, bu hatayı aşağıdaki gibi masum kodlar için de görebilirsiniz:

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

    Dosyaların başlangıcında ve kopyalanıp yapıştırılan kodlarda oldukça yaygındır. Kodunuz görsel olarak bir sözdizimi sorunu içeriyor gibi görünmüyorsa, bir hexeditor ile kontrol edin.

Ayrıca bakınız

• Search: unexpected T_VARIABLE

Beklenmeyen T_STRING

T_STRINGbiraz yanlış bir isimlendirmedir. Tırnak içine alınmış bir"string"e atıfta bulunmaz. Ham bir tanımlayıcı ile karşılaşıldığı anlamına gelir. Bu,barekelimelerden artıkCONSTANT` veya fonksiyon isimlerine, unutulmuş tırnaksız dizelere veya herhangi bir düz metne kadar değişebilir.

1. Yanlış alıntılanmış dizeler

   Bu sözdizimi hatası en çok yanlış alıntılanmış dize değerleri için yaygındır. Tırnak içine alınmamış ve başıboş `"` veya `'` tırnak işaretleri geçersiz bir ifade oluşturacaktır: ⇓ ⇓ echo "click here"; Sözdizimi vurgulama bu tür hataları çok belirgin hale getirecektir. Hangisinin [string enclosure][1] olarak kullanıldığına bağlı olarak, `\"` çift tırnaklardan veya `\'` tek tırnaklardan kaçmak için ters eğik çizgi kullanmayı unutmamak önemlidir. - Kolaylık sağlamak için, içinde çift tırnak bulunan düz HTML çıktısı alırken dış tek tırnakları tercih etmelisiniz. - Değişkenleri enterpole etmek istiyorsanız çift tırnaklı dizeleri kullanın, ancak bu durumda `"` çift tırnaklarının kaçmasına dikkat edin. - Daha uzun çıktılar için, içeri ve dışarı kaçmak yerine birden fazla `echo`/`print` satırını tercih edin. Daha da iyisi bir [HEREDOC][2] bölümü düşünün. Ayrıca bakınız *https://stackoverflow.com/questions/3446216/what-is-the-difference-between-single-quoted-and-double-quoted-strings-in-php*.

2. Kapalı olmayan dizgiler

   Eğer bir kapanış `"`][3] kaçırırsanız, genellikle daha sonra bir sözdizimi hatası ortaya çıkar. Sonlandırılmamış bir dize genellikle bir sonraki amaçlanan dize değerine kadar biraz kod tüketecektir: ⇓ echo "Some text", $a_variable, "and some runaway string ; success("finished"); ⇯ O zaman ayrıştırıcının itiraz edebileceği sadece gerçek `T_STRING`ler değildir. Sık rastlanan bir başka varyasyon da tırnak içine alınmamış değişmez HTML için [``Unexpected '>'`](https://stackoverflow.com/questions/6507796/troubleshooting-parse-error-unexpected-error).

3. Programlama dışı dize tırnak işaretleri

   Bir blog veya web sitesinden *kodu kopyalayıp yapıştırırsanız*, bazen geçersiz kodla karşılaşırsınız. PHP'nin beklediği [tipografik tırnak işaretleri][4] değildir: $text = 'Bir şey bir şey...' + "bunlar tırnak işareti değil"; Tipografik/akıllı tırnak işaretleri Unicode sembolleridir. PHP bunları bitişik alfanümerik metnin bir parçası olarak ele alır. Örneğin `"bunlar" bir sabit tanımlayıcı olarak yorumlanır. Ancak, takip eden herhangi bir metin değişmezi ayrıştırıcı tarafından bir bareword/T_STRING olarak görülür.

4. Eksik noktalı virgül; tekrar

   Önceki satırlarda sonlandırılmamış bir ifadeniz varsa, takip eden herhangi bir ifade veya dil yapısı ham tanımlayıcı olarak görülür: ⇓ func1() function2(); PHP iki fonksiyonu birbiri ardına mı çalıştırmak istediğinizi, yoksa sonuçlarını çarpmak, toplamak, karşılaştırmak ya da sadece birini mi çalıştırmak istediğinizi anlayamaz.

5. PHP betiklerinde kısa açık etiketler ve <?xml başlıkları

   Bu oldukça nadir görülen bir durumdur. Ancak short_open_tags etkinleştirilmişse, PHP betiklerinize [bir XML bildirimi ile] başlayamazsınız[5]: ⇓ <?xml version="1.0"?> PHP `<?`'yi görecek ve kendisi için geri alacaktır. Başıboş `xml`nin ne için kullanıldığını anlamayacaktır. Sabit olarak yorumlanacaktır. Ancak `version` başka bir değişmez/sabit olarak görülecektir. Ve ayrıştırıcı, aralarında bir ifade operatörü olmadan birbirini takip eden iki değişmezi/değeri anlamlandıramayacağından, bu bir ayrıştırıcı hatası olacaktır.

6. Görünmez Unicode karakterler

   Sözdizimi hatalarının en korkunç nedenlerinden biri [boşluk bırakmayan][6] gibi Unicode sembolleridir. PHP Unicode karakterlerin tanımlayıcı ismi olarak kullanılmasına izin verir. Eğer bir T_STRING ayrıştırıcı şikayeti alırsanız aşağıdaki gibi tamamen şüpheli olmayan kodlar için: <?php Baskı 123; Başka bir metin düzenleyicisine ihtiyacınız var. Ya da bir hexeditor. Burada düz boşluklar ve satırsonları gibi görünen şeyler görünmez sabitler içerebilir. Java tabanlı IDE'ler bazen UTF-8 BOM'un içine karışmış, sıfır genişlikli boşluklar, paragraf ayırıcılar vb. Her şeyi yeniden düzenlemeye, boşlukları kaldırmaya ve normal boşlukları geri eklemeye çalışın. Her satır başına gereksiz `;` deyim ayırıcıları ekleyerek sorunu azaltabilirsiniz: <?php ;print 123; Buradaki fazladan `;` noktalı virgül, önceki görünmez karakteri tanımlanmamış bir sabit referansa dönüştürecektir (ifade olarak ifade). Bu da PHP'nin yararlı bir uyarı üretmesini sağlar.

7. Değişken isimlerinin önünde `$` işareti eksik

   [PHP'de değişkenler][7] bir dolar işareti ve ardından değişkenin adı ile gösterilir. Dolar işareti (`$`), tanımlayıcıyı bir değişken adı olarak işaretleyen bir [sigil][8] işaretidir. Bu işaret olmadan, tanımlayıcı bir [dil anahtar sözcüğü][9] veya bir [sabit][10] olabilir. Bu, PHP kodu başka bir dilde yazılmış koddan ["translated"][11] (C, Java, JavaScript, vb.) olduğunda yaygın bir hatadır. Bu gibi durumlarda, değişken tipinin bir bildirimi (orijinal kod tipli değişkenler kullanan bir dilde yazıldığında) de gizlice girebilir ve bu hatayı üretebilir.

8. Kaçan Tırnak İşaretleri

   Bir dize içinde `` kullanırsanız, bunun özel bir anlamı vardır. Buna "[Kaçış Karakteri][12]" denir ve normalde ayrıştırıcıya bir sonraki karakteri harfi harfine almasını söyler. Örnek: `echo 'Jim said \'Hello\'';`, `Jim said 'hello'` yazdıracaktır. Bir dizenin kapanış tırnak işaretinden kaçarsanız, kapanış tırnak işareti amaçlandığı gibi değil tam anlamıyla alınır, yani dizenin bir parçası olarak yazdırılabilir bir tırnak işareti olarak alınır ve dizeyi kapatmaz. Bu, genellikle bir sonraki dizeyi açtıktan sonra veya kodun sonunda bir ayrıştırma hatası olarak gösterilir. Windows'ta yol belirtirken çok yaygın bir hata: `"C:\xampp\htdocs\"` yanlış. İhtiyacınız olan `"C:\\xampp\\htdocs\\"`.