Tại sao một người bỏ qua thẻ đóng?

Tôi tiếp tục đọc nó là một thực tế kém để sử dụng thẻ đóng PHP ?>ở cuối tệp. Vấn đề tiêu đề dường như không liên quan trong bối cảnh sau (và đây là tranh luận tốt duy nhất cho đến nay):

Các phiên bản hiện đại của PHP đặt cờ output_buffering trong php.ini Nếu bật bộ đệm đầu ra, bạn có thể đặt tiêu đề HTTP và cookie sau khi xuất HTML vì mã trả về không được gửi đến trình duyệt ngay lập tức.

Mỗi cuốn sách thực hành tốt và wiki bắt đầu với 'quy tắc' này nhưng không ai đưa ra lý do chính đáng. Có một lý do tốt để bỏ qua thẻ PHP kết thúc?

Gửi tiêu đề sớm hơn khóa học bình thường có thể có hậu quả sâu rộng. Dưới đây chỉ là một vài trong số chúng tình cờ xuất hiện trong tâm trí tôi lúc này:

1. Mặc dù các bản phát hành PHP hiện tại có thể có bộ đệm đầu ra, các máy chủ sản xuất thực tế mà bạn sẽ triển khai mã của mình quan trọng hơn nhiều so với bất kỳ máy phát triển hoặc thử nghiệm nào. Và họ không luôn luôn có xu hướng theo các xu hướng PHP mới nhất ngay lập tức.

2. Bạn có thể đau đầu vì mất chức năng không thể giải thích . Giả sử, bạn đang triển khai một số loại cổng thanh toán và chuyển hướng người dùng đến một URL cụ thể sau khi bộ xử lý thanh toán xác nhận thành công. Nếu một số loại lỗi PHP, thậm chí là cảnh báo hoặc kết thúc dòng vượt quá xảy ra, thanh toán có thể vẫn chưa được xử lý và người dùng vẫn có thể không được thanh toán. Đây cũng là một trong những lý do tại sao chuyển hướng không cần thiết là xấu và nếu sử dụng chuyển hướng, nó phải được sử dụng một cách thận trọng.

3. Bạn có thể gặp loại lỗi "Tải trang bị hủy" trong Internet Explorer, ngay cả trong các phiên bản gần đây nhất. Điều này là do phản hồi AJAX / json bao gồm chứa thứ gì đó không nên chứa, vì các kết thúc dòng thừa trong một số tệp PHP, giống như tôi đã gặp vài ngày trước.

4. Nếu bạn có một số tệp tải xuống trong ứng dụng của mình, chúng cũng có thể bị hỏng, vì điều này. Và bạn có thể không nhận thấy điều đó, thậm chí sau nhiều năm, vì thói quen phá vỡ cụ thể của việc tải xuống phụ thuộc vào máy chủ, trình duyệt, loại và nội dung của tệp (và có thể một số yếu tố khác tôi không muốn làm bạn chán) .

5. Cuối cùng, nhiều khung công tác PHP bao gồm Symfony , Zend và Laravel (không có đề cập đến điều này trong hướng dẫn mã hóa nhưng nó tuân theo quy định) và tiêu chuẩn PSR-2 (mục 2.2) yêu cầu bỏ qua thẻ đóng. Bản thân hướng dẫn sử dụng PHP ( 1 , 2 ), Wordpress , Drupal và nhiều phần mềm PHP khác tôi đoán, khuyên nên làm như vậy. Nếu bạn chỉ đơn giản tạo thói quen tuân theo tiêu chuẩn (và thiết lập PHP-CS-Fixer cho mã của bạn), bạn có thể quên vấn đề. Nếu không, bạn sẽ luôn cần phải giữ vấn đề trong tâm trí của bạn.

Phần thưởng: một vài vấn đề (thực tế hiện tại là một) liên quan đến 2 nhân vật này:

1. Ngay cả một số thư viện nổi tiếng có thể chứa kết thúc dòng thừa sau ?>. Một ví dụ là Smarty, ngay cả các phiên bản gần đây nhất của cả hai nhánh 2. * và 3. * đều có cái này. Vì vậy, như mọi khi, xem mã bên thứ ba . Phần thưởng trong phần thưởng: Một regex để xóa các kết thúc PHP không cần thiết: thay thế (\s*\?>\s*)$bằng văn bản trống trong tất cả các tệp có chứa mã PHP.

Lý do bạn nên bỏ thẻ đóng php ( ?>) là để lập trình viên không vô tình gửi thêm ký tự dòng mới.

