Чудеса с поведением htmlspecialchars

[Dovg]

Это прописная истина, что не надо использовать двойную кавычку если нет подстановок...

echo "\n"; как бы говорит нам, что иногда надо.

Ты еще скажи, что echo быстрее, чем print.

ps. Статья ужасна, не надо ее читать.
Там ужасен каждый пример.

$row['id'] быстрее, чем $row[id]
Первый вариант быстрее в 7 раз.

... а второй вариант ведет к нотису.

 

[Dez]

echo "\n"; как бы говорит нам, что иногда надо.

\n - это подстановка . Да и дело не в той статье и обсуждения разных ее пунктов. Если можешь доказать что include - это вообще никак не ресурсоемкая операция, я слушаю.

 

[Vladson]

В статье только 1-2 совета имеют под собой реальное основание, почти ко всем остальным можно приписать "делайте так и ваш код не смогут взломать потому что никто не поймёт как оно работает, впрочем глянув в написанный код через час вы и сами этого не поймёте"

Исходя из расчётной посещаемости (если она планируется небольшая даже на пике, а в 99% обычных сайтов это именно так) удобнее использовать неоптимальный по быстродействию код может дать возможность упростить его настолько, что его модификация сэкономит реальные человеко-часы а стало быть и деньги, а код написаный со всеми оптимизациями повысит затраты, при этом даст только запас ресурсов который скорее всего так и не будет востребован.

include жрёт ресурсы первый раз, когда читает HDD (это самое медленное звено) после первого раза ни сам РНР и ни скрипт, а именно ОС держит его в кеше, и все последующие инклуды (если кончно на сервере не Windows Server 2012 c гигом оперативки, а файл который вы инклудите не генерируется самим скриптом) будут идти прямо из оперативки.

 

[Фанат]

Это только для тебя "прописная истина".
А для людей, которые что-то понимают, это бред сумасшедшего.
Сказка, которую один идиот рассказывает другим.

По какой-то причине у тебя голова устроена так, что пропускает всё умное, а оставляет только глупости. Которые ты записываешь в разряд "прописных истин"

 

[doran7]

Что мешает самому проверить?

Проверяю, скорее для того, чтобы убедиться, что textarea отображает эти спецсимволы не как текстовый редактор.

// в $str содержимое из БД в виде &, ", ', <, >
$file = 'ztest.txt';
file_put_contents($file, $str);

Открываю ztest.txt в текстовом редакторе и вижу, естественно:
&, ", ', <, >
Если это пропустить через htmlspecialchars_decode, то видим, естественно:
&, ", ', <, >

Я предполагал, когда открывал эту тему (в первом посте), что в textarea все вышеуказанное будет отображаться аналогичным образом (как в текстовом редакторе). Но textarea ведет себя как часть окна браузера, а не как простой текстовый редактор, отображающий содержимое текст-плэйн файла. Выходит, что дело здесь не в том, как устроены спецсимволы, а в том, как устроена textarea.

 

[Фанат]

Фантастика.
Оказывается, что код

<p>
    &nbsp;
</p>
<blockquote>
    &nbsp;
</blockquote>
<textarea>
    &nbsp;
</textarea>

во всех трех случаях ведет себя одинаково!

И база - оказывается - тоже не при чём.
Жизнь полна удивительных открытий

 

[Dez]

Фанат, ты говоришь ерунду. Даже если отбросить проводимые тесты на которых основываются такие советы (а отбрасывать их нельзя ! ), то даже с примитивной логики понятно что в пхп для обработки строк в двойных кавычках используется более сложный алгоритм - который будет переменные искать, специальные значки {}, ошибку сгенерирует если переменной нет,...

 

[doran7]

Оказывается, что код

<p>
    &nbsp;
</p>
<blockquote>
    &nbsp;
</blockquote>
<textarea>
    &nbsp;
</textarea>

во всех трех случаях ведет себя одинаково!

Что получается, что внутри контейнера textarea (и соответственно, поля формы редактирования) текст и всякие спецсимволы ведут себя так же, как и внутри какого-нить <div></div> или <p></p> ?
Я-то всегда смотрел на это поле формы как на окошко некоего текстового редактора... Чей-то у меня с мозгой наверное... Недавно очень тяжелое дело в суде выиграл, все мозги оно вынесло, ... плюс php месяца три вообще не занимался... Это надо переварить моей мозге, что textarea - обычный тег html в этом плане и ничего более.

 

[Dez]

да, это обычный тег, а не текстовый редактор. Тоже касается и всех остальных элементов форм и их атрибутов value

 

[doran7]

да, это обычный тег, а не текстовый редактор. Тоже касается и всех остальных элементов форм и их атрибутов value

Убьюсь об стенку.... чтобы поле, предназначенное для ввода и редактирования текста, так себя вело. Практически, как браузер (часть его окна).

 

[Фанат]

Фанат, ты говоришь ерунду.

ОМГ.
И тут эта дичь лезет.

Попробуй, хотя бы на минуту, вообразить, что сам язык пишут не такие как ты обычные похапе-говнокодеры, у которых весь "сложный алгоритм" где применяется - там и навален кучей. А реализуется отдельно от парсинга. А парсеру все равно надо весь скрипт перебрать, без разницы - одинарная там кавычка, двойная, или запятая. И если между двойными кавычками никаких спецсимволов не встретится, то и "сложный алгоритм" ВНЕЗАПНО применять не придется.

