перл срабатывет мгновенно.

(Reply to this) (Thread)

Какая версия, последняя?

Заметка (ссылка у меня) от января 2007-го года, там мужик про версию 5.8.7 писал (правда, другие выражения). Можете проверить с ней? А выражения мужика (повторы всякие "a" и вопросиков).

Я Перл не проверял, только До-диез и одну библиотеку на Паскале (которой пользуюсь; у меня выражения длинные, но несложные, так что проблем с быстродействием особых не было).

Яву ещё думаю посмотреть, но я в ней не секу, так что лень, конечно (на неделе где-нибудь скачаю обновление и поковыряюсь).

(Reply to this) (Parent) (Thread)

Сначала пробовал с v5.10.0, только что попробовал с v5.6.1 -- то же самое.

(Reply to this) (Parent) (Thread)

А дядькины http://swtch.com/~rsc/regexp/regexp1.html экспериментальные данные как, подтверждаются?

(Reply to this) (Parent) (Thread)

Не знаю, слишком долго разбираться.

(Reply to this) (Parent)

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

(Reply to this) (Parent) (Thread)

Да, наверное. Это говорят почти про все движки. Люди, с которыми я такое обсуждал устно, априорно отрицали плохие для конкретных движков строки, а при демонстрации говорили, что всё равно.

Реально проблемы быстродействия актуальны при серьёзных объёмах обрабатываемых данных (а для серьёзных задач найдут специалиста, который, если надо, сам движок напишет под задачу), а также при возможности DOS-атак или чего-нибудь такого (не особо просто подставить "неудобный" текст, когда выражение фиксированное, но почти "совсем просто", если и выражение можно вогнать, например, в URL).

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

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

(Reply to this) (Parent) (Thread)

Когда-то на rsdn.ru критиковались регулярные выражения, как таковые, и как альтернатива предлагалось написать нечто на основе EBNF.

(Reply to this) (Parent) (Thread)

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

А Бакуса-Нуара формы (тем более расширенные, которые Вирт сформировал) предназначены сразу и для синтаксического анализа. И у них на быстродействие такие теоретические претензии мне не известны. Так что к ним по поводу торможения, вероятно, должны быть какие-то совершенно другие претензии: сравнивающие реализации, что-нибудь такое, а не абсолютные.

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

В общем, если только простой лексический анализ, то формы Бакуса-Нуара скорее всего будут более громоздкими и без гарантий (теоретических) быстрой работы, чем регулярные выражения.

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

Типа того. Посмотрю ещё по теме в "книжке с драконом" при случае.

(Reply to this) (Parent)

(Reply to this) (Parent) (Thread)

Да, всякое давно придумано и написано. "Классикой" считается и какой-нибудь Lex+Yacc…

(Reply to this) (Parent)

Все эти примеры типа a?a?a?aaa -- они на самом деле не из жизни. Так что может, если взять первый график, где сравнивается перл и NFA, то начальный участок графика, возможно, более важен, а на этом участке перл выигрывает.

(Reply to this) (Parent) (Thread)

А-а-а!!! Перл сам использует НКА, а то, с чем сравнивается — оптимизированные НКА. То, что "=XX==…" работает быстро, означает, что в Перле тоже оптимизированные НКА. Оба движка — оптимизированные НКА.

"Из жизни" — отстойный аргумент, по-моему, для того, что может аукнуться. Я поэтому с сортировкой сравнивал. Аргумент "из жизни" про формальные вещи претендует на знание самой жизни, а жизнь у каждого своя.

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

Попробую скачать Перл, проверить на своих выражениях. Может, буду использовать какую-нибудь .dll-ку на основе него, если шустро работает.

(Reply to this) (Parent) (Thread)

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

Вот именно это я и имел в виду. Я не вижу, где можно реально применить a?a?a?aaa, и подозреваю, что любое полезное регулярное выражение может быть оптимизировано так, что перловый движок будет работать адекватно.

(Reply to this) (Parent) (Thread)

что любое полезное регулярное выражение может быть оптимизировано так, что перловый движок будет работать адекватно
Это очень плохо, по-моему. Адекватно — чтобы движок оптимизировал регулярные выражения. Но чувство собственной значимости у людей, конечно, может повышаться от того, что они владеют Искусством написания регулярных выражений, наверное. Ну и про "полезность": обычно люди так называют такие выражения, которыми сами пользуются, не более того, частнейшее мнение. А если есть формализуемая "полезность" собственно выражений, то, опять же, можно её анализировать и либо оптимизировать, либо ругаться.

