Форум PHP

Здравствуйте! Я новичок в PHP и поэтому прошу мне помоч.

Возникла проблема с применением функции htmlspecialchars() .

Цель такова. На сайте c базой данных MyCQL и админкой надо разместить страницу с элементарной инструкцией, которая объясняла бы пользователю, совсем незнакомому с HTML как надо редактировать тексты , применяя хотя бы только три тэга <p></p> , <span></span> и <br>.

Т. е. в тексте такой инструкции должны присутствовать тэги HTML. А это значит, что в HTML-коде текста инструкции надо угловые скобки заменить спецсимволами &lt; и &gt; , иначе браузер в тексте страницы "нарисует" пустоту. Там где в коде спецсимвол, браузер должен "нарисовать" соответствующую угловую скобку.

В моём случае браузер правильно отображает текст, НО ТОЛЬКО до первого редактирования. Стоит только сделать изменение в редакторе, нажать на кнопочку, так сразу спецсимволы самопроизвольно меняются на угловые скобки в базе данных, и соответственно в тексте страницы там где должны быть тэги HTML появляются пустые места.

То, что я хочу сделать, элементарно реализуется без базы данных. Но хочется сделать с базой данных.

Вот код формы редактора.


<div class="forma1">
<?php

if (!isset($id))
{
$result = mysql_query("SELECT title, id FROM settings");
$myrow = mysql_fetch_array($result);
do
{
printf ("<p><a class='iskl' href='redakt.php?id=%s'>%s</a></p>", $myrow["id"], $myrow["title"]);
}
while ($myrow = mysql_fetch_array($result));
}
else
{
$result = mysql_query("SELECT * FROM settings WHERE id='$id'");
$myrow = mysql_fetch_array($result);

print <<<HERE

<form action="obrabred.php" method="POST" name="form1">

<p>Название страницы<br><br>
<input value="$myrow[title]" id="title" type="text" name="title" width="100">
</p>
<p>Редактируемый текст<br><br>
<textarea name="text" id="text" cols="90" rows="50">
$myrow[text]
</textarea>
</p>
<p><input name="id" type="hidden" value="$myrow[id]"></p>
<p>
<input type="submit" name="submit" id="submit" value="Сохранить изменение">
</p>
</form>
</div>
HERE;

}
?>
</div>

А это код обработчика.

<?php

if (isset($title) && isset($text))
{
/*здесь пишем, что можно заносить информацию в базу*/
$result = mysql_query ("UPDATE settings SET title='$title', text='$text' WHERE id='$id'");

if ($result == 'true') {echo "<p>Ваш текст успешно обновлён </p>";}
else {echo "<p>Ваша страница не обновлена.</p>";}
}
else
{
echo "<p>Вы ввели не всю информацию, поэтому данные этой страницы в базе не могут быть обновлены.</p>";
}
?>


Не могу врубиться, где надо разместить функцию htmlspecialchars() и что написать в круглых скобках? Что то в литературе об этой функции скупо написано.


Может быть кто то подскажет как решить проблему? Заранее благодарен.

-

при выводе из базы данный, та переменная, которая в своём значении содержит теги записывается в круглые скобки функции htmlspecialchars().

<?php $a = htmlspecialchars($myrow['text']);// в значении переменной $myrow['text'] содержится текст, например, "<p>Редактировать</p>" echo $a // получаем "&lt;p&gt;Редактировать&lt;/p&gt;" ?>

при выводе в окно браузера html теги будут видны.

Лучше хранить данные в базе в таком виде "&lt;p&gt;Редактировать&lt;/p&gt;"

лучше чем что? зачем хранить в таком виде?

Строка в базу заносится 1 раз, а выводится оттуда постоянно.
Зачем потрошить её постоянно после каждого SELECTa в поисках спецсимволов?

Да и вообще строки типа "<script>alert('Отправляю ваши кукисы к себе')</script>" в вашей базе рано или поздно рискуют быть выведенными в открытом виде, если вы после очередного запроса забыли обработать их с помощью обсуждаемой функции.

