ну вот. предлагаю собрать коллекцию всех уязвимостей в JavaScript.
цель - вовсе не повредничать и обидеть программистов, а совсем наоборот.
сейчас мы все грани революции в web-программирование. я о том, что уже назвали web 2.0.
в скором времени JavaScript будет играть чуть- ли не решающую роль в разработке веб-страниц и тем более веб-приложений.
на мой взгяд, он к этому ещё не совсем готов.
предлагаю нам всем собраться и найти всё то, чего нам не хватает в JS.
затем мы сможем делать всё что угодно с нашим архивом: наивно отсылать разработчикам, писать плагины к браузерам, писать грамотные библиотеки с обходом лагов, и т.п. что в голову взбредёт.
мы будем знать свои проблемы.

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

ну вот.

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

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

чтобы не запутаться в комментариях, предлагаю писать всё это дело по номерам и выделять жирным и цветом. причем, предлагаю выделять синим - те возможности, которые отсутствуют в JS полностью, красным - те, которые отсутствуют в одном из браузеров, а в другом имеют обходное решение или извращения, а также просто извращения и зелёным - html.

итак, начну.
первое, что приходит в голову:
хотелось бы
1. цикл с возможностью задания паузы между единичными выполнениями, который мог бы возвращать результат после каждого из своих выполнений
как обходим: используем в качестве цикла функцию, в которой указываем счетчик и вызываем её с помощью setTimeout() или setInterval().
Добавлено @ 17:54
1. HTML: <SELECT> с возможностью ввода текста + подбор из опций соотвутствующих записей.
Добавлено @ 17:56
так же предлагаю договорится, что сюда НЕ пишем только то, что одинаково правильно функционирует в трех браузерах - MSIE, Firefox и Opera.

Это сообщение отредактировал(а) Alx - 9.2.2006, 17:51

Это называется не уязвимости, а недостатки или баги (или-или).

3. Медленное быстродействие как в вычислениях, так и в доступе к объектам.

4. Утечка памяти в анонимных функциях в ie.

5. неуклюжесть в определении свойств - margin - border - padding и очень оригинальное определение width c учётом этих свойств.

6. и там - и там - одни враги.

А давай потом организуем W3C 2.0, в котором этот список будет руководством к действию. Будем мировую моду определять, чем плохо?

По 1-му: здесь 2 подхода к описанию программ. Первый: сопрограммы - процесс описан в виде цикла с паузами. Это то же, что вместо пауз будут запросы на обмен с соседними процессами. Второй: пишем всё как программы, которые в идеале стремятся к нулевому времени исполнения. В JS реализован 2-й, а в других языках непоследовательно - элементы 1-го - паузы, например. Поэтому загвоздка не в паузах, а в чистом 1-м подходе - нигде не писать в стиле сопрогамм. Язык с сопрограммами - будет совсем другой язык.

По 2-му пункту (select, точнее, combo-box): с ним чаще вспоминается не отсутствие комбобокса, а особые функции добавления/убирания опций. В своё время их было сложно реализовать в общем порядке, сделали специальные add(). А в IE до сих пор все стили неприменимы к объекту select.

В общем - недостатков - сотни, их как раз хватит на нашу плодотворную работу в комитете W3C 2.0 в течение пары-тройки лет

Скудная работа с картинками
Практически отсутсвие работы с файлами
Open-source
Кроссбраузерность

12345c
я ничего такого глобального не предлагал, хотя в принципе, наверное, ты прав, я погорячился
я просто предлагаю обобщить всё то, что хотелось бы, а не работает.
не в глобальном плане, а конекретные примеры, которые очень связывают руки.

а с w3c это ты классно придумал

Этого на толстую книгу хватит. Которые почти так и пишутся (Гудман - библия) - свойство - применимость в версиях и с какой версии. Пройтись по форумам - таких данных много наберётся, и работы много. Я тоже подумывал над тем, как это всё систематизировать, чтобы росла коллективная база знаний. Но не текстовая - книги писать некому, а некий движок IDE с контекстными подсказками. Пишешь метод в одном стиле - тебе подсказки совместимых подобных методов. Как бы туда ещё включить наводящие ключевые слова? Типа. сохранение в файл - > FileSystemObject