(Reply to this) (Parent) (Thread)

Формальные критерии бывают хорошими и плохими, хороший ли тот или иной критерий или плохой -- зависит опять-таки от субъективного мнения. Моё субъективное мнение таково, что критерий, полагающийся на время выполнения a?a?a?a?aaaa... -- очень плохой критерий, ибо из него не происходит никакой практической полезности. Насчёт того, что разные люди полезными называют разные критерии -- ну, это есть такой факт, только обозначение его ничем делу не помогает. По-моему, докопаться до точки, где мнения всех люей бы сходились, невозможно, а значит, выражение "объективное мнение" лишено смысла. Все мнения в той или иной мере субъективны, а обозначение мнения "частнейшим" я рассматриваю лишь как приём весьма дешёвой демагогии.

(Reply to this) (Parent) (Thread)

А значит надо исходить из того, что для регулярных выражений с очевидным смыслом движок не должен выдавать неочевидные торможения — это моё демагогическое частнейшее мнение.

(Reply to this) (Parent) (Thread)

Для меня смысл выражения типа a?a?a?aaa не является очевидным. Вот смысл a{3,6} очевиден, а a?a?a?aaa -- нет. Если б я нечто такое встретил в чужом коде, я б, наверно, надолго задумался над вопросом "а что он этим, собственно, хотел сказать?".

(Reply to this) (Parent) (Thread)

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

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

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

(Reply to this) (Parent)

То не "до-диез", а си-шарп. Давай посмотрим код того примера.

(Reply to this) (Thread)

А почему не До-диез? Если язык назвали так, как обозначается до-диез, зачем мне его иначе называть по-русски? И в русском языке нет слова "шарп".

Выражение и текст, к которому оно применяется, ты видел в моих сообщениях (количество "=" в конце выражения я не смогу написать точно), а текст (короткий) на До-диезе писал в основном мой товарищ (хотя мне пришлось его исправить, ибо он забыл сделать вывод результатов). Сейчас звоню уточнить у него, что именно он писал. Да, как я и сам, пока звонил, в MSDN прочитал, это был Regex.Match.

Или если там класс создавать, на компиляцию ему намекать или что-нибудь такое, то быстро работает (это .net, а не Mono, кстати)?

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

неконвенцинальное написание затруднит потом поиск интересующихся темой
Мне не нужны интересующиеся собственно До-диезом, мне вообще на данный момент в Дельфах (не .net-ских) регулярные выражения нужны. И какая-то сторонняя библиотека у меня в принципе работает, хотя и хреново по моим меркам, так что моё бухтение вообще не очень актуально. Я бухчу как компьютеро-научник, а не до-диезник.

мой интерес к исходному коду
Там был Regex.Match.

Сейчас специально написал суперпрограмму:

using System;
using System.Text.RegularExpressions;

public class Test
{
    public static void Main()
    {
        string sss = "=XX==========================";
        string srx = "X(.+)+X";

        Console.WriteLine("        Начало: {0:o}", DateTime.Now);

        Regex rx = new Regex(srx);
        Match mmm = rx.Match(sss,0,sss.Length);
        Console.WriteLine(mmm.Value);

        Console.WriteLine(" Regex...Match: {0:o}", DateTime.Now);

        mmm = Regex.Match(sss,srx);
        Console.WriteLine(mmm.Value);

        Console.WriteLine("   Regex.Match: {0:o}", DateTime.Now);

        Regex ry = new Regex("X(.+)+X",RegexOptions.Compiled);

        Console.WriteLine("RxOpt.Compiled: {0:o}", DateTime.Now);

        mmm = ry.Match(sss,0,sss.Length);
        Console.WriteLine(mmm.Value);
        
        Console.WriteLine(" RxOpt...Match: {0:o}", DateTime.Now);
    }
}

У меня времена: 92 секунды, 101 секунда и молниеносные 48 секунд (а компиляция условно мгновенна).

В документации прямо и беззастенчиво написано, что в .Net — "Traditional NFA" (который можно и оптимизировать, вообще-то, не меняя интерфейса).

(Reply to this) (Parent) (Thread)

2 минуты 40 секунд

(Reply to this) (Parent) (Thread)

На моём тормознутом компе примерно так. Дебаг:

Match took: 00:01:48.2879910

Another match took: 00:02:58.5403305
Compiling regexp: 00:00:00.0019530

