javascript - одинарные - экранирование кавычек js




Когда нужно использовать двойные или одинарные кавычки в JavaScript? (20)

console.log("double"); vs console.log('single');

Я вижу все больше и больше библиотек JavaScript, использующих одинарные кавычки при обработке строк. Каковы причины использования одного над другим? Я думал, что они очень взаимозаменяемы.


Изучение плюсов и минусов

В пользу одинарных кавычек

  • Меньше визуального беспорядка.
  • Создание HTML: атрибуты HTML обычно ограничиваются двойными кавычками.

elem.innerHTML = '<a href="' + url + '">Hello</a>';
Однако одинарные кавычки так же легальны в HTML.

elem.innerHTML = "<a href='" + url + "'>Hello</a>";

Кроме того, встроенный HTML обычно является анти-шаблоном. Предпочитают шаблоны.

  • Создание JSON: в JSON допускаются только двойные кавычки.

myJson = '{ "hello world": true }';

Опять же, вам не нужно создавать JSON таким образом. JSON.stringify () достаточно часто. Если нет, используйте шаблоны.

В пользу двойных кавычек

  • Удваивать проще, если у вас нет цветового кодирования. Как в консольном журнале, так и в какой-то форме источника.
  • Сходство с другими языками: в программировании оболочки (Bash и т. Д.) Существуют строковые литералы с одной кавычкой, но escape-коды не интерпретируются внутри них. C и Java используют двойные кавычки для строк и одинарные кавычки для символов.
  • Если вы хотите, чтобы код был действительным JSON, вам нужно использовать двойные кавычки.

В пользу обоих

В JavaScript нет никакой разницы. Поэтому вы можете использовать то, что сейчас удобно. Например, следующие строковые литералы производят одну и ту же строку:

    "He said: \"Let's go!\""
    'He said: "Let\'s go!"'
    "He said: \"Let\'s go!\""
    'He said: \"Let\'s go!\"'

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


Одиночные цитаты

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

Одиночные кавычки:

Нет предпочтений:

Двойные кавычки:


Давайте посмотрим, что делает ссылка.

Внутри jquery.js каждая строка имеет двойные кавычки.

Итак, теперь я буду использовать строки с двойными кавычками. (Я использовал сингл!)


Если вы делаете встроенный JavaScript (возможно, «плохой», но избегаете этого обсуждения), я считаю, что одинарные кавычки - это ваш единственный вариант для строковых литералов.

например, это прекрасно работает:

<a onclick="alert('hi');">hi</a>

Но вы не можете обернуть «привет» в двойные кавычки, используя любой способ экранирования, о котором я знаю. Даже &quot; который был бы моим лучшим предположением (поскольку вы избегаете кавычек в значении атрибута HTML) не работает для меня в Firefox. \" не будет работать, потому что на данный момент вы ускользаете для HTML, а не для JavaScript.

Итак, если название игры согласовано, и вы собираетесь сделать некоторые встроенные JavaScript в части вашего приложения, я думаю, что одинарные кавычки являются победителями. Кто-то, пожалуйста, поправьте меня, если я ошибаюсь.


Если вы используете jshint , это приведет к возникновению ошибки, если вы используете строку двойной кавычки.

Я использовал его через Yeoman scafflholding AngularJS, но, возможно, есть способ настройки этого.

Кстати, когда вы обрабатываете HTML в JavaScript, проще использовать одиночную кавычку:

var foo = '<div class="cool-stuff">Cool content</div>';

И, по крайней мере, JSON использует двойные кавычки для строк-повторов.

Нет тривиального способа ответить на ваш вопрос


Еще одна вещь, которую вы можете рассматривать как причину перехода от двойных кавычек к одинарным кавычкам, - это увеличение популярности серверных сценариев. При использовании PHP вы можете передавать переменные и анализировать функции javascript, используя строки и переменные в PHP.

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

Пример. Мне нужно запустить функцию javascript, используя переменную с моего сервера.

public static function redirectPage( $pageLocation )
{
    echo "<script type='text/javascript'>window.location = '$pageLocation';</script>";
}

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

