SQL-Ex blog
Одной из моих любимых команд SQL являлась QUOTENAME. При программировании генерации кода обычно возникает необходимость заключать строковое значение в кавычки и экранировать любые символы, совпадающие с теми, которыми вы ограничиваете строку, их удвоением. (А если у вас пара таких символов в строке, вам их потребуется уже четыре.) Например, чтобы взять следующую строку в одинарные кавычки (‘):
Чтобы иметь возможность использовать её в динамическом операторе или объявлении переменной, потребуется удвоить одинарную кавычку в строке:
Или, если вы Rob Volk (@sql_r на Twitter), и хотите создать раздражающую базу данных на вашем лучшем заклятом SQL Server, то, чтобы включить скобки в имя базы типа:
вам придется сделать так:
Удваивается закрывающая скобка, но не открывающая. Для экранирования можно использовать QUOTENAME. Параметрами этой функции являются строка и разделитель. По умолчанию удваивается скобка как у большинства имён SQL Server, хотя вы можете использовать любой символ для удвоения. Так для нашей строки:
Этот код вернет
| objectName | string | |
|---|---|---|
| Mr. O’Malley | [Mr. O’Malley] | ‘Mr. O»Malley’ |
Кажется, работает отлично, поэтому вы чувствуете, что, если вам потребуется нагенерировать некоторый код, вы сможете поступить так:
Выполните этот запрос в Management Studio. Вы увидите на вкладке результата строку, начинающуюся с приведенного выше текста. Проблема состоит в том, что QUOTENAME предназначена для закавычивания значений имен SQL Server, а поскольку в SQL Server имена не могут быть длиннее, чем 128 символов. на входе должно быть не более 128 символов (ниже покажем, что может быть и больше). Итак:
Когда вход превышает 128 символов, возвращается NULL без каких либо предупреждений. Это, мягко говоря, не то, что вы хотели. В моем случае я разработал генератор скрипта расширенных свойств, который принимает значение типа sql_variant и преобразует его к nvarchar(max). Я не тестировал входы, превышающие 128 символов, но коллега любезно предоставил мне строку размером порядка 8000 символов. К счастью, это не был рабочий сервер, где бы безостановочно звонил телефон поддержки.
Итак, я могу предложить использование QUOTENAME в рабочем коде только для квотирования реальных имен операторов SQL, и использовать более неуклюжий метод для других целей:
Этот код демонстирует один и тот же результат для обоих вариантов.
Следует заметить, что это (как и любая простая повторно исполняемая скалярная функция) просится для использования в качестве пользовательской функции. В версиях, предшествующих 2019, всегда однозначно советовали избегать их, т.к. они, мягко говоря, ограничивали производительность. В одних случаях падение производительности было незначительным, в других — существенными провалами. В SQL Server 2019 Microsoft изменила механизм выполнения некоторых скалярных функций, который будет «встраивать» код функции в план запроса, использующего эту функцию. В результате производительность, полученная для перекодируемого оператора и при использовании функции соизмеримы (даже для довольно сложных функций!).
Построим, например, в базе данных WideWorldImporters следующую функцию:
Выполнить функцию можно так:
И вы можете проверить, встраивается ли она, таким образом:
Этот запрос для нашей новой функции возвращает 1.
Встраиваемая или нет, вы не увидите каких либо изменений в этом простом примере — я просто хотел указать на это как на более ценную возможность в будущем. Подробнее о встраиваемых функциях смотрите в публикации Brent Ozar’а.
Наконец, давайте взглянем на немного туповатый трюк, который в целом полезен для определения того, наколько длинной может быть заковыченная строка. Меня интересует, какого максимального размера может быть вывод функции QUOTENAME. Если вы выполните следующий оператор:
вернет []]]]], что на 2 символа больше, чем исходная строка. Если у нас 128 символов ], мы должны получить SELECT 127*2+4 или 258 символов, которые должен вывести следующий оператор.
Мы могли бы это просто прочитать в документации о QUOTENAME, где говорится о результате nvarchar(258)! Следовательно, вот какого размера должна быть переменная/столбец, чтобы ее можно было обработать с помощью функции EscapeString:
Здесь максимальная длина — это не 2 миллиарда как у varchar(max), а максимальная длина, которую может иметь ваш источник данных. Конечно, когда вы используете это значение со всеми экранированными строками, оно будет выглядеть больше, чем результирующее значение, но просто потому, что нам требуется пространство для 258 символов на имя, что не означает, что нам требуется именно 258 символов. Это просто еще одно препятствие, с которым вы столкнетесь, строя пуленепробиваемый генератор кода.
Как экранировать кавычки в sql
Строка представляет собой последовательность символов, заключенных либо в одинарные кавычки ( `» ) — апострофы, либо в двойные кавычки ( `»‘ ). При использовании диалекта ANSI SQL допустимы только одинарные кавычки. Например:
Внутри строки некоторые последовательности символов имеют специальное назначение. Каждая из этих последовательностей начинается обратным слешем ( `\’ ), известным как escape-символ или символ перехода. MySQL распознает следующие escape-последовательности:
\0 Символ 0 ( NUL ) в ASCII коде. \’ Символ одиночной кавычки ( `» ). \» Символ двойной кавычки ( `»‘ ). \b Возврат на один символ. \n Символ новой строки (перевода строки). \r Символ перевода каретки. \t Символ табуляции. \z Символ (Control-Z) таблицы ASCII(26). Данный символ можно закодировать, чтобы обойти проблему, заключающуюся в том, что под Windows ASCII(26) означает конец файла (проблемы возникают при использовании ASCII(26) в выражении mysql database < filename) . \\ Символ обратного слеша. \% Символ процентов `%’ . Используется для поиска копий литерала `%’ в контекстах, где выражение `%’ в противном случае интерпретировалось бы как групповой символ (see section 6.3.2.1 Функции сравнения строк). \ `_’ Символ подчеркивания `_’ . Используется для поиска копий литерала `_’ в контекстах, где выражение `_’ в противном случае интерпретировалось бы как групповой символ (see section 6.3.2.1 Функции сравнения строк).
Обратите внимание на то, что при использовании `\%’ или `\_’ в контекстах некоторых строк будут возвращаться значения строк `\%’ и `\_’ , а не `%’ и `_’ .
Существует несколько способов включить кавычки в строку:
- Одиночная кавычка (апостроф) `» внутри строки, заключенной в кавычки `» , может быть записана как `»’ .
- Двойная кавычка `»‘ внутри строки, заключенной в двойные кавычки `»‘ , может быть записана как `»»‘ .
- Можно предварить символ кавычки символом экранирования ( `\’ ).
- Для символа `» внутри строки, заключенной в двойные кавычки, не требуется специальной обработки; его также не требуется дублировать или предварять обратным слешем. Точно так же не требует специальной обработки двойная кавычка `»‘ внутри строки, заключенной в одиночные кавычки `» .
Ниже показаны возможные варианты применения кавычек и escape-символа на примерах выполнения команды SELECT:
Если необходимо вставить в строку двоичные данные (такие как BLOB ), следующие символы должны быть представлены как escape-последовательности:
NUL ASCII 0. Необходимо представлять в виде `\0′ (обратный слеш и символ ASCII `0′ ). \ ASCII 92, обратный слеш. Представляется как `\\’ . ‘ ASCII 39, единичная кавычка. Представляется как `\» . » ASCII 34, двойная кавычка. Представляется как `\»‘ .
При написании программы на языке C для добавления символов экранирования в команде INSERT можно использовать функцию mysql_real_escape_string() из C API (see section 8.4.2 Обзор функций интерфейса C). При программировании на Perl можно использовать метод quote из пакета DBI для превращения специальных символов в соответствующие escape-последовательности (see section 8.2.2 Интерфейс DBI ).
Не следует забывать, что указанное свойство escape-символа должно использоваться во всех строках, которые могут содержать любые специальные символы, перечисленные выше.
В качестве альтернативы многие интерфейсы прикладного программирования (API) для MySQL предоставляют определенную возможность использования символов-заменителей, что позволяет вносить специальные маркеры в строку запроса и затем связывать с ними значения данных при выдаче результатов запроса.
Экранирование кавычек в php, javascript и sql
Здравствуйте, уважаемые читатели блога LifeExample, сегодня я бы хотел раскрыть тему экранирования кавычек в php, javascript и sql, рассказать что это такое и зачем нужно, а также привести несколько полезных примеров показывающих необходимость экранирования.
Что такое экранирование кавычек
Чтобы дать определение этому понятию, для начала приведу небольшой пример объявления строки.
Практически в любом языке программирования мы используем следующий принцип объявления строковой переменной:
Все, что содержится между кавычек — понимается интерпретатором как строка.
Если нам нужно передать в строковую переменную текст содержащий кавычки и мы попытаемся сделать это таким образом:
то произойдет ошибка, поскольку вместо одной строки интерпретатор увидит две:
- "Название моего блога: "
- " "
а между ними неизвестный ему оператор – lifeexample.ru .
Чтобы такого не происходило необходимо экранировать кавычки. В javascript, например, это будет выглядеть таким образом:
После данного практического примера можно дать определение понятию экранирования кавычек.
Экранирование кавычек – это действие, совершаемое над строковой переменной в ходе работы скрипта. Действие это позволяет использовать кавычки в строке. Частным но довольно распространенным способом экранирования является подстановка обратного слеша \ перед внутренними кавычками.
Php экранирование кавычек
В php экранировать кавычки можно несколькими способами, первый из них аналогичен рассматриваемому выше.
Например, мы имеем строку с авторской и прямой речью, которая содержит кавычки:
"Как же вы поживаете?" – спросила Екатерина Ивановна. "Ничего, живем понемножечку", – ответил Старцев (Чехов)
Чтобы вывести ее на страницу, в PHP следует делать одним из следующих способов.
Экранирование обратным слешем:
Экранирование одинарными кавычками
В случае, когда внутренних кавычек в строке много проще при объявлении строки использовать одинарные кавычки, а внутри нее двойные. Либо, наоборот, в зависимости от наличия в тексте тех или иных кавычек.
Зачем может понадобиться экранирование кавычек в PHP
Помимо разобранного примера с выводом строк, экранирование кавычек и других спец символов зачастую необходимо при работе с БД.
Чтобы не допустить, различного рода проблем при работе с базой данных, перед сохранением данных в таблицы можно использовать функцию addslashes
Обе эти функции являются стандартными в php и экранируют спецсимволы строк. Когда и какую использовать, зависит от конкретных задач. Например addslashes лучше использовать для сериализованной строки при записи ее в базу, а mysql_real_escape_string для всех пользовательских данных пришедших с формы на сайте.
В небольших web-приложениях, можно не использовать ручное экранирование addslashes или mysql_real_escape_string если включить "Магические кавычки" — magic_quotes_gpc
Зачастую магические кавычки включены по умолчанию на сервере, это можно узнать из информацией полученной при выполнении функции
javascript экранирование кавычек
Очень часто, особенно в javascript приходится работать со строками, содержащими HTML разметку.
В javascript экранирование кавычек происходит аналогичным образом, либо обратным слешем, либо использованием разного типа кавычек.
Пример с обратным слешем:
Пример с внутренними кавычками:
Когда строка с HTML разметкой слишком длинная и требует переноса строки, снова появляется необходимость экранирования, в этом случае уже не кавычек, а символа переноса строки
Если в данном примере не использовать обратный слешь перед переносом строки, то скрипт работать не будет.
Довольно редко, но можно столкнуться с задачей передать HTML разметку в сериализованной строке формата JSON. Если строка содержит символы переноса, то формат JSON будет нарушен.
Чтобы избежать этих проблем нужно прогнать текст с переносом строк через функцию JSON.stringify()
JSON.stringify() – доступна только после подключения библиотеки jquery.
Sql экранирование кавычек
В sql экранирование кавычек помимо разобранных нами в php и js способов — обратного слеша и внутренних кавычек, имеет еще одно решение.
Для экранирования кавычки в sql нужно их дублировать.
Убрать экранирование кавычек
Убрать экранирование кавычек в php можно стандартной функцией stripslashes();
В javascript не существует аналога stripslashes, но ведь мы всегда можем воспользоваться регулярным выражением, которое поможет нам убрать экранирование кавычек в javascript
В данной статье я постарался раскрыть тему экранирования кавычек в php, js, mysql и показать в каких случаях необходимо применять экранирование. Надеюсь, статья оказалась полезной. Подписывайтесь на рассылку, ставьте лайки, добавляйтесь в друзья ��
Читайте также похожие статьи:
Чтобы не пропустить публикацию следующей статьи подписывайтесь на рассылку по E-mail или RSS ленту блога.
How do I escape a single quote in SQL Server?
I am trying to insert some text data into a table in SQL Server 9.
The text includes a single quote ‘ .
How do I escape that?
I tried using two single quotes, but it threw me some errors.
eg. insert into my_table values(‘hi, my name»s tim.’);
14 Answers 14
Single quotes are escaped by doubling them up, just as you’ve shown us in your example. The following SQL illustrates this functionality. I tested it on SQL Server 2008:
Results
If escaping your single quote with another single quote isn’t working for you (like it didn’t for one of my recent REPLACE() queries), you can use SET QUOTED_IDENTIFIER OFF before your query, then SET QUOTED_IDENTIFIER ON after your query.
Many of us know that the Popular Method of Escaping Single Quotes is by Doubling them up easily like below.
we are going to look on some other alternate ways of escaping the single quotes.
1. UNICODE Characters
39 is the UNICODE character of Single Quote. So we can use it like below.
2. QUOTED_IDENTIFIER
Another simple and best alternate solution is to use QUOTED_IDENTIFIER. When QUOTED_IDENTIFIER is set to OFF, the strings can be enclosed in double quotes. In this scenario, we don’t need to escape single quotes. So,this way would be very helpful while using lot of string values with single quotes. It will be very much helpful while using so many lines of INSERT/UPDATE scripts where column values having single quotes.
The above mentioned methods are applicable to both AZURE and On Premises .
2 ways to work around this:
for ‘ you can simply double it in the string, e.g. select ‘I»m happpy’ — will get: I’m happy
For any charactor you are not sure of: in sql server you can get any char’s unicode by select unicode(‘:’) (you keep the number)
So this case you can also select ‘I’+nchar(39)+’m happpy’
The doubling up of the quote should have worked, so it’s peculiar that it didn’t work for you; however, an alternative is using double quote characters, instead of single ones, around the string. I.e.,
insert into my_table values(«hi, my name’s tim.» );
Also another thing to be careful of is whether or not it is really stored as a classic ASCII ‘ (ASCII 27) or Unicode 2019 (which looks similar, but not the same).
This isn’t a big deal on inserts, but it can mean the world on selects and updates.
If it’s the unicode value then escaping the ‘ in a WHERE clause (e.g where blah = ‘Workers»s Comp’) will return like the value you are searching for isn’t there if the ‘ in «Worker’s Comp» is actually the unicode value.
If your client application supports free-key, as well as copy and paste based input, it could be Unicode in some rows, and ASCII in others!
A simple way to confirm this is by doing some kind of open ended query that will bring back the value you are searching for, and then copy and paste that into notepad++ or some other unicode supporting editor.
The differing appearance between the ascii value and the unicode one should be obvious to the eyes, but if you lean towards the anal, it will show up as 27 (ascii) or 92 (unicode) in a hex editor.