Czy dopuszczalne są krótkie tagi PHP?

Oto informacje zgodnie z oficjalną dokumentacją :

Istnieją cztery różne pary otwierających i zamykających znaczników, których można używać w PHP. Dwa z nich, <?php ?> i <script language="php"> </script>są zawsze dostępne. Pozostałe dwa są krótkimi znacznikami i znacznikami stylu ASP i można je włączać i wyłączać z pliku konfiguracyjnego php.ini. W związku z tym, chociaż niektórzy uważają, że krótkie tagi i tagi stylu ASP są wygodne, są one mniej przenośne i generalnie nie są zalecane .

Z mojego doświadczenia wynika , że większość serwerów ma włączone krótkie tagi. Pisanie na maszynie

<?=

jest o wiele wygodniejszy niż pisanie

<?php echo 

Wygoda programistów jest ważnym czynnikiem, więc dlaczego nie są zalecane?

Nie są zalecane, ponieważ jest to PITA, jeśli kiedykolwiek będziesz musiał przenieść swój kod na serwer, na którym nie jest obsługiwany (i nie możesz go włączyć). Jak mówisz, wiele wspólnych gospodarzy zrobić shorttags wsparcia, ale „wiele” to nie wszystkie z nich. Jeśli chcesz udostępnić swoje skrypty, najlepiej użyć pełnej składni.