Цитата из документов PHP : «Самая важная особенность строк с двойными кавычками - это то, что имена переменных будут расширены. Подробнее см.« Анализ строк ».


Наиболее вероятной причиной использования single vs double в разных библиотеках является предпочтение программиста и / или согласованность API.

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

Использование другого типа цитаты в качестве литерала:

alert('Say "Hello"');
alert("Say 'Hello'");

... но это может усложниться ...

alert("It's \"game\" time.");
alert('It\'s "game" time.');

Другим вариантом, новым в ES6, являются литералы шаблонов, которые используют символ back-tick :

alert(`Use "double" and 'single' quotes in the same string`);
alert(`Escape the \` back-tick character in a string`);

Литералы шаблонов предлагают чистый синтаксис для: интерполяции переменных, многострочных строк и т. Д.


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

Компилятор будет выполнять манипуляции с строками в строке с двойными кавычками, оставив одну строку с кавычками буквально нетронутой. Это использовало для того, чтобы «хорошие» разработчики решили использовать одинарные кавычки для строк, которые не содержали контрольные символы, такие как \n или \0 (не обрабатывались в одинарных кавычках) и двойные кавычки, когда они нуждались в анализируемой строке (при небольшой стоимости в цикле процессора для обработки строки).


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

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

  • Стиль дома: некоторые группы разработчиков уже используют одно соглашение или другое.
  • Требования к стороне клиента: будете ли вы использовать кавычки в строках? (См. Ответ Ади).
  • Язык на стороне сервера: люди VB.Net могут использовать одиночные кавычки для java-скрипта, чтобы скрипты могли быть созданы на стороне сервера (VB.Net использует двойные кавычки для строк, поэтому строки java-script легко различаются если они используют одинарные кавычки).
  • Код библиотеки. Если вы используете библиотеку, использующую определенный стиль, вы можете использовать тот же стиль самостоятельно.
  • Личные предпочтения: вы можете отличить один или другой стиль.

Технически нет никакой разницы, это только вопрос стиля и условности.

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

Я лично следую этому.

ОБНОВЛЕНИЕ: Похоже, что мистер Крокфорд crockford и теперь рекомендует использовать двойные кавычки по всему миру :)


Я бы хотел сказать, что разница чисто стилистическая, но я действительно сомневаюсь. Рассмотрим следующий пример:

/*
   Add trim() functionality to JavaScript...
    1. By extending the String prototype
    2. By creating a 'stand-alone' function
   This is just to demonstrate results are the same in both cases.
*/

// Extend the String prototype with a trim() method
String.prototype.trim = function() {
 return this.replace(/^\s+|\s+$/g, '');
};

// 'Stand-alone' trim() function
function trim(str) {
 return str.replace(/^\s+|\s+$/g, '');
};

document.writeln(String.prototype.trim);
document.writeln(trim);

В Safari, Chrome, Opera и Internet Explorer (протестировано в IE7 и IE8) это вернет следующее:

function () {
 return this.replace(/^\s+|\s+$/g, '');
}
function trim(str) {
 return str.replace(/^\s+|\s+$/g, '');
}

Однако Firefox даст немного другой результат:

function () {
    return this.replace(/^\s+|\s+$/g, "");
}
function trim(str) {
    return str.replace(/^\s+|\s+$/g, "");
}

Одиночные кавычки были заменены двойными кавычками. (Также обратите внимание, как пространство отступа было заменено четырьмя пробелами.) Это создает впечатление, что по крайней мере один браузер анализирует JavaScript внутри, как будто все было написано с использованием двойных кавычек. Можно подумать, что Firefox меньше времени для разбора JavaScript, если все уже написано в соответствии с этим стандартом.

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

Заключение: Думаю, нам нужно больше исследовать это.

Редактировать: Это может объяснить результаты теста Питера-Поля Коха еще в 2003 году.

Кажется, что одиночные кавычки иногда бывают быстрее в Windows Explorer (примерно 1/3 из моих тестов показывает более быстрое время отклика), но если Mozilla показывает разницу вообще, она обрабатывает двойные кавычки немного быстрее. В Opera я не обнаружил никакой разницы.

