Mengapa orang menghilangkan tag penutup?


374

Saya terus membaca itu adalah praktik yang buruk untuk menggunakan tag penutup PHP ?>di akhir file. Masalah header tampaknya tidak relevan dalam konteks berikut (dan ini adalah satu-satunya argumen yang bagus sejauh ini):

Versi modern dari PHP mengatur flag output_buffering di php.ini Jika output buffering diaktifkan, Anda dapat mengatur HTTP header dan cookie setelah mengeluarkan HTML karena kode yang dikembalikan tidak segera dikirim ke browser.

Setiap buku praktik dan wiki yang bagus dimulai dengan 'aturan' ini tetapi tidak ada yang menawarkan alasan yang bagus. Apakah ada alasan lain untuk melewatkan tag PHP penutup?


3
kemungkinan duplikat dari [mengapa dalam beberapa skrip mereka menghilangkan tag php penutup?>] ( stackoverflow.com/questions/3219383/... )
Gordon

@Christian - Maksud Anda menggunakan output_buffering adalah malas, atau meninggalkan ?>malas?
El Yobo

4
@ Gordon - Saya tidak berpikir itu dup, OP tahu alasan yang masuk akal, hanya ingin tahu apakah itu sepenuhnya diselesaikan dengan buffering output.
El Yobo

5
Pertanyaan yang lebih baik adalah: Mengapa orang menyertakan tag penutup? Kode itu jahat. Kode terbaik adalah tidak ada kode sama sekali. Jika masalah dapat dihilangkan alih-alih diselesaikan dengan kode, ini lebih baik daripada memiliki kode. Dalam hal ini, tidak ada masalah yang perlu dipecahkan. Kode berfungsi dengan baik tanpa tag penutup.
still_dreaming_1

19
Ya Tuhan, ini bukan tempat untuk tab vs ruang perang suci, lol :)
Kevin Wheeler

Jawaban:


322

Mengirim header lebih awal dari yang biasa mungkin memiliki konsekuensi yang jauh jangkauannya. Di bawah ini adalah beberapa di antaranya yang muncul di benak saya saat ini:

  1. Sementara rilis PHP saat ini mungkin memiliki buffering output, server produksi aktual Anda akan menyebarkan kode Anda jauh lebih penting daripada mesin pengembangan atau pengujian. Dan mereka tidak selalu cenderung mengikuti tren PHP terbaru dengan segera.

  2. Anda mungkin mengalami sakit kepala karena kehilangan fungsionalitas yang tidak dapat dijelaskan . Katakanlah, Anda menerapkan semacam gateway pembayaran, dan mengarahkan pengguna ke URL tertentu setelah konfirmasi berhasil oleh prosesor pembayaran. Jika beberapa jenis kesalahan PHP, bahkan peringatan, atau kelebihan garis berakhir terjadi, pembayaran mungkin tetap tidak diproses dan pengguna mungkin masih tampak tidak ditagih. Ini juga salah satu alasan mengapa redirection yang tidak perlu itu jahat dan jika redirection akan digunakan, itu harus digunakan dengan hati-hati.

  3. Anda mungkin mendapatkan jenis kesalahan "Memuat halaman dibatalkan" di Internet Explorer, bahkan di versi terbaru. Ini karena respons AJAX / json include berisi sesuatu yang seharusnya tidak dikandungnya, karena kelebihan garis berakhiran pada beberapa file PHP, sama seperti yang saya temui beberapa hari yang lalu.

  4. Jika Anda memiliki beberapa unduhan file di aplikasi Anda, mereka juga dapat rusak, karena ini. Dan Anda mungkin tidak menyadarinya, bahkan setelah bertahun-tahun, karena kebiasaan khusus untuk mengunduh tergantung pada server, browser, jenis dan isi file (dan mungkin beberapa faktor lain yang tidak ingin membuat Anda bosan) .

  5. Akhirnya, banyak kerangka kerja PHP termasuk Symfony , Zend dan Laravel (tidak disebutkan tentang ini dalam pedoman pengkodean tetapi mengikuti yang sesuai) dan standar PSR-2 (item 2.2) membutuhkan penghilangan tag penutup. Manual PHP itu sendiri ( 1 , 2 ), Wordpress , Drupal dan banyak perangkat lunak PHP lainnya saya kira, menyarankan untuk melakukannya. Jika Anda hanya membiasakan mengikuti standar (dan mengatur PHP-CS-Fixer untuk kode Anda), Anda bisa melupakan masalah ini. Kalau tidak, Anda akan selalu perlu menyimpan masalah dalam pikiran Anda.

