Экранирование (или что нужно знать для работы с текстом в тексте). Escape символ двойной кавычки в XML Встроенные простые типы

С давних пор стандарт предписывает для вставки обычных кавычек в HTML -текст применять конструкцию " Ибо внутри тегов кавычки "" используются для обозначения атрибутов.

Однако, мне пока не попадался броузер, который бы не показал как кавычку простой символ " ВНЕ каких-либо тегов. Так скажите, уважаемые коллеги, может быть, применение " вне тегов есть попросту никому не нужное занудство? Можно спокойно и не мудрствуя писать "? Особенно в текстах, где кавычек много, а соблюдение строгих дизайнерских правил (насчет правильного употребления национальных кавычек) неактуально.

ИМХО, многие так и делают... но не совсем понятен вопрос: если вы понимаете, что по стандартам нужно кавычки писать как ", но лениво, притом что куча сайтов работает и так, то чего вы ожидаете услышать? Думаю, что о том, будет ли отображение кавычек поддерживаться в новых версиях броузеров, не знает никто, поэтому скороее всего можно дать очевидную рекомендацию: не хотите проблем в дальнейшем на 100% - держитесь стандартов:) Но это вы и так знаете. Или вы ждете подтверждения: да занудство это все, забей, и через 10 лет все будет так же, я(Microsoft,Mozilla и.т.д) гарантирую?

Lynn «Кофеман»[досье]
да, кстати... сейчас полез читать, нигде не утверждается что кавычки нужно представлять в виде "
http://www2.stack.ru/~julia/HTML401/charset.html :

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

про то что, нужно использовать именно entity говорится только про и &:

Если автор хочет поместить в текст символ "" (десятичный код ASCII 62).

Во избежание путаницы со ссылками на символы (метка начала ссылки на символ) вместо символа "&" следует использовать ссылку "&" (десятичный код ASCII 38). Кроме того, ссылку "&" следует использовать и в значениях атрибутов, поскольку ссылки на символы внутри значений атрибута CDATA разрешены.

А вот как раз и ожидаю что-то вроде ответа Lynn: что такого стандарта собственно нет. Мне это даже в голову не пришло - моя информация из популярных учебников и из соображений "все так делают".

Или другой вариант: а вот если следовать новым стандартам, с которыми я в своей практике не сталкивался - вроде xhtml (именно вроде, xhtml я проверил), то такой фокус не пройдет. Стало быть, не надо создавать проблем с переносимостью написанного HTML -кода.

Ну или наконец: вы-то сами как делаете?

&, кстати, порождает аналогичный вопрос. В приведенном выше документе говорится "во избежание путаницы". Но путаница возможна, только если за & следует один из предусмотренных кодов. А если это, скажем, URL типа "..../script?A=1&B=2" ? Рискую ли я чем-либо, если по ошибке в качестве href указал такой URL (который, разумеется, при тесте работает корректно)? Чем-либо кроме той крайне маловероятной ситуации, что лет через 10 (когда сайт устареет или будет уже десять раз переписан) появится сущность с экстравагантным именем &B без завершающей; ? Иными словами - насколько тщательно надо проверять все подобные случаи?

Даниил, если вы уверены что с существующими кодами у вас проблем не возникает - то вы можете писать и просто &. Если в дальнейшем и появится новый код - то он, думаю, будет объявлен явно не в спецификации HTML 4.01, следовательно на нормально объявленный документ влиять не должен. Или вы расчитываете обеспечить себе поддержку будущих стандартов путем простого изменения схемы документа?

Даниэль Алиевский[досье]
В XML обычная кавычка как текст тоже никакой проблемы не представляет (соответственно и в XHTML, конечно). IMHO кавычки обычно переводят в " лишь по одной причине — не хочется писать две функции для приведения текста к безопасному виду при подстановке в XML/ HTML /XHTML.

