¿Por qué se omite la etiqueta de cierre?

Sigo leyendo que es una mala práctica usar la etiqueta de cierre de PHP ?>al final del archivo. El problema del encabezado parece irrelevante en el siguiente contexto (y este es el único buen argumento hasta ahora):

Las versiones modernas de PHP establecen el indicador output_buffering en php.ini. Si el buffer de salida está habilitado, puede configurar encabezados HTTP y cookies después de generar HTML porque el código devuelto no se envía al navegador de inmediato.

Todo libro de buenas prácticas y wiki comienza con esta 'regla', pero nadie ofrece buenas razones. ¿Hay otra buena razón para omitir la etiqueta PHP final?

Enviar encabezados antes del curso normal puede tener consecuencias de largo alcance. A continuación se detallan algunos de los que me vinieron a la mente en este momento:

1. Si bien las versiones actuales de PHP pueden tener almacenado en el búfer de salida, los servidores de producción reales en los que implementará su código son mucho más importantes que cualquier máquina de desarrollo o prueba. Y no siempre tienden a seguir las últimas tendencias de PHP de inmediato.

2. Puede tener dolores de cabeza por la inexplicable pérdida de funcionalidad . Supongamos que está implementando algún tipo de pasarela de pago y redirige al usuario a una URL específica después de una confirmación exitosa por parte del procesador de pagos. Si se produce algún tipo de error de PHP, incluso una advertencia o un final de línea en exceso, el pago puede permanecer sin procesar y el usuario aún puede parecer no facturado. Esta es también una de las razones por las cuales la redirección innecesaria es mala y si se va a utilizar la redirección, debe usarse con precaución.

3. Puede obtener el tipo de error "Carga de página cancelada" en Internet Explorer, incluso en las versiones más recientes. Esto se debe a que una respuesta AJAX / incluir json contiene algo que no debería contener, debido al exceso de terminaciones de línea en algunos archivos PHP, tal como lo encontré hace unos días.

4. Si tiene algunas descargas de archivos en su aplicación, también pueden romperse debido a esto. Y es posible que no lo note, incluso después de años, ya que el hábito de interrupción específico de una descarga depende del servidor, el navegador, el tipo y el contenido del archivo (y posiblemente algunos otros factores con los que no quiero aburrirlo) .

5. Finalmente, muchos frameworks PHP, incluidos Symfony , Zend y Laravel (no se menciona esto en las pautas de codificación, pero sigue el ejemplo) y el estándar PSR-2 (elemento 2.2) requieren la omisión de la etiqueta de cierre. Manual PHP en sí ( 1 , 2 ), Wordpress , Drupal y muchos otros programas PHP, supongo, aconsejo hacerlo. Si simplemente tiene la costumbre de seguir el estándar (y configura PHP-CS-Fixer para su código), puede olvidar el problema. De lo contrario, siempre tendrá que tener el problema en mente.

Bonificación: algunas trampas (actualmente una) relacionadas con estos 2 personajes:

1. Incluso algunas bibliotecas bien conocidas pueden contener terminaciones de línea en exceso después ?>. Un ejemplo es Smarty, incluso las versiones más recientes de la rama 2. * y 3. * tienen esto. Entonces, como siempre, esté atento al código de terceros . Bonificación en bonificación: una expresión regular para eliminar terminaciones PHP innecesarias: reemplace (\s*\?>\s*)$con texto vacío en todos los archivos que contienen código PHP.

La razón por la que debe dejar la etiqueta de cierre php ( ?>) es para que el programador no envíe accidentalmente caracteres adicionales de nueva línea.

La razón por la que no debe omitir la etiqueta de cierre de php es porque causa un desequilibrio en las etiquetas de php y cualquier programador con media mente puede recordar no agregar espacios en blanco adicionales.

Entonces para su pregunta:

¿Hay otra buena razón para omitir la etiqueta php final?

No, no hay otra buena razón para omitir las etiquetas php finales.

Terminaré con algunos argumentos para no molestarme con la etiqueta de cierre:

1. Las personas siempre pueden cometer errores, no importa cuán inteligentes sean. Adherirse a una práctica que reduce el número de posibles errores es (en mi humilde opinión) una buena idea.

2. PHP no es XML. PHP no necesita adherirse a los estándares estrictos de XML para estar bien escrito y ser funcional. Si una etiqueta de cierre faltante te molesta, puedes usar una etiqueta de cierre, no es una regla establecida de una manera u otra.

