Google Code Prettify - Как исправить escape-символ SQL

Я пытаюсь решить следующую проблему, так как она очень раздражает мой сайт. https://code.google.com/p/google-code-prettify/issues/detail?id=341&thanks=341&ts=1398085413

и ссылается на следующий файл кода prettify: https://code.google.com/p/google-code-prettify/source/browse/trunk/src/lang-sql.js?r=179

Проблема в том, что

  1. Когда в SQL создается строка, оканчивающаяся на «\», подсветчик считает, что она экранирована, хотя это не синтаксис T-SQL.
  2. Для воспроизведения используйте этот код в качестве исходного кода: (с установленным Google Code Prettify)

    <pre class="prettyprint lang-sql">
     SELECT @BUPath = 'c:\backups\' + @DBName + '-B4 CHANGE.bak'
     SELECT @BUName = @DBName + '-B4 CHANGE'
    </pre>
    

Я ожидаю, что код поймет, что косая черта перед кавычкой в ​​части «c:\backups\» не является экранирующим символом...

Я ожидаю, что эту строку нужно будет изменить, но я не уверен, как это сделать:

[PR['PR_STRING'],      /^(?:"(?:[^\"\\]|\\.)*"|'(?:[^\'\\]|\\.)*')/, null,
      '"\'']

скрипка, показывающая проблему: http://jsfiddle.net/JH5uj/5/


person AlexT82    schedule 21.04.2014    source источник


Ответы (1)


Я думаю, что определение PR_STRING на https://github.com/google/code-prettify/blob/master/src/lang-sql.js должен быть скопирован из какого-либо другого языка, где обратная косая черта является escape-символом.

/^(?:"[^"]*"|'[^']*')/

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

(Извините, что опоздал на вечеринку с этим, но я только что столкнулся с той же проблемой и нашел эту тему.)

person William Robertson    schedule 26.08.2015
comment
Используются ли двойные кавычки для строковых литералов в SQL Server? В Oracle xyz будет идентификатором, а не строкой. Если нет, то просто /^'[^']*'/ - person William Robertson; 27.08.2015
comment
Я проверил, и вы тоже можете потерять двойные кавычки. msdn.microsoft.com/en-us/library/ms179899.aspx - person William Robertson; 01.09.2015
comment
@WilliamRobertson Для SQL Server (T-SQL). 1) строковые литералы заключаются только в одинарные кавычки. 2) Обратная косая черта для T-SQL не является escape-символом. - person TT.; 10.11.2016
comment
В ANSI-SQL обратная косая черта в escape-символе, кроме одинарных и двойных кавычек. Таким образом, lang-sql реализует это как таковое, AFAICT, это не было скопировано вслепую. - person TT.; 10.11.2016
comment
@ТТ. - Это интересно. В Oracle SQL, конечно, нет escape-символа (мой фон), и, по-видимому, нет и в MS SQL, согласно OP. Я нашел это для Informix, который также мимоходом упоминает ANSI, но затем продолжает говорить, что ANSI SQL не позволяет экранировать кавычки с обратной косой чертой. Мне удалось найти только этот документ SQL-1992, который не упоминает об этом. - person William Robertson; 10.11.2016
comment
@ТТ. только что заметил, что вы говорите то же самое. Таким образом, lang-sql неправильно разрешать обратную косую черту для выхода из кавычки, верно? - person William Robertson; 10.11.2016
comment
(Отредактировано =) Да. ANSI-SQL не позволяет экранировать одинарные и двойные кавычки обратной косой чертой. - person TT.; 10.11.2016
comment
Tbh, я получил это по этой ссылке на IBM.com. У меня нет официальной ссылки на стандарт ANSI SQL. - person TT.; 10.11.2016