Compiled match took: 00:01:23.6010945

Релиз:

Match took: 00:02:17.0966940

Another match took: 00:02:16.3223295
Compiling regexp: 00:00:00.0029295

Compiled match took: 00:01:21.8375355

Разброс большой из-за троттлинга, но в принципе, понятно, что регекспы тормозят. МС обычно делает всё по-своему, ухудшая и не доводя до конца, как и в случае регекспов.

(Reply to this) (Parent) (Thread)

Так это Моно?

(Reply to this) (Parent) (Thread)

Нет, дотнет 3.5 (наверно, всё равно, что и 2.0) под Вистой и на тормозном компе (с переменчивыми тормозами).

(Reply to this) (Parent) (Thread)

А в Моно реализован класс Regex? Как оно в Моно?

Мне казалось, что ты им пользовался.

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

Зачем лезть в плохой код лишний раз? У меня своего плохого кода хватает.

(Reply to this) (Parent)

Про Моно: http://lj.rossia.org/users/ppkk/87753.html?thread=295625#t295625

(Reply to this) (Parent)

Я не совсем понял, это сумма моих чисел, аналогичный результат у себя или что ещё?

(Reply to this) (Parent) (Thread)

аналогиный результат у себя

(Reply to this) (Parent)

>Мне не нужны интересующиеся собственно До-диезом,

Тебе не нужны, а вот кому-то эта информация может понадобиться.

(Reply to this) (Parent) (Thread)

Тогда пусть знают заодно, что пишут на До-диезе.

(Reply to this) (Parent) (Thread)

Гыгыгы, вот же ты упрямый.

(Reply to this) (Parent)

то ли я чо нипонял, то ли чо… GNU regex, TRE — результат мгновенный, нифига не найдено (что логично). мона сожрала весь моск (у меня оного три гига), после чего завалилась с воплем «память кончилась!»

(Reply to this) (Parent) (Thread)

А TRE не является традиционным. Там сразу по слову POSIX возникает мысль, что старались и писали аккуратно.

И выбрали хорошее компромиссное решение ("O(M^2*N)" по времени и "O(M^2)" по памяти). И фишки!

В общем, спасибо за ссылку!

А долго Моно умирало?

(Reply to this) (Parent) (Thread)

не, секунд за 5-7 слопало всю память и наебнулось.

(Reply to this) (Parent) (Thread)

Несмотря на то, что дотнет легко декомпилируется, и даже его сорцы теперь официально доступны для дебага, Моно, судя по всему, в значительной степени переписало исходный код либ с нуля. Отчасти, думаю, из лицензионных ограничений, отчасти потому, что в дотнете много чего реализовано через старые COM-интерфейсы и WinAPI. Поэтому отличия в реализации регекспов неудивительны.

(Reply to this) (Parent) (Thread)

Зато удивительно, что не использовали приличный движок.

(Reply to this) (Parent) (Thread)

А что ты там парсишь?

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent)

удивительно то, что они не работают. а так ничего, нормально всё.

мне слабо понятно, как на этом мусоре можно что-либо кроме «привет, мир» ваять.

(Reply to this) (Parent) (Thread)

А я вот использую из года в год, представь себе. ;)

(Reply to this) (Parent) (Thread)

то-то современный софт с одним окошком и кнопочкой "ok" требует минимум 4 гига моска, многоядерный проц на 3 гигагерца и винт минимум в пол-терабайта.

(Reply to this) (Parent)

Согласен с ответом ketmar-а. Ещё добавлю: и всё равно в некоторых ситуациях виснет.

(Reply to this) (Parent)

TRE? мне особенно нравится фишка «приблизительного совпадения», больше нигде такой не видел.

(Reply to this) (Thread)

В любом наманом индексере есть. Реализуется легко тоже. Википедия подсказывает, что это 10-строчечный "алгоритм Левенштейна".

(Reply to this) (Parent) (Thread)

Пока что обсуждаются проблемы нераспространённости "нормальных" движков регулярных выражений.

(Reply to this) (Parent) (Thread)

В блогах не бывает оффтопика.

(Reply to this) (Parent) (Thread)

1. Бывает.
2. Я имел в виду, что доступность алгоритма и наличие его пристойной реализации — очень разные вещи.

(Reply to this) (Parent) (Thread)

Не пойму, ты хочешь, чтоб здесь обсуждался только топик?

(Reply to this) (Parent) (Thread)

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