Bonus: beberapa gotcha (sebenarnya saat ini satu) terkait dengan 2 karakter ini:

  1. Bahkan beberapa perpustakaan yang terkenal mungkin mengandung akhiran garis setelahnya ?>. Contohnya adalah Smarty, bahkan versi terbaru dari cabang 2. * dan 3. * memilikinya. Jadi, seperti biasa, perhatikan kode pihak ketiga . Bonus dalam bonus: Regex untuk menghapus akhir PHP yang tidak perlu: ganti (\s*\?>\s*)$dengan teks kosong di semua file yang berisi kode PHP.

Regex yang sedikit berbeda, saya gunakan untuk menemukan tag dengan Netbeans IDE, untuk dialog Find & Replace: \?>(?s:.){0,10}\Z Penjelasan singkat: changeset.hr/blog/miscellaneous/catch-near-eof-with-regex
frnhr

@Cek, ia menangkap teks apa saja - termasuk kode - yaitu 10 karakter atau kurang setelah ?>: misalnya cocok -dan akan dihapus- ?> Hellodi <?php echo "test"; ?> Hello. Kami ingin menghapus hanya tag penutup.
Halil Özgür

6
Lebih buruk lagi, apache 2.4.6 dengan PHP 5.4 sebenarnya kesalahan seg pada mesin produksi kami ketika ada ruang kosong di belakang tag penutup. Saya hanya membuang-buang waktu sampai saya akhirnya mempersempit bug dengan strace. Berikut adalah kesalahan yang apache melempar: [core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11).
Artem Russakovskii

3
@ INTPnerd Oh, pertanyaan dan sebagian besar jawaban merujuk pada hal header, jadi saya berasumsi siapa pun yang membaca utas ini akan memiliki ide tentang itu. Masalah mendasar dan penyebab sebenarnya dari masalah di banyak jawaban di sini adalah spasi putih yang tidak diperlukan setelah itu ?>, yang (sama seperti output apa pun) menyebabkan header dikirim segera setelah hasilnya. Tidak ada "header HTML" (selain <header>tag HTML5 yang tidak terkait ).
Halil Özgür

2
Ini harus bekerja, terlepas dari pengubah global: \ s * \?> \ S * \ Z Perhatikan '\ Z' di bagian akhir. Ini memastikan bahwa Anda menangkap tag penutup php jika dan hanya jika itu bukan spasi terakhir di bagian paling akhir file.
Erutan409

122

Alasan Anda harus meninggalkan tag penutup php ( ?>) adalah agar programmer tidak sengaja mengirim karakter baris baru tambahan.

Alasan Anda tidak boleh meninggalkan tag penutup php adalah karena hal itu menyebabkan ketidakseimbangan dalam tag php dan setiap programmer dengan pikiran setengah ingat untuk tidak menambahkan ruang putih tambahan.

Jadi untuk pertanyaan Anda:

Apakah ada alasan lain untuk melewatkan tag php penutup?

Tidak, tidak ada alasan bagus untuk melewatkan tag php penutup.

Saya akan menyelesaikan dengan beberapa argumen untuk tidak repot dengan tag penutup:

  1. Orang selalu dapat membuat kesalahan, tidak peduli seberapa pintar mereka. Mengikuti praktik yang mengurangi jumlah kemungkinan kesalahan adalah (IMHO) ide yang bagus.

  2. PHP bukan XML. PHP tidak perlu mematuhi standar ketat XML agar ditulis dengan baik dan fungsional. Jika tag penutup yang hilang mengganggu Anda, Anda diizinkan untuk menggunakan tag penutup, itu bukan aturan baku.


2
> programmer mana pun yang memiliki pikiran setengah sadar untuk tidak menambahkan ruang putih ekstra. Bahkan lebih baik lagi, pengembang mana pun yang memiliki 1/2 pikiran dapat menambahkan kait pra-komit ke SVC sehingga setiap ruang tambahan dihapus secara otomatis: tanpa ribut, tanpa masalah.
BryanH

