¿Por qué se omitiría la etiqueta de cierre?
Sigo leyendo que es una mala práctica utilizar 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 configuran el indicador output_buffering en php.ini. Si el almacenamiento en búfer 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 inmediatamente.
Todo libro y wiki de buenas prácticas comienza con esta "regla", pero nadie ofrece buenas razones. ¿Existe otra buena razón para omitir la etiqueta PHP final?
Enviar encabezados antes de lo normal puede tener consecuencias de gran alcance. A continuación se detallan algunos de los que me vinieron a la mente en este momento:
Si bien las versiones actuales de PHP pueden tener un 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.
Es posible que tenga dolores de cabeza por la pérdida inexplicable de funcionalidad . Digamos que está implementando algún tipo de pasarela de pago y redirige al usuario a una URL específica después de la 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 excesivo, es posible que el pago no se procese y que el usuario siga pareciendo no facturado. Esta es también una de las razones por las que la redirección innecesaria es mala y si se va a utilizar la redirección, debe hacerse con precaución.
Es posible que obtenga errores del tipo "Carga de página cancelada" en Internet Explorer, incluso en las versiones más recientes. Esto se debe a que una respuesta AJAX /inclusión json contiene algo que no debería contener, debido al exceso de finales de línea en algunos archivos PHP, tal como me encontré hace unos días.
Si tiene algunas descargas de archivos en su aplicación, también pueden fallar debido a esto. Y es posible que no lo notes, 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 contenido del archivo (y posiblemente algunos otros factores con los que no quiero aburrirte). .
Finalmente, muchos frameworks PHP, incluidos Symfony , Zend y Laravel (no se menciona esto en las pautas de codificación , pero siguen el ejemplo) y el estándar PSR-2 (elemento 2.2) requieren la omisión de la etiqueta de cierre. El manual de PHP en sí ( 1 , 2 ), Wordpress , Drupal y muchos otros programas PHP, supongo, recomiendo hacerlo. Si simplemente adquiere el hábito de seguir el estándar (y configurar PHP-CS-Fixer para su código), puede olvidarse del problema. De lo contrario, siempre tendrás que tener presente el problema.
Bonificación: algunas trampas (en realidad, una) relacionadas con estos 2 personajes:
- Incluso algunas bibliotecas conocidas pueden contener finales de línea adicionales después de
?>. Un ejemplo es Smarty, incluso las versiones más recientes de las ramas 2.* y 3.* tienen esto. Entonces, como siempre, esté atento al código de terceros . Bonificación adicional: una expresión regular para eliminar terminaciones PHP innecesarias: reemplácelas(\s*\?>\s*)$con texto vacío en todos los archivos que contengan código PHP.
La razón por la que debes omitir la etiqueta de cierre de php ( ?>) es para que el programador no envíe accidentalmente caracteres de nueva línea adicionales.
La razón por la que no debes omitir la etiqueta de cierre de php es porque causa un desequilibrio en las etiquetas de php y cualquier programador con algo de mente puede recordar no agregar espacios en blanco adicionales.
Entonces para tu pregunta:
¿Existe 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 molestarnos con la etiqueta de cierre:
Las personas siempre pueden cometer errores, por muy inteligentes que sean. Adherirse a una práctica que reduzca el número de posibles errores es (en mi humilde opinión) una buena idea.
PHP no es XML. PHP no necesita cumplir con los estrictos estándares XML para estar bien escrito y ser funcional. Si le molesta una etiqueta de cierre faltante, puede usar una etiqueta de cierre, no es una regla escrita en piedra de una forma u otra.
Es una recomendación de estilo de codificación para principiantes , bien intencionada y recomendada por el manual .
Sin embargo, evitarlo
?>resuelve sólo una pequeña parte de las causas comunes de los encabezados ya enviados (salida sin procesar, lista de materiales , avisos, etc.) y sus problemas de seguimiento.PHP en realidad contiene algo de magia para consumir saltos de línea individuales después del
?>token de cierre. Aunque eso tiene problemas históricos y deja a los recién llegados todavía susceptibles a editores poco fiables y a barajar sin darse cuenta otros espacios en blanco después?>.Estilísticamente, algunos desarrolladores prefieren ver
<?phpy?>como etiquetas SGML/instrucciones de procesamiento XML, lo que implica la coherencia del equilibrio de un token de cierre final. (Lo cual, por cierto, es útil para las clases de unión de dependencias que incluyen para reemplazar la carga automática ineficiente archivo por archivo).De manera algo poco común, la apertura
<?phpse caracteriza como shebang de PHP (y es totalmente factible según binfmt_misc ), validando así la redundancia de una etiqueta de cierre correspondiente.Existe una discrepancia obvia entre los consejos de las guías de sintaxis PHP clásicas que exigen
?>\ny las más recientes (PSR-2) que acuerdan la omisión.
(Para que conste: Zend Framework postular 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 API difíciles de manejar).Los SCM y los IDE modernos proporcionan soluciones integradas que alivian principalmente el cuidado de las etiquetas cercanas.
Desalentar cualquier uso de la ?>etiqueta close simplemente retrasa la explicación del comportamiento básico del procesamiento 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 de los participantes.
Cerrar variaciones de etiquetas
La etiqueta de cierre normal ?> también se conoce como
T_CLOSE_TAG"token de cierre".Comprende algunas encarnaciones más, debido a la alimentación mágica de nueva línea de PHP :
?>\n (salto de línea Unix)
?>\r (Retorno de carro, MAC 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 de cierre), que es el probable origen histórico de la evitación de etiquetas de cierre.A menudo se pasa por alto, pero hasta que PHP7 los elimine , el token de apertura normal
<?phpse puede combinar válidamente con el token de cierre impar</script>que rara vez se usa .La " etiqueta de cierre duro " ni siquiera es una, simplemente inventó ese término para hacer una analogía. Sin embargo , desde el punto de vista conceptual y de uso,
__halt_compilerdebe reconocerse como un token cercano.__HALT_COMPILER(); ?>Lo que básicamente hace que el tokenizador descarte cualquier código o secciones HTML simples a partir de entonces. En particular, los stubs de PHAR hacen uso de eso, o de su combinación redundante como
?>se muestra.Del mismo modo, rara vez se sustituye un void
return;en los scripts de inclusión, lo que hace que cualquiera?>que tenga espacios en blanco al final no sea efectivo.Luego están todo tipo de variaciones de etiquetas de cierre suave o falso ; Menos conocido y rara vez utilizado, pero generalmente por tokens comentados :
Espaciado simple
// ? >para evadir la detección por parte del tokenizador de PHP.O sustitutos elegantes de Unicode
// ﹖﹥(Signo de interrogación pequeño U+FE56, soporte de ángulo pequeño U+FE65) que una expresión regular puede captar.
Ambos no significan nada para PHP , pero pueden tener usos prácticos para kits de herramientas externos semiconscientes o no conscientes de PHP. 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 que dependen del contexto a una omisión imperativa de etiqueta cercana.
El cuidado manual de ?>niños cercanos no es muy contemporáneo de ninguna manera. Siempre ha habido herramientas de automatización para eso (aunque solo sean sed/awk o regex-oneliners). En particular:
Etiqueta phptags más ordenada
https://fossil.include-once.org/phptags/
Lo que generalmente podría usarse para --uncloseetiquetas php para código de terceros, o más bien simplemente solucionar cualquier (y todos) problemas reales de espacios en blanco/BOM:
phptags --warn --whitespace *.php
También maneja --longla conversión de etiquetas, etc. para compatibilidad con el tiempo de ejecución/configuración.
No es una etiqueta...
Pero si lo tiene, corre el riesgo de tener espacios en blanco después.
Si luego lo usa como 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.
Según los documentos , es preferible omitir la etiqueta de cierre si está al final del archivo por el siguiente motivo:
Si un archivo es código PHP puro, es preferible omitir la etiqueta de cierre PHP al final del archivo. Esto evita que se agreguen espacios en blanco accidentales o nuevas líneas después de la etiqueta de cierre de PHP, lo que puede causar efectos no deseados porque PHP comenzará a almacenar en búfer la salida cuando el programador no tenga la intención de enviar ninguna salida en ese punto del script.
Manual de PHP > Referencia del lenguaje > Sintaxis básica > Etiquetas PHP