(Последнее замечание [выше, про TRE]: POSIX-то мне тоже не нравится на самом деле. Я же к Паскалю привык, так что особое отношение к нулевому символу мне кажется бредом.)

(Reply to this) (Parent)

я что, говорю, что это сложно? я говорю, что ни в каком движке регэкспов больше этого не видел. а утилитка agrep, которая идёт в наборе с TRE — полезная штука.

(Reply to this) (Parent)

Что мне не нравится в POSIX — это ограничение на использование нулевого символа. Как упомянуто на главной странице TRE, там это ограничение тоже есть, как упомянута и полезная задача, которую можно было бы решать с помощью рег. выражений: выдирание текста из нетекстовых файлов.

(Reply to this) (Parent) (Thread)

ну, никто не мешает нетекстовые файлы препроцессить предварительно. например, менять нули на еденички.

а в принципе да — особая роль нуля задолбала.

(Reply to this) (Parent) (Thread)

например, менять нули на еденички
Не пройдёт. Необходимо как-то обратимо, а значит ещё один символ задействовать: типа, $01 -> $0101, $00 -> $0102. В любом случае теоретически невозможно это сделать в общем случае так, чтобы файл не разбухал, а значит не получится без создания вспомогательных файлов (или памяти).

особая роль нуля задолбала
Для любителей Паскаля это изначально нелепо. Хотя недавно я в одной задаче пользовался строками, заканчивающимися на ноль: память экономил и всё такое, хранил строки сплошняком (итого: пять лишних байтов на строку, а с обычными паскалевскими строками что-то было существенно бОльшее [в Дельфах 2009 — 13 байт как минимум, но съедается память на управление ей же, когда много мелких объектов]).

(Reply to this) (Parent) (Thread)

>Для любителей Паскаля это изначально нелепо.
для любителей Qt тоже. %-) также нам, любителям Qt, забавно смотреть, как дельфисты до сих пор сражаются с юникодом. и с отсутствием в VCL такой простой вещи, как layout manager.

зыж есличо — я изначально паскалист и дельфист (лет 10, что ли), на c++/Qt перелез не так давно, в связи с тем, что Lazarus — феерическое, невообразимое говно.

(Reply to this) (Parent) (Thread)

до сих пор сражаются с юникодом
1. В обед сто лет TntUnicode (или как он там) есть. Там в визуальных компонентах везде widestring.
2. У меня Дельфы 2009, в них тип string какой-то нереальный: он почти всё что угодно поддерживает (из-за этого не работают старые программы, которые считают индексацию байтовой, я такие тоже писал, причём специфических предупреждений при компиляции не вываливается).

А layout manager-а продвинутого не хватает, да, последние нововведения в основном всякое микрософтовское говно (элементы MSO 2007 и Vista).

Freepascal использую (для консольных приложений), но он память жрёт не по-детски, по сравнению с Дельфами, а с Лазарем ничего путного действительно на горизонте не просматривается.

(Reply to this) (Parent) (Thread)

1. это уебанство. юникод должен быть во всём генофонде.
2. d2009 — тоже уебанство. баг на баге, даже в генофонде. тьфу.

не знаю, вот как раз проблем с памятью в fpc не видел.

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

(Reply to this) (Parent) (Thread)

1. Нет. Я бы предпочёл отдельный тип для юникодных строк, обрабатываемых как текст. Дело ведь в том, что юникод — безальтернативное, но тоже говно.
2. Ну, отрицать категорически не берусь, но в чём?

вот как раз проблем с памятью в fpc не видел
Когда много мелких объектов, он жрёт раза в полтора-два больше памяти, чем Дельфы с тем же исходником. Параметры выравнивания и т.п. не помогают.

с сей на паскаль
Ну да, это несколько мешает жить.

(Reply to this) (Parent) (Thread)

1. как раз юникод — вполне нормально. а что, есть какая-то другая мегаидея, как работать с кучей языков и срать на локали? заметь, я не про utf тут, а про ucs.

2. как минимум — в генериках. вон, недавно в QuickSort позорнейший баг нашли. настолько позорный, что и говорить стыдно. уебанство. даже не в реализации генериков, а тупо в алгоритме. и дельфей и раньше Q&A хромало, так теперь оно вовсе отсуствует.

>Когда много мелких объектов, он жрёт раза в полтора-два больше памяти, чем Дельфы
>с тем же исходником.
потому что борманды асилили спереть FastMM, а FPC — нет.

