Справочник по javascript на русском: Справочники и спецификации

Справочники и спецификации

`;document.write(t),showTopNotification()}}

• ARعربي
• ENEnglish
• ESEspañol
• FAفارسی
• FRFrançais
• IDIndonesia

• ITItaliano
• JA日本語
• KO한국어
• RUРусский
• TRTürkçe
• UKУкраїнська

• ZH简体中文

Мы хотим сделать этот проект с открытым исходным кодом доступным для людей во всем мире. Пожалуйста, помогите нам перевести это руководство на свой язык

КупитьEPUB/PDF

7 июня 2022 г.

Эта книга является учебником и нацелена на то, чтобы помочь вам постепенно освоить язык. Но когда вы хорошо изучите основы, вам понадобятся дополнительные источники информации.

Спецификация ECMA-262 содержит самую глубокую, детальную и формализованную информацию о JavaScript. Она определяет сам язык.

Вначале спецификация может показаться тяжеловатой для понимания из-за слишком формального стиля изложения. Если вы ищете источник самой достоверной информации, то это правильное место, но она не для ежедневного использования.

Новая версия спецификации появляется каждый год. А пока она не вышла официально, все желающие могут ознакомиться с текущим черновиком на https://tc39.es/ecma262/.

Чтобы почитать о самых последних возможностях, включая те, которые «почти в стандарте» (так называемые «stage 3 proposals»), посетите https://github.com/tc39/proposals.

Если вы разрабатываете под браузеры, то существуют и другие спецификации, о которых рассказывается во второй части этого учебника.

• MDN (Mozilla) JavaScript Reference – это справочник с примерами и другой информацией. Хороший источник для получения подробных сведений о функциях языка, методах встроенных объектов и так далее.

  Располагается по адресу https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference.

  Хотя зачастую вместо их сайта удобнее использовать какой-нибудь интернет-поисковик, вводя там запрос «MDN [что вы хотите найти]», например https://google.com/search?q=MDN+parseInt для поиска информации о функции

  parseInt.

• MSDN – справочник от Microsoft, содержащий много информации, в том числе по JavaScript (который там часто обозначается как JScript). Если вам нужно найти что-то специфическое по браузеру Internet Explorer, лучше искать там: https://msdn.microsoft.com/.

  Так же, как и в предыдущем случае, можно использовать интернет-поиск, набирая фразы типа «RegExp MSDN» или «RegExp MSDN jscript».

JavaScript – это развивающийся язык, в который постоянно добавляется что-то новое.

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

• http://caniuse.com – таблицы с информацией о поддержке по каждой возможности языка. Например, чтобы узнать, какие движки поддерживают современные криптографические функции, посетите: http://caniuse.com/#feat=cryptography.
• https://kangax.github.io/compat-table – таблица с возможностями языка и движками, которые их поддерживают и не поддерживают.

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

Пожалуйста, запомните эти ссылки (или ссылку на эту страницу) на случай, когда вам понадобится подробная информация о какой-нибудь конкретной возможности JavaScript.

Предыдущий урокСледующий урок

Поделиться

Карта учебника

• © 2007—2023  Илья Кантор
• о проекте
• связаться с нами
• пользовательское соглашение
• политика конфиденциальности

Справочники и спецификации

7 июня 2022 г.

Материал на этой странице устарел, поэтому скрыт из оглавления сайта.

Более новая информация по этой теме находится на странице https://learn.javascript.ru/manuals-specifications.

В этом разделе мы познакомимся со справочниками и спецификациями.

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

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

Самая полная и подробная информация по JavaScript и браузерам есть в справочниках.

Её объём таков, что перевести всё с английского невозможно. Даже сделать «единый полный справочник» не получается, так как изменений много и они происходят постоянно.

Тем не менее, жить вполне можно если знать, куда смотреть.

Есть три основных справочника по JavaScript на английском языке:

1. Mozilla Developer Network – содержит информацию, верную для основных браузеров. Также там присутствуют расширения только для Firefox (они помечены).

   Когда мне нужно быстро найти «стандартную» информацию по RegExp – ввожу в Google «RegExp MDN», и ключевое слово «MDN» (Mozilla Developer Network) приводит к информации из этого справочника.

2. MSDN – справочник от Microsoft. Там много информации, в том числе и по JavaScript (они называют его «JScript»). Если нужно что-то, специфичное для IE – лучше лезть сразу туда.

   Например, для информации об особенностях RegExp в IE – полезное сочетание:

   «RegExp msdn». Иногда к поисковой фразе лучше добавить термин «JScript»: «RegExp msdn jscript».

3. Safari Developer Library – менее известен и используется реже, но в нём тоже можно найти ценную информацию.

Есть ещё справочники, не от разработчиков браузеров, но тоже хорошие:

1. http://help.dottoro.com – содержит подробную информацию по HTML/CSS/JavaScript.
2. http://javascript.ru/manual – справочник по JavaScript на русском языке, он содержит основную информацию по языку, без функций для работы с документом. К нему можно обращаться и по адресу, если знаете, что искать. Например, так: http://javascript.ru/RegExp.
3. https://www.quirksmode.org – информация о браузерных несовместимостях. Этот ресурс сам по себе довольно старый и, в первую очередь, полезен для поддержки устаревших браузеров. Для поиска можно пользоваться комбинацией
   «quirksmode onkeypress» в Google.
4. https://caniuse.com – ресурс о поддержке браузерами новейших возможностей HTML/CSS/JavaScript. Например, для поддержки функций криптографии: https://caniuse.com/#feat=cryptography.
5. https://kangax.github.io/compat-table – таблица с обзором поддержки спецификации ECMAScript различными платформами.

Спецификация – это самый главный, определяющий документ, в котором написано, как себя ведёт JavaScript, браузер, CSS и т.п.

Если что-то непонятно, и справочник не даёт ответ, то спецификация, как правило, раскрывает тему гораздо глубже и позволяет расставить точки над i.

Спецификация ECMAScript

Спецификация (формальное описание синтаксиса, базовых объектов и алгоритмов) языка JavaScript называется ECMAScript.

Вы можете спросить: «Почему спецификация для JavaScript не называется просто «JavaScript», зачем существует какое-то отдельное название?»

Всё потому, что JavaScript™ – зарегистрированная торговая марка, принадлежащая корпорации Oracle.

Название «ECMAScript» было выбрано, чтобы сохранить спецификацию независимой от владельцев торговой марки.

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

Спецификации HTML/DOM/CSS

JavaScript – язык общего назначения, поэтому в спецификации ECMAScript нет ни слова о браузерах.

Главная организация, которая занимается HTML, CSS, XML и множеством других стандартов – Консорциум Всемирной паутины (World Wide Web Consortium, сокращённо W3C).

Информацию о них можно найти на сайте w3.org. К сожалению, найти в этой куче то, что нужно, может быть нелегко, особенно когда неизвестно в каком именно стандарте искать. Самый лучший способ – попросить Google с указанием сайта.

Например, для поиска document.cookie набрать document.cookie site:w3.org.

Последние версии стандартов расположены на домене dev.w3.org.

Кроме того, в том, что касается HTML5 и DOM/CSS, W3C активно использует наработки другой организации – WhatWG. Поэтому самые актуальные версии спецификаций по этим темам обычно находятся на https://whatwg.org/specs/.

Иногда бывает так, что информация на сайте https://dev.w3.org отличается от https://whatwg.org. В этом случае, как правило, следует руководствоваться https://whatwg.org.

Итак, посмотрим какие у нас есть источники информации.

Справочники:

• Mozilla Developer Network – информация для Firefox и большинства браузеров. Google-комбо: "RegExp MDN", ключевое слово «MDN».
• MSDN – информация по IE. Google-комбо: "RegExp msdn". Иногда лучше добавить термин «JScript»: "RegExp msdn jscript".
• Safari Developer Library – информация по Safari.
• http://help.dottoro.com – подробная информация по HTML/CSS/JavaScript с учётом браузерной совместимости. Google-комбо: "RegExp dottoro".
• http://javascript.ru/manual – справочник по JavaScript на русском языке. К нему можно обращаться и по адресу, если знаете, что искать. Например, так: http://javascript.ru/RegExp. Google-комбо: "RegExp site:javascript.ru".

Спецификации содержат важнейшую информацию о том, как оно «должно работать»:

• JavaScript, современный стандарт ES5 (англ), и предыдущий ES3 (рус).
• HTML/DOM/CSS – на сайте https://w3.org. Google-комбо: "document.cookie site:w3.org".
• …А самые последние версии стандартов – на https://dev.w3.org и на https://whatwg.org/specs/.

То, как оно на самом деле работает и несовместимости:

• https://quirksmode.org/. Google-комбо: "innerHeight quirksmode".

Поддержка современных и новейших возможностей браузерами:

• https://caniuse.com. Google-комбо: "caniuse geolocation".

Поделиться

Карта учебника

unicode — Какую кодировку использовать для хранения русского текста в файлах javascript в виде массива

спросил 12 лет, 4 месяца назад

Изменено 12 лет, 4 месяца назад

Просмотрено 3к раз

Я создаю страницу coldfusion, которая берет данные языкового перевода, хранящиеся в таблице в моей базе данных, и создает статические js-файлы для каждой языковой пары с английского на ___ и т.

 д…

Сейчас я начинаю работать с русским языком, другие языки у меня заработали нормально..

Однако при сохранении файла весь текст выглядит как вопросительные знаки. Даже когда я запускаю свое приложение для перевода, текст только для этого языка выглядит как все ?????

Я пытался записать его через cffile как utf-8 или ISO-8859-1, но ни один из них, похоже, не отображает правильно.

Есть предложения?

• Юникод
• coldfusion
• перевод

2

Вы пробовали ISO-8859-5? Я считаю, что это кодировка, которая «должна» использоваться для русского языка.

2

Обязательно используйте UTF-8 вместо любого другого типа кодировки. Вы должны убедиться, что:

• ваши шаблоны cfm были записаны на диск в кодировке UTF-8 (с этим отлично справляется notepad++, а также Eclipse или новый ColdFusion Builder)
• ваша база данных была создана с правильной кодовой страницей для типов данных nvarchar (и varchar)
• ваше соединение с базой данных обрабатывает UTF-8

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

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

Есть две категории, в которые можно отнести проблемы преобразования. Первый предполагает отправку данных в неправильном формате в клиентский API. Хотя это невозможно с API-интерфейсами Unicode, это возможно со всеми другими клиентскими API и приводит к мусорным данным.

Вторая категория проблем связана с символом, который не имеет эквивалента в окончательном наборе символов или в одном из промежуточных наборов символов. В этом случае используется замещающий символ. Это называется преобразованием с потерями и может произойти с любым клиентским API. Вы можете избежать преобразований с потерями, настроив базу данных на использование UTF-8 в качестве набора символов базы данных.

Преимущество UTF-8 перед любой другой кодировкой заключается в том, что вы можете обрабатывать любое количество языков в одной базе данных/клиенте.

Лично я никак не могу воспроизвести эту проблему. Является ли шаблон ColdFusion, который выполняет вызов, UTF-8? (с спецификацией или без для русского языка значения не имеет). В любом случае UTF-8 — это то, что вам следует использовать. Убедитесь, что вы используете редактор, совместимый с UTF-8. Это большинство вещей на Mac. В Windows вы можете использовать Scite или GVim.

Правильная кодировка для использования в .js — это любая кодировка, в которой находится родительская страница. Хотя существуют методы для обслуживания JavaScript с использованием другой кодировки для страницы, включая ее, они не работают во всех браузерах.

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

• ISO-8859-5. Однобайтовая кодировка с кириллицей в старших байтах, аналогичная кодовой странице Windows 1251. cp1251 будет кодировкой по умолчанию при сохранении в текстовом редакторе из русской установки Windows;

• или UTF-8. Многобайтовая кодировка, содержащая каждый символ. Все современные веб-сайты должны использовать кодировку UTF-8.

(ISO-8859-1 является западноевропейским и не содержит кириллицы. Она аналогична кодовой странице 1252, используемой по умолчанию при установке Windows на западе. Она вам бесполезна.)

Так что лучше сохранить как шаблон cf, так и файл js как UTF-8, и добавьте , если CF не подберет его автоматически.

Если вы не можете контролировать кодировку страницы, содержащей скрипт (например, потому что это третья сторона), вы не можете напрямую использовать любые символы, отличные от ASCII. Вместо этого вам придется использовать escape-символы строкового литерала JavaScript:

 var translation_ru= {
    launchMyCalendar: '\ u0417\u0430\u043f\u0443\u0441\u043a \u041c\u043e\u0439 \u043a\u0430\u043b\u0435\u043d\u0434\u0430\u0440\u044c'
};
 

при сохранении в файл это «·ÐßãáÚ ¼ÞÙ ÚÐÛÕÝÔÐàì», поэтому кодировка неверна

Похоже, вы сохранили как cp1251 (т. е. кодовая страница по умолчанию на русской машине), а затем скопировали файл на западный сервер, где по умолчанию используется кодовая страница cp1252.

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

Да, это была причина, по которой я больше не использовал его. EmEditor (коммерческий) и Notepad++ (с открытым исходным кодом) являются хорошей заменой.

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя адрес электронной почты и пароль

Опубликовать как гость

Электронная почта

Обязательно, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Библиотека JavaScript обновлена ​​для удаления файлов из российских систем • Реестр

Разработчик библиотеки JavaScript node-ipc, которая используется в популярном фреймворке vue. js, намеренно ввел критическую уязвимость в системе безопасности, которая для некоторых пользователей сети может разрушить их файлы компьютеров.

Брэндон Нодзаки Миллер, также известный как RIAEvangelist на GitHub, создал node-ipc, который извлекается примерно миллион раз в неделю из реестра NPM и описывается как «модуль межпроцессного взаимодействия для Node, поддерживающий сокеты Unix, TCP, TLS и UDP».

Похоже, Миллер намеренно изменил свой код, чтобы перезаписать данные хост-системы, а затем изменил код, чтобы отобразить сообщение с призывом к миру во всем мире в знак протеста против вторжения России в Украину. GitHub в среду объявил об этой уязвимости критической, отслеживаемой как CVE-2022-23812.

«Вредоносный код был предназначен для перезаписи произвольных файлов в зависимости от географического положения IP-адреса пользователя», — говорится в сообщении Microsoft.

В период с 7 по 8 марта были выпущены версии 10. 1.1 и 10.1.2 библиотеки. При импорте в качестве зависимости и запуске в рамках проекта они проверяли, имеет ли хост-компьютер IP-адрес в России или Беларуси, и если да, перезаписывали все файлы, которые могли, символом сердца. Вскоре после этого была выпущена версия 10.1.3 без этой деструктивной функциональности; 10.1.1 и 10.1.2 были удалены из реестра NPM.

Затем была опубликована версия 11, а на следующей неделе — версия 9.2.2. Оба принесли новый пакет Миллера под названием Peacenotwar, который создает файлы WITH-LOVE-FROM-AMERICA.txt на рабочем столе пользователя и в папках OneDrive. Этот текстовый файл должен содержать сообщение от разработчика, в котором среди прочего говорится: «Война — это не ответ, какой бы плохой она ни была», хотя некоторые люди сообщали, что файл был пуст.

Всякий раз, когда node-ipc версии 11 или 9.2.2 используются как зависимость другим проектом, они вносят мирноутвар и запускают его, оставляя файлы на компьютерах людей. Версия 9.2.2 исчезла из реестра NPM вместе с деструктивными версиями 10.1.x. Vue.js, например, принес node-ipc 9.2.2, пока он был доступен, поскольку 9.x считается стабильной ветвью, а это означает, что был период, когда у некоторых разработчиков Vue могли неожиданно появляться файлы .txt.

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

Хронология событий была задокументирована отделом информационной безопасности Snyk. Мы отмечаем, что на целевой странице модуля node-ipc в NPM указано: «Начиная с v11 этот модуль использует модуль мира, но не войны».

Миллер защитил свой модуль PeacenotWar на GitHub, заявив, что «это общедоступно, задокументировано, лицензировано и имеет открытый исходный код». Ранее было отмечено более 20 проблем с node-ipc из-за его плохого поведения, а сейчас гораздо больше проблем с Peacenotwar.

В некоторых комментариях творение Миллера упоминается как «программное обеспечение протеста». Другие могут назвать это вредоносным ПО. Программист был недоступен для комментариев.

Кто-то даже утверждал, что у американской неправительственной организации свои производственные файлы в одной системе были уничтожены node-ipc, поскольку они запускали библиотеку на сервере мониторинга в Беларуси с IP-адресом, который запускал код очистки данных.

• Наблюдаю за вами с помощью Vue to a Kill: разработчики Викимедиа отказываются от React для преобразования JavaScript, несмотря на жалобы
• Как один разработчик сломал Node, Babel и тысячи проектов с помощью 11 строк JavaScript
• Travis CI незаметно исправил ошибку, из-за которой раскрывались секретные ключи
• Беспокоитесь о случайных угрозах вредоносного ПО npm? Это встречается чаще, чем вы думаете
• Разработчик JavaScript намеренно испортил собственные популярные пакеты npm, чтобы подчеркнуть свою точку зрения

Продолжающийся рост JavaScript-фреймворка Node. js дал миру совершенно новый тип уязвимости программного обеспечения.

Менеджером пакетов Node является NPM, который в настоящее время контролируется и принадлежит GitHub вместе с реестром модулей NPM. Этот инструмент позволяет приложениям Node автоматически извлекать другие библиотеки кода непосредственно из онлайн-репозиториев. Это приводит к огромному количеству загрузок многих модулей, а это означает, что небольшие изменения кода могут очень быстро распространяться на большое количество компьютеров.

Версия node-ipc для сброса файлов была включена в версию 3.1 Unity Hub, инструмента для чрезвычайно популярного игрового движка Unity, хотя он был удален в тот же день.

«Это исправление устраняет проблему, из-за которой сторонняя библиотека могла создать пустой текстовый файл на рабочем столе людей, использующих эту версию выпуска», — написала команда Unity. «Хотя это было неприятно, проблема не включала вредоносные функции. Любой пользователь, у которого этот файл появился на рабочем столе после обновления Unity Hub, может удалить этот файл».