Антология PHP, Том 1, Глава 1 — Основы PHP

Расширения, рассматриваемые как «несущественные» функциональные возможности (т.е. они потребуются некоторым, но не всем разработчикам), должны добавляться отдельно. Важная информация появляется под заголовком «Установка» на главной странице для каждого расширения. Основные расширения описаны предложением «Для использования этих функций не требуется установка; они являются частью ядра PHP». Нестандартные расширения рассматриваются в Приложении B «Контрольный список провайдеров хостинга».

Доступ к информации в справочнике по функциям осуществляется через поле поиска (вверху справа) и поиск в «Списке функций». Обратите внимание, что поиск в списке функций рассматривает только раздел «Справочник по функциям» в руководстве. Для поиска по всему руководству вам необходимо выполнить поиск в «Онлайн-документации».

Еще один удобный способ обойти это «ярлык» к функциям, передавая название интересующей вас темы через URL. Например, попробуйте ввести следующее в поле адреса вашего браузера: http://www.php.net/strings . Это приведет вас к http://www.php.net/manual/en/ref.strings.php , которая является главной страницей для расширения Strings. Глядя на эту страницу, вы увидите список всех функций, доступных расширению; тот же список доступен в меню слева.

Взяв в качестве примера функцию strpos, введите URL-адрес http://www.php.net/strpos (который приведет вас к http://www.php.net/manual/en/function.strpos.php ). Вы увидите следующую информацию о функции strpos :