Zgadzam się, że <?i <?=są łatwiejsze niż na programistów <?phpi <?php echoale jest to możliwe do zrobienia większość znajdź i zastąp tak długo, jak korzystać z tego samego formularza za każdym razem (i nie rzucić w przestrzeniach (np: <? phplub <? =)

W ogóle nie kupuję czytelności za przyczynę. Większość poważnych programistów ma możliwość podświetlania składni.

Jak wspomina ThiefMaster w komentarzach, od PHP 5.4 <?= ... ?>tagi są obsługiwane wszędzie, niezależnie od ustawień skrótów . To powinno oznaczać, że można je bezpiecznie używać w przenośnym kodzie, ale to oznacza, że ​​istnieje zależność od PHP 5.4+. Jeśli chcesz obsługiwać wersję starszą niż 5.4 i nie możesz zagwarantować skrótów, nadal musisz użyć <?php echo ... ?>.

Musisz także wiedzieć, że znaczniki ASP <%,%>, <% = i znacznik skryptu są usuwane z PHP 7 . Jeśli więc chcesz obsługiwać długoterminowy przenośny kod i chcesz przejść do najnowocześniejszych narzędzi, rozważ zmianę tej części kodu.

Jestem zbyt lubi, <?=$whatever?>aby odpuścić. Nigdy nie miałam z tym problemu. Poczekam, aż ugryzie mnie w tyłek. Z całą powagą 85% (moich) klientów ma dostęp do php.ini w rzadkich przypadkach, gdy są oni wyłączani. Pozostałe 15% korzysta z głównych dostawców hostingu i praktycznie wszyscy mają ich włączonych. Kocham ich.

Począwszy od PHP 5.4, skrót echa jest zagadnieniem odrębnym od krótkich znaczników, ponieważ skrót echa zawsze będzie włączony. To teraz fakt:

• Wersja SVN autorstwa Rasmus Lerdorf
• Dyskusja o liście mailowej

Tak więc sam skrót echa ( <?=) jest teraz bezpieczny.

Problem z całą tą dyskusją polega na wykorzystaniu PHP jako języka szablonów. Nikt nie twierdzi, że w plikach źródłowych aplikacji należy stosować tagi.

Jednak wbudowana składnia PHP pozwala na użycie jej jako potężnego języka szablonów, a szablony powinny być tak proste i czytelne, jak to możliwe. Wiele osób uważa, że ​​łatwiej jest używać znacznie wolniejszego, dodatkowego silnika szablonów, takiego jak Smarty, ale dla tych purystów wśród nas, którzy wymagają szybkiego renderowania i czystej bazy kodu, PHP jest jedynym sposobem pisania szablonów.

Jedynym poprawnym argumentem PRZECIWKO użyciu krótkich tagów jest to, że nie są one obsługiwane na wszystkich serwerach. Komentarze na temat konfliktów z dokumentami XML są absurdalne, ponieważ prawdopodobnie nie powinieneś mieszać PHP i XML; a jeśli tak, powinieneś używać PHP do wyprowadzania ciągów tekstu. Bezpieczeństwo nigdy nie powinno stanowić problemu, ponieważ jeśli umieszczasz poufne informacje, takie jak poświadczenia dostępu do bazy danych, w plikach szablonów, to masz większe problemy!

Teraz, jeśli chodzi o obsługę serwerów, trzeba przyznać, że należy być świadomym ich platformy docelowej. Jeśli hosting współdzielony jest prawdopodobnym celem, należy unikać krótkich tagów. Ale dla wielu profesjonalnych programistów (takich jak ja) klient przyjmuje (i faktycznie zależy od tego), że będziemy dyktować wymagania dotyczące serwera. Często jestem odpowiedzialny za samodzielne konfigurowanie serwera.

I NIGDY nie współpracujemy z dostawcą hostingu, który nie daje nam absolutnej kontroli nad konfiguracją serwera - w takim przypadku moglibyśmy liczyć na znacznie więcej problemów niż tylko utratę obsługi krótkich tagów. To się po prostu nie zdarza.

Tak więc - zgadzam się, że użycie krótkich tagów powinno być dokładnie rozważone. Ale głęboko wierzę również, że ZAWSZE powinna to być opcja i że programista, który jest świadomy swojego środowiska, powinien swobodnie z nich korzystać.

Krótkie tagi powracają dzięki Zend Framework wypychając „ PHP jako język szablonów ” w ich domyślnej konfiguracji MVC . Nie rozumiem, o co chodzi w debacie, większość oprogramowania, które wytworzysz w ciągu swojego życia, będzie działało na serwerze, który kontrolujesz ty lub twoja firma. Dopóki będziesz konsekwentny, nie powinno być żadnych problemów.

AKTUALIZACJA

Po sporo pracy z Magento , który używa długiej formy. W rezultacie przeszedłem na długą formę:

<?php and <?php echo

nad

<? and <?=

Wydaje się, że niewielka ilość pracy zapewnia interoperacyjność.

Ponieważ zamieszanie może generować z deklaracjami XML. Jednak wiele osób się z tobą zgadza .

Dodatkową troską jest ból, który spowodowałby kodowanie wszystkiego za pomocą krótkich tagów, aby na końcu dowiedzieć się, że końcowy serwer hostingowy je wyłączył ...

Oto wspaniały schemat tego samego:

Źródło: podobne pytanie dotyczące wymiany stosów inżynierii oprogramowania

http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php zawiera wiele porad, w tym:

chociaż niektórzy uważają, że krótkie tagi i tagi stylu ASP są wygodne, są mniej przenośne i generalnie nie są zalecane.

i

pamiętaj, że jeśli osadzasz PHP w XML lub XHTML, będziesz musiał użyć <?php ?>tagów, aby zachować zgodność ze standardami.

i

Należy unikać używania krótkich tagów podczas tworzenia aplikacji lub bibliotek przeznaczonych do redystrybucji lub wdrażania na serwerach PHP, które nie są pod twoją kontrolą, ponieważ krótkie tagi mogą nie być obsługiwane na serwerze docelowym. W przypadku przenośnego, redystrybucyjnego kodu pamiętaj, aby nie używać krótkich tagów.

Jeśli ktoś nadal zwraca na to uwagę ... Od wersji PHP 5.4.0 Alpha 1 <?=jest zawsze dostępna:

http://php.net/releases/NEWS_5_4_0_alpha1.txt

Wygląda więc na to, że krótkie tagi są (a) dopuszczalne i (b) są tutaj. Na razie przynajmniej ...

• Krótkie tagi nie są domyślnie włączone na niektórych serwerach WWW (hosty współdzielone itp.), Więc przenoszenie kodu staje się problemem, jeśli musisz przejść na jeden z nich.

• Czytelność może stanowić problem dla niektórych. Wielu programistów może zauważyć, że <?phpprzyciąga wzrok jako bardziej oczywisty znacznik początku bloku kodu niż <?podczas skanowania pliku, szczególnie jeśli utkniesz w bazie kodu z HTML i PHP ściśle splecionymi.

Uwaga: Począwszy od PHP 5.4 krótki znacznik <?=, jest teraz zawsze dostępny.

Przeczytałem tę stronę po poszukiwaniu informacji na ten temat i uważam, że nie wspomniano o jednym głównym problemie: lenistwo a konsekwencja. „Prawdziwe” tagi dla PHP to <? Php i?>. Dlaczego? Nie obchodzi mnie to. Dlaczego miałbyś chcieć użyć czegoś innego, skoro są one wyraźnie dla PHP? <% i%> oznaczają dla mnie ASP, a <skrypt ..... oznacza Javascript (w większości przypadków). Więc dla spójności, szybkiego uczenia się, przenośności i prostoty, dlaczego nie trzymać się standardu?

Z drugiej strony zgadzam się, że krótkie tagi w szablonach (i TYLKO w szablonach) wydają się przydatne, ale problem polega na tym, że poświęciliśmy tyle czasu na omawianie ich tutaj, że prawdopodobnie zajęłoby to bardzo dużo czasu tyle czasu wpisując dodatkowe trzy znaki „php” !!

Chociaż posiadanie wielu opcji jest przyjemne, nie jest wcale logiczne i może powodować problemy. Wyobraź sobie, że każdy język programowania dopuszcza 4 lub więcej typów tagów: JavaScript może być <JS lub <skrypt .... lub <% lub <? JS .... czy to by było pomocne? W przypadku PHP kolejność analizowania jest na korzyść pozwalania na te rzeczy, ale język na wiele innych sposobów nie jest elastyczny: rzuca uwagi lub błędy na najmniejszą niespójność, jednak często używane są krótkie tagi. A gdy na serwerze, który ich nie obsługuje, używane są krótkie tagi, ustalenie, co jest nie tak, może zająć bardzo dużo czasu, ponieważ w niektórych przypadkach nie występuje błąd.

Wreszcie, nie sądzę, że problem stanowią krótkie tagi: istnieją tylko dwa logiczne typy bloków kodu PHP: 1) zwykły kod PHP, 2) echa szablonu. W przypadku tych pierwszych mocno wierzę, że tylko <? Php i?> Powinny być dozwolone, aby zachować wszystko spójne i przenośne. W tym drugim przypadku metoda <? = $ Var?> Jest brzydka. Dlaczego tak musi być? Dlaczego nie dodać czegoś bardziej logicznego? <? php $ var?> To by nic nie zrobiło (i tylko w najbardziej odległych możliwościach mogłoby kolidować z czymś), a to z łatwością zastąpiłoby niezręczną składnię <? =. Lub jeśli jest to problem, być może mogliby użyć <? Php = $ var?> I nie martwić się niespójnościami.