6
@ BryanH, sampai Anda memiliki file di mana spasi spasi diperlukan, tapi itu sangat jarang.
zzzzBov

1
Kamu benar, tentu saja. Lihat jawaban mario untuk beberapa alternatif yang sangat keren.
BryanH

> "Alasan mengapa Anda tidak boleh meninggalkan tag penutup php adalah karena hal itu menyebabkan ketidakseimbangan dalam tag php dan setiap pemrogram dengan pikiran setengah hati ingat untuk tidak menambahkan ruang putih tambahan." Di Windows, mungkin. Pada sistem mirip UNIX, semua file diakhiri dengan \ n dan program menambahkannya untuk Anda. EDIT: Aha! Seperti dicatat di bawah oleh @mario, PHP memakannya, sebenarnya.
Andrea

2
Yang lebih penting lagi adalah bahwa bahkan programmer yang memiliki dua kali lipat pikiran adalah manusia dan melupakan sesuatu.
Sebastian Mach

57

Ini adalah rekomendasi gaya pengkodean pemula , bermaksud baik, dan disarankan oleh manual .

  • ?>Namun menjauhi memecahkan tetesan dari header umum sudah mengirim penyebab (output mentah, BOM , pemberitahuan, dll) dan masalah tindak lanjut mereka.

  • PHP sebenarnya mengandung beberapa sihir untuk memakan satu linebreak setelah ?>token penutup. Meskipun memiliki masalah bersejarah , dan membuat pendatang baru masih rentan terhadap editor yang tidak stabil dan menyeret secara tidak sengaja di ruang putih lain setelahnya ?>.

  • Secara gaya, beberapa pengembang lebih suka melihat <?phpdan ?>sebagai tag SGML / instruksi pemrosesan XML, menyiratkan konsistensi keseimbangan dari token close trailing. (Yang mana, berguna untuk dependensi-kelas penyertaan termasuk untuk menggantikan file-by-file yang tidak efisien.)

  • Agak jarang pembukaan <?phpditandai sebagai PHP shebang (dan sepenuhnya layak per binfmt_misc ), dengan demikian memvalidasi redundansi dari tag penutup yang sesuai.

  • Ada perbedaan yang jelas antara mandat panduan PHP sintaksis klasik?>\n dan yang lebih baru (PSR-2) menyetujui penghilangan.
    (Sebagai catatan: Zend Framework mendalilkan satu di atas yang lain tidak menyiratkan superioritas yang melekat. Ini adalah kesalahpahaman bahwa para ahli tertarik dengan / menargetkan audiens API yang sulit).

  • SCM dan IDE modern menyediakan solusi bawaan yang sebagian besar mengurangi pemeliharaan tag dekat.

Mencegah penggunaan ?>tag penutup hanya menunda menjelaskan perilaku pemrosesan PHP dasar dan semantik bahasa untuk menghindari masalah yang jarang terjadi. Masih praktis untuk pengembangan perangkat lunak kolaboratif karena variasi kecakapan peserta.