Es una recomendación de estilo de codificación para novatos , bien intencionada y recomendada por el manual .

• Evitando ?>sin embargo resuelve simplemente un chorrito de los comunes cabeceras ya enviado causas (salida cruda, BOM , avisos, etc.) y sus problemas de seguimiento.

• PHP en realidad contiene algo de magia para comer saltos de línea individuales después del ?>token de cierre. Aunque eso tiene problemas históricos , y deja a los recién llegados aún susceptibles a los editores escamosos y luego a barajar inconscientemente en otros espacios en blanco ?>.

• Estilísticamente, algunos desarrolladores prefieren ver <?phpy ?>como etiquetas SGML / instrucciones de procesamiento XML, lo que implica la coherencia del equilibrio de un token cercano al final. (Que por cierto, es útil para la clase de unión de dependencias que incluye suplantar la carga automática ineficiente de archivo por archivo).

• De manera poco común, la apertura <?phpse caracteriza como shebang de PHP (y completamente factible por binfmt_misc ), lo que valida la redundancia de una etiqueta de cierre correspondiente.

• Hay una discrepancia obvia entre las guías clásicas de sintaxis de PHP obligatorias ?>\ny las más recientes (PSR-2) que acuerdan la omisión.
  (Para el registro: Zend Framework postulando uno sobre el otro no implica su superioridad inherente. Es un error pensar que los expertos se sintieron atraídos por el público objetivo de las API difíciles de manejar).

• Los SCM y los IDE modernos proporcionan soluciones integradas que alivian principalmente el cuidado de etiquetas cercanas.

Desalentar cualquier uso de la ?>etiqueta de cierre simplemente retrasa la explicación del comportamiento de procesamiento básico de PHP y la semántica del lenguaje para evitar problemas poco frecuentes. Todavía es práctico para el desarrollo de software colaborativo debido a las variaciones de competencia en los participantes.

Cerrar variaciones de etiqueta

• La etiqueta de cierre regular ?> también se conoce como T_CLOSE_TAG"token de cierre".

• Comprende algunas encarnaciones más, debido a la alimentación mágica de la nueva línea de PHP :

  ?>\n (Salto de línea Unix)

  ?>\r (Retorno de carro, MACs clásicos)

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

  Sin embargo, PHP no admite el salto de línea combinado Unicode NEL(U + 0085).

  Las primeras versiones de PHP tenían compilaciones IIRC que limitaban un poco el agnosticismo de la plataforma (FI incluso solo se usaba >como marcador cercano), que es el origen histórico probable de la evitación de etiqueta cerrada.

• A menudo se pasa por alto, pero hasta PHP7 los elimina , la regularidad <?phpelemento de obertura puede ser válidamente emparejado con el rara vez se utiliza </script>como símbolo de cierre extraña .

• La " etiqueta de cierre duro " ni siquiera es una, simplemente creó ese término para analogía. __halt_compilerSin embargo, desde el punto de vista conceptual y de uso se debe reconocer como un token cercano.

  __HALT_COMPILER();
  ?>

  Básicamente, el tokenizador descarta cualquier código o secciones HTML simples a partir de entonces. En particular, los talones de PHAR hacen uso de eso, o su combinación redundante con la ?>que se muestra.

• Del mismo modo, un vacíoreturn; sustituye infrecuentemente los guiones de inclusión, lo que hace que ninguno ?>con espacios en blanco finales no sea efectivo.

• Luego hay todo tipo de variaciones de etiqueta de cierre suave / falsa ; menos conocido y raramente utilizado, pero generalmente por tokens comentados :

  • Espaciado simple // ? >para evadir la detección por el tokenizador de PHP.

  • O sustitutos elegantes de Unicode // ﹖﹥(U + FE56 SMALL QUESTION MARK, U + FE65 SMALL ANGLE BRACKET) que una expresión regular puede captar.

  Ambos no significan nada para PHP , pero pueden tener usos prácticos para kits de herramientas externas que no son conscientes de PHP o semi-conscientes. Nuevamente, catme vienen a la mente scripts unidos, con // ? > <?phpconcatenaciones resultantes que retienen en línea la sección anterior del archivo.

Por lo tanto, existen alternativas prácticas pero dependientes del contexto para una omisión de etiqueta cerrada imperativa.