А как Вы планируете эти данные потом клиенту на редактирование отдавать?

Даже и не знаю. Об этом не думал еще

Очень четко сформулированный основной промах.

Вы о чем?

о
не думал еще

То что Вы пытаетесь реализовать принято называть кэшем и реализуется он немного не так.

Все вдруг забыли о http://www.php.net/manual/en/function.htmlspecialchars-decode.php ?

Это типа чтоб масло соскребать?

Аналогия с маслом тут совсем неуместна, это как универсальный вариант:
- в базе хранится уже готовая для выдачи информация
- при редактировании она не искажается
- при выдачах информации пользователям не нужно производить никаких действий

В чем проблема то? Клиент не сможет отредактировать эти данные чтоли?

Вам виднее - попробуйте вызывать на редактирование, например, сообщение этого форума, при условии что оно хранится в таком "переваренном" виде... bbcode сможете на место вернуть?

Конечно смогу. А это так трудно?

<?php // получаем переменную из формы $_POST["var"] = "<p>Преждевремменная оптимизация - это [b*]ЗЛО!!![/b*]</p>"; // экранируем символы $var = htmlspecialchars($_POST["var"]); # $var = "&lt;p&gt;Преждевремменная оптимизация - это [b*]ЗЛО!!![/b*]&lt;/p&gt;"; // находим bbcode $var = str_replace("[b*]", "<b>", $var); $var = str_replace("[/b*]", "</b>", $var); # $var = &lt;p&gt;Преждевремменная оптимизация - это <b>ЗЛО!!!</b>&lt;/p&gt;"; // Заносим переменную $var в Базу (после обработки) // 1. при выводе распечатываем ее # $var = &lt;p&gt;Преждевремменная оптимизация - это <b>ЗЛО!!!</b>&lt;/p&gt;"; echo $var; // 2. при редактировании вытаскиеваем переменную из базы # $var = &lt;p&gt;Преждевремменная оптимизация - это <b>ЗЛО!!!</b>&lt;/p&gt;"; // возвращаем bbcode $var = str_replace("<b>", "[b*]", $var); $var = str_replace("</b>", "[/b*]", $var); echo "<input type=\"text\" name=\"var\" value=\"$var\" />"; # на экране <p>Преждевремменная оптимизация - это [b*]ЗЛО!!![/b*]</p> ?>

Разве этот код не имеет места быть?
А если у вас на 1000 просмотров записи всего 1 редактирование?
А если 1 на 100 000?

И "надругательство над данными" и преждевременная оптимизация о которой ниже говорил Trianon (и Дональд Кнут) здесь непричем. В каждой второй статье только и написано, что это корень всех зол...
Только очень трудно определить где этот корень начинается, и где заканчивается здравый смысл (в использовании рессурсов сервера).

Я был неточен, сказав что "лучше хранить данные в базе в таком виде "&lt;p&gt;Редактировать&lt;/p&gt;". Конечно не всегда, но в некоторых ситуациях лучше.

* (звездочки) в коде для корректного отображения на форуме

Теперь представьте на минутку, что злой враг и разбойник проник каким то немыслимым образом в базу данных. Не через этот скрипт, через другой к примеру. И в каждое сообщение напихал XSS. Вы даже ни ухом ни рылом знать не будете, как подставите под удар всех своих пользователей. Ведь Вы выдадите это в в поток в чистом виде, без обработки!
Вот о чем тут речь. Стоит ли "преждевременная оптимизация (ЗЛО)" такой откровенной подставы. Вы ведь с помощью этой, с позволения сказать, заботы о безопасности и оптимальности делаете заложниками всех посетителей.
Вот и весь здравый смысл.
Существуют ситуации, когда из двух зол приходится выбирать меньшее. Но. Они крайне редки - раз. И реализуется это совсем не так - два. И овчинка не стоит выделки при посещаемости меньше миллиона(наверно не меньше) уников в сутки - три. Все остальное - суета и параноя.