Давайте, давайте больше недостатков. Я их в свою статью вставлю ;)

(Хотя, по моему, весь JS-это один большой недостаток... но это мое ИМХО)

По поводу отсутствия delay (или чего-то в этом роде): это, по-моему, вполне намеренная фича. Скрипт не должен захватывать управление (по кр. мере, на продолжительное время) -- соответственно, весь тайминг может быть реализуем только через setTimeout() / setInterval().

По поводу отсутствия работы с файлами: безопасность. Вы представьте, что будет, если любой скрипт на любом сайте сможет с вашими системными файлами работать?

По поводу быстродействия (вернее, медленнодействия): а чего еще ждать от языка, в котором все (включая даже числа) является объектами? (Причем в каждом -- хэш-словарь для компонент/аттрибутов, и т.п.)

Откуда такая уверенность?

А эти недостатки будут услышаны людьми свыше?

Я напишу не недостаток языка, а такую штуку:
так как пишем мы это дело в блокноте (ну или другом редакторе) возникают часто проблемы с кодом, и их бы проследить, а такой возможности нету. То есть Отладка программы... (Debug вроде называется). Может я конечно ошибаюсь- в некоторых редакторах это есть, ноя не видел...
А то иногда в циклах путаешься (когда они громоздкие) а следиьт одними alert'ами не удобно

Innuendo,
ну, может, просто смотреть на какой строке ошибка и исправлять?
а то ведь с дебагером и писать не интересно...

Alx,
ну не знаю... очнеь часто пишет строку, а ты понимаешь что это только при каком-то условии цикла...
всё равно видеть все ходы цикла гораздо удобнее

Берёшь Firefox, ставишь плагин venkman и вот тебе полноценный дибагер
Добавлено @ 00:11

Саня, ты прикалываешься ))) Не интересно, когда 10 строк, а если 20 кБ кода, то с распечаткой с ума сойти можно.

ну не наю)))
я как-то всю жизнь пока обходился...)

можн и дальше обходится.. зато с ней можно скэономить время поиска ошибки.

Очень хочеться поддержки многозадачности, что то типа:

Возникнет масса проблем с синхронизацией, для решения можно ввести synchronized ключевое слово. Dead lock'и можно отследить, хотя если копнуть глубже можно найти кск другие скрипты поддерживающие треды решили сии проблемы. В любом случе множество тредов просто необходимо в AJAX приложениях, уже сейчас сам XMLHttpRequest и его события отрабатываються в отдельном треде.


Это не задача JS, а компонент браузера. Стили, разметку, фичи, всё это к JS не приписываем, язык только управляет этими обьектами


В смысле? В CSS стилях названия содержат '-' что являеться оператором в JS, потому именование типа backgroundColor ИМXО очень даже подходящее. Если ты о формате общих свойств border, margin и т.д., то это не к JS, а к спецификации CSS


Это опять же браузерный обьект Мозилла(Gecko) и Safari имеют canvas, очень даже удобно рисовать. Xотя когдабраузеры начнут свободно понимать SVG и подключат API к JS, то можно будет из JS работать с SVG примитивами, вот это будет действительно "Флешевая анимация"

От себя добавлю:

• скудный язык, приходиться много работать с DOM коллекциями, а удобных итераторов нет. Самая плохая реализация for in тоже в JS, т.к. не удобно, перечисляет всё, что правильно для JS, т.к. у обьектов и методы и поля это одно и тоже.
• нет хороших коллекций, всё что имеем это массивы и обьекты. Обьекты наследуют прототип Object, так что даже пустой обьект полон всего, отсюда понимаем почему for in не удобно. Требуеться словарь (ключь=>значение), множества, кортежи и другое.
• нет человеческого API у существующих коллекций, в языке где в основе лежат closures пользуем for(var i; i<length; i++) для перебора, а с ключами вообще лажа. Вообще это позорно...
• нет пространств имён/пакетов/модулей или любого другого механизма контроля видимости кода. Сейчас ещё не актуально, но в будущем может понадобиться. Сюда хорошо бы дополнить загрузку кода с сервера (только с домена страницы) нормальным API, а не создаванием скриптов в ручную, что не везде работает, да и "грязно"