W miejscu, w którym istnieją 4 opcje otwierania i zamykania tagów oraz losowego dodawania specjalnego znacznika „echo”, PHP może również mieć flagę „niestandardowe tagi otwieranie / zamykanie” w php.ini lub .htaccess. W ten sposób projektanci mogą wybrać ten, który najbardziej im się podoba. Ale z oczywistych powodów to przesada. Dlaczego więc dopuszczać opcje 4+?

Dobrze jest ich używać podczas pracy ze strukturą MVC lub CMS, które mają osobne pliki widoków.
Jest szybki, mniej kodu, nie jest mylący dla projektantów. Upewnij się tylko, że konfiguracja serwera pozwala na ich użycie.

Trochę inna jest sytuacja przy opracowywaniu aplikacji CodeIgniter . CodeIgniter wydaje się używać skrótów za każdym razem, gdy PHP jest używane w szablonie / widoku, w przeciwnym razie w modelach i kontrolerach zawsze używa długich znaczników. Nie jest to twarda i szybka reguła w frameworku, ale w przeważającej części frameworka i wiele źródeł innych zastosowań jest zgodnych z tą konwencją.

Moje dwa centy? Jeśli nigdy nie planujesz uruchamiać kodu w innym miejscu, użyj go, jeśli chcesz. Wolałbym nie przeprowadzać masowych poszukiwań i zastępować, kiedy zdaję sobie sprawę, że to głupi pomysł.

<?jest domyślnie wyłączony w nowszych wersjach. Możesz włączyć to tak, jak opisano Włączanie krótkich tagów w PHP .

Ludzie IMHO, którzy używają krótkich tagów, często zapominają uciec od tego, co odbijają. Byłoby miło mieć silnik szablonów, który domyślnie ucieka. Wierzę, że Rob A napisał szybki hack, aby uciec przed krótkimi tagami w aplikacjach Zend Frameworks. Jeśli lubisz krótkie tagi, ponieważ ułatwia to czytanie PHP. Czy Smarty może być lepszym rozwiązaniem?

