Выражение не имеет смысла, т.к. все строки в 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 ты был прав!