> представьте на минутку, что злой враг и разбойник проник каким то немыслимым образом в базу данных...

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

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

Не вижу смысла рассуждать о том, что могло бы произойти если бы у бабушки был х....
Ну вот о том и говорил Trianon в (26.01.2010 в 12:51)

Мне инструктор по вождению говорил: первое правило ДД - думай за дурака. На всю жизнь запомнил.
С таким подходом, что "не вижу смысла рассуждать ( а значит думать)", кто нибудь когда нибудь подумает. И не только вашей бабушке привинтит, но и у дедушки все поотрывает.

Николай, конечно, глупость сморозил.

Но Вы сами потом в своём говнокоде утоните.

Николай, конечно, глупость сморозил.
С этого момента поподробнее плиз.

"Если бы да кабы во рту росли грибы ..."

Не надо придумывать подобные ситуации. А если человек завладел паролем от FTP? Ай-яй-яй, что же тогда? Все ваши скриты неустойчивы к этому? Вы ставите под удар своих пользователей!

Ну еще один. Во первых, тут и думать особо не нужно. А во вторых, это может повлечь за собой такой геморрой, что потом поздно будет волосы то рвать. Как раз если кто то завладеет паролем, (они не в скриптах, а на машинах админов и никто гарантий дать не может), то можно всю базу загадить. И загадить так, что всплывет только через месяц-два-полгода, когда бэкапы не актуальны станут. Именно так и делаются грамотные атаки.
Что тогда, бабушку вспоминать будем или мою глупость?
Это же элементарная гигиена, как зубы чистить. Подумаешь кариес, нет ведь пока. А когда хватишься - половины зубов не досчитаешься.

Я-то htmlspecialchars() перед занесением в базу не пихаю. А делаю всё идеологически верно.

Вы являетесь троллем и ждёте, когда я Вас кормить начну. Не дождётесь — я себя уважаю, а Вас — презираю.

Ну вот, обиделся... Обзывается...

Ну не пихаете, молодец, хороший мальчик. Зачем же других с толку сбивать..

Заметьте, не я это начал. А от того, что кто то там меня презирает мне ни кисло ни холдно. Уважать себя нужно за слова и поступки, а и то и другое у Вас ни как тому не способствует. Я Вас даже презирать не могу, потому как теперь Вы не просто тень, а вообще пустое место.

Попав в базу он уже овладел основной частью нашего приложения и защититься от этого одним htmlspecialchars уже не получится тк. он может с таким-же успехом использовать XSS в полях редактирования и других модулях.

Если ваша база так подвержена атакам, то нужно создавать целую оболочку вокруг PHP приложения и проверять абсолютно все входящие\выходящие данные.

Попав в базу он уже овладел основной частью нашего приложения
Вот рассудите, что нужно человеку, который стремится попасть в базу. А нужно ему
1. Нахулиганить
2. Изменить какие то данные
3. Завладеть секретной информацией.
4. Получить управление ресурсом и, как следствие, машиной пользователя..

Так вот, для борьбы с первым есть бэкапы. Как только взлом вскроется, восстановить информацию труда не представит.
Для второго случая аппаратные методы не подходят, только следить вручную, сверять с опять же резервными данными.
А вот третьим и четвертым стоит озаботиться.

Про криптологию и защиту секретных данных - другая тема. А вот про управление - как раз.

Ведь XSS это не только банальная кража кукисов. Это скажем редирект на свои ресурсы. И хорошо, если это просто реклама, а если эксплоит? Ведь не секрет, что через дыры в браузерах можно заразить машину пользователя любой гадостью и получить доступ к любым данным. А это не шутки, у людей водятся серьёзные электронные деньги.
Так вот.
Если скрипт выводит сырой текст, надеясь, что в базе все в порядке, значит он выводит всю гадость, которая там есть. И легко и непренужденно выведет в браузер ничего не подозревающего юзера XSS примочку.
А если скрипт выводит в поток обработанные данные, то совершенно не важно, как гадость попала в базу и есть ли она там вообще, все равно не будет вреда.
И кто сказал, что
htmlspecialchars уже не получится тк. он может с таким-же успехом использовать XSS в полях редактирования и других модулях.
? Почему Вы решили, что в полях редактирования и других модулях не нужно их обрабатывать?