Niñera manual de ?>etiquetas cercanas no es muy contemporánea de ninguna manera. Siempre ha habido herramientas de automatización para eso (incluso si solo sed / awk o regex-oneliners). En particular:

phptags tag tidier

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

Que generalmente se puede usar para --uncloseetiquetas php para código de terceros, o más bien simplemente para solucionar cualquier (y todos) problemas de espacios en blanco / BOM reales:

• phptags --warn --whitespace *.php

También maneja la --longconversión de etiquetas, etc. para compatibilidad / configuración de tiempo de ejecución.

No es una etiqueta ...

Pero si lo tiene, corre el riesgo de tener espacios en blanco después.

Si lo usa como una inclusión en la parte superior de un documento, podría terminar insertando espacios en blanco (es decir, contenido) antes de intentar enviar encabezados HTTP ... lo cual no está permitido.

Es bastante útil no dejar entrar el cierre ?>.

El archivo sigue siendo válido para PHP (no es un error de sintaxis) y, como dijo @David Dorward, permite evitar espacios en blanco / líneas de corte (cualquier cosa que pueda enviar un encabezado al navegador) después de ?>.

Por ejemplo,

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

No será válido.

Pero

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

será.

Por una vez, debes ser flojo para estar seguro .

Según los documentos , es preferible omitir la etiqueta de cierre si está al final del archivo por la siguiente razón:

Si un archivo es código PHP puro, es preferible omitir la etiqueta de cierre de PHP al final del archivo. Esto evita que se agreguen espacios en blanco accidentales o que se agreguen nuevas líneas después de la etiqueta de cierre de PHP, lo que puede causar efectos no deseados porque PHP comenzará el almacenamiento en búfer de salida cuando el programador no tenga la intención de enviar ningún resultado en ese punto del script.

Manual PHP> Referencia del lenguaje> Sintaxis básica> Etiquetas PHP

Bueno, sé el motivo, pero no puedo mostrarlo:

Para los archivos que contienen solo código PHP, la etiqueta de cierre ( ?>) nunca está permitida. PHP no lo requiere, y omitirlo evita la inyección accidental de espacios en blanco finales en la respuesta.

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

Bueno, hay dos formas de verlo.

1. El código PHP no es más que un conjunto de instrucciones de procesamiento XML y, por lo tanto, cualquier archivo con una .phpextensión no es más que un archivo XML que se analiza para el código PHP.
2. PHP simplemente comparte el formato de instrucción de procesamiento XML para sus etiquetas de apertura y cierre. En base a eso, los archivos con .phpextensiones PUEDEN ser archivos XML válidos, pero no es necesario que lo sean.

Si cree en la primera ruta, entonces todos los archivos PHP requieren el cierre de etiquetas finales. Omitirlos creará un archivo XML no válido. Por otra parte, sin tener una <?xml version="1.0" charset="latin-1" ?>declaración de apertura , no tendrá un archivo XML válido de todos modos ... Por lo tanto, no es un problema importante ...

Si cree en la segunda ruta, eso abre la puerta a dos tipos de .phparchivos:

• Archivos que contienen solo código (archivos de biblioteca por ejemplo)
• Archivos que contienen XML nativo y también código (archivos de plantilla, por ejemplo)

En base a eso, los archivos de solo código pueden finalizar sin una ?>etiqueta de cierre . Pero los archivos de código XML no están bien para finalizar sin un cierre ?>ya que invalidaría el XML.

Pero sé lo que estás pensando. Estás pensando qué importa, nunca vas a renderizar un archivo PHP directamente, así que a quién le importa si es XML válido. Bueno, importa si estás diseñando una plantilla. Si es XML / HTML válido, un navegador normal simplemente no mostrará el código PHP (se trata como un comentario). Para que pueda simular la plantilla sin necesidad de ejecutar el código PHP dentro de ...

No digo que esto sea importante. Es solo una vista que no veo expresada con demasiada frecuencia, entonces, ¿qué mejor lugar para compartirla?

Personalmente, no cierro etiquetas en archivos de biblioteca, pero sí en archivos de plantilla ... Creo que es una preferencia personal (y una guía de codificación) basada más que nada difícil ...

Además de todo lo que ya se ha dicho, voy a agregar otra razón que fue un gran dolor para nosotros para depurar.