Lý do bạn không nên bỏ thẻ đóng php là vì nó gây ra sự mất cân bằng trong các thẻ php và bất kỳ lập trình viên nào có thể nhớ một nửa để không thêm khoảng trắng.

Vì vậy, cho câu hỏi của bạn:

Có một lý do tốt để bỏ qua thẻ php kết thúc?

Không, đó không phải là một lý do chính đáng để bỏ qua các thẻ php kết thúc.

Tôi sẽ kết thúc với một số đối số để không làm phiền với thẻ đóng:

1. Mọi người luôn có thể phạm sai lầm, bất kể họ thông minh đến đâu. Tuân thủ một thực tiễn làm giảm số lượng sai lầm có thể là (IMHO) là một ý tưởng tốt.

2. PHP không phải là XML. PHP không cần phải tuân thủ các tiêu chuẩn nghiêm ngặt của XML để được viết tốt và có chức năng. Nếu thẻ đóng bị thiếu làm phiền bạn, bạn được phép sử dụng thẻ đóng, đó không phải là quy tắc cài đặt theo cách này hay cách khác.

Đó là một đề xuất về phong cách mã hóa cho người mới , có thiện chí và được hướng dẫn sử dụng .

• ?>Tuy nhiên, Eschewing chỉ giải quyết được một phần nhỏ các tiêu đề phổ biến đã được gửi đi (đầu ra thô, BOM , thông báo, v.v.) và các vấn đề tiếp theo của chúng.

• PHP thực sự có chứa một số phép thuật để ăn hết các ngắt dòng đơn sau khi ?>mã thông báo đóng. Mặc dù có vấn đề lịch sử , và khiến những người mới đến vẫn dễ bị các biên tập viên dễ xáo trộn và xáo trộn bất thường trong các khoảng trắng khác sau đó ?>.

• Về mặt phong cách, một số nhà phát triển thích xem <?phpvà ?>như các thẻ SGML / hướng dẫn xử lý XML, ngụ ý tính nhất quán cân bằng của mã thông báo gần. (Mà btw, rất hữu ích cho lớp liên kết phụ thuộc bao gồm để thay thế tự động tải từng tệp không hiệu quả.)

• Hơi khác thường mở <?phpđược mô tả như PHPs công việc (và khả thi đầy đủ mỗi binfmt_misc ), qua đó chứng thực dư thừa của một thẻ đóng tương ứng.

• Có một sự khác biệt về lời khuyên rõ ràng giữa các hướng dẫn cú pháp PHP cổ điển bắt buộc ?>\nvà các hướng dẫn gần đây hơn (PSR-2) đồng ý về thiếu sót.
  (Đối với bản ghi: Zend Framework đưa ra cái khác không bao hàm ưu thế vốn có của nó. Đó là một quan niệm sai lầm rằng các chuyên gia đã bị thu hút / nhắm mục tiêu đối tượng của các API khó sử dụng).

• SCM và IDE hiện đại cung cấp các giải pháp dựng sẵn chủ yếu làm giảm bớt việc chăm sóc thẻ gần.

Không khuyến khích bất kỳ việc sử dụng ?>thẻ đóng chỉ làm chậm trễ việc giải thích hành vi xử lý PHP cơ bản và ngữ nghĩa ngôn ngữ đối với các vấn đề không thường xuyên. Đó là thực tế vẫn còn cho phát triển phần mềm hợp tác do sự thay đổi thành thạo trong người tham gia.

Đóng các biến thể thẻ

• Các thường xuyên ?> tag gần còn được gọi là T_CLOSE_TAG, hoặc do "gần hiệụ bài".

• Nó bao gồm một vài hóa thân nữa, bởi vì ăn uống ma thuật mới của PHP :

  ?>\n (Nguồn cấp dữ liệu Unix)

  ?>\r (Vận chuyển trở lại, MAC cổ điển)

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

  Tuy nhiên, PHP không hỗ trợ ngắt dòng kết hợp Unicode NEL(U + 0085).

  Các phiên bản PHP ban đầu có phần mềm biên dịch giới hạn nền tảng của IIRC phần nào (FI thậm chí chỉ được sử dụng >như một điểm đánh dấu gần), đây là nguồn gốc lịch sử của việc tránh thẻ gần.

• Thường bị bỏ qua, nhưng cho đến khi PHP7 loại bỏ chúng , <?phpmã thông báo mở thông thường có thể được ghép nối hợp lệ với mã thông báo đóng hiếm khi được sử dụng </script>làm mã thông báo đóng lẻ .