В целом язык уже не молод, но ещё сырой на текущее время, а учитывая что вводиться он везде и повсеместно (вернее ECMA Script или pure JS без браузерного API), то требуеться под шумок его расширить JS 2.0 ИМXО лажа, полная. Не хочу видеть видеть классы в языке без типов, это провал, притянуто за уши под моду. Читаем Fortress и traits, почти это реализовано уже в JS, осталось ввести контроль импорта окружения в функции, так что бы не приходилось "извращаться" делая "приватные" переменные. Xотя текущие подходы извратами не нахожу. Xочеться что бы JS начал по своей гибкости напоминать Python

Это сообщение отредактировал(а) Destruction - 12.2.2006, 21:28

ну конечно, если создать объект числа, то число будет объектом...

Destruction, и что пример должен показать? Обернул ты строку в Number обьект, во второй строке опросил конструктор у конструктора, т.е. у функции (Function обьект). В JS есть оьекты и примитивы, строки, числа, это всё примитивы. Xотя new String, new Number и т.д. это обьекты. Особенно сбивает с толку такой приём

Sardar,
а вот получается что условия типа if (a) проверяют на наличие переменной, а не на то что, она равна false, true или 0,1 ?

Innuendo,
нет, тут всё сложнее. на наличие не перемнных, а объектов.
кода

работат "правильно".

а также



Это сообщение отредактировал(а) Alx - 12.2.2006, 22:24

Наличие переменной не при чём. Всё работает по строгой логике для if (см. Ecma-262, 12.5), выражение в скобках вычисляется и приводится к типу Boolean (см. Ecma-262, 9.2). Соответственно, приведение к этому типу объекта new Boolean(false) даст true.

Существование обьекта это true, null это false, не важно состояние обьекта (в примере содержи false).

@ Sardar & Alx:

в том и проблема, что даже самые обычные числа являются объектами (класса Number). Скажем, они имеют уйму методов (вроде toString). Все это есть в документации. Попробуйте у себя в браузере выполнить



например...

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



Это сообщение отредактировал(а) Destruction - 13.2.2006, 11:48

regis & Destruction, Нет, это называеться autoboxing, проиходит динамически когда ты обращаешся с примитивом как с обьектом, но значение всё равно не оборачиваеться в обьект.



Обьекты почти всегда в скриптах выполнены на как хештаблицы, реже деревья. Т.е. обьект это набор пар ключь=>значение + сылка на прототип (опять же обьект). Держать хештаблицу для каждого значения весьма накладно (интересно как порешали в Ruby, где действительно всё это обьекты?), потому и существуют примитивы, что "имеют" ссылку только на прототип Number. Числа обычно храняться прямо в структуре "универсального значения", обычно в union. Фактически никаких ссылок нет, все числа при обращении с ними как с обьектами обращаються к прототипу Number.

Когда мы пишем:

Происходит следующее, по шагам:

• сложить, результат на стек
• найти поле constructor, это примитив число, значит обращаемся к нативному обьекту Number
• найти у обьекта Number (помним что это функция, т.е. обьект) поле toString, если поле это обьект-функция, то вызываем, иначе кидаем исключение