>Ну да, это несколько мешает жить.
на винде — несколько. на никсах — ПИЗДЕЦ, КАК МЕШАЕТ.

(Reply to this) (Parent) (Thread)

про utf тут, а про ucs
Юникод — это и utf-7, и utf-8 и ещё куча всего.

в QuickSort позорнейший баг
Вообще нефиг пользоваться ей. От тех, кто в качестве сортировки предлагает первым делом "быструю сортировку" надо сторониться также, как от сторонников "пузырьковой". Мне тут прорекламировали недавно "Median of medians" вариант, как "нормальную быструю сортировку": на списке из одинаковых элементов застрял.

(Reply to this) (Parent) (Thread)

>Юникод — это и utf-7, и utf-8 и ещё куча всего.
это вот никакого отношения к юникоду не имеет. а то так можно сказать, что base64 — это такой ascii.

>От тех, кто в качестве сортировки предлагает первым делом «быструю сортировку»
>надо сторониться также, как от сторонников «пузырьковой».
а дело не в этом. дело в том, что в известнейшем алгоритме позорнейший баг. а алгоритм — в генофонде. что навевает мысли о прискорбном увольнении всей Q&A команды. ёмбаркадеры, видимо, в кризисе, на Q&A бабла нет.

(Reply to this) (Parent) (Thread)

это вот никакого отношения к юникоду не имеет
Ну-ну. UCS-2 is what a Unicode implementation was up to Unicode 1.1, before surrogate code points and UTF-16 were added as concepts to Version 2.0 of the standard. This term should be now be avoided. When interpreting what people have meant by "UCS-2" in past usage, it is best thought of as not a data format, but as an indication that an implementation does not interpret any supplementary characters. …
What does Unicode conformance require? … Process UTF-* by the book. http://www.unicode.org/faq/basic_q.html

ёмбаркадеры, видимо, в кризисе
Вряд ли. Дельфы 2009 на порядок лучше работают, чем Дельфы 2007, которые они не так давно (в конце июня 2008-го года) купили у Борланда. Ссылку не дашь на ошибку?

(Reply to this) (Parent) (Thread)

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

ну, не знаю. для меня дельфи закончилось, когда стало требовать вротнет. ну, и то, что там сделали справку m$-like — тоже. нормальные люди ушли, уебаны пришли.

(Reply to this) (Parent) (Thread)

Ты ругай тогда уж Юникод, а не какие-то нестандартные непостижимые вещи пиши: ничего не понять.

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

Ну, символы не они придумали, они их только организовали, чтобы на компьютере потреблять. Так что ругай Юникод!

(Reply to this) (Parent) (Thread)

не буду я юникод ругать. я буду ругать уродов, которые придумали utf.

(Reply to this) (Parent) (Thread)

То есть, Unicode Consortium? "Ругать буду не всех евреев, вместе взятых, а еврейский народ"?

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

Такой уж консорциум. Повторюсь: буквы не они придумали. А они даже общедоступных шрифтов не сделали, как я понимаю.

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

Они договорились о каком-то едином способе хранения символов в виде байтов (UTF-*) и о начертаниях тоже (начертания также придумали не они, но они записали какие-то определённые варианты http://www.unicode.org/Public/UNIDATA/ — некая урезанная часть описаний). Примеры изображений они дают в таблицах символов, но не разрешают использовать этот шрифт.

http://www.unicode.org/charts/About.html — "The fonts and font data used in production of the Unicode Standard may not be extracted, or used in any way in any product or publication, without permission or license granted by the typeface owner(s)." (А из таблиц даже копировать-вставлять нельзя [в смысле, стоит запрещающий флажок в pdf-е]: хотя копируется не изображение а скорее только код символа.)

И ещё, например: http://www.unicode.org/versions/Unicode5.0.0/ch07.pdf — "This file is part of the electronic edition of The Unicode Standard, Version 5.0, provided for online access, content searching, and accessibility. It may not be printed."

Так что в каком-то смысле "UTF-*" — основное, что они сделали.

(Reply to this) (Parent)

а, да. ссылку не дам. где-то на «Мастерах Дельфи» в «потрепаловке» кто-то кидал. чуть ли не Palladin. кто-то из старичков, в общем.

(Reply to this) (Parent)

кстати, регулярки в Lua (хотя они там откровенно слабые) ноль чем-то особым не считают. его можно отлично мачить метасимволом %z. %-)

(Reply to this) (Parent)