Не говоря уже о том, что "сложность алогоритма" немножчеко чересчур преувеличена.

Я доступно объясняю?
Или всё уже - похапе головного мозга в терминальной стадии, как у предыдущего пациента, и объяснять бесполезно? Надо только с умным видом писать статьи в интернете "25 советов как написать эталонный говнокод" - ты только в такой форме информацию усваиваешь?

 

[Dovg]

Dez, забудь уже про эту статью, не читай ее больше.

php /tmp/trolo.php 
0.058418035507202
0.066687107086182
<?php

	$start = microtime(true);
	
	$str = " ";
	for ($i = 0; $i < 1000000; $i++) {
		$str += " ";
	}
	echo (microtime(true) - $start)."\n";

	$start = microtime(true);

	$str = ' ';
	for($i = 0; $i < 1000000; $i++) {
		$str += ' ';
	}

	echo (microtime(true) - $start)."\n";

	readfile(__FILE__);

 

[doran7]

Так, значит. Спасибо людям, подлечившим мой выпавший мозг на етой самой textarea (я ее особой считал, она ведь даже орфографию верную-неверную отображает), Вурдалаку, Dez, Фанату. Тут мне были упреки, что я спорю вяло по холивару, мол самый умный и т.д.... Ну, теперь я целевой вопрос темы чуток прояснил, мозгу свою разгрузил, могу и к холивару подключиться насчет хайлоада, куда лучше htmlspecialchars втыкать и т.д.

 

[Dez]

даже если как ты говоришь там якобы есть проверка на наличие в строке спец символов, то уже эта проверка время займет. Хотя я сомневаюсь что такая тупая проверка там есть.
Потому что и с ней однозначности нет - $ может встретиться и без имени переменной и за ним может не буква идти например, тоже касается и {}, все эти ситуации надо обрабатывать. Это для любой строки.

 

[Фанат]

Охохох.
Обрабатывать надо. Если встречается.
А если НЕ встречается, то - сюрприз! - ничего обрабатывать не надо.
Я понимаю, вышеприведённую логическую конструкцию понять непросто.
Но попробуй поднапрячься.

 

[doran7]

Значит, по поводу htmlspecialchars, которую рекомендуют применять исключительно после чтения данных из БД для их вывода в браузер. Мол, так легче редактировать контент, есть экономия объема БД и т.п...., htmlspecialchars быстро работает, и потому потери по времени пренебрежимо малы. Есть сомнение, что это во всех случаях так. Первое, процедуру просмотра надо стараться делать как можно быстрее, и контент из БД, в идеале, для скорости и снижения нагрузки на сервер, надо избавлять от преобразований, от которых можно избавиться. Почему? Процедура просмотра - самая частая процедура на сайте. И если есть возможность фильтрацию через htmlspecialchars из просмотра перенести в другие процедуры - в создание и редактирование контента, почему бы не попробовать?
Выигрыш, имхо, может быть ощутимым, при просмотре - и по скорости отображения контента сайта и по нагрузке на сервер. Причем чем больше юзеров будут просматривать контент в единицу времени - тем больше выигрыш. Еще, чем больше объем статьи - тем опять же, больше выигрыш. Допустим, на нагруженном сайте десятки и сотни довольно объемных статей пытаются одновременно просмотреть десятки и сотни юзеров. При таком раскладе htmlspecialchars при фильтрации через него данных из БД для вывода контента отберет немало времени и ресурсов сервера.

 

[Фанат]

Мол, так легче редактировать контент, есть экономия объема БД

Это аргументы, опять же, от идиотов. Ну, первый - частично.
В то время как единственный реальный аргумент здесь - здравый смысл.

Форматировать любые данные надо перед использованием. просто потому что мы заранее не знаем, как они будут использоваться.

А то о чем ты говоришь - разывается кэширование. которое всегда делается отдельно от хранения, а ты зачем-то решил навалить все в одну кучу.

 

[Вурдалак]

$ cat opcodes.php
<?php

$foo = 42;

echo 'hey';
echo "hey";
echo "hey $foo";

$ php -d vld.active=1 -d vld.execute=0 -f opcodes.php
Finding entry points
Branch analysis from position: 0
Return found
filename: ~/opcodes.php
function name: (null)
number of ops: 7
compiled vars: !0 = $foo
line # * op fetch ext return operands
---------------------------------------------------------------------------------
3 0 > ASSIGN !0, 42
5 1 ECHO 'hey'
6 2 ECHO 'hey'
7 3 ADD_STRING ~1 'hey+'
4 ADD_VAR ~1 ~1, !0
5 ECHO ~1
8 6 > RETURN 1

branch: # 0; line: 3- 8; sop: 0; eop: 6
path #1: 0,

На уровне опкодов нет различий между тем, как был определен строковой литерал. С использованием кешеров опкода различий нет вообще.

 

[Dez]

Dovg, как говорится, кто проверяет у того и... У меня твой код подтверждает как раз мою версию, сколько не обновляй, ни разу втрой код не медленнее. С более длинными строками разница ощутимей.

 

[Вурдалак]

Dez, чувак, тебя слили