Tutup variasi tag

  • The reguler ?> tag dekat juga dikenal sebagai T_CLOSE_TAG, atau dengan demikian "dekat tanda".

  • Ini terdiri dari beberapa inkarnasi lagi, karena makan PHP newline ajaib :

    ?>\n (Unix linefeed)

    ?>\r (Pengembalian kereta, MAC klasik)

    ?>\r\n (CR / LF, di DOS / Menang)

    Namun PHP tidak mendukung kombinasi baris Unicode NEL(U + 0085).

    Versi PHP awal memiliki kompilasi-ins yang membatasi platform-agnostisisme IIRC (FI bahkan hanya digunakan >sebagai penanda dekat), yang kemungkinan merupakan asal historis penghindaran close-tag.

  • Sering diabaikan, tetapi sampai PHP7 menghapus mereka , biasa <?phptanda pembukaan dapat secara sah dipasangkan dengan jarang digunakan </script>sebagai tanda penutupan aneh .

  • " Hard close tag " bahkan bukan satu - hanya membuat istilah itu untuk analogi. Namun secara konseptual dan penggunaan __halt_compilerharus diakui sebagai token dekat.

    __HALT_COMPILER();
    ?>

    Yang pada dasarnya memiliki tokenizer, buang semua kode atau bagian HTML biasa sesudahnya. Khususnya PHAR bertopik memanfaatkan itu, atau kombinasi yang berlebihan dengan ?>seperti yang digambarkan.

  • Demikian juga void yangreturn; jarang menggantikan dalam skrip include, menjadikannya ?>dengan trailing spasi kosong tidak efektif.

  • Lalu ada semua jenis variasi tag penutup lunak / palsu ; kurang dikenal dan jarang digunakan, tetapi biasanya per token komentar :

    • Spasi sederhana // ? >untuk menghindari deteksi oleh tokenizer PHP.

    • Atau pengganti Unicode yang mewah // ﹖﹥(U + FE56 MARK PERTANYAAN KECIL, U + FE65 BRACKET KECIL KECIL) yang dapat dipahami oleh regexp.

    Keduanya tidak berarti apa-apa untuk PHP , tetapi dapat memiliki kegunaan praktis untuk toolkit eksternal yang tidak sadar PHP atau semi-aware. catSkrip-skrip yang bergabung lagi muncul di benak, dengan hasil // ? > <?phpgabungan yang sejalan-mempertahankan bagian sebelumnya file.

Jadi ada alternatif tergantung konteks tapi praktis untuk penghilangan tag penutup imperatif.

Penjagaan ?>tag dekat secara manual juga tidak terlalu kontemporer. Selalu ada alat otomatisasi untuk itu (bahkan jika hanya sed / awk atau regex-oneliners). Khususnya:

tag phptag tidier

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

Yang umumnya dapat digunakan untuk --unclosetag php untuk kode pihak ketiga, atau lebih tepatnya hanya memperbaiki (dan semua) masalah whitespace / BOM aktual:

  • phptags --warn --whitespace *.php

Ini juga menangani --longkonversi tag dll. Untuk kompatibilitas runtime / konfigurasi.


7
Ya, ungkapan yang tumpul DAN provokatif menarik downvotes. Dari apa yang saya baca dari waktu ke waktu, meninggalkan token penutup sama sekali tidak ada kerugian selama Anda tidak bekerja dengan perangkat lunak yang tidak bisa mengatasinya. Kecuali jika Anda benar-benar dapat membuktikan bahwa menghilangkan token penutupan adalah hal yang buruk dan sangat tidak perlu dilakukan, downvote saya tetap;)
jpeltoniemi

2
@Pichan: Saya akan mengizinkannya. Tapi saya kira Anda belum mengerti apa yang dikatakan di sini. Menghindari dan menghindari adalah dua hal yang berbeda. Dan masalah yang setengah terpecahkan adalah hasil dari nasihat minyak ular.
mario

6
@ Mario: Ini adalah rekomendasi gaya pengkodean pemula . Saya tidak setuju. Seluruh Kerangka Zend menghilangkan tag penutup. Saya pikir itu pilihan yang sangat pribadi, saya benar-benar lebih suka membiarkan <? Php saya dibuka dan saya tidak merasa pemula :)
Daniele Vrut

1
Bagaimana dengan HTML? Apakah itu dibutuhkan? Untuk contoh <?php if($var): ?>Hello World<?php endif; ?>??? Saya benar-benar ingin tahu karena tidak disebutkan secara spesifik.
WASasquatch

1
@Wasquatch Ya. Jika Anda beralih antara mode HTML dan PHP, maka Anda harus menutup token dalam hal apa pun. (Tidak terlalu relevan dengan pertanyaan asli di sini.)
mario

22

Itu bukan tag ...

Tetapi jika Anda memilikinya, Anda berisiko memiliki ruang putih setelahnya.

Jika kemudian Anda menggunakannya sebagai termasuk di bagian atas dokumen, Anda bisa memasukkan ruang kosong (yaitu konten) sebelum Anda mencoba mengirim header HTTP ... yang tidak diizinkan.


10
Jika itu bukan tag, apa itu?
danidacar

Bisakah Anda memberikan contoh? Mungkin konfigurasi php saya rusak, tetapi saya tidak dapat mereproduksi masalahnya.
danidacar