Если ваша база так подвержена атакам, то нужно создавать целую оболочку вокруг PHP приложения и проверять абсолютно все входящие\выходящие данные.
Если уж делать приложение, особенно на заказ, то именно так и надо думать. И что подвержена, и что абсолютно все данные. Это и есть профессиональный подход.
Только никаких оболочек не нужно, нужно просто правильно все использовать. На своих местах.

Добавьте парсинг тегов [url], [img] и т.п. и тут же и огребете всю прелесть...

Не пугайте. Не страшно.

Если есть четкие аргументы в пользу того, почему нельзя использовать этот способ (вместо "стотысячектратного" вызова функции) пожалуйста выскажитесь.

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

В этой теме и так уже хватает болтовни.

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

Ни один с ваших пунктов не является действительностью.
1. Запоминать должна система парсинга соощений. И память тут не при чём.
2. Использовать не можно? Пример?
3. Документация по проекту зачем? Через пол года никто не вспомнить и какой метод что делает, что тогда?

>Документация по проекту зачем? Через пол года никто не вспомнить и какой метод что делает, что тогда?

а как же комментарии?

$var = htmlspecialchars($_POST["var"]);
А если нужно проверить $_POST["var"], то так и проверять $var с учетом мусора &lt; &gt; ?

Если очень нужно можно раскодировать

А может лучше сперва проверить, а пользователю возвращать (при необходимости) htmlspecialchars($var)?
Вы же сами о логике упоминали. Ну и где в этом случае логика? Это скорее с перепугу. ;-)
С одной стороны вы озабочены производительностью, с другой стороны предлагаете лишние телодвижения.

Это вы предложили лишнее телодвижение:
> А если нужно проверить $_POST["var"], то так и проверять $var с учетом мусора &lt; &gt; ?
Вы спросили - я ответил, что можно раскодировать.
Я не знаю зачем проверять $_POST["var"]. В моем коде этого нет.

В вашем нет такого условия, да, но записей подобной вашей, если поковырять форум, предостаточно, и при условиях проверки. И ноги такого перепуга с того же места растут )
Я согласиться с вами только в одном могу:
у вас есть "контракт" с пользователем на "поставку" HTML- JS-кода в чистом виде, и коли это оговаривается условиями "контракта", то вы с чистой совестью обработали и сохранили. Почему бы и нет, друго то ведь не предусмотрено.
В иных случаях я не вижу как раз этой самой "логики" (в действиях). Если сбросить "макинтош программиста" и подумать абстрагиварованно, то не получается ни естественного, ни осмысленного.

Логика может быть в том, что возможна ситуация, когда ты пропустишь вставку htmlspecialchars и сделаешь дырку для XSS.

На то вы и "родитель", чтобы следить за своим "дидятко".

PS. Знаете с чем можно сравнить ваш аргумент? Со строителем, который обязан всю жизнь ходить в каске, так как это обуславливается техникой безопасности.

Ну достала уже донельзя такая аргументация!

Это вполне адекватная аргументация, просто вы не видите примеров когда она важна. Если вы один работаете над продуктом и он не большой, то да - делайте как вам нравится, а когда работает команда или исходный код open sourc'ный и каждый может вносить правки, то ваш подход недопустим.

Вы думаете почему почти во всех опен соурс решениях редактируемые данные сразу же проходят парсинг? Многие могут пропустить дырки, ну и если ваш парсер не ограничивается htmlspecialchars, то запускать его каждый раз - очень накладно.