Опустил детали конкретного движка, вычисления могут быть традиционно на стеке (Java, C#), а могут быть в "регистрах" (Parrot (Perl6)). В целом видим что примитивы это всё таки очень лёгкие "существа" в отличии от полноценных обьектов. Все примитивы не мутируемы, чем и отличаються от ссылочных значений. Только строки исключение, они не мутируемы, но ссылочные, что бы не копировать их по чём зря в памяти

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

бл... пойду умные книжки читать.. - половину ваще не понял.

Это сообщение отредактировал(а) Destruction - 13.2.2006, 15:21

Перевёл разговор про примитивы сюда - http://forum.vingrad.ru/index.php?showtopic=83710

Вот недостатки, которые сразу пришли в голову:
1. Нет статических переменных.
2. Нет ООП (фичи с prototype, this и т.д. не считаются)
3. Нет инклуда других скриптов.
4. Нет аргументов по умолчанию у функций (пляски с .arguments не веселят)

Это так, недостатки самого языка. Недостатки всей платформы (если можно так выразиться) упираются в кроссбраузерность.

ИМХО ^

что ты подразумеваешь под статичными переменными и ООП?
JavaScript даже слишком ОО...
инклуд есть, чуть-чуть изворотливый, но в общем совсем не сложный
а вот 4 дейчаствительно большой недостаток, кстати, как пример, именно вот такие недостатки я и хотел собрать, то есть не пространные, а конкретные и обидные.

Как представлю такой синтаксис в JS

Ещё бы вызов с именованными аргументами:

Да... красиво было бы
Добавлено @ 01:45
А вообще долго тащился

Кто пользовал XMLHttpRequest знает что его onreadystatechange исполняеться в отдельном треде. JS не многопоточная среда, все setTimeout, события и прочее исполняеться друг за дргугом, модальное окно alert останавливает исполнение. Раз нет многопоточности, значит нет проблем с синхронизацией, концепция проста и удобна.

В результате "второго треда" от XMLHttpRequest гармония нарушаеться, т.к. средств синхронизации нет приходиться надеяться что "основной тред" и тот что от XMLHttpRequest не возьмуться работать с одной нодой. Хотя шанс на это мал, но всё таки не приятна такая не ясность.

Настоящая трабла возникает в поведении JS обьектов, судя по всему они копируються в новый тред. Попробуйте создать обьект (назововём А), очертить closure которой будет "виден" обьект, отдать полученный closure на onreadystatechange обьекта XMLHttpRequest. В closure измените какое нибудь свойство обьекта А, сразу же убедитесь что свойство изменилось. Напишите кнопку что будет опрашивать изменяемое свойство А. Запускаем, видим что поле обьекта А изменяеться, затем жмём кнопку, удивляемся почему поле того же обьекта А не изменилось.

Обьяснение фокусу пока одно - JS обьект передаваемый в "новый тред" копируеться, обработчик события работает с копией в "новом треде", из него видим что поле изменяеться. События кнопки работают в "основном треде", замечаем что "оригинальная копия" обьекта не изменяеться.

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

Код с эффектом копирования обьектов между тредами здесь:
http://forum.vingrad.ru/index.php?showtopi...st&p=648667

Дискуссия была интересная, и по ее итогам родился серьезный вопрос. Кто-нибудь из посетителей форума реально хочет поучаствовать в разработке и тестировании нового скрипт-языка? Уточню, впрочем, что к JavaScript он относится очень отдаленно -- значительно больше он поход на Perl и LISP.

regis,
кто он? его что - уже кто-то разрабатывает?

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

Как ты себе это представляешь? Почти у всех браузеров своя реализация JS, со своим особым API, расширить это не реально, да и пользоваться не будет.

regis, давно планы вынашиваю , сделать язык похожий по мощам на Python, но с C подобным синтаксисом. Язык общего назначения, "полу-скриптовый", т.е. как в .Net JIT компиляция с кешем и статистикой заложена в дизайн движка. Чем больше изучаю питон и расширения к нему, тем больше убеждаюсь н сколько мощен движок, хотя почистить его от эволюционного мусора стоило бы

Открывай топ здесь. Дай название топу подобное "Идеальный скриптовый язык, каким его видим?". Соберём опыт воедино.

@Alx: да, разрабатывают (и не "кто-то", а я сам ;) ). Более того, простой интерпретатор этого языка уже вполне работает (хотя баги еще ловить и ловить...)

@Sardar: рад буду обменяться опытом (хотя с питоном я знаком довольно плохо).
Где-то через недельку-другую попробую выложить то, что наработал, и тогда открою тему.

По поводу расширения JavaScript: Alx, наверное, имел в виду подключаемые извне модули с "родным" кодом? Впрочем, мне тоже не вполне понятно, зачем это нужно, и, главное, кто этим будет пользоваться...


Это сообщение отредактировал(а) regis - 27.2.2006, 15:25

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

кстати обзывание параметров по умолчанию делается очень просто с помощью || или ?.

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

функцию можно вызывать 3-мя способами:



а вот функция:

Свежий пример "недостатка" от большого ума, наверное. IE и FF имеют свойство "подскролливать" ползунок окна, если они посчитают, что появившийся в окне слой того заслуживает. Алгоритма и возможности его отмены, естественно, никакого. Пришлось перехитрить - подождать маленькое время, а потом установить скролл по-своему (в задаче с подкруткой окна в область демонстрации слоя.

--------------------------------

Невозможно выделить selection в IE в слое, расположенном ниже конца документа (иначе, как через Select All).

Это сообщение отредактировал(а) 12345c - 29.3.2006, 03:03

Вот еще пару недостатков, не так давно для меня всплывших:
---
нельзя остановить программу и дождаться каких - нибудь событий аля WaitForSingleObject()
---
очень скудные регулярные выражения
---
может что - то недопонял, но не придумал как передать переменную по ссылке
---

Это сообщение отредактировал(а) S.A.P. - 29.3.2006, 07:30

Если это примитив, то оберни в обьект, все обьекты передаються по ссылке. Естественно это не указатель как в C/C++, т.е. не разрушающая ссылка, что есть безопасный и хороший подход к программингу. "Опасные" ссылки в новых языках по моему уже не появляються, слишком не предсказуемое поведение проги можно нагородить.

Отсутствие (по крайней мере в книге Гудмана) конструкции elseif - вот это действительно страшно!!! =)
Шутим... =)