2
file1.php: <?php $i = 1; ?> lalu file2.php:<?php include 'file1.php'; header('Location: http://www.google.com');?>
Quentin

1
Ada juga kerugian output buffering; ia menggunakan lebih banyak memori di server (karena semua output harus disimpan dalam RAM sampai outputnya; tanpa buffering langsung saja). Ini juga sedikit lebih lambat. Tidak satu pun dari ini akan menjadi masalah dalam banyak kasus, tapi saya malas, jadi mengapa tidak membiarkan tag penutupnya? Saya menggunakan phpcsuntuk memastikan bahwa tag penutup dibiarkan setiap satu file saya dan kemudian saya tidak khawatir tentang buffering output :)
El Yobo

1
@danip: Jika Anda telah mengatur flag output_buffer dalam file konfigurasi php, Anda tidak dapat mereproduksi masalah ini.
Jichao

16

Sangat berguna untuk tidak membiarkan penutupan ?>.

File tetap valid untuk PHP (bukan kesalahan sintaksis) dan seperti @David Dorward mengatakan itu memungkinkan untuk menghindari memiliki spasi putih / break-line (apa pun yang dapat mengirim header ke browser) setelah ?>.

Sebagai contoh,

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

tidak akan valid

Tapi

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

akan.

Untuk sekali ini, Anda harus malas untuk merasa aman .


3
Itu sebabnya saya amankan dengan huruf miring. Ini mencegah Anda dari kesalahan yang mungkin menghabiskan banyak waktu untuk ruang yang tidak diinginkan setelah ?>. secure mungkin bukan kata yang baik di sini. Lagi pula, itu tidak memperbaiki apa-apa (itu bukan kode buruk bagi saya untuk mencegah hal-hal, di echosini akan menjadi kode yang buruk) tapi / dan itu masih valid. Buktikan saya salah tentang ini.
Shikiryu

Saya tidak memilih Anda, btw. Tapi maksud saya kompatibel dengan Anda. Itu tidak memperbaiki apa pun. Saya tidak pernah mengatakan itu tidak valid, jadi saya tidak perlu membuktikan apa pun.
Christian

1
Chouchenos, saya yakin Anda berarti aman, bukan aman. IMHO neg untuk itu terlalu banyak. Membawa Anda kembali ke titik awal. ;-) Anda tidak mengatakan hal yang salah. Bahkan pedoman pengembangan PHP mendorong Anda untuk melakukan itu. Sebenarnya jauh lebih baik untuk mengandalkan penghapusan tag penutup, daripada buffering output, misalnya. Yang terakhir akan seperti mengatur display_errors untuk dimatikan. Kecurangan murni. Dan kemungkinan besar aplikasi Anda tidak akan portabel. Saya benar-benar berpikir, sebagai aturan, lebih baik tidak mengandalkan buffering output sama sekali.
maraspin

1
Saya tidak ingin mempertanyakan orang-orang yang suka meletakkan ?>di akhir file php saja. tetapi apakah Anda pernah memiliki kebutuhan untuk men-debug beberapa kesalahan yang disebabkan oleh spasi tambahan? Juga tidak semua server dikonfigurasi dengan cara yang sama terutama ketika Anda pindah ke host lain, mengetahui bahwa kesalahan sangat memakan waktu. Jika Anda ingin menempatkan ?>lakukan saja, jika Anda juga menambahkan beberapa ruang tambahan dan tim Anda perlu men-debug yang siap menyalahkan git ^^
CoffeDeveloper

16

Menurut dokumen , lebih baik menghilangkan tag penutup jika ada di akhir file karena alasan berikut:

Jika file adalah kode PHP murni, lebih baik untuk menghilangkan tag penutup PHP di akhir file. Ini mencegah spasi atau baris baru yang tidak disengaja ditambahkan setelah tag penutup PHP, yang dapat menyebabkan efek yang tidak diinginkan karena PHP akan memulai buffering output ketika tidak ada niat dari programmer untuk mengirim output apa pun pada saat itu dalam skrip.

Manual PHP> Referensi Bahasa> Sintaks dasar> Tag PHP


10

Yah, saya tahu alasannya, tetapi saya tidak bisa menunjukkannya:

Untuk file yang hanya berisi kode PHP, tag penutup ( ?>) tidak pernah diizinkan. Itu tidak diperlukan oleh PHP, dan menghilangkannya mencegah injeksi tidak disengaja dari spasi putih ke dalam respons.

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


23
Tag yang "tidak pernah diizinkan" mungkin merupakan standar pengkodean Zend, tetapi itu bukan aturan sintaks untuk pemformatan file PHP.
Matt Huggins

9

Ya, ada dua cara untuk melihatnya.

  1. Kode PHP tidak lebih dari satu set instruksi pemrosesan XML , dan oleh karena itu file dengan .phpekstensi tidak lebih dari file XML yang kebetulan diuraikan untuk kode PHP.
  2. PHP kebetulan berbagi format instruksi pemrosesan XML untuk tag buka dan tutupnya. Berdasarkan hal itu, file dengan .phpekstensi MUNGKIN menjadi file XML yang valid, tetapi tidak perlu.

Jika Anda meyakini rute pertama, maka semua file PHP memerlukan tag penutup penutup. Untuk menghilangkannya akan membuat file XML tidak valid. Kemudian lagi, tanpa memiliki <?xml version="1.0" charset="latin-1" ?>deklarasi pembukaan , Anda tidak akan memiliki file XML yang valid ... Jadi itu bukan masalah besar ...

Jika Anda yakin dengan rute kedua, itu membuka pintu untuk dua jenis .phpfile:

  • File yang hanya berisi kode (misalnya file perpustakaan)
  • File yang berisi XML asli dan juga kode (file template misalnya)

Berdasarkan itu, file hanya kode OK untuk mengakhiri tanpa ?>tag penutup . Tetapi file kode XML tidak boleh berakhir tanpa penutup ?>karena itu akan membatalkan XML.

Tapi saya tahu apa yang Anda pikirkan. Anda berpikir apa bedanya, Anda tidak akan pernah merender file PHP secara langsung, jadi siapa yang peduli apakah itu XML yang valid. Ya, tidak masalah jika Anda mendesain templat. Jika itu XML / HTML yang valid, peramban normal tidak akan menampilkan kode PHP (diperlakukan seperti komentar). Jadi Anda dapat mengejek templat tanpa perlu menjalankan kode PHP dalam ...

Saya tidak mengatakan ini penting. Itu hanya pandangan yang tidak terlalu sering saya ungkapkan, jadi tempat apa yang lebih baik untuk membagikannya ...

Secara pribadi, saya tidak menutup tag dalam file perpustakaan, tetapi lakukan dalam file template ... Saya pikir itu adalah preferensi pribadi (dan pedoman pengkodean) berdasarkan lebih dari apa pun yang sulit ...


1
Ini sepenuhnya salah. PHP TIDAK menerjemahkan tag-tag itu ke XML, dan dengan demikian tidak ada ketidakseimbangan yang dihasilkan.
Drachenkatze

7
@Felicitus: Saya kira Anda melewatkan bagian yang mengatakan "Saya tidak mengatakan ini penting. Ini hanya pandangan yang saya tidak melihat terlalu sering diungkapkan, jadi tempat apa yang lebih baik untuk membaginya ..." Ini bukan tentang PHP menerjemahkan tag ke XML. Ini tentang apa yang terjadi ketika file diinterpretasikan dalam konteks XML (seperti HTML, atau editor, dll) ... Tetapi poin terjawab ...
ircmaxell

7

Selain semua yang telah dikatakan, saya akan memberikan alasan lain yang sangat menyebalkan bagi kami untuk melakukan debug.

Apache 2.4.6 dengan PHP 5.4 sebenarnya kesalahan segmentasi pada mesin produksi kami ketika ada ruang kosong di belakang phptag penutup . Saya hanya membuang-buang waktu sampai saya akhirnya mempersempit bug dengan strace .

Berikut adalah kesalahan yang dilemparkan Apache:

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

6

"Apakah ada alasan bagus lainnya (selain masalah header) untuk melewatkan tag php penutup?"

Anda tidak ingin secara tidak sengaja menampilkan karakter whitepace yang asing ketika menghasilkan keluaran biner, data CSV , atau keluaran non-HTML lainnya.