• " Thẻ đóng cứng " thậm chí không phải là một - chỉ tạo ra thuật ngữ tương tự. __halt_compilerTuy nhiên, theo quan niệm và cách sử dụng nên được công nhận là mã thông báo gần.

  __HALT_COMPILER();
  ?>

  Về cơ bản, mã thông báo sẽ loại bỏ bất kỳ mã hoặc phần HTML đơn giản nào sau đó. Cụ thể, các cuống PHAR sử dụng điều đó hoặc kết hợp dự phòng của nó với ?>như mô tả.

• Tương tự như vậy, một khoảng trốngreturn; thường xuyên thay thế trong các tập lệnh bao gồm, hiển thị bất kỳ ?>với khoảng trắng theo sau không có tác dụng.

• Sau đó, có tất cả các loại biến thể thẻ mềm / giả ; ít được biết đến và hiếm khi được sử dụng, nhưng thường là trên mỗi mã thông báo nhận xét :

  • Khoảng cách đơn giản // ? >để tránh sự phát hiện bằng mã thông báo PHP.

  • Hoặc các sản phẩm thay thế Unicode ưa thích // ﹖﹥(U + FE56 NHỎ CÂU HỎI NHỎ, U + FE65 BRACKET NHỎ) mà một regrec có thể nắm bắt được.

  Cả hai đều không có ý nghĩa gì với PHP , nhưng có thể có những cách sử dụng thực tế cho các bộ công cụ bên ngoài không biết hoặc bán nhận biết PHP. Các catkịch bản liên kết lại xuất hiện trong tâm trí, với các kết quả // ? > <?phpnối tiếp mà giữ nguyên phân đoạn tệp cũ.

Vì vậy, có những sự thay thế phụ thuộc vào ngữ cảnh nhưng thực tế cho một thiếu sót thẻ gần bắt buộc.

Cách giữ trẻ bằng tay của ?>các thẻ đóng không phải là rất hiện đại. Luôn có các công cụ tự động hóa cho điều đó (ngay cả khi chỉ là sed / awk hoặc regex-oneliners). Đặc biệt:

thẻ phptags tidier

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

Mà thường có thể được sử dụng cho --unclosecác thẻ php cho mã của bên thứ ba, hoặc chỉ sửa chữa bất kỳ (và tất cả) các vấn đề khoảng trắng / BOM thực tế:

• phptags --warn --whitespace *.php

Nó cũng xử lý --longchuyển đổi thẻ, vv để tương thích với thời gian chạy / cấu hình.

Nó không phải là một thẻ tag

Nhưng nếu bạn có nó, bạn có nguy cơ có khoảng trắng sau nó.

Sau đó, nếu bạn sử dụng nó như một phần bao gồm ở đầu tài liệu, bạn có thể sẽ chèn khoảng trắng (nghĩa là nội dung) trước khi bạn cố gửi tiêu đề HTTP mà không được phép.

Nó khá hữu ích để không đóng cửa ?>.

Tệp vẫn hợp lệ với PHP (không phải lỗi cú pháp) và như @David Dorward nói rằng nó cho phép tránh có khoảng trắng / ngắt dòng (bất cứ thứ gì có thể gửi tiêu đề tới trình duyệt) sau ?>.

Ví dụ,

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

sẽ không có giá trị.

Nhưng

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

sẽ.

Để một lần, bạn phải lười biếng để được an toàn .

Theo các tài liệu , tốt hơn là bỏ qua thẻ đóng nếu nó ở cuối tệp vì lý do sau:

Nếu một tệp là mã PHP thuần túy, tốt hơn là bỏ qua thẻ đóng PHP ở cuối tệp. Điều này ngăn chặn khoảng trắng ngẫu nhiên hoặc các dòng mới được thêm vào sau thẻ đóng PHP, điều này có thể gây ra các hiệu ứng không mong muốn vì PHP sẽ bắt đầu đệm đầu ra khi lập trình viên không gửi bất kỳ đầu ra nào tại điểm đó trong tập lệnh.

Hướng dẫn PHP> Tham khảo ngôn ngữ> Cú pháp cơ bản> Thẻ PHP

Chà, tôi biết lý do, nhưng tôi không thể chỉ ra:

Đối với các tệp chỉ chứa mã PHP, thẻ đóng ( ?>) không bao giờ được phép. Nó không được yêu cầu bởi PHP và bỏ qua nó ngăn chặn việc vô tình tiêm dấu trắng vào phản hồi.

Nguồn: http://framework.zend.com/manual/en/coding-st Chuẩn.php-file-formatted.html

Vâng, có hai cách nhìn vào nó.

1. Mã PHP không có gì khác hơn là một tập hợp các hướng dẫn xử lý XML và do đó, bất kỳ tệp nào có .phpphần mở rộng không gì khác hơn là một tệp XML chỉ xảy ra để được phân tích cú pháp cho mã PHP.
2. PHP chỉ tình cờ chia sẻ định dạng hướng dẫn xử lý XML cho các thẻ mở và đóng của nó. Dựa vào đó, các tệp có .phpphần mở rộng CÓ THỂ là các tệp XML hợp lệ, nhưng chúng không cần phải như vậy.

Nếu bạn tin tuyến đầu tiên, thì tất cả các tệp PHP đều yêu cầu đóng các thẻ kết thúc. Để bỏ qua chúng sẽ tạo một tệp XML không hợp lệ. Sau đó, một lần nữa, không có khai <?xml version="1.0" charset="latin-1" ?>báo mở , dù sao bạn cũng sẽ không có tệp XML hợp lệ ... Vì vậy, đây không phải là vấn đề chính ...

Nếu bạn tin tuyến đường thứ hai, điều đó sẽ mở ra cơ hội cho hai loại .phptệp:

• Các tệp chỉ chứa mã (ví dụ: tệp thư viện)
• Các tệp chứa XML nguyên gốc và cả mã (ví dụ: tệp mẫu)

Dựa vào đó, các tệp chỉ có mã là OK để kết thúc mà không cần ?>thẻ đóng . Nhưng các tệp mã XML không thể kết thúc mà không đóng ?>vì nó sẽ làm mất hiệu lực XML.

Nhưng tôi biết bạn đang nghĩ gì. Bạn đang nghĩ vấn đề là gì, bạn sẽ không bao giờ kết xuất trực tiếp một tệp PHP, vì vậy ai quan tâm nếu đó là XML hợp lệ. Vâng, nó không thành vấn đề nếu bạn đang thiết kế một mẫu. Nếu đó là XML / HTML hợp lệ, một trình duyệt bình thường sẽ không hiển thị mã PHP (nó được coi như một nhận xét). Vì vậy, bạn có thể giả lập mẫu mà không cần chạy mã PHP trong ...

Tôi không nói điều này là quan trọng. Đó chỉ là một quan điểm mà tôi không thấy được thể hiện quá thường xuyên, vì vậy nơi nào tốt hơn để chia sẻ nó ...

Cá nhân, tôi không đóng các thẻ trong các tệp thư viện, nhưng thực hiện trong các tệp mẫu ... Tôi nghĩ rằng đó là một sở thích cá nhân (và hướng dẫn mã hóa) dựa trên nhiều thứ khó hơn ...

Ngoài tất cả những gì đã được nói, tôi sẽ đưa ra một lý do khác là một nỗi đau rất lớn để chúng tôi gỡ lỗi.

Apache 2.4.6 với PHP 5.4 thực sự có lỗi phân đoạn trên các máy sản xuất của chúng tôi khi có khoảng trống phía sau phpthẻ đóng . Tôi chỉ lãng phí giờ cho đến khi cuối cùng tôi đã thu hẹp xuống lỗi với strace .

Đây là lỗi mà Apache ném ra:

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

"Có một lý do chính đáng nào khác (ngoài vấn đề tiêu đề) để bỏ qua thẻ php kết thúc không?"

Bạn không muốn vô tình xuất các ký tự dấu trắng bên ngoài khi tạo đầu ra nhị phân, dữ liệu CSV hoặc đầu ra không phải HTML khác.

Ưu

• Sẽ là hợp lý để đóng bất kỳ thẻ mở , như với các ngôn ngữ khác. Không chỉ các thẻ X (HT) ML, mà cả dấu ngoặc nhọn, dấu ngoặc ...
• Ít gây nhầm lẫn cho người mới bắt đầu .

Nhược điểm

• Tránh đau đầu với việc thêm các khoảng trắng vô tình sau thẻ đóng, vì nó phá vỡ hành vi chức năng tiêu đề () ... Một số trình  soạn thảo hoặc máy khách / máy chủ FTP cũng được biết là tự động thay đổi phần cuối của tệp (ít nhất, đó là cấu hình mặc định của chúng)
• Hướng dẫn sử dụng PHP cho biết thẻ đóng là tùy chọn và Zend thậm chí còn cấm nó .