P.S.: Как мне не нравится, что каждый на этом сайте пытается всё доказывать только с точки зрения разработчика-одиночки маленьких приложений с маленькими нагрузками.
Достала такая аргументация...

Знаете, разработчик коллективный, у всей вашей команды может сложиться ситуация, когда вы выходя на улицу забудете застегнуть ширинку. Конфуз конечно, но исправим, и на ошибках учатся. Но вот то, что после этого вы все зашьете себе ширинки, я не уверен. ;-)
Делайте как хотите, вам никто и не указывает, но работа в команде, значит команда, а не одиночки по своим углам.

PS. Вы ведь тоже "свое" хотите доказать.

Знаете что такое опенсоурс? Это и есть работа по углам...

У такой работы должен быть координатор, так что это проблемы не мои, а команды вашей.

Писал длинный ответ... Забил. Почитайте про опенсорс, поучитесь немного, наберитесь ещё опыта, выпустите пару коммерческих продуктов, а потом поговорим.

Закрыто.

> поучитесь немного, наберитесь ещё опыта
Андрюша, начни с себя

Бедные юзеры... кто польстится на Ваш опенсоурс.
Вы не Жени Попова представитель? Тому тоже плевать, как что будет, лишь бы ОПЕНСОУРС был, да ще какой...
Только после этого вопросы почему то здесь (и не только) всплывают - "Я же все правильно делал, почему меня хакнули????????????"
Он на своем сайте предпочитает отмалчиваться. Опенсоурс сделал свое дело.

Команде Вашей только посочуствовать остается, раз так массово все заблуждаются.

Какие же недалёкие люди попадаются, жаль.

[модераторам - удалите мой аккаунт и все сообщения с форума, не хочу находится среди людей, которые за года не научились смотреть на одну задачу по-разному. вот пишите пишите вы книги - лучше бы учили чему-то новому, а не перепечатывали маны с небольшими примерчиками.]

> модераторам - удалите мой аккаунт и все сообщения с форума

Ни в коем случае! Пусть этот позор так и будет висеть. Бугага!

позор нажимать логаут и писать анонимно :D
так низко...

Я просто не хочу делать логин. софттайм меня задолбал, но от скуки иногда вот сюда захожу.

Сразу залп отговорок. Жалкая попытка слива не засчитана :D

Какие же недалёкие люди попадаются, жаль.
Не жалейте. Радуйтесь. На фоне таких как я недалеких людей Вы, со своими революционными взглядами - скала. Иначе не с чем было бы сравниться.

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

И кстати, на обиженных возят воду. Если нет ума мужества признать свои ошибки, остается только пожелать удачи...
Хотя искренне жаль.

Кстати, Андрюща -- украинец, насколько я помню. Это так, к слову...

Дело ваше, можете и не появляться здесь, но не стоит считать себя обиженным, ибо вас никто здесь и не собирался унижать. Вы не новичок, у вас есть опыт, и к вашим словам будут прислушиваться те, кто только впервые взял в руки учебник. Вот это и плохо, ибо начитавшись ваших рекомендаций, они поступают обычно примерно так: как в этой теме. Почитаейте этут тему, где начинающий так и говорит "Вроде как защищающая функция..."! Он ее и назначение то слабо представляет, не то что умение пользоваться ею. А есть на форуме и куда более заковырестее "испуги". Вот так.

Будем считать, что я немного знаю где и зачем применять этот htmlspecialchars, а так как ваш пост адресовался мне, то я вам и ответил - нет, это глупо и необдуманно, и мне не подходит.
Не надо пугать открытым кодом и проблемами его разаработчиков - Linux при таком "жестком подходе" к страстям был бы не ОС в конечном итоге, а невообразымым и неуклюжим монстром. Эта ОС горазде более серьезнее продукт, нежели ваш пусть и коллективный сайт, и вопросам безопасности в ней уделяется конечно много, но вот чтобы любой ценой, я не верю. И не поверю, что она на все 100% непробиваемая, а Windows изначально в дырках, есть в ней и дыры, но их латают, и все те же разработчики "по углам сидящие".

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

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