Цель данного урока:

  • БИ должен знать формат записи языка XML
  • БИ должен уметь оформлять документ в виде XML - кода
  • БИ должен знать типы данных и уметь ими пользоваться
  • Примечание: Язык XML не настолько краток, как мы описали его в данном уроке. Мы рассматриваем только те возможности языка XML, которые будут использоваться в системе ODA-TM.

    XML. Основа

    XML был создан для структурирования, хранения и транспортировки информации.

    Следующий пример "Записка друга к другу", имеет XML вид:

    Николаю Ивана Напоминание Надеюсь, ты не забыл о нашей встрече

    Визуально можно представить этот код в следующем виде (Рис.1.).

    Код имеет отправителя и получателя информации, он также имеет заголовок и тело сообщения.

    Он предназначен для того, чтобы его кто-то обработал, отправил и отобразил.

    Но, тем не менее, этот документ XML не делает ничего. Это просто информация, завернутая в теги.

    XML – дерево

    XML имеет древовидную структуру. В документе всегда имеется корневой элемент (инструкция к дереву отношения не имеет). У элемента дерева всегда существуют потомки и предки, кроме корневого элемента, у которого предков нет, а также тупиковых элементов (листьев дерева), у которых нет потомков. Каждый элемент дерева находится на определенном уровне вложенности (далее - «уровень»). У элементов на одном уровне бывают предыдущие и следующие элементы.

    С помощью XML придумывайте собственные теги

    Для создании тегов (дескрипторов, элементов) стандартного формата не существует.

    Язык XML не имеет предопределенных тегов.

    • XML позволяет автору определить его собственные теги и его собственную структуру документа.
    • XML используется для передачи данных
    • XML представляет собой программно-аппаратно независимый инструмент для переноса информации.
    • XML, теперь так же важен для сети как HTML
    • XML является наиболее распространенным инструментом для передачи данных между разными приложениями
    • XML используется во многих аспектах веб-разработки, часто для упрощения хранения данных и обмена ими
    XML синтаксис

    Синтаксис правил XML очень просто и логичен

    • Все элементы XML должны иметь закрывающий тег
    • XML элементы должны быть правильно вложены (один в другой, и, ни в коем случае, не пересекаться)
    • XML – документы должны иметь корневой элемент (XML-документы должны содержать один элемент, который является родителем всех других элементов. Это элемент называется корневым элементом.
    • Значение XML – атрибута должно быть заключено в кавычки.
    Комментарии

    Если надо сделать какой-то фрагмент документа XML вообще "невидимым" для программы-анализатора, то его можно оформить как комментарий, записав перед ним символы < !-- , а после него - символы --> с двумя дефисами подряд.

    Например:

    < !-- Это комментарий -->

    Программа-анализатор пропустит всю эту конструкцию, даже не "заглянув" в нее.

    Такой синтаксис комментария накладывает на него два ограничения:

    • в комментарии нельзя записывать два дефиса подряд;
    • комментарий нельзя завершить дефисом.
    XML-элементы

    Элементом XML является все, начиная от начального тега элемента и заканчивая конечным.

    Элемент может содержать:

    • другие элементы
    • текст
    • атрибуты
    • или сочетание всех выше...
    XML Правила именования

    XML элементы должны следовать этим правилам именования:

    • Имена могут содержать буквы, цифры и другие символы
    • Имена не могут начинаться с номера или знака препинания
    • Имена не могут содержать пробелы
    Атрибуты

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

    В приведенном ниже примере, тип файла не имеет отношения к данным, но важен для программного обеспечения, которое может манипулировать элементом:

    computer.gif

    XML атрибуты должны быть заключены в кавычки

    Значения атрибутов всегда должны быть в кавычках. Либо одинарные или двойные кавычки могут быть использованы. Пример: для определения пола человека, элемент может быть записан так:

    Если значение атрибута само содержит двойные кавычки можно использовать одинарные кавычки, как в этом примере:

    или вы можете использовать символьные объекты: & &

    Несколько примеров использования типа данных Дата

    Дата как атрибут

    Tove Jani Reminder Don"t forget me this weekend!

    Дата как элемент

    10/01/2008 Tove Jani Reminder Don"t forget me this weekend!

    Дата как элемент расширенный

    10 01 2008 Tove Jani Reminder Don"t forget me this weekend!

    Атрибуты метаданных

    Эти идентификаторы могут быть использованы для определения XML-элементов.

    Пример:

    Tove Jani Reminder Don"t forget me this weekend! Jani Tove Re: Reminder I will not

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

    XML. Тип данных Встроенные простые типы Дата и время
    • dateTime содержит дату и время в формате CCYY-MM-DThh:mm:ss
    • duration - представляет временную длительность, которая выражена компонентами григорианских дней, часов, минут и секунд.

    Например: запись P1Y2M3DT10H30M45S означает один год (1Y), два месяца (2M), три дня (3DT), десять часов (10H), тридцать минут (30M) и 45 секунд (45S).

    Запись может быть сокращенной P120M означает 120 месяцев, а Т120М - 120 минут.

    • time содержит время в обычном формате hh:mm:ss
    • date содержит дату в формате CCYY-MM-DD
    • gYearMonth выделяет год и месяц в формате CCYY-MM
    • gYear означает год в формате CCYY
    • gMonthDay содержит месяц и день в формате MM-DD
    • gDay день месяца в формате DD
    • gMonth месяц в формате ММ
    Строки символьные

    string - основной символьный тип.

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

    • normalizedString - подтип типа - это строки, не содержащие символов перевода строки "\n", возврат каретки "\r" и горизонтальной табуляции "\t".
      • token - подтип типа normalizedString- нет, кроме того начальных и завершающих пробелов и несколько подряд идущих пробелов.
        • language - подтип token, определен для записи названия языка согласно рекомендации RFC 1766 , например, ru, en, de, fr.
        • NMTOKEN - подтип token, используется только в атрибутах для записи их перечисляемых значений.
        • Name - подтип token, составляют имена XML - последовательности букв, цифр, дефисов, точек, двоеточий, знаков подчеркивания, начинающиеся с буквы (кроме зарезервированной последовательности букв X, x, M, m, L, l в любом сочетании регистров) или знака подчеркивания. Имена, начинающиеся со строки, xml , используются самой спецификацией XML.
          • NCName - подтип name, не содержащий двоеточие. Определены три подтипа: ID, IDREF, ENTITY
    Двоичные типы
    • boolen - двоичное, логическое. Принимает значения: True или False (1 или 0)
    • base64Binary - двоичные целые числа в кодировке Base64
    • hexBinary - двоичные целые числа в шестнадцатеричной форме без всяких дополнительных символов
    Вещественные числа
    • decimal составляют вещественные числа, записанные с фиксированной точкой: 123.45, -0.48747798 и т.д.
    • double и float типы соответствуют стандарту IEEE754-85, записываются с фиксированной или плавающей точкой.
    Целые числа
    • integer - основной целый тип, содержащий числа с нулевым порядком, понимается как подтип decimal
    • number - определяет число (без ограничений на количество цифр); может содержать знак, дроби, а также показатель степени. Значения изменяются

    от 1.7976931348623157Е+308 до 2.2250738585072014Е-308

    • Перевод
    • Tutorial

    SQL инъекции, подделка межсайтовых запросов, поврежденный XML… Страшные, страшные вещи, от которых мы все бы хотели защититься, да вот только знать бы почему это все происходит. Эта статья объясняет фундаментальное понятие, стоящее за всем этим: строки и обработка строк внутри строк.

    Основная проблема Это всего лишь текст. Да, просто текст - вот она основная проблема. Практически все в компьютерной системе представлено текстом (который, в свою очередь, представлен байтами). Разве что одни тексты предназначены для компьютера, а другие - для людей. Но и те, и те, всё же остаются текстом. Чтобы понять, о чем я говорю, приведу небольшой пример:
    Homo Sapiens Suppose, there is the English text, which I don"t wanna translate into Russian
    Не поверите: это - текст. Некоторые люди называют его XML, но это - просто текст. Возможно, он не подойдет для показа учителю английского языка, но это - всё еще просто текст. Вы можете распечатать его на плакате и ходить с ним на митинги, вы можете написать его в письме свое маме… это - текст.

    Тем не менее, мы хотим, чтобы определенные части этого текста имели какое-то значение для нашего компьютера. Мы хотим, чтобы компьютер был в состоянии извлечь автора текста и сам текст отдельно, чтобы с ним можно было что-то сделать. Например, преобразовать вышеупомянутое в это:
    Suppose, there is the English text, which I don"t wanna translate into Russian by Homo Sapiens
    Откуда компьютер знает, как сделать это? Ну, потому что мы весьма кстати обернули определенные части текста специальными словами в забавных скобках, как, например, и. Поскольку мы сделали это, мы можем написать программу, которая искала бы эти определенные части, извлекала текст и использовала бы его для какого-нибудь нашего собственного изобретения.

    Иными словами, мы использовали определенные правила в нашем тексте, чтобы обозначить некое особое значение, которое кто-то, соблюдая те же правила, мог бы использовать.
    Ладно, это всё не так уж и трудно понять. А что если мы хотим использовать эти забавные скобки, имеющие какое-то особое значение, в нашем тексте, но без использования этого самого значения?.. Примерно так:
    Homo Sapiens < n and y >
    Символы "" не являются ничем особенным. Они могут законно использоваться где угодно, в любом тексте, как в примере выше. Но как же наша идея о специальных словах, типа? Значит ли это, что тоже является каким-то ключевым словом? В XML - возможно да. А возможно нет. Это неоднозначно. Поскольку компьютеры не очень справляются с неоднозначностями, то что-то в итоге может дать непредвиденный результат, если мы не расставим сами все точки над i и не устраним неоднозначности.
    Решить эту дилемму можно, заменив неоднозначные символы чем-то однозначным.
    Homo Sapiens Basic math tells us that if x < n and y > n, x cannot be larger than y.
    Теперь, текст должен стать полностью однозначным. "".
    Техническое определение этого - экранирование , мы избегаем специальные символы, когда не хотим, чтобы они имели свое особое значение.
    escape |iˈskāp| [ no obj. ] вырваться на свободу [ with obj. ] не заметить / не вспомнить [...] [ with obj. ] IT: причина быть интерпретированным по-разному [...]
    Если определенные символы или последовательности символов в тексте имеют особое значение, то должны быть правила, определяющие, как разрешить ситуации, когда эти символы должны использоваться без привлечения своего особого значения. Или, другими словами, экранирование отвечает на вопрос: "Если эти символы такие особенные, то как мне их использовать в своем тексте?" .
    Как можно было заметить в примере выше, амперсанд (&) - это тоже специальный символ. Но что делать, если мы хотим написать "


    Если ваши пользователи будут хорошими и добрыми, то они будут размещать цитаты старых философов, а сообщения будут иметь примерно следующий вид:

    Posted by Plato on January 2, 15:31

    I am said to have said "Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat."


    Если пользователи будут умниками, то они, наверное, будут говорить о математике, и сообщения будут такие:

    Posted by Pascal on November 23, 04:12

    Basic math tells us that if x < n and y > n, x cannot be larger than y.


    Хм... Опять эти осквернители наших скобок. Ну, с технической точки зрения они могут быть неоднозначными, но браузер простит нам это, правда?


    Хорошо, СТОП, что за черт? Какой-то шутник ввел javascript теги на ваш форум? Любой, кто смотрит на это сообщение на вашем сайте, сейчас загружает и выполняет скрипты в контексте вашего сайта, которые могут сделать не весть что. А это не есть хорошо.

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

    Что? Что говоришь, мальчишка? Ах, ты говоришь, "экранирование"? И ты абсолютно прав, возьми печеньку!
    Если мы применим экранирование к пользовательским данным до объединения их с запросом, то проблема решена. Для наших запросов к БД это будет что-то вроде:
    $name = $_POST["name"]; $name = mysql_real_escape_string($name); $query = "SELECT phone_number FROM users WHERE name = "$name""; $result = mysql_query($query);
    Просто одна строка кода, но теперь больше никто не может "взломать" нашу базу данных. Давайте снова посмотрим как будут выглядеть SQL-запросы, в зависимости от ввода пользователя:
    Alex
    SELECT phone_number FROM users WHERE name = "Alex"
    Mc"Donalds
    SELECT phone_number FROM users WHERE name = "Mc\"Donalds"
    Joe"; DROP TABLE users; --
    SELECT phone_number FROM users WHERE name = "Joe\"; DROP TABLE users; --"
    mysql_real_escape_string без разбора помещает косую черту перед всем, у чего может быть какое-то особое значение.


    Мы применяем функцию htmlspecialchars ко всем пользовательским данным, прежде, чем вывести их. Теперь сообщение вредителя выглядит так:

    Posted by JackTR on July 18, 12:56


    Обратите внимание, что значения, полученные от пользователи, на самом деле не "повреждены". Любой браузер парсит этот как HTML и выведет на экран все в правильной форме.

    Что возвращает нас к... Все вышеупомянутое демонстрирует проблему, характерную для многих систем: текст в тексте должно быть подвергнут экранированию, если предполагается, что он не должен иметь специальных символов. Помещая текстовые значения в SQL, они должны быть экранированы по правилам SQL. Помещая текстовые значения в HTML, они должны быть экранированы по правилам HTML. Помещая текстовые значения в (название технологии), они должны быть экранированы по правилам (название технологии). Вот и все.Для полноты картины Есть, конечно, другие способы борьбы с пользовательским вводов, который должен или не должен содержать специальные символы:
    • Validation
      Вы можете проверить, соответствует ли пользовательский ввод некоторой заданной спецификации. Если Вы требуете ввода числа, а пользователь вводит нечто другое, программа должна сообщить ему об этом и отменить ввод. Если все это правильно организовать, то нет никакого риска схватить "DROP TABLE users" там, где, предполагалось, пользователь введет "42". Это не очень практично, для избегания HTML/SQL-инъекций, т.к. часто требуется принять текст свободного формата, который может содержать "подковырки". Обычно валидацию используют в дополнение к другим мерам.
    • Sanitization
      Вы можете так же "втихую" удалить любые символы, которые считаете опасными. Например, просто удалить что-либо похожее на HTML-тег, что избежать добавления на ваш форум. Проблема в том, что вы можете удалить вполне законные части текста.
      Prepared SQL statements
      Есть специальные функции, делающие то, чего мы и добивались: заставляют БД понять различия между самим SQL-запросом и информацией, предоставленной пользователями. В РНР они выглядят примерно так:
      $stmt = $pdo->prepare("SELECT phone_number FROM users WHERE name = ?"); $stmt->execute($_POST["name"]);
      При этом отправка происходит в два этапа, четко разграничивая запрос и переменные. БД имеет возможность сначала понять структуру запроса, а потом заполнить его значениями.

    • В реальном мире, все это используется вместе для различных ступеней защиты. Вы должны всегда использовать проверку допустимости (валидацию), чтобы быть уверенным, что пользователь вводит корректные данные. Затем вы можете (но не обязаны) сканировать введенные данные. Если пользователь явно пытается "втюхать" вам какой-то скрипт, вы можете просто удалить его. Затем, вы всегда, всегда должны экранировать пользовательские данные прежде, чем поместить их в SQL-запрос (это же касается и HTML).

    Здравствуйте, уважаемые посетители сайта сайт! Продолжим тему о языке разметки XML и рассмотрим использование атрибутов. Атрибуты в XML элементах могут присутствовать, также как в HTML. Атрибуты обеспечивают дополнительную информацию об элементе.

    XML Атрибуты

    В HTML атрибуты обеспечивают дополнительную информацию об элементах:

    XML Атрибуты Должны Заключаться в Кавычки

    Значения атрибутов в xml всегда должны быть заключены в кавычки. Могут использоваться как одинарные, так и двойные кавычки. Для указания пола элемента человек (person) можно написать так:

    Если значение атрибута само по себе содержит двойные кавычки, вы можете использовать одинарные кавычки, как в этом примере:

    XML Элементы против Атрибутов

    Взгляните на следующие примеры:

    Виктория
    Петрова

    female
    Виктория
    Петрова

    В первом примере пол (sex) является атрибутом. В последнем, sex – это элемент. Оба примера предоставляют одну и ту же информацию.

    Нет правил о том, когда использовать атрибуты, а когда элементы. Атрибуты удобны в HTML. В XML я советую их избегать. Используйте вместо них элементы.

    Мой Любимый Способ

    Следующие три XML документа содержат в точности одинаковую информацию:

    XML атрибут date используется в первом примере:

    Расширенный элемент date используется в третьем: (ЭТО МОЙ ЛЮБИМЫЙ СПОСОБ):



    10
    01
    2008

    Петя
    Света
    Напоминание

    Избегать XML Атрибуты?

    Некоторые из проблем с использованием xml атрибутов:

    • атрибуты не могут содержать несколько значений (элементы могут)
    • атрибуты не могут содержать древовидные структуры (элементы могут)
    • атрибуты сложнее расширить (для будущих изменений)

    Не делайте подобным образом:


    XML Атрибуты для Метаданных


    Вася
    Света
    Напоминание
    Не забудь мне позвонить завтра!


    Света
    Вася
    Re: Напоминание
    ОК

    Атрибуты id выше используются для идентификации разных заметок. Они не являются частью заметки самой по себе.

    Что я пытаюсь здесь сказать – метаданные (данные о данных) следует хранить как xml-атрибуты, а сами данные хранить как элементы.

    Спасибо за внимание!.