Edit 2014: Современные версии Firefox / Spidermonkey больше не делают этого.


Единственное различие проявляется в следующем:

'A string that\'s single quoted'

"A string that's double quoted"

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


Просто соблюдайте последовательность в том, что вы используете. Но не подведи свой уровень комфорта.

"This is my string."; // :-|
"I'm invincible."; // comfortable :)
'You can\'t beat me.'; // uncomfortable :(
'Oh! Yes. I can "beat" you.'; // comfortable :)
"Do you really think, you can \"beat\" me?"; // uncomfortable :(
"You're my guest. I can \"beat\" you."; // sometimes, you've to :P
'You\'re my guest too. I can "beat" you too.'; // sometimes, you've to :P

Обновление ES6

Использование синтаксиса шаблона литерала .

`Be "my" guest. You're in complete freedom.`; // most comfort :D

В JavaScript нет разницы между одиночными и двойными кавычками.

Спецификация важна:

Возможно, существуют различия в производительности, но они абсолютно минимальны и могут меняться каждый день в соответствии с реализацией браузеров. Дальнейшее обсуждение бесполезно, если ваше приложение JavaScript не содержит сотни тысяч.

Это похоже на бенчмарк, если

a=b;

быстрее, чем

a = b;

(дополнительные пробелы)

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


Если вы прыгаете вперед между JavaScript и C #, лучше всего тренировать пальцы для общего соглашения, которое является двойным кавычками.


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

Легенда о разнице скоростей может исходить из мира PHP, где две кавычки имеют другое поведение.


Вы можете использовать одинарные кавычки или двойные кавычки. Это позволяет вам, например, легко вставлять javascript внутри атрибутов HTML, без необходимости избегать кавычек. То же самое, когда вы создаете javascript с PHP.

Общая идея такова: если можно использовать такие цитаты, которые вам не нужно бежать. Меньше экранирования = лучший код.


Есть люди, которые утверждают, что имеют разницу в производительности: старая нить списка рассылки . Но я не мог найти ни одного из них для подтверждения.

Главное - посмотреть, какие цитаты (двойные или одиночные) вы используете внутри своей строки. Это помогает снизить количество побегов. Например, когда вы работаете с html внутри своих строк, проще использовать одинарные кавычки, чтобы вам не приходилось избегать всех двойных кавычек вокруг атрибутов.


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

"This is my #{name}"

ES6 использует обратные тики (`) для строк шаблонов. Вероятно, это имеет вескую причину, но при кодировании это может быть громоздким для изменения символа строковых литералов из кавычек или двойных кавычек для обратных тиков, чтобы получить функцию интерполяции. CoffeeScript может быть не идеальным, но использование одного и того же символа строковых литералов везде (двойные кавычки) и всегда быть способным интерполировать - хорошая функция.

`This is my ${name}`

Просто добавьте свои 2 цента: несколько лет назад я работал с JS и PHP, я привык использовать одинарные кавычки, поэтому я могу набирать escape-символ ('\'), не избегая его. Я обычно использовал его при вводе необработанных строк с файловыми путями и т. Д. ( http://en.wikipedia.org/wiki/String_literal#Raw_strings )

Во всяком случае, мое соглашение закончилось тем, что стало использовать одинарные кавычки в сырых строках типа идентификатора, например if (typeof s == 'string') ...(в которых escape-символы никогда не использовались никогда) и двойные кавычки для текстов , например «Эй, что случилось?». Я также использую одинарные кавычки в комментариях как типографское соглашение для отображения имен идентификаторов. Это просто эмпирическое правило, и я отключаюсь только тогда, когда это необходимо, например, при вводе строк HTML '<a href="#"> like so <a>'(хотя вы также можете отменить цитаты). Я также знаю, что в случае JSON для имен используются двойные кавычки, но за пределами этого лично я предпочитаю одиночные кавычки, когда экранирование никогда не требуется для текста между кавычками document.createElement('div').

Итог, и, как некоторые из них упоминали / намекали, выбирали конвенцию, придерживались ее и только отклонялись, когда это было необходимо.





conventions