Я вот так мыслю, а открытый код, закрытый код, это уже другой вопрос.
Ошибки делают все - это естественно, жить тоже страшно - но жить приятная вещь. ;-)

> вас никто здесь и не собирался унижать

Не обобщайте!

Не надо, вот этого не надо - виртуальные драки, пусть и словесные, это уже совсем глупо. :)

<? /* CREATE TABLE IF NOT EXISTS `forum_th` (    `id` int(10) NOT NULL auto_increment,    `name` varchar(100) NOT NULL,     . . .   PRIMARY KEY  (`id`)  ) ; */ # название новой темы $_POST['th_name'] = 'функция "htmlspecialchars" — Преобразует специальные символы в HTML сущности, символы: &, ", \', <, >'; # кол-во символов echo strlen($_POST['th_name']).'<br />'; // 100, отлично прям в пору!!! =) # занимаемся куйней.. $_POST['th_name'] = htmlspecialchars($_POST['th_name']); # кол-во символов echo strlen($_POST['th_name']).'<br />'; // 125, епт.. некрасиво половину нету.. =( # и что же будет в базе? echo substr($_POST['th_name'], 0, 100); // =) и даже не представляете на каком месте обрубается) никакой HTML сущности.. //страничку уже имеет синт. ошибку // понимаю, для html не так уж страшно.. а для xhtml?  ?>

Чтоб не грузить используют кэш.
Вот как раз в кэш заносят после htmlspecialchars, bbcode, smiles

То, о чем вы хотите сказать может возникнуть всегда. При транслите текста например ("ш" => "sh", "ц" => "ts"). Это можно предусмотреть, а точнее это нужно предусмотреть при любой обработке данных.

Кто-то мешает вам написать свою функцию обрезки?

В чем проблема то? Клиент не сможет отредактировать эти данные чтоли?

Вы батон дома тоже храните не только нарезанным, но и намазанным маслом?

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

Есть считанные случаи, когда производительность стоит выжимать любой ценой.
Совершенно очевидно, что на этом форуме их быть не может. Здесь цены не такие.

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

Но, от части человек прав и если он хочет учиться сразу выжимать всё, что можно, то зачем его заставлять делать это иначе?

>Ну с этим я согласен, когда последний раз задал вопрос по максимальному выжиму он так и остался без ответа...

Вот видите? :)

>Но, от части человек прав и если он хочет учиться сразу выжимать всё, что можно, то зачем его заставлять делать это иначе?

Потому что это порочный подход. Результат будет обратным.
Опережающая оптимизация наносит лишь вред. Тем более - когда она разрушает логику связи алгоритмы-данные.

На самом деле "учиться сразу всё" тоже не самый благородный подход.

> Потому что это порочный подход
Нет в этом подходе ничего "порочного".
Логику связей алгоритмов и данных, устанавливает программист в зависимости от поставленной задачи.

PS. В следующий раз когда буду шутить (я про "не подумал") поставлю смайл))

Я вообще-то прочел постановку, а не огульно хаять начал, как, вероятно, можно было бы заподозрить.
Постановка противоречит такому надругательству над данными, как Вы предложили.

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

Только что, именно на этом сайте скачал гостевую, где данные обрабатываются функцией htmlspecialchars, перед занесением в базу. "Правилами плохого тона" и "издевательствами над данными" это никто не называет?

Это не ко мне вопрос. Я о вашей реплике выше, о JS коде.

Я называю.

> Только что, именно на этом сайте скачал гостевую, где данные обрабатываются функцией htmlspecialchars, перед занесением в базу. "Правилами плохого тона" и "издевательствами над данными" это никто не называет?

Да, это ужасно. Вы это хотели услышать? Или Вы свято верите, что все скрипты, скачанные с этого сайта, написаны Богом?