{$myString|escape}

dla mnie to wygląda lepiej niż

<?= htmlspecialchars($myString) ?> 

Trzeba zapytać, jaki jest sens używania krótkich tagów.

Szybsze pisanie

MDCore powiedział:

<?= jest o wiele wygodniejszy niż pisanie <?php echo

Tak to jest. Zaoszczędzasz konieczności wpisywania 7 znaków * X razy w swoich skryptach.

Jednak, kiedy skrypt zajmuje godzinę, 10 godzin lub więcej, aby zaprojektować, rozwinąć i napisać, jak istotne jest, aby kilka sekund nie wpisywało tych 7 znaków tu i tam przez czas trwania skryptu?

W porównaniu do możliwości niektórych podstawowych lub wszystkich skryptów, które nie działają, jeśli krótkie tagi nie są włączone lub są włączone, ale aktualizacja lub ktoś zmieniający konfigurację pliku / serwera ini zatrzymuje je, inne potencjały.

Niewielka korzyść, którą zyskujesz, nie jest prawie równa z ciężkością potencjalnych problemów, to znaczy, że twoja strona nie działa, lub gorzej, tylko niektóre jej części nie działają, a zatem ból głowy do rozwiązania.

Łatwiejszy do odczytania

To zależy od znajomości .
Zawsze widziałem i używałem <?php echo. Chociaż <?=nie jest trudny do odczytania, nie jest mi znany i dlatego nie jest łatwiejszy do odczytania .

A czy przy podzieleniu programisty front-end / back-end (jak w przypadku większości firm) programista front-end pracujący na tych szablonach byłby bardziej znany, wiedząc, że <?=jest to równoznaczne z „otwartym tagiem PHP i echem”?
Powiedziałbym, że najbardziej byłoby wygodniej z logicznym. To znaczy, wyraźny otwarty tag PHP, a następnie to, co się dzieje „echo” - <?php echo.

Ocena ryzyka
Problem = cały skrypt lub podstawowe skrypty nie działają;

Potencjał problemu jest bardzo niski + dotkliwość wyniku jest bardzo wysoka = wysokie ryzyko

Wniosek

Zaoszczędzisz kilka sekund tu i tam, bez konieczności wpisywania kilku znaków, ale ryzykujesz za to wiele, a także prawdopodobnie stracisz czytelność.

Przednia lub tylna end koderzy znane ze <?=są bardziej prawdopodobne, aby zrozumieć <?php echo, jak oni standardowych rzeczy PHP - Standardowy <?phptagu otwarte i bardzo dobrze znany „echo”.
(Nawet kodery front-endowe powinny znać „echo” lub po prostu nie będą pracować na żadnym kodzie obsługiwanym przez framework).

Podczas gdy odwrotność nie jest tak prawdopodobna, ktoś nie może logicznie wywnioskować, że znak równości na krótkim znaczniku PHP to „echo”.

Spojrzmy prawdzie w oczy. PHP jest brzydki jak diabli bez krótkich tagów.

Możesz włączyć je w .htaccesspliku, jeśli nie możesz dostać się do php.ini:

php_flag short_open_tag on

Aby uniknąć problemów związanych z przenośnością, uruchamiaj tagi PHP za pomocą, <?phpa jeśli plik PHP to wyłącznie PHP, bez HTML, nie musisz używać tagów zamykających.

• Krótkie tagi są dopuszczalne w przypadkach, gdy masz pewność, że serwer będzie je obsługiwał i że programiści to zrozumieją.
• Wiele serwerów go nie obsługuje, a wielu programistów zrozumie go po obejrzeniu go raz.
• Używam pełnych tagów, aby zapewnić przenośność, ponieważ tak naprawdę nie jest tak źle.

Powiedziawszy to, mój przyjaciel powiedział to na poparcie alternatywnych standardowych tagów w stylu asp, takich jak <%zamiast <?, co jest ustawieniem w php.ini o nazwie asp_tags. Oto jego uzasadnienie:

... arbitralne konwencje powinny zostać znormalizowane . Oznacza to, że za każdym razem, gdy mamy do czynienia z zestawem możliwości o jednakowej wartości - takich jak dziwna interpunkcja, której nasz język programowania powinien używać do wyznaczania siebie - powinniśmy wybrać jeden standardowy sposób i trzymać się go. W ten sposób zmniejszamy krzywą uczenia się wszystkich języków (lub cokolwiek innego, czego dotyczy konwencja).

Brzmi dla mnie dobrze, ale nie sądzę, aby ktokolwiek z nas mógł okrążyć wagony wokół tej przyczyny. W międzyczasie trzymałbym się wszystkiego <?php.

Pomyślałem, że warto wspomnieć, że od PHP 7:

• Krótkie tagi ASP PHP <% … %>zniknęły
• Krótkie karty PHP <? … ?>są nadal dostępne, jeślishort_open_tag jest ustawione na true. To jest domyślne.
• Od PHP 5.4 tagi krótkiego wydruku<?=… ?> są zawsze włączone, niezależnie od short_open_tagustawienia.

Dobra riddance do pierwszego, ponieważ kolidował z innymi językami.

Teraz nie ma powodu, aby nie używać tagów z krótkim nadrukiem, poza osobistymi preferencjami.

Oczywiście, jeśli piszesz kod, aby był zgodny ze starszymi wersjami PHP 5, musisz trzymać się starych zasad, ale pamiętaj, że wszystko przed PHP 5.6 nie jest już obsługiwane.

Zobacz: https://secure.php.net/manual/en/language.basic-syntax.phptags.php

Jeśli zależy ci na XSS , powinieneś użyć<?= htmlspecialchars(…) ?> większość czasu, więc krótki tag nie robi dużej różnicy.

Nawet jeśli skrócisz echo htmlspecialchars()doh() , to wciąż problem, że trzeba pamiętać, aby dodać go niemal za każdym razem (i stara się śledzić, które dane jest wstępnie uciekł, która jest Niecytowany-ale-nieszkodliwy sprawia tylko błędy bardziej prawdopodobne).

Używam domyślnie bezpiecznego silnika szablonów i zapisuje <?phpdla mnie tagi.

<?php ?>są znacznie lepsze w użyciu, ponieważ twórcy tego języka programowania masowo zaktualizowali swój język podstawowy. Możesz zobaczyć różnicę między krótkimi i długimi tagami.

Krótkie tagi zostaną podświetlone na jasno czerwone, a dłuższe - ciemniejsze!

Jednak echo czegoś, na przykład: <?=$variable;?>jest w porządku. Ale wolę dłuższe tagi.<?php echo $variable;?>

Konwertuj <?(bez spacji końcowej) na <?php(z spacją końcową):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\?(?!php|=|xml|mso| )/<\?php /g'

Konwertuj <?(z końcowym odstępem) na <?php(zachowując końcowy odstęp):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\? /<\?php /g'

Krótki tag jest zawsze dostępny w php. Więc nie potrzebujesz echa pierwszej instrukcji w skrypcie

przykład:

    $a =10;
    <?= $a;//10 
    echo "Hellow";//
    echo "Hellow";

   ?>

Nagle musisz użyć jednego skryptu php, a następnie możesz go użyć. przykład:

<html>
<head>
<title></title>
</head>  
<body>
<p>hellow everybody<?= hi;?></p>
<p>hellow everybody  </p> 
<p>hellow everybody  </p>   
</body>
</html>

Od 2019 r. Nie zgadzam się z niektórymi odpowiedziami tutaj. Polecam używać długich tagów

<?php /* code goes here */ ?>

lub krótkie znaczniki echa

<?= /* code goes here */ ?>

Powód: są zalecane przez podstawowy standard kodowania PSR-1

Inne krótkie tagi, takie jak, <? /* code goes here */ ?>nie są zalecane.

Specyfikacja mówi:

Kod PHP MUSI używać długich znaczników lub krótkich ech; NIE WOLNO używać innych odmian tagów .

3 tagi są dostępne w php:

1. długi znacznik, który <?php ?>nie wymaga kierowania żadnymi skonfigurowanymi
2. short_open_tag, który jest <? ?> dostępny, jeśli włączona jest opcja short_open_tag w php.ini
3. skróć znacznik, <?= ponieważ php 5.4.0 jest zawsze dostępny

z php 7.0.0 asp i tag skryptu zostały usunięte

Nie, i są one wycofywane przez PHP 6, więc jeśli cenisz sobie długowieczność kodu, po prostu nie używaj ich ani <% ... %>tagów.