Perché si dovrebbe omettere il tag di chiusura?

Continuo a leggere è una cattiva pratica usare il tag di chiusura PHP ?>alla fine del file. Il problema dell'intestazione sembra irrilevante nel seguente contesto (e questo è l'unico argomento valido finora):

Le versioni moderne di PHP impostano il flag output_buffering in php.ini Se il buffering dell'output è abilitato, è possibile impostare intestazioni e cookie HTTP dopo aver emesso HTML perché il codice restituito non viene inviato immediatamente al browser.

Ogni libro di buone pratiche e wiki inizia con questa "regola", ma nessuno offre buone ragioni. C'è un altro buon motivo per saltare il tag PHP finale?

L'invio di intestazioni prima del normale corso può avere conseguenze di vasta portata. Di seguito sono riportati solo alcuni di quelli che mi sono venuti in mente al momento:

1. Mentre le attuali versioni di PHP possono avere buffer di output attivo, i server di produzione reali su cui verrà distribuito il codice sono molto più importanti di qualsiasi macchina di sviluppo o test. E non sempre tendono a seguire immediatamente le ultime tendenze di PHP.

2. Potresti avere mal di testa per inspiegabile perdita di funzionalità . Supponiamo che tu stia implementando un tipo di gateway di pagamento e reindirizzi l'utente a un URL specifico dopo la corretta conferma da parte del responsabile del pagamento. Se si verifica un tipo di errore PHP, anche un avvertimento o una fine della linea in eccesso, il pagamento potrebbe rimanere non elaborato e l'utente potrebbe comunque non essere pagato. Questo è anche uno dei motivi per cui il reindirizzamento inutile è malvagio e se il reindirizzamento deve essere usato, deve essere usato con cautela.

3. È possibile che venga visualizzato il tipo di errori "Caricamento pagina annullato" in Internet Explorer, anche nelle versioni più recenti. Questo perché una risposta / json AJAX include qualcosa che non dovrebbe contenere, a causa delle terminazioni di riga in eccesso in alcuni file PHP, proprio come ho riscontrato qualche giorno fa.

4. Se hai alcuni download di file nella tua app, anche loro possono rompersi, per questo motivo. E potresti non accorgertene, anche dopo anni, poiché l'abitudine di rottura specifica di un download dipende dal server, dal browser, dal tipo e dal contenuto del file (e forse da alcuni altri fattori con cui non voglio annoiarti) .

5. Infine, molti framework PHP tra cui Symfony , Zend e Laravel (non si fa menzione di questo nelle linee guida per la codifica ma segue l'esempio) e lo standard PSR-2 (elemento 2.2) richiedono l'omissione del tag di chiusura. Il manuale stesso di PHP ( 1 , 2 ), Wordpress , Drupal e molti altri software PHP credo, consigliano di farlo. Se hai semplicemente l'abitudine di seguire lo standard (e installare PHP-CS-Fixer per il tuo codice) puoi dimenticare il problema. Altrimenti dovrai sempre tenere a mente il problema.

Bonus: alcuni gotcha (attualmente uno) relativi a questi 2 personaggi:

1. Anche alcune librerie note possono contenere terminazioni di riga in eccesso dopo ?>. Un esempio è Smarty, anche le versioni più recenti di entrambi i rami 2. * e 3. * hanno questo. Quindi, come sempre, cerca il codice di terze parti . Bonus in bonus: una regex per l'eliminazione di finali PHP inutili: sostituisci (\s*\?>\s*)$con testo vuoto in tutti i file che contengono codice PHP.

Il motivo per cui dovresti lasciare il tag di chiusura php ( ?>) è che il programmatore non invii accidentalmente caratteri extra per la nuova riga.

Il motivo per cui non dovresti lasciare il tag di chiusura php è perché provoca uno squilibrio nei tag php e qualsiasi programmatore con una mezza mente può ricordare di non aggiungere ulteriore spazio bianco.

Quindi per la tua domanda:

C'è un altro buon motivo per saltare il tag php finale?

No, non c'è un altro buon motivo per saltare i tag php finali.

Finirò con alcuni argomenti per non preoccuparmi del tag di chiusura:

1. Le persone sono sempre in grado di commettere errori, non importa quanto siano intelligenti. Aderire a una pratica che riduce il numero di possibili errori è (IMHO) una buona idea.

2. PHP non è XML. PHP non ha bisogno di aderire agli standard rigorosi di XML per essere ben scritto e funzionale. Se un tag di chiusura mancante ti dà fastidio, ti è consentito utilizzare un tag di chiusura, non è una regola set-in-stone in un modo o nell'altro.

È una raccomandazione di stile di codifica per principianti , ben intenzionata e consigliata dal manuale .

• Evitare, ?>tuttavia, risolve solo un piccolo tratto delle comuni intestazioni già inviate (output non elaborato , distinta base , avvisi, ecc.) E dei loro problemi di follow-up.

• PHP in realtà contiene un po 'di magia per divorare singole interruzioni di riga dopo il ?>token di chiusura. Anche se ha problemi storici , e lascia i nuovi arrivati ​​ancora suscettibili agli editor traballanti e inavvertitamente mescolandosi in altri spazi bianchi dopo ?>.

• Stilisticamente alcuni sviluppatori preferiscono visualizzare <?phpe ?>come istruzioni di elaborazione tag / XML SGML, il che implica la coerenza del bilanciamento di un token vicino finale. (Quale tra l'altro, è utile per la classe che unisce le dipendenze include per soppiantare il caricamento automatico file per file inefficiente.)

• In qualche modo non comune l'apertura <?phpè caratterizzata come shebang PHP (e pienamente fattibile per binfmt_misc ), convalidando in tal modo la ridondanza di un corrispondente tag di chiusura.

• Esiste un'ovvia discrepanza di consulenza tra il mandato obbligatorio delle guide alla sintassi PHP?>\n e le più recenti (PSR-2) che concordano sull'omissione.
  (Per la cronaca: Zend Framework postula l'uno sull'altro non implica la sua intrinseca superiorità. È un'idea sbagliata che gli esperti siano stati attratti / indirizzati al pubblico di API ingombranti).

• Gli SCM e gli IDE moderni forniscono soluzioni integrate per lo più alleviando la cura dei tag vicini.

Scoraggiare qualsiasi uso del ?>tag di chiusura ritarda semplicemente a spiegare il comportamento di base dell'elaborazione PHP e la semantica del linguaggio per evitare problemi rari. È ancora pratico per lo sviluppo di software collaborativo a causa delle variazioni di competenza dei partecipanti.

Chiudi le varianti dei tag

• Il tag di chiusura regolare ?> è anche noto come T_CLOSE_TAG"token vicino".

• Comprende alcune incarnazioni in più, a causa del consumo magico di newline di PHP :

  ?>\n (Avanzamento riga Unix)

  ?>\r (Ritorno a capo, MAC classici)

  ?>\r\n (CR / LF, su DOS / Win)

  PHP non supporta tuttavia l'interruzione di riga combo Unicode NEL(U + 0085).

  Le prime versioni di PHP avevano compilazioni IIRC che limitavano un po 'l'agnosticismo della piattaforma (FI anche usato solo >come marker vicino), che è la probabile origine storica dell'elusione dei tag ravvicinati.

• Spesso trascurato, ma fino a quando PHP7 li rimuove , il regolare <?phptoken di apertura può essere validamente accoppiato con il raramente utilizzato </script>come pedina di chiusura dispari .

• Il " tag di chiusura ravvicinata " non è nemmeno uno - ha appena inventato quel termine per analogia. Dal punto di vista concettuale e d'uso __halt_compilerdovrebbe essere riconosciuto come token vicino.

  __HALT_COMPILER();
  ?>

  Che in pratica ha il tokenizer in seguito scartare qualsiasi codice o sezione HTML semplice. In particolare gli stub PHAR ne fanno uso, o la sua combinazione ridondante con ?>come raffigurato.

• Allo stesso modo un vuotoreturn; sostituisce raramente gli script include, rendendo ?>inefficaci quelli con spazio bianco finale.

• Quindi ci sono tutti i tipi di varianti di tag di chiusura soft / faux ; meno conosciuti e usati di rado, ma di solito per token commentati :

  • Spaziatura semplice // ? >per eludere il rilevamento tramite tokenizer PHPs.

  • O fantasiosi sostituti Unicode // ﹖﹥(U + FE56 SMALL QUESTION MARK, U + FE65 SMALL ANGLE BRACKET) che un regexp può cogliere.

  Entrambi non significano nulla per PHP , ma possono avere usi pratici per toolkit esterni PHP ignari o semi-consapevoli. catMi vengono in mente script di nuovo uniti, con conseguenti // ? > <?phpconcatenazioni che mantengono in linea la precedente sezione di file.

Quindi ci sono alternative dipendenti dal contesto ma pratiche a un'omissione di tag stretta imperativa.

La babysitter manuale di ?>tag vicini non è molto contemporanea in entrambi i casi. Ci sono sempre stati strumenti di automazione per questo (anche se solo sed / awk o regex-oneliners). In particolare:

tag phptags tidier

https://fossil.include-once.org/phptags/

Che potrebbe generalmente essere usato per i --unclosetag php per codice di terze parti, o piuttosto per risolvere qualsiasi (e tutti) problemi reali di spazi bianchi / DBA:

• phptags --warn --whitespace *.php

Gestisce anche la --longconversione di tag, ecc. Per compatibilità runtime / configurazione.

Non è un tag ...

Ma se ce l'hai, rischi di avere spazio bianco dopo di esso.

Se poi lo usi come un'inclusione nella parte superiore di un documento, potresti finire con l'inserimento di spazi bianchi (ad es. Contenuto) prima di tentare di inviare intestazioni HTTP ... cosa non consentita.

È abbastanza utile non lasciare entrare ?>.

Il file rimane valido per PHP (non un errore di sintassi) e come diceva @David Dorward consente di evitare di avere spazi bianchi / linee di interruzione (tutto ciò che può inviare un'intestazione al browser) dopo il ?>.

Per esempio,

<?
    header("Content-type: image/png");
    $img = imagecreatetruecolor ( 10, 10);
    imagepng ( $img);
?>
[space here]
[break line here]

non sarà valido.

Ma

<?
    header("Content-type: image/png");
    $img = imagecreatetruecolor ( 10, 10 );
    imagepng ( $img );

volere.

Per una volta, devi essere pigro per essere sicuro .

Secondo i documenti , è preferibile omettere il tag di chiusura se si trova alla fine del file per il seguente motivo:

Se un file è puro codice PHP, è preferibile omettere il tag di chiusura PHP alla fine del file. Ciò impedisce che vengano aggiunti spazi bianchi accidentali o nuove righe dopo il tag di chiusura di PHP, il che può causare effetti indesiderati poiché PHP avvierà il buffering dell'output quando il programmatore non ha intenzione di inviare alcun output in quel punto dello script.

Manuale PHP> Riferimento lingua> Sintassi di base> Tag PHP

Bene, conosco il motivo, ma non posso mostrarlo:

Per i file che contengono solo codice PHP, il tag di chiusura ( ?>) non è mai consentito. Non è richiesto da PHP e ometterlo impedisce l'iniezione accidentale di spazio bianco finale nella risposta.

Fonte: http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html

Bene, ci sono due modi per vederlo.

1. Il codice PHP non è altro che un insieme di istruzioni di elaborazione XML , e quindi qualsiasi file con .phpestensione non è altro che un file XML che viene analizzato per il codice PHP.
2. In questo caso PHP condivide il formato dell'istruzione di elaborazione XML per i suoi tag di apertura e chiusura. Sulla base di ciò, i file con .phpestensioni POTREBBERO essere file XML validi, ma non devono esserlo.

Se ritieni che il primo percorso, tutti i file PHP richiedano tag di chiusura. Ometterli creerà un file XML non valido. Poi di nuovo, senza avere un'apertura<?xml version="1.0" charset="latin-1" ?> dichiarazione di , non avrai comunque un file XML valido ... Quindi non è un grosso problema ...

Se credi nel secondo percorso, questo apre le porte a due tipi di .phpfile:

• File che contengono solo codice (file di libreria ad esempio)
• File che contengono XML nativo e anche codice (file modello per esempio)

Sulla base di ciò, i file di solo codice possono terminare senza un ?>tag di chiusura . Ma i file di codice XML non sono OK per terminare senza una chiusura ?>poiché invaliderebbe l'XML.

Ma so cosa stai pensando. Stai pensando a ciò che conta, non renderai mai direttamente un file PHP, quindi chi se ne frega se è un XML valido. Bene, importa se stai progettando un modello. Se è XML / HTML valido, un normale browser non visualizzerà semplicemente il codice PHP (viene trattato come un commento). Quindi puoi deridere il modello senza dover eseguire il codice PHP in ...

Non sto dicendo che questo è importante. È solo una visione che non vedo espressa troppo spesso, quindi quale posto migliore per condividerla ...

Personalmente, non chiudo i tag nei file di libreria, ma nei file di modello ... Penso che sia una preferenza personale (e una linea guida per la codifica) basata più di ogni altra cosa ...

Oltre a tutto ciò che è già stato detto, aggiungerò un'altra ragione per cui è stato un grande dolore per noi eseguire il debug.

Apache 2.4.6 con PHP 5.4 in realtà presenta errori di segmentazione sulle nostre macchine di produzione quando c'è spazio vuoto dietro il phptag di chiusura . Ho solo perso ore fino a quando finalmente ho ristretto il bug con lo strace .

Ecco l'errore generato da Apache:

[core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11)

"C'è un'altra buona ragione (oltre al problema dell'intestazione) per saltare il tag php finale?"

Non si desidera generare inavvertitamente caratteri di spazi bianchi estranei durante la generazione di output binario, dati CSV o altri output non HTML.

Professionisti

• Sarebbe logico chiudere qualsiasi tag aperto , come con altre lingue. Non solo tag X (HT) ML, ma anche parentesi graffe, parentesi graffe ...
• Meno confuso per i principianti .

Contro

• Evita il mal di testa con l'aggiunta involontaria di spazi bianchi dopo il tag di chiusura, perché interrompe il comportamento della funzione header () ... Alcuni  editor o client / server FTP sono noti anche per modificare automaticamente la fine dei file (almeno, è la loro configurazione predefinita)
• Il manuale di PHP dice che il tag di chiusura è opzionale e Zend lo proibisce persino .

Conclusione

Direi che gli argomenti a favore dell'omissione del tag sembrano più forti (aiuta a evitare grossi mal di testa con header () + è la "raccomandazione" di PHP / Zend). Ammetto che questa non è la soluzione più "bella" che abbia mai visto in termini di coerenza della sintassi, ma cosa potrebbe esserci di meglio?

Poiché la mia domanda è stata contrassegnata come duplicata di questa, penso che sia OK pubblicare perché NON omettere il tag di chiusura ?>può essere desiderato per alcuni motivi.

• Con le istruzioni di elaborazione complete Sintassi ( <?php ... ?>), la fonte PHP è un documento SGML valido, che può essere analizzato ed elaborato senza problemi con il parser SGML. Con ulteriori restrizioni può essere valido anche XML / XHTML.

Nulla ti impedisce di scrivere codice XML / HTML / SGML valido. La documentazione di PHP ne è consapevole. Estratto:

Nota: nota anche che se stai incorporando PHP in XML o XHTML dovrai utilizzare i tag <? Php?> Per rimanere conforme agli standard.

Naturalmente la sintassi PHP non è rigorosa SGML / XML / HTML e si crea un documento, che non è SGML / XML / HTML, proprio come è possibile trasformare HTML in XHTML per renderlo conforme o meno a XML.

• Ad un certo punto potresti voler concatenare le fonti. Questo non sarà facile come fare semplicemente cat source1.php source2.phpse si introduce un'incoerenza omettendo i ?>tag di chiusura .

• Senza ?>è più difficile dire se il documento è stato lasciato in modalità PHP escape o PHP ignore mode (il tag PI <?phppotrebbe essere stato aperto o meno). La vita è più semplice se lasci costantemente i tuoi documenti in modalità PHP ignora. È come lavorare con documenti HTML ben formattati rispetto ai documenti con tag non chiusi, annidati male ecc.

• Sembra che alcuni editor come Dreamweaver possano avere problemi con PI lasciato aperto [1] .

Se capisco correttamente la domanda, ha a che fare con il buffering dell'output e l'effetto che questo potrebbe avere sui tag di chiusura / chiusura. Non sono sicuro che sia una domanda del tutto valida. Il problema è che il buffer di output non significa che tutto il contenuto sia tenuto in memoria prima di inviarlo al client. Significa che parte del contenuto è.

Il programmatore può eliminare intenzionalmente il buffer o il buffer di output, quindi l'opzione buffer di output in PHP cambia davvero il modo in cui il tag di chiusura influisce sulla codifica? Direi che non lo è.

E forse è per questo che la maggior parte delle risposte è tornata allo stile e alla sintassi personali.

Ci sono 2 possibili usi del codice php:

1. Codice PHP come definizione di classe o definizione di funzione
2. Usa PHP come linguaggio modello (cioè nelle viste)

nel caso 1. il tag di chiusura è totalmente inutile, anche in questo caso vorrei vedere solo 1 (uno) tag di apertura php e NO (zero) tag di chiusura. Questa è una buona pratica in quanto rende il codice pulito e separa la logica dalla presentazione. Per il caso di presentazione (2.) alcuni hanno scoperto che è naturale chiudere tutti i tag (anche quelli elaborati da PHP), il che porta alla confusione, poiché in realtà il PHP ha 2 casi d'uso separati, che non devono essere mescolati: logica / calcolo e presentazione