1
Saya punya klien yang mengeluh karena parser XML mereka menolak output kami ketika ada baris kosong tambahan di awal. Lebih buruk lagi, itu hanya terjadi pada satu server dari tujuh dengan garis tambahan setelah tag penutup dalam file konfigurasi yang tidak direvisi.
eswald

5

Pro

Cons

Kesimpulan

Saya akan mengatakan bahwa argumen yang mendukung menghilangkan tag terlihat lebih kuat (membantu menghindari sakit kepala besar dengan header () + ini adalah PHP / Zend "rekomendasi"). Saya akui bahwa ini bukan solusi paling "indah" yang pernah saya lihat dalam hal konsistensi sintaksis, tetapi apa yang bisa lebih baik?


2

Karena pertanyaan saya ditandai sebagai duplikat dari pertanyaan ini, saya pikir tidak masalah untuk memposting mengapa TIDAK menghilangkan tag penutup ?>karena beberapa alasan yang diinginkan.

  • Dengan Sintaks Instruksi Pemrosesan yang Lengkap ( <?php ... ?>) Sumber PHP adalah dokumen SGML yang valid, yang dapat diuraikan dan diproses tanpa masalah dengan pengurai SGML. Dengan batasan tambahan, itu juga bisa menjadi XML / XHTML yang valid.

Tidak ada yang mencegah Anda menulis kode XML / HTML / SGML yang valid. Dokumentasi PHP mengetahui hal ini. Kutipan:

Catatan: Perhatikan juga bahwa jika Anda menanamkan PHP ke dalam XML atau XHTML, Anda harus menggunakan tag <? Php?> Untuk tetap mematuhi standar.

Tentu saja sintaks PHP tidak ketat SGML / XML / HTML dan Anda membuat dokumen, yang bukan SGML / XML / HTML, sama seperti Anda dapat mengubah HTML menjadi XHTML menjadi XML compliant atau tidak.

  • Pada titik tertentu Anda mungkin ingin menggabungkan sumber. Ini tidak akan semudah melakukan hanya cat source1.php source2.phpjika Anda memiliki inkonsistensi yang diperkenalkan dengan menghilangkan ?>tag penutup .

  • Tanpa ?>lebih sulit untuk mengetahui apakah dokumen dibiarkan dalam mode pelarian PHP atau mode abaikan PHP (tag PI <?phpmungkin telah dibuka atau tidak). Hidup lebih mudah jika Anda secara konsisten meninggalkan dokumen dalam mode diabaikan PHP. Ini seperti bekerja dengan dokumen HTML yang diformat dengan baik dibandingkan dengan dokumen dengan tag yang tidak tertutup, bersarang buruk dll.

  • Tampaknya beberapa editor seperti Dreamweaver mungkin memiliki masalah dengan PI dibiarkan terbuka [1] .


0

Jika saya memahami pertanyaan dengan benar, itu ada hubungannya dengan buffering output dan pengaruhnya pada tag penutup / penutup. Saya tidak yakin itu adalah pertanyaan yang sepenuhnya valid. Masalahnya adalah bahwa buffer output tidak berarti semua konten disimpan dalam memori sebelum mengirimkannya ke klien. Itu berarti beberapa konten.

Pemrogram dapat dengan sengaja menyiram buffer, atau buffer output, jadi apakah opsi buffer output dalam PHP benar-benar mengubah bagaimana tag penutup mempengaruhi pengkodean? Saya berpendapat bahwa itu tidak benar.

Dan mungkin itu sebabnya sebagian besar jawaban kembali ke gaya pribadi dan sintaksis.


0

Ada 2 kemungkinan penggunaan kode php:

  1. Kode PHP seperti definisi kelas atau definisi fungsi
  2. Gunakan PHP sebagai bahasa templat (yaitu dalam tampilan)

dalam kasus 1. tag penutup benar-benar tidak berguna, juga saya ingin melihat hanya 1 (satu) tag buka php dan TIDAK (nol) tag penutup dalam kasus seperti itu. Ini adalah praktik yang baik karena membuat kode bersih dan memisahkan logika dari presentasi. Untuk kasus presentasi (2.) beberapa menemukan itu wajar untuk menutup semua tag (bahkan yang diproses PHP), yang mengarah ke confution, karena PHP sebenarnya memiliki 2 use case terpisah, yang tidak boleh dicampur: logika / kalkulus dan presentasi

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.