Phần kết luận

Tôi sẽ nói rằng các đối số ủng hộ việc bỏ qua thẻ trông mạnh mẽ hơn (giúp tránh đau đầu lớn với tiêu đề () + đó là "đề xuất" PHP / Zend). Tôi thừa nhận rằng đây không phải là giải pháp "đẹp nhất" mà tôi từng thấy về tính nhất quán cú pháp, nhưng điều gì có thể tốt hơn?

Vì câu hỏi của tôi được đánh dấu là trùng lặp với câu hỏi này, tôi nghĩ sẽ ổn khi đăng lý do tại sao KHÔNG bỏ qua thẻ đóng ?>có thể vì một số lý do mong muốn.

• Với Hướng dẫn xử lý hoàn chỉnh <?php ... ?>Nguồn cú pháp ( ) Nguồn PHP là tài liệu SGML hợp lệ, có thể được phân tích cú pháp và xử lý mà không gặp vấn đề với trình phân tích cú pháp SGML. Với các hạn chế bổ sung, nó cũng có thể là XML / XHTML hợp lệ.

Không có gì ngăn cản bạn viết mã XML / HTML / SGML hợp lệ. Tài liệu PHP nhận thức được điều này. Trích đoạn:

Lưu ý: Cũng lưu ý rằng nếu bạn nhúng PHP trong XML hoặc XHTML, bạn sẽ cần sử dụng các thẻ <? Php?> Để duy trì tuân thủ các tiêu chuẩn.

Tất nhiên cú pháp PHP không nghiêm ngặt SGML / XML / HTML và bạn tạo một tài liệu, không phải SGML / XML / HTML, giống như bạn có thể biến HTML thành XHTML để tuân thủ XML hay không.

• Tại một số điểm bạn có thể muốn nối các nguồn. Điều này sẽ không dễ dàng như chỉ đơn giản là làm cat source1.php source2.phpnếu bạn có sự không nhất quán được giới thiệu bằng cách bỏ qua ?>các thẻ đóng .

• Không có ?>gì khó khăn hơn để biết liệu tài liệu có bị bỏ lại trong chế độ thoát PHP hay chế độ bỏ qua PHP (thẻ PI <?phpcó thể đã được mở hay không). Cuộc sống sẽ dễ dàng hơn nếu bạn liên tục để các tài liệu của mình ở chế độ bỏ qua PHP. Nó giống như làm việc với các tài liệu HTML được định dạng tốt so với các tài liệu có thẻ không được tiết lộ, lồng nhau xấu, v.v.

• Có vẻ như một số biên tập viên như Dreamweaver có thể có vấn đề với PI bị bỏ ngỏ [1] .

Nếu tôi hiểu chính xác câu hỏi, nó phải thực hiện với bộ đệm đầu ra và ảnh hưởng này có thể có trên các thẻ đóng / kết thúc. Tôi không chắc đó là một câu hỏi hoàn toàn hợp lệ. Vấn đề là bộ đệm đầu ra không có nghĩa là tất cả nội dung được lưu giữ trong bộ nhớ trước khi gửi nó ra máy khách. Nó có nghĩa là một số nội dung là.

Lập trình viên có thể cố tình xóa bộ đệm hoặc bộ đệm đầu ra để tùy chọn bộ đệm đầu ra trong PHP thực sự thay đổi cách thẻ đóng ảnh hưởng đến mã hóa? Tôi sẽ tranh luận rằng nó không.

Và có lẽ đó là lý do tại sao hầu hết các câu trả lời đã trở lại phong cách và cú pháp cá nhân.

Có 2 cách sử dụng mã php:

1. Mã PHP như định nghĩa lớp hoặc định nghĩa hàm
2. Sử dụng PHP làm ngôn ngữ mẫu (nghĩa là trong chế độ xem)

trong trường hợp 1. thẻ đóng hoàn toàn không chính xác, tôi cũng muốn thấy chỉ 1 (một) thẻ mở php và thẻ đóng NO (không) trong trường hợp như vậy. Đây là một thực hành tốt vì nó làm cho mã sạch và tách biệt logic khỏi cách trình bày. Đối với trường hợp trình bày (2.) một số người thấy việc đóng tất cả các thẻ (ngay cả những thẻ được xử lý PHP) là điều tự nhiên, dẫn đến sự nhầm lẫn, vì thực tế PHP có 2 trường hợp sử dụng riêng biệt, không nên trộn lẫn: logic / tính toán và thuyết trình