Гигантское спасибо всем, кто озаботился моей проблемой. Не думал, что мой вопрос вызовет такую дискуссию. Сохранил эту страницу -- сейчас буду изучать. Ещё раз спасибо.

Будут ещё вопросы — обращайтесь к Жене Попову!

угу, лучше бы его сразу на хэ послали, чем к Попову

Лучше бы ты, Тень, его к домохозяйке отправил за советом, Хахаха

Сохранил эту страницу -- сейчас буду изучать.
Ну вот еще несколько поводов для размышления.

<div class="forma1"> <?php // Предположим, что инициализация $id где то выше. Тогда тут уместнее empty() if (!isset($id)) {   $result = mysql_query("SELECT title, id FROM settings"); // Функция mysql_fetch_array() должна (если уж приспичило) использоваться с подобающим флагом   $myrow = mysql_fetch_array($result); // Цикл do... while тут не к месту   do   { // Функция printf служит для форматирования данных, а не для организации вывода      printf ("<p><a class='iskl' href='redakt.php?id=%s'>%s</a></p>", $myrow["id"], $myrow["title"]);   }   while ($myrow = mysql_fetch_array($result)); } else { // В запрос попала необработанная внешняя переменная. Кроме того, // она явно числовая, а значит тут не нужны апострофы $result = mysql_query("SELECT * FROM settings WHERE id='$id'"); // Функция mysql_fetch_array() должна (если уж приспичило) использоваться с подобающим флагом $myrow = mysql_fetch_array($result); print <<<HERE <form action="obrabred.php" method="POST" name="form1"> <p>Название страницы<br><br> // Ключ ассоциативного массива должен быть заключен в кавычки (апострофы) <input value="$myrow[title]" id="title" type="text" name="title" width="100"> </p> <p>Редактируемый текст<br><br> // В текстарее нельзя делать переносы. <textarea name="text" id="text" cols="90" rows="50"> // Ключ ассоциативного массива должен быть заключен в кавычки (апострофы) $myrow[text] </textarea> </p> // Ключ ассоциативного массива должен быть заключен в кавычки (апострофы) <p><input name="id" type="hidden" value="$myrow[id]"></p> <p> <input type="submit" name="submit" id="submit" value="Сохранить изменение"> </p> </form> </div> HERE; } ?> </div>

А вот так уже лучше:

<div class="forma1"> <?php $id = isset($_POST['id'])?$_POST['id']:NULL; if (empty($id)) {   $result = mysql_query("SELECT title, id FROM settings");       while ($myrow = mysql_fetch_assoc($result));   print ('<p><a class="iskl" href="redakt.php?id='. $myrow["id"].'">'. $myrow["title"] .'</a></p>'); } else { $result = mysql_query("SELECT * FROM settings WHERE id=". (int)$id); $myrow = mysql_fetch_assoc($result); print <<<HERE <form action="obrabred.php" method="POST" name="form1"> <p>Название страницы<br><br> <input value="$myrow['title']" id="title" type="text" name="title" width="100"> </p> <p>Редактируемый текст<br><br> <textarea name="text" id="text" cols="90" rows="50">$myrow['text']</textarea> </p> <p><input name="id" type="hidden" value="$myrow['id']"></p> <p> <input type="submit" name="submit" id="submit" value="Сохранить изменение"> </p> </form> </div> HERE; } ?> </div>

Хотя еще лучше бросили бы вы этот курс. Не доведет до добра он.

>А вот так уже лучше:

<?  FROM settings WHERE id=". (int)$id);

<? $a='123нu4567891234dgjя'; $b='1234567891234dgjя'; echo (int)($a);                // 123 echo (int)($b);                // 2147483647 echo (int)(123456789);         // 123456789 echo (int)(12345678917743);    // 1942909039

И что?
Я писал не универсальное решение, а применительно к данному случаю. Если посмотреть внимательно, есть комментарий:

// В запрос попала необработанная внешняя переменная. Кроме того,  // она явно числовая, а значит тут не нужны апострофы