Apache 2.4.6 con PHP 5.4 en realidad falla en la segmentación en nuestras máquinas de producción cuando hay un espacio vacío detrás de la phpetiqueta de cierre . Solo perdí horas hasta que finalmente reduje el error con strace .

Aquí está el error que arroja Apache:

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

"¿Hay otra buena razón (además del problema del encabezado) para omitir la etiqueta php final?"

No desea generar caracteres de espacio en blanco extraños sin darse cuenta al generar resultados binarios, datos CSV u otros resultados que no sean HTML.

Pros

• Sería lógico cerrar cualquier etiqueta abierta , como con otros idiomas. No solo etiquetas X (HT) ML, sino también llaves, llaves ...
• Menos confuso para principiantes .

Contras

• Evita el dolor de cabeza al agregar espacios en blanco inadvertidamente después de la etiqueta de cierre, porque rompe el comportamiento de la función de encabezado () ... Algunos  editores o clientes / servidores FTP también cambian automáticamente el final de los archivos (al menos, es su configuración predeterminada)
• El manual de PHP dice que la etiqueta de cierre es opcional , y Zend incluso lo prohíbe .

Conclusión

Diría que los argumentos a favor de omitir la etiqueta parecen más fuertes (ayuda a evitar un gran dolor de cabeza con el encabezado () + es "recomendación" PHP / Zend). Admito que esta no es la solución más "hermosa" que he visto en términos de coherencia de sintaxis, pero ¿qué podría ser mejor?

Como mi pregunta se marcó como un duplicado de esta, creo que está bien publicar por qué NO se puede omitir la etiqueta de cierre ?>por algunas razones deseadas.

• Con las instrucciones de procesamiento completas, la sintaxis ( <?php ... ?>) de la fuente PHP es un documento SGML válido, que se puede analizar y procesar sin problemas con el analizador SGML. Con restricciones adicionales, también puede ser válido XML / XHTML.

Nada le impide escribir un código XML / HTML / SGML válido. La documentación de PHP es consciente de esto. Extracto:

Nota: Tenga en cuenta también que si está incorporando PHP en XML o XHTML, deberá usar las etiquetas <? Php?> Para seguir cumpliendo con los estándares.

Por supuesto, la sintaxis PHP no es estricta SGML / XML / HTML y usted crea un documento, que no es SGML / XML / HTML, al igual que puede convertir HTML en XHTML para que sea compatible con XML o no.

• En algún momento es posible que desee concatenar las fuentes. Esto no será tan fácil como simplemente hacerlo cat source1.php source2.phpsi tiene una inconsistencia introducida al omitir las ?>etiquetas de cierre .

• Sin ?>esto, es más difícil saber si el documento se dejó en modo de escape PHP o en modo de ignorar PHP (la etiqueta PI <?phppuede haberse abierto o no). La vida es más fácil si constantemente deja sus documentos en modo de ignorar PHP. Es como trabajar con documentos HTML bien formateados en comparación con documentos con etiquetas mal cerradas, mal anidadas, etc.

• Parece que algunos editores como Dreamweaver pueden tener problemas con PI dejado abierto [1] .

Si entiendo la pregunta correctamente, tiene que ver con el búfer de salida y el efecto que esto podría tener en el cierre / finalización de las etiquetas. No estoy seguro de que sea una pregunta completamente válida. El problema es que el búfer de salida no significa que todo el contenido se almacena en la memoria antes de enviarlo al cliente. Significa que parte del contenido es.

El programador puede vaciar el búfer a propósito, o el búfer de salida, ¿la opción del búfer de salida en PHP realmente cambia la forma en que la etiqueta de cierre afecta la codificación? Yo diría que no es así.

Y tal vez es por eso que la mayoría de las respuestas volvieron al estilo personal y la sintaxis.

Hay 2 posibles usos del código php:

1. Código PHP como definición de clase o definición de función
2. Utilice PHP como lenguaje de plantilla (es decir, en vistas)

en el caso 1. la etiqueta de cierre es totalmente inútil, también me gustaría ver solo 1 (una) etiqueta abierta de php y NO (cero) etiqueta de cierre en tal caso. Esta es una buena práctica ya que hace que el código sea limpio y separe la lógica de la presentación. Para el caso de presentación (2.), algunos encontraron que es natural cerrar todas las etiquetas (incluso las procesadas por PHP), lo que lleva a la confusión, ya que PHP tiene de hecho 2 casos de uso separados, que no deben mezclarse: lógica / cálculo y presentación