чтобы передать переменную по ссылке, она должна быть объектом, а именно иметь тип Object. а для соэдания экземпляра некоторые объекты имеют метод типа createInstance() и тп
а говоря о регулярных выражениях, готов поспорить. просто строка поиска бывает  требует дополнительной обработки (например при поиске символа "а" в строке из юникода или в hex'e и тп.). ну Перл в этом вопросе рулит, даже по скорости

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


Не правда, приведи пример.


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

Рекурсивные шаблоны, соответствие/несоответствие с залядыванием назад, условные подмаски и много еще чего. Всего этого в JS - нет.

С переносами в обрабатываемой строке тоже не всё гладко.

Так что тут и спорить не о чем   .

Это сообщение отредактировал(а) S.A.P. - 5.8.2006, 09:24

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



символ в формате ASCII  не найдешь в строке Юникод.
также есть проблема с локализацией.
допустим есть текст на греческом.
поиск идет с игнорированием регистра. большая ГАММА и маленькая ГАММА - разные вещи для регулярных выражений. не говорю о китайском.
ты должен обработать строку таким образом, чтобы она понимала язык.
Майкрософт решит эту проблему с помощью XML и JSCRIPT.NET. 

если не очень ясно написал, то дай знать. просто времени не было....

Выражение не имеет смысла, т.к. все строки в JS (в памяти) в юникоде, для этого при чтении сорцов и нужно указывать кодировку (по дефолту равна кодировке страницы). Символы ASCII (латинский алфавит) входит в юникод и нормально там ищеться, другое дело что этот символ может иметь совсем другой числовой код в юникоде. Приведи пример кода, т.к. то что ты сказал физически не возможно, когда исходник будет разобран парсером все строковые константы будут в памяти в юнкикоде, и только через String.fromCharCode можно получить "левый символ" (указываешь числовой код своей кодировки, а функция принимает юникод, нужна таблица трансформации, так в любом языке). Приведи код где проблема провяляеться.


Реги отдельной либой реализованы, у разных браузеров разными либами. Для всех языков есть таблица упорядочивания (collating rules), она определена в локале, в ней могут быть ошибки, но для юникогда по моему все правила заданы жёстко. Убедись что проблема появляеться во всех браузерах. Приведи код где проблема проявляеться.


Да, реги конечно уже отстают. Пинать нужно ECMA, вместо того что бы заставить стандартом реализовать сегодняшние потребности, они написали стандарт который вобрал в себя мимимум возможностей со всех платформ (автоматом со всеми браузерами совместим, только кому нужна такая ограниченность? Это не единственный кривой стандарт ECMA, глянуть на тот же Eiffel... оторваны от народа их деяния...   ). С выходом JS 2 возможности может быть расширят.

какая латиница??? латиница всегда имеет код меньше 128, а проблема заключается в сопоставлении ASCII с Юникодом не латиницей. русская буква в ASCII находится с 128 до 256 (уточнения не в тему), а в Юникоде за 1000. даже таблицы это доказывают. и ничего не сопоставляется. это косяк...
более того, некоторые алфавиты не укладываются в 128 символов (азиатские). они по ASCII представляют собой 2хбайтный код. и реализовать поиск, сопоставляя 2хбайтный код юникодам, довольно трудоемкая задача. и на сегодняшний день наиболее удачно решил только перл.
надо проверить для русской кодировки, может че-то будет, но для азиатской - мёртво...


не факт.(особенно ослик). в книге фридла эта проблема прекрасно описана. строки в юникоде - это только как объекты, а в ASCII - простые строки.



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

эта проблема с локализацией (а именно сопоставление ASCII с Unicode) она пока не решена нигде.. лишь перл близок, а остальные пока ппппп..

Добавлено @ 02:12 
а код напишу

А как получить такой символ в JS? Допустим:


Если сохранить исходник как win-1251, то редактор сгенерит для ю верный код в win-1251. Браузер загрузит страницу, а с ней и скрипт в win-1251, затем он сконвертирует все символы (включая саму страницу, DOM дерево только в юникоде) в юникод, т.е. в перемнной a будет лежат строка с одним символом имеющим код 'ю' в юникоде, и совершенно до лампочки разработчику скрипта должно быть какой это код на самом деле 

Естественно если ты попытаешся воссоздать символ через String.fromCharCode(code), и передашь код 'ю' в win-1251 (>128, < 256), то ты получишь один из латинских символов с акцентом, т.к. в юникоде под твоим заданным кодом лежит именно этот символ. И JS абсолютно по барабануы какую кодировку ты имел в виду, принимаеться только юникод (что логично) и любое необходимое перекодирование ты должен выполнить сам. Другое дело как ты получил эти коды? Вбил сам? Любым другим путём ты будешь получать готовые строки... ну если только ты сам не делаешь жизнь сложнее, и не принимаешь данные от сервера в кодах символов 


Абсолютно не трудоёкая это задача (естественно таблицы символовм с доступом по индексу делать глупо, всё таки (2^18) памяти захаваем, но это уже детали), гораздо трудоёмкая задача работать с UTF-8 в памяти, в прямом смысле держат UTF-8 байтами в памяти, ибо сложно эффективно узнать длину всей строки или просто произвольный символ.
Резюмирую: с  UCS-2 работать также просто, как и с ASCII. Сложно работать если длина символва в байтах варьируеться, как например в UTF-8. Но такая кривизна необходима если язык не поддерживает юникод нативно, например PHP.


Выбрасывай эту книгу, датирована вероятно 98 годом. Современные браузеры, как и современные оси все на юникоде, всегда. Другое дело что при записи пользуються кодировками или UTF-8 для меньших размеров, или перекодирывают в что нибудь если "целевая сущность" юнкод не поддерживает (консоль например).
Резюмирую: любые строки и сам документ любой браузер держит в юникоде. Исключаем старый нетскейп и вообще браузеры датированные до 2000.


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

• ряд символов (range) типа [в-я]
• сравнение в <> я
• определение что есть буква, цифра и т.д.

На основе третьего строяться такие мета-символы как .(любой символ кроме перевода строки) и подобное.
Резюмирую: если сравнение строк глючит - глючит локаль твоей системы, либо во всём виновата кривизна рук разработчика либы. JS здесь никаким боком, прикрути эту либу к любому другому языку, будет тот же эффект.


Я пояснил почему это не так (почему это выражение вообще не имеет смысла). Также замечу что помимо самой реговой либы есть PCRE стандарт, позволяющий писать совместимые с перлом либы. В принципе идееентично должно работать, тут уж от собственного понимания что есть 1-байтные кодировки, что юнкод, а что локализация и где это соприкасаеться. Рулят у перла 6 его вшитые контекстно-свободные грамматики, по мощи превосходящие всё что могут позволить реги сейчас 

M Sardar

ИМХО пошёл флуд, если разрастёмся, то срежу в отдельную тему.

Sardar ты был прав!