(PHP 3, PHP 4)

  strpos - Найти позицию первого вхождения строки
  Описание 


 int strpos (string haystack, string needle [, int offset]) 
  Возвращает числовую позицию первого вхождения иглы в строке сена.  В отличие от strrpos() , эта функция может принимать полную строку в качестве параметра иглы, и будет использоваться вся строка. 
  Если needle не найдена, возвращает FALSE . 
  Первая строка содержит имя функции, а вторая - список версий PHP, в которых доступна функция.  Третья строка говорит вам, что на самом деле делает функция.  В данном случае это довольно краткое объяснение, но strpos действительно не тот предмет, который вас может заинтересовать. 
  Под заголовком «Описание» находится, пожалуй, самая важная строка из всех - подпись функции.  Здесь описываются аргументы, которые принимает эта функция, и значение, которое она возвращает в ответ.  Читая слева направо, вы получаете int, который говорит вам, что значение, возвращаемое функцией, является целым числом (в данном случае это позиция одного фрагмента текста внутри другого).  Далее следует имя самой функции, а затем в скобках аргументы, которые принимает эта функция, разделенные запятыми. 
  Давайте посмотрим на string haystack аргумента string haystack .  Это говорит о том, что первый аргумент должен быть строковым значением, в то время как haystack просто называет аргумент так, чтобы на него можно было ссылаться в подробном описании.  Обратите внимание, что третий аргумент помещается в квадратные скобки, что означает, что он необязательный (т.е. вам не нужно указывать этот аргумент). 
  Вот как вы можете использовать strpos : 
  Пример 1.1.  1.php 


            


 <?php  $haystack = 'Hello World!';  $needle   = 'orld';   // Use the strpos() function  $position = strpos($haystack, $needle);   echo 'The substring "' . $needle . '" in "' .     $haystack . '" begins at character ' . $position;  ?> 
  Обратите внимание, что я использовал strpos аналогично тому, как это выглядит в руководстве.  Я использовал имена переменных $haystack и $needle чтобы прояснить, как каждая из них связана с объяснением в руководстве, но вы можете использовать любые имена переменных, которые вам нравятся. 
  Соглашение о сигнатурах функций постоянно используется в руководстве, поэтому, как только вы к нему привыкнете, вы сможете быстро понять, как использовать функции, которые вы раньше не пробовали. 
  Получить помощь при возникновении проблем 
  Если вы допустили ошибку, используя встроенную функцию в PHP 4.3.0, стандартный механизм отчетов об ошибках PHP отобразит сообщение об ошибке со ссылкой, которая приведет вас непосредственно к руководству. 
  Если у вас возникли сомнения, обязательно прочитайте комментарии других разработчиков PHP, которые появляются внизу каждой страницы руководства.  Обычно вы, по крайней мере, увидите пример того, как используется функция, которая может решить конкретную дилемму, с которой вы столкнулись.  Во многих случаях вы также найдете альтернативные объяснения и использования для функции, которые помогут расширить ваше понимание. 
  Дальнейшая помощь 
  Помимо руководства, есть буквально тысячи онлайн-ресурсов, из которых вы можете получить дополнительную помощь.  Я бы осмелился сказать, что на 99% всех распространенных проблем, с которыми вы столкнетесь в PHP, уже где-то уже есть ответы, и они доступны онлайн.  Это означает, что самым очевидным (но иногда забытым) местом для начала является Google, где быстрый поиск «проблемы PHP strpos» даст вам представление о том, что я имею в виду. 
  Есть также несколько отличных сайтов, где вы можете получить ответы непосредственно от других разработчиков PHP (конечно, бесплатно - это часть этики PHP).  Возможно, три самых больших в английском языке: 

  Форумы SitePoint: http://www.sitepointforums.com/ 
  Форумы Dev Shed: http://forums.devshed.com/ 
  phpBuilder: http://www.phpbuilder.com/board/ 

  Каждый из них использует vBulletin для проведения онлайн-дискуссий и, как таковой, имеет очень дружественные и простые в использовании интерфейсы.  У всех очень активное членство, и вы должны найти ответы на большинство вопросов в течение 24 часов. 
  Обратите внимание, что когда вы просите о помощи на форумах, важен принцип «помогать другим помогать себе».  Не публикуйте сообщение «У этого скрипта есть проблема» и вставляйте весь свой PHP-скрипт.  Сузьте проблему — определите область, в которой у вас возникли проблемы, и опубликуйте этот фрагмент кода вместе с другой соответствующей информацией, такой как сообщения об ошибках, назначение кода, ваша операционная система и т. Д.  Люди, предлагающие помощь, как правило, не хотят тратить больше нескольких минут на решение вашей проблемы (в конце концов, они делают это бесплатно), поэтому экономия их времени повысит ваши шансы получить полезный ответ. 
  Менее удобными, но, возможно, наиболее эффективными последними средствами являются списки рассылки PHP , где новичкам предлагается использовать общий список PHP.  Списки доступны для ограниченного просмотра , хотя некоторые из них можно искать с помощью поля поиска на веб-сайте PHP и выбора списка по вашему выбору. 
  Zend, компания, разрабатывающая ядро ​​движка PHP, также ведет довольно активный форум по общим вопросам PHP. 
  Если вы хотите получить гарантированный ответ, стоит изучить PHP Helpdesk , службу, управляемую Tap Internet , которая сотрудничает с Zend, предлагая обучение PHP. 





  Как исправить ошибку, обнаруженную PHP в моем скрипте? 
  Итак, вы на полпути к вашему последнему и лучшему сценарию, и внезапно выполнение теста выдает эту ошибку: 
 Parse error: parse error, unexpected T_ECHO, expecting ',' or ';'  in c:htdocssitepointphpbasics2.php on line 5 
  Оскорбительный код здесь выглядит следующим образом: 
  Пример 1.2.  2.php 
 <?php  echo 'This is some code<br />';  echo 'Somewhere in here I've got a ';  echo 'parse error!<br />'  echo 'But where is it?<br />';  ?> 
  То, с чем вы здесь работаете, называется синтаксической ошибкой, и, хотя вы новичок в PHP, вы можете потратить много времени на поиск таких проблем.  По мере того, как вы становитесь более опытным с PHP, отслеживание синтаксических ошибок станет легче.  Вы даже узнаете свои собственные вредные привычки и, вероятно, сможете угадать ошибку, которую сделали до начала охоты (мои собственные типичные ошибки — забыть окончательную цитату при построении операторов SQL в строке PHP и пропустить запятые при сборке массивы).  Хотя знакомство с сообщениями об ошибках PHP — хорошая идея. 
  В общих чертах, в ваших PHP-приложениях вы можете встретить четыре основных типа ошибок: 
  Синтаксические ошибки 
  Как и в приведенном выше примере, синтаксические ошибки возникают, когда вы нарушаете правила синтаксиса PHP.  Синтаксические ошибки обычно приводят к сообщению об ошибке разбора от PHP. 
  В приведенном выше примере сама проблема возникает в строке 4: 
 echo 'parse error!<br />' 
  Я забыл добавить в конце строки точку с запятой (;), необходимую для обозначения завершения каждого оператора.  Синтаксический анализатор PHP обнаружил проблему только в пятой строке, когда столкнулся с другим оператором echo, так как инструкции могут по закону занимать более одной строки.  Об этом стоит знать, так как иногда это затрудняет поиск ошибок — возможно, ошибка действительно произошла до того, как PHP обнаружил проблему. 
  Синтаксические ошибки могут стать особенно запутанными в случае больших операторов if-else или while, когда, например, вы забыли закрывающую скобку.  Возможно, у вас есть длинный список, который перемежается блоками HTML;  найти пропущенную фигурную скобку может быть чрезвычайно сложно.  Однако, по мере того как ваша техника кодирования улучшается, и вы начинаете использовать классы, разбивая свой код на отдельные блоки, внутри которых код короток и прост для чтения, вы обнаружите, что обнаруживать синтаксические ошибки намного проще. 
  Еще одна вещь, о которой следует знать, это использование токенов в PHP.  В приведенном выше сообщении об ошибке PHP жаловался на «неожиданный T_ECHO».  T_ECHO — это токен, представляющий оператор echo в вашем PHP-скрипте.  Парсер PHP разбивает ваш код на токены, чтобы он мог анализировать и обрабатывать скрипт.  Некоторые из токенов, которые вы увидите в отчетах об ошибках, менее очевидны, чем другие, поэтому, если вы не уверены, стоит посмотреть руководство по токенам . 
  Если вы используете PHP 4.3.0, вы обнаружите, что он включает в себя так называемое расширение токенизатора , которое позволяет вам видеть ваш скрипт так, как его анализирует PHP-парсер.  Ради интереса, вот как вы можете просмотреть вывод токенизатора: 



  Пример 1.3.  3.php 
 <?php  /* Note: This script will only work with PHP 4.3.0 or later */   // Read a PHP script as a string  $script = file_get_contents('2.php');   // Fetch the tokens into an array  $tokens = token_get_all($script);   // Display  echo '<pre>';  print_r($tokens);  echo '</pre>';  ?> 
  Семантические ошибки 
  Семантические ошибки возникают, когда вы пишете код, который подчиняется правилам синтаксиса PHP, но который при исполнении нарушает «правила времени выполнения» PHP.  Например, оператор foreach ожидает, что вы передадите ему массив: 
  Пример 1.4.  4.php 
 <?php  $variable = 'This is not an array';   foreach ($variable as $key => $value) {  echo $key . ' : ' . $value;  }  ?> 
  Поскольку $variable не был массивом, этот скрипт выдает следующее сообщение об ошибке: 
 Warning: Invalid argument supplied for foreach() in  c:htdocssitepointphpbasics3.php on line 4 
  Семантические ошибки обычно приводят к появлению предупреждающего сообщения об ошибке, подобного этому. 
  Ошибки среды 
  Ошибки среды возникают, когда система, которая является внешней по отношению к сценарию PHP, вызывает проблему.  Например, ваш сервер MySQL мог быть недоступен в тот момент, когда ваш PHP-скрипт пытался подключиться к нему.  Возможно, вы указали неверный путь к файлу, который хотите открыть, поэтому PHP не смог найти файл. 
  Эти ошибки также возникают, когда мы берем скрипт PHP, написанный на одной системе, и выполняем его на другой системе с другой средой.  Проблема может заключаться просто в том, что базовая структура каталогов или доменное имя веб-сервера отличается.  Распространено решать проблемы такого типа, создавая сценарий центральной конфигурации, в котором хранятся все эти переменные среды. 
  PHP также имеет ряд настроек в php.ini, которые могут вызвать сбой скрипта в другой системе, где настройки отличаются.  Я рассмотрю их в разделе «Как писать переносимый код PHP?»  ;  также есть сводная информация в Приложении A, Конфигурация PHP. 
  Ошибки логики 
  Логические ошибки возникают, когда приложение работает идеально, если речь идет о PHP-движке, но код выполняет нечто иное, чем вы предполагали.  Например, представьте, что у вас есть почтовый скрипт, который вы хотите использовать для отправки одного и того же сообщения нескольким участникам вашего онлайн-форума.  К вашему ужасу, после выполнения сценария вы обнаружите, что отправили письмо всем членам форума … двадцать раз! 
  Такого рода проблемы найти сложнее всего;  пользователи Windows XP будут хорошо знакомы с обновлениями Windows — даже крупные компании борются с логическими ошибками. 



  Критическим для обнаружения логических ошибок является ваша способность тщательно тестировать свой код в безопасной среде, отдельной от вашего «живого» веб-сервера.  К счастью, PHP и связанные с ним технологии, такие как Apache и MySQL (если вы их используете), являются кроссплатформенными, что упрощает создание эффективной среды разработки, даже если базовые операционные системы отличаются. 
  Вам также следует изучить модульное тестирование, аспект экстремального программирования (XP), с которым вы познакомитесь в главе 6 «Техника разработки».  Я также предложил продолжить чтение в конце этой главы. 
  В главе 10 «Обработка ошибок» я расскажу о стратегиях обработки самих ошибок, особенно ошибок среды.  В частности, мы обсудим, как вы можете записывать (или перехватывать) ошибки для своего анализа, не отображая отвратительные сообщения пользователям ваших приложений. 


  Как включить один PHP-скрипт в другой? 
  Обнаружив, что написание сценариев из тысячи строк, возможно, не лучший способ оставаться организованным, вы, вероятно, ищете способы разбить свой код на отдельные файлы.  Возможно, используя чужое приложение с открытым исходным кодом, вы испытываете трудности с устранением сообщений об ошибках, подобных приведенному ниже: 
 Fatal error: Failed opening required 'script.php' 
  Взаимное включение 
  PHP предоставляет четыре команды, которые позволяют вам добавлять содержимое одного PHP-скрипта в другой, а именно: include, require, include_once и require_once .  В каждом случае PHP выбирает файл, указанный в команде, а затем выполняет его содержимое.  Разница между include и require заключается в том, как они ведут себя, если им не удается найти скрипт, который им сказали извлечь. 
  include генерирует предупреждающее сообщение PHP вроде этого: 
 Warning: Failed opening 'script.php' for inclusion 
  Это позволит сценарию, вызвавшему команду include, продолжить выполнение. 
  Напротив, require приводит к фатальной ошибке, подобной показанной выше, что означает, что вызывающий скрипт завершится, и все остановится.  Если файл, который был необходим, имеет решающее значение для вашего приложения, прекратить работу скрипта — очень хорошая вещь. 
  Команды include_once и require_once ведут себя так же, как и их соответствующие двоюродные братья, но если сценарий уже был включен или требуется где-либо еще (с помощью любой из четырех команд), оператор будет проигнорирован.  На первый взгляд, может быть неочевидно, как эти команды могут быть использованы;  конечно, вы будете знать, сколько раз вы использовали команду включения, верно?  Команды _once становятся чрезвычайно _once в более сложных приложениях, в которых у вас есть PHP-скрипты, которые включают другие PHP-скрипты, которые, в свою очередь, включают еще больше PHP-скриптов.  Это особенно важно, когда вы используете библиотеки классов (которые мы рассмотрим в главе 2, Объектно-ориентированный PHP), и эти классы многократно используются многими сценариями.  Один класс может зависеть от доступности другого;  использование require_once для включения требуемого класса гарантирует, что он всегда будет доступен, но при этом не вызывает проблем, если этот класс использовался в другом месте. 
  Чтобы увидеть все это в действии, давайте создадим скрипт с именем include_me.php: 
  Пример 1.5.  include_me.php 



 <?php  // include_me.php   echo 'I've been included!<br />';  ?> 
  Каждый раз, когда этот скрипт включен, он будет отображать сообщение «Я был включен!»  так что мы знаем, что это сработало. 
  Теперь давайте проверим различные способы включения этого файла в другой скрипт: 
  Пример 1.6.  5.php 
 <?php  // This works fine  echo '<br />Requiring Once: ';  require_once 'include_me.php';   // This works fine as well  echo '<br />Including: ';  include 'include_me.php';   // Nothing happens as file is already included  echo '<br />Including Once: ';  include_once 'include_me.php';   // This is fine  echo '<br />Requiring: ';  require 'include_me.php';   // Again nothing happens - the file is included  echo '<br />Requiring Once again: ';  require_once 'include_me.php';   // Produces a warning message as the file doesn't exist  echo '<br />Include the wrong file: ';  include 'include_wrong.php';   // Produces a fatal error and script execution halts  echo '<br />Requiring the wrong file: ';  require 'include_wrong.php';   // This will never be executed as we have a fatal error  echo '<br />Including again: ';  include 'include_me.php';  ?> 
  Вот вывод, который это генерирует (обратите внимание, что в конце я упростила сообщения об ошибках): 
 Requiring Once: I've been included!   Including: I've been included!   Including Once:   Requiring: I've been included!   Requiring Once again:   Include the wrong file:  Warning: Failed opening 'include_wrong.php' for inclusion   Requiring the wrong file:Fatal error: Failed opening required  'include_wrong.php' 
  Обратите внимание, что первое использование include_once ничего не делает (файл уже был включен), как и последующее использование require_once .  Позже, когда я пытаюсь включить неправильный файл (в данном случае это файл, который не существует), я получаю предупреждение.  Однако выполнение продолжается до следующей строки, где я пытаюсь запросить файл, который не существует.  На этот раз PHP выдает фатальную ошибку, и выполнение скрипта прекращается, а это означает, что последняя попытка включить файл никогда не произойдет. 
  Имейте в виду, что файлы, которые вы включаете, не должны содержать только PHP.  Включенный файл может просто содержать HTML без PHP. 
  Какую команду использовать? 
  Как правило, если у вас нет особых обстоятельств, требующих какого-либо другого поведения, всегда используйте команду require_once для включения одного файла в другой.  Это особенно важно, когда вы размещаете классы PHP в отдельных файлах, и один класс может зависеть от другого.  Полный рассказ о классах см. В главе 2 «Объектно-ориентированный PHP». 
  Четыре команды включения PHP не следует путать с различными функциями, связанными с файлами (обсуждается в главе 4 «Файлы»);  они предназначены для извлечения файлов без немедленного их анализа в виде сценариев PHP, что позволяет вам работать с их содержимым. 
  Обратите внимание, что в этой книге я буду говорить об «включении» файла, даже когда я использую одну из команд require.  Это общее соглашение для разговора о PHP, которое происходит от старых языков программирования, используемых первыми пионерами PHP. 
  Найти путь 
  До сих пор я рассматривал только файлы, включенные в тот же каталог, что и скрипт, содержащий команду include.  На практике вы обычно захотите организовать файлы в подкаталоги в зависимости от выполняемой ими работы.  Это может привести к путанице, особенно когда вы используете сторонний код, поскольку существует множество альтернативных подходов к работе с включениями в других каталогах. 
  Первое, что нужно знать, это то, что все включения рассчитываются относительно каталога, в котором находится основной скрипт (где началось выполнение).  Например, представьте, что у нас есть три файла в следующих местах: 



 /home/username/www/index.php  /home/username/www/includes/script.php  /home/username/www/another.php 
  Сначала давайте рассмотрим index.php.  Команда include ‘включает в себя / script.php’;  будет правильно включать script.php, предполагая, что index.php — фактический запрошенный файл. 
  Но что, если мы используем следующую команду в script.php: 
 include '../another.php'; // ??? 
  Если script.php — это страница, которую мы просматриваем, эта команда будет правильно включать еще один .php.  Однако, если index.php — это страница, которую мы просматриваем, и она включает script.php, эта команда не будет выполнена, потому что местоположение another.php рассчитывается относительно местоположения index.php, а не относительно script.php , 
  У нас есть два варианта.  Мы можем изменить script.php так, чтобы он включал в себя другой .php следующим образом: 
 include 'another.php'; 
  В качестве альтернативы, мы можем ввести полный путь к другому .php, например так: 
 include '/home/username/www/another.php'; 
  Это не оставляет сомнений относительно того, где находится другой файл .php. 
  Файл конфигурации PHP php.ini также содержит директиву include_path .  Это позволяет вам указывать каталоги, из которых можно включать файлы, без необходимости указывать их расположение при использовании одной из команд включения. 
  Этот подход следует использовать с осторожностью, так как он может привести к странным результатам, если включенный файл с тем же именем существует в нескольких каталогах, но он может быть эффективным средством для решения проблем, связанных с включением.  Например, PHP-библиотека классов PEAR полагается на добавление каталога, содержащего файлы включения PEAR, в путь включения.  Также обратите внимание, что не стоит указывать слишком много местоположений в пути включения, так как это замедлит работу PHP, когда он попытается найти сценарии, включенные в ваш код. 
  Если вы используете Apache в среде общего хостинга, вы можете переопределить значение include_path с помощью файла .htaccess.  Помещенный в каталог, к которому вы хотите применить его (он также будет применяться ко всем подкаталогам), файл должен содержать что-то вроде этого: 
 php_value include_path ".:/usr/local/lib/php:/home/user/phplib/" 
  То же самое можно сделать с помощью функции PHP ini_set , например: 
 ini_set('include_path', 'C:/phplib/'); 
  Это позволяет вносить изменения во время выполнения из скрипта PHP. 
  Вы найдете ссылку на значения php.ini в Приложении A, Конфигурация PHP. 





  Как мне написать переносимый код PHP? 
  Не все установки PHP одинаковы.  В зависимости от версии и настроек конфигурации в php.ini, ваш скрипт может корректно работать или не работать на другом сервере, где установлен PHP.  Тем не менее, есть некоторые общие рекомендации, которые вы можете использовать, чтобы упростить жизнь и свести к минимуму необходимость переписывать код для других серверов. 
  Держите всю конфигурацию центральной 
  Для большинства приложений PHP будет необходимо предоставить информацию, описывающую среду, в которой будет выполняться сценарий, включая имена пользователей и пароли в базе данных, расположение каталогов и т. Д.  Как правило, старайтесь хранить большую часть этой информации в одном месте — возможно, даже в одном файле — чтобы в случае необходимости изменения информации вы могли делать все это в одном месте.  Тем не менее, при создании модульных приложений вы можете хранить элементы конфигурации, которые являются локальными для конкретного «модуля» вместе с самим модулем, а не централизованно. 
  Как именно вы решили хранить эту информацию, зависит от вашего личного выбора.  В некоторых случаях, возможно, стоит рассмотреть файл XML или сохранить некоторую информацию в базе данных.  Также стоит знать о функции parse_ini_file , которую я расскажу в главе 4 «Файлы». 
  Простой, но эффективный механизм — поместить все настройки в один файл как константы PHP, что делает их доступными из любой функции или класса в вашем приложении.  Например: 
  Пример 1.7.  6.php 
 <?php  // Configuration settings  define('DOMAIN', 'sitepoint.com');   // In another script  echo 'The domain is ' . DOMAIN;  ?> 
  Константы должны использоваться с осторожностью, хотя.  Чтобы сделать ваши функции и классы повторно используемыми в других приложениях, они не должны зависеть от констант фиксированного имени;  скорее они должны принять информацию о конфигурации в качестве аргументов.  В таких случаях лучше всего использовать переменные PHP в вашем центральном файле конфигурации, который затем можно при необходимости передать функциям и классам.  Если вы посмотрите на Главу 3, PHP и MySQL, при подключении к MySQL мы можем определить ряд переменных, которые нам нужны в центральном расположении: имя хоста сервера, имя пользователя, пароль и имя выбранной базы данных. , 
  Используя команду require_once мы рассматривали в предыдущем решении, мы можем создать файл, например, config.php, и поместить его вне общедоступных веб-каталогов.  Это помогает гарантировать, что никто не случайно перейдет к файлу, содержащему эту критическую информацию, что поставит под угрозу безопасность сайта. 
  Используйте полные теги <?php ?> 
  PHP поддерживает множество стилей тегов для разметки разделов кода PHP, включая короткие теги ( <? ?> ) И теги в стиле ASP ( <% %> ).  Они управляются из php.ini с настройками short_open_tag и asp_tags .  Пока эти настройки установлены на Вкл, другие люди не могут.  Например, стиль коротких тегов вызывает проблему, когда PHP смешивается с документами XML, которые используют такие инструкции обработки: 
 <?xml version="1.0"?> 
  Если у нас есть документ, который содержит PHP и XML, и у нас включен short_open_tag , PHP будет ошибочно принимать инструкцию обработки XML <?xml за открывающий тег PHP. 
  Вполне возможно, что ваш код должен будет выполняться в средах, в которых оба параметра short_open_tags и asp_tags отключены.  Лучший способ быть уверенным в том, что они есть, — это привыкнуть всегда использовать стиль тега <?php ?> , В противном случае может потребоваться много переписывания кода в будущем. 
  register_globals off 



  PHP способен превращать входящие данные в собственные переменные PHP.  Эта функция управляется настройкой register_globals в php.ini.  Если включен register_globals , если я $logged_in браузеру на адрес, например http://www.mysite.com/index.php?logged_in=1, PHP автоматически создаст переменную $logged_in и присвоит ей значение 1 .  Группа PHP теперь рекомендует отключить этот параметр, поскольку он представляет угрозу безопасности, как предлагает предыдущий пример. 
  Итак, в php.ini убедитесь, что следующий код на месте: 
 register_globals = Off 
  Это заставит вас обращаться к входящим данным через специальные предопределенные суперглобальные переменные (например, $_GET['username'] ), что означает, что они не будут конфликтовать с переменными, которые вы создали в вашем скрипте. 
  Используя файл .htaccess с Apache, тот же результат может быть достигнут с помощью следующего кода: 
 php_flag register_globals off 
  Дополнительную информацию можно найти в руководстве по PHP , а также в статье Кевина Янка « Напишите безопасные сценарии с помощью PHP 4.2!».  на сайте. 


  Магические цитаты 
  Волшебные кавычки — это функция, предназначенная для предотвращения нарушений безопасности на сайтах, разработанных новичками в PHP. 
Он автоматически добавляет escape-символы (см. Главу 5 «Манипулирование текстом») во входящие строки запроса URL, сообщения формы и данные cookie, прежде чем ваш сценарий сможет получить доступ к любому из этих значений. Если вы вставляете данные непосредственно в базу данных, нет риска, что кто-то сможет вмешаться в работу базы данных, если включена функция магических кавычек.
Для новичков это, безусловно, полезный способ предотвращения бедствий. Однако, как только вы поймете, что такое атаки с использованием SQL-инъекций, и выработаете привычку иметь дело с ними в своем коде, функциональность магической цитаты может стать большей проблемой, чем она того стоит.
Функциональность Magic Quotes контролируется настройкой PHP, magic_quotes_gpcкоторая может быть включена или выключена.
Я предпочитаю всегда отключать магические кавычки и самостоятельно обрабатывать экранирование данных для операторов SQL. К сожалению, это означает, что код, который я пишу, не будет хорошо переноситься на установки PHP, где включены волшебные кавычки (в результате я получу обратную косую черту в моем контенте). К счастью, для решения этой проблемы PHP предоставляет функцию get_magic_quotes_gpc, которую можно использовать, чтобы узнать, включены ли магические кавычки. Чтобы сохранить код в этой книге переносимым, мы будем использовать простой файл, который удаляет магические кавычки, если функциональность включена:
Пример 1.8. MagicQuotes / strip_quotes.php (в SPLIB)



 <?php  /**  * Checks for magic_quotes_gpc = On and strips them from incoming  * requests if necessary  */  if (get_magic_quotes_gpc()) {  $_GET    = array_map('stripslashes', $_GET);  $_POST   = array_map('stripslashes', $_POST);  $_COOKIE = array_map('stripslashes', $_COOKIE);  }  ?> 
Если мы включим это в начало любого файла, в который мы принимаем данные из строки запроса, сообщения формы или файла cookie, мы удалим все косые черты, добавленные с помощью магических кавычек, если эта функция будет включена. Это эффективно возвращает нас к тому, с чего мы начали.
Тема атак с использованием SQL-инъекций подробно обсуждается в разделе «Как устранить ошибки базы данных, вызванные кавычками / апострофами?». Если вы еще не уверены, что можете защитить себя от атак SQL-инъекций, используйте магические кавычки. Как только вы будете счастливы, у вас есть полное понимание всех проблем, отключите функцию волшебных цитат и избавьте себя от многих головных болей. Обратите внимание, что волшебные кавычки могут быть включены или выключены только с помощью файла php.ini или одного из файлов Apache .htaccess. Для получения дополнительной информации см. Приложение A, Конфигурация PHP.
 Переадресация по вызову по времени выключена 
Ссылка похожа на «короткий путь» к значению переменной. Ссылки часто требуются, когда мы используем функции и классы PHP, предмет, который мы обсудим далее в главе 2, Объектно-ориентированный PHP. Когда вы используете ссылку на переменную при вызове функции или метода класса, она определяется как передача по ссылке во время вызова. Рассмотрим этот пример:
 $result = myFunction(&$myVariable); 
Здесь &оператор говорит PHP использовать ссылку на переменную $ myVariable в качестве аргумента, а не создавать копию ее значения. Сейчас это обычно считается плохой практикой, поскольку это может сделать работу по пониманию чужого кода чрезвычайно сложной.
 Выключите это в php.ini, используя следующую команду: 
 allow_call_time_pass_reference = Off 
 Или же отключите его в файле .htaccess следующим образом: 
 php_flag allow_call_time_pass_reference off 
 Напишите повторно используемый код 
Легко сказать, я знаю, но если вы пишете больше, чем один PHP-скрипт, вам нужно подумать о том, как сделать ваш код многократно используемым, прежде чем вы начнете страдать от преждевременной потери волос. Технически это не совсем проблема переносимости как таковой, но если вы в конечном итоге будете работать с другими сайтами или приложениями, вы по достоинству оцените готовый код, который вы можете просто подключить к своему новому проекту. Кроме того, если вы пишете код, который другие люди будут интегрировать с существующими приложениями на своих веб-сайтах, вам необходимо упаковать его в форму, которая не предъявляет требований к коду, который они уже используют.
 Например, если ваше приложение имеет какую-то систему аутентификации пользователей, будет ли оно интегрироваться с той, которую они уже используют — системой, которая уже имеет большую базу данных пользователей, связанных с ней? 
Наилучшим подходом является написание объектно-ориентированного кода (основное внимание в главе 2 «Объектно-ориентированный PHP») с целью создания многократно используемых «компонентов». Некоторые люди утверждают, что написание объектно-ориентированного кода на PHP замедляет производительность приложения, и поэтому его следует избегать любой ценой. Что они забывают упомянуть, так это резкое повышение производительности, которое обеспечивает объектно-ориентированное программирование. В конце концов, быстрые программисты стоят дороже, чем быстрые микропроцессоры!
 Некоторые вещи, которые следует учитывать при измерении потенциала вашего кода для повторного использования: 

 Что происходит при изменении требований? 
 Насколько легко добавить новые функции в ваш код? 
 Вы все еще можете понять код после долгого периода времени? 
 Может ли ваш код быть легко интегрирован с другими приложениями? 
 Будут ли предположения, сделанные в вашем коде, применяться к вашей работе на других сайтах? 

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

  Напишите безопасные сценарии с PHP 4.2! 
 Учебное пособие, объясняющее важность написания сценариев с выключенным register_globals. 
 Обнаружение ошибок без лишних усилий (или лучше!) С помощью утверждений PHP 
 Использование строк 
 Zend предоставляет обзор основных функций, доступных для работы со строками.
 String Theory 
 DevShed предлагает углубленный взгляд на строки, вплоть до расширенных регулярных выражений Posix.

 Посмотрите другие главы Антологии PHP на SitePoint в ближайшие недели! Если вы не можете ждать, загрузите образцы глав или закажите свою собственную копию прямо сейчас ! 

































														


														

									

        
Share: