\ d менее эффективен, чем [0-9]


1249

Я вчера сделал комментарий на ответ , где кто - то используется [0123456789]в регулярном выражении , а не [0-9]или \d. Я сказал, что, вероятно, более эффективно использовать спецификатор диапазона или цифр, чем набор символов.

Я решил проверить это сегодня и с удивлением обнаружил, что (по крайней мере в движке C # regex) \d, по-видимому, менее эффективен, чем любой из двух других, которые, похоже, не сильно отличаются. Вот мой тестовый вывод более 10000 случайных строк из 1000 случайных символов, причем 5077 фактически содержат цифру:

Regular expression \d           took 00:00:00.2141226 result: 5077/10000
Regular expression [0-9]        took 00:00:00.1357972 result: 5077/10000  63.42 % of first
Regular expression [0123456789] took 00:00:00.1388997 result: 5077/10000  64.87 % of first

Это удивляет меня по двум причинам:

  1. Я бы подумал, что диапазон будет реализован гораздо эффективнее, чем набор.
  2. Я не могу понять, почему \dэто хуже, чем [0-9]. Есть ли что-то большее, \dчем просто сокращение [0-9]?

Вот тестовый код:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Diagnostics;
using System.Text.RegularExpressions;

namespace SO_RegexPerformance
{
    class Program
    {
        static void Main(string[] args)
        {
            var rand = new Random(1234);
            var strings = new List<string>();
            //10K random strings
            for (var i = 0; i < 10000; i++)
            {
                //Generate random string
                var sb = new StringBuilder();
                for (var c = 0; c < 1000; c++)
                {
                    //Add a-z randomly
                    sb.Append((char)('a' + rand.Next(26)));
                }
                //In roughly 50% of them, put a digit
                if (rand.Next(2) == 0)
                {
                    //Replace one character with a digit, 0-9
                    sb[rand.Next(sb.Length)] = (char)('0' + rand.Next(10));
                }
                strings.Add(sb.ToString());
            }

            var baseTime = testPerfomance(strings, @"\d");
            Console.WriteLine();
            var testTime = testPerfomance(strings, "[0-9]");
            Console.WriteLine("  {0:P2} of first", testTime.TotalMilliseconds / baseTime.TotalMilliseconds);
            testTime = testPerfomance(strings, "[0123456789]");
            Console.WriteLine("  {0:P2} of first", testTime.TotalMilliseconds / baseTime.TotalMilliseconds);
        }

        private static TimeSpan testPerfomance(List<string> strings, string regex)
        {
            var sw = new Stopwatch();

            int successes = 0;

            var rex = new Regex(regex);

            sw.Start();
            foreach (var str in strings)
            {
                if (rex.Match(str).Success)
                {
                    successes++;
                }
            }
            sw.Stop();

            Console.Write("Regex {0,-12} took {1} result: {2}/{3}", regex, sw.Elapsed, successes, strings.Count);

            return sw.Elapsed;
        }
    }
}

178
Может иметь \dдело с локалями. Например, иврит использует буквы для цифр.
Бармар


37
Это интересный вопрос именно потому \d, что на разных языках это не означает одно и то же. В Java, например \d, действительно соответствует только 0-9
Рэй Тоал

17
@ Бармар Иврит обычно не использует буквы для цифр, а те же цифры латинских цифр [0-9]. Буквы могут быть заменены цифрами, но это редкое использование и зарезервировано для специальных терминов. Я не ожидал бы, что синтаксический анализатор регулярных выражений будет соответствовать כ"ג יורדי סירה (с 23"ג вместо 23). Кроме того, как видно из ответа Сины Ираванян, буквы на иврите не соответствуют действительным совпадениям для \ d.
Ювал Адам

7
Портирование кода Weston на Java дает: - Regex \ d заняло 00: 00: 00.043922 результат: 4912/10000 - Regex [0-9] заняло 00: 00: 00.073658 результат: 4912/10000 167% первого - Regex [ 0123456789] взял 00: 00: 00.085799 результат: 4912/10000 195% от первого
Ланчбокс

Ответы:


1566

\dпроверяет все цифры Unicode, [0-9]ограничиваясь этими 10 символами. Например, персидские цифры, ۱۲۳۴۵۶۷۸۹являются примером цифр Unicode, которые сопоставляются \d, но не совпадают [0-9].

Вы можете создать список всех таких символов, используя следующий код:

var sb = new StringBuilder();
for(UInt16 i = 0; i < UInt16.MaxValue; i++)
{
    string str = Convert.ToChar(i).ToString();
    if (Regex.IsMatch(str, @"\d"))
        sb.Append(str);
}
Console.WriteLine(sb.ToString());

Который генерирует:

012345678901234567890123456789߀߁߂߃߄߅߆߇߈߉012345678 9 01২345678901234567890123456789 ୦୧୨୩୪୫୬୭୮୯ 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 ᠐᠑᠒᠓᠔᠕᠖᠗᠘᠙ ᥆᥇᥈᥉᥊᥋᥌᥍᥎᥏ ᧐᧑᧒᧓᧔᧕᧖᧗᧘᧙ ᭐᭑᭒᭓᭔᭕᭖᭗᭘᭙᮰᮱᮲᮳᮴᮵᮶᮷᮸᮹᱀᱁᱂᱃᱄᱅᱆᱇᱈᱉᱐᱑᱒᱓᱔᱕᱖᱗᱘᱙꘠꘡꘢꘣꘤꘥꘦꘧꘨꘩꣐꣑꣒꣓꣔꣕꣖꣗꣘꣙꤀꤁꤂꤃꤄꤅꤆꤇꤈꤉꩐꩑꩒꩓꩔꩕꩖꩗꩘꩙0123456789


121
Вот более полный список цифр, которые не являются 0-9: fileformat.info/info/unicode/category/Nd/list.htm
Роберт Макки

8
@ Weston Unicode имеет 17 самолетов по 16 бит в каждом. Самые важные символы находятся в базовой плоскости, но некоторые специальные символы, в основном китайские, находятся в дополнительных плоскостях. Работа с теми, кто работает в C #, немного раздражает.
CodesInChaos

9
@RobertMcKee: Nitpick: Полный набор символов Юникода на самом деле 21 бит (17 плоскостей по 16 бит каждая). Но, конечно, использование 21-битного типа данных нецелесообразно, поэтому, если вы используете тип данных с степенью двойки, вам действительно нужно 32-битное.
слеське

3
Согласно этой статье в Википедии , Консорциум Unicode заявил, что ограничение в 1,114,112 кодовых точек (от 0 до 0x010FFFF) никогда не изменится. Он ссылается на unicode.org, но я не нашел там заявления (возможно, я просто пропустил его).
Кит Томпсон

14
Это никогда не изменится - пока им не нужно это изменить.
Роберт Макки

271

Благодарим ByteBlast за то, что он заметил это в документации. Просто изменив конструктор регулярных выражений:

var rex = new Regex(regex, RegexOptions.ECMAScript);

Дает новые сроки:

Regex \d           took 00:00:00.1355787 result: 5077/10000
Regex [0-9]        took 00:00:00.1360403 result: 5077/10000  100.34 % of first
Regex [0123456789] took 00:00:00.1362112 result: 5077/10000  100.47 % of first

11
Что делает RegexOptions.ECMAScript?
Лоран

7
Из параметров регулярного выражения : «Включить ECMAScript-совместимое поведение для выражения».
Крисайкок

28
@ 0xFE: Не совсем. Экранирование Unicode все еще действует в ECMAScript( \u1234). Это «просто» сокращенные классы символов, которые меняют значение (например \d), и сокращения / свойства Unicode, которые исчезают (как \p{N}).
Тим Пицкер

9
Это не ответ на вопрос «почему». Это ответ «исправить симптомы». По-прежнему ценная информация.
USR

Как правило, Regrex поддерживает сопоставление юникода. Но ECMAScript нет. Следовательно, при использовании RegexOptions.ECMAScript он соответствует только ascii, то есть 0-9.
lzlstyle

119

От «\ d» в регулярном выражении означает цифру? :

[0-9]не является эквивалентом \d. [0-9]соответствует только 0123456789символам, в то время как \dсоответствует [0-9]и другим цифровым символам, например восточно-арабским цифрам٠١٢٣٤٥٦٧٨٩


49
Согласно: msdn.microsoft.com/en-us/library/20bw873z.aspx If ECMAScript-compliant behavior is specified, \d is equivalent to [0-9].
Пользователь 12345678

2
да, я не прав или это предложение по ссылке говорит об обратном. "\ d соответствует любой десятичной цифре. Это эквивалентно шаблону регулярного выражения \ p {Nd}, который включает стандартные десятичные цифры 0-9, а также десятичные цифры ряда других наборов символов."
Исмет Алкан

3
@ByteBlast спасибо, используя конструктор: var rex = new Regex(regex, RegexOptions.ECMAScript);делает их практически неразличимыми с точки зрения производительности.
Уэстон

2
о, в любом случае, спасибо всем. этот вопрос оказался для меня очень полезным.
Исмет Алкан

3
Пожалуйста, не «просто копируйте» ответы на другие вопросы. Если вопрос дубликат, отметьте его как таковой.
BoltClock

20

Дополнение к началу ответа от Сина Iravianian , вот версия .NET 4.5 (так как только этого выхода версии поддерживает utf16, сравните первые три строк) его кода, используя полный набор кодовых точек Unicode. Из-за отсутствия надлежащей поддержки для более высоких плоскостей Юникода многие люди не знают, что нужно всегда проверять и включать верхние плоскости Юникода. Тем не менее, они иногда содержат некоторые важные символы.

Обновить

Так \dкак не поддерживает символы не-BMP в регулярных выражениях (спасибо xanatos ), здесь версия, которая использует базу данных символов Unicode

public static void Main()
{
    var unicodeEncoding = new UnicodeEncoding(!BitConverter.IsLittleEndian, false);
    Console.InputEncoding = unicodeEncoding;
    Console.OutputEncoding = unicodeEncoding;

    var sb = new StringBuilder();
    for (var codePoint = 0; codePoint <= 0x10ffff; codePoint++)
    {
        var isSurrogateCodePoint = codePoint <= UInt16.MaxValue 
               && (  char.IsLowSurrogate((char) codePoint) 
                  || char.IsHighSurrogate((char) codePoint)
                  );

        if (isSurrogateCodePoint)
            continue;

        var codePointString = char.ConvertFromUtf32(codePoint);

        foreach (var category in new []{
        UnicodeCategory.DecimalDigitNumber,
            UnicodeCategory.LetterNumber,
            UnicodeCategory.OtherNumber})
        {
        sb.AppendLine($"{category}");
            foreach (var ch in charInfo[category])
        {
                sb.Append(ch);
            }
            sb.AppendLine();
        }
    }
    Console.WriteLine(sb.ToString());

    Console.ReadKey();
}

Дает следующий вывод:

DecimalDigitNumber 0123456789 ٠١٢٣٤٥٦٧٨٩۰۱۲۳۴۵۶۷۸۹߀߁߂߃߄߅߆߇߈߉०१२३४५६७८ ০১২৩৪৫৬৭৮৯੦੧੨੩੪੫੬੭੮੯૦૧૨૩૪૫૬૭૮૯০১২৩৪৫৬৭৮৯੦੧੨੩੪੫੬੭੮੯૦૧૨૩૪૫૬૭૮૯

LetterNumber

ᛮᛯᛰⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩⅪⅫⅬⅭⅮⅯⅰⅱⅲⅳⅴⅵⅶⅷⅸⅹⅺⅻⅼⅽⅾⅿↀↁↂↅↆↇↈ〇〡〢〣〤〥〦〧〨〩〸〹〺ꛦꛧꛨꛩꛪꛫꛬꛭꛮꛯ 𐅀𐅁𐅂𐅃𐅄𐅅𐅆𐅇𐅈𐅉𐅊𐅋𐅌𐅍𐅎𐅏𐅐𐅑𐅒𐅓𐅔𐅕𐅖𐅗𐅘𐅙𐅚𐅛𐅜𐅝𐅞𐅟𐅠𐅡𐅢𐅣𐅤𐅥𐅦𐅧𐅨𐅩𐅪𐅫𐅬𐅭𐅮𐅯𐅰𐅱𐅲𐅳𐅴 𐍁𐍊 𐏑𐏒𐏓𐏔𐏕 𒐀𒐁𒐂𒐃𒐄𒐅𒐆𒐇𒐈𒐉𒐊𒐋𒐌𒐍𒐎𒐏𒐐𒐑𒐒𒐓𒐔𒐕𒐖𒐗𒐘𒐙𒐚𒐛𒐜𒐝𒐞𒐟𒐠𒐡𒐢𒐣𒐤𒐥𒐦𒐧𒐨𒐩𒐪𒐫𒐬𒐭𒐮𒐯𒐰𒐱𒐲𒐳𒐴𒐵𒐶𒐷𒐸𒐹𒐺𒐻𒐼𒐽𒐾𒐿𒑀𒑁𒑂𒑃𒑄𒑅𒑆𒑇𒑈𒑉𒑊𒑋𒑌𒑍𒑎𒑏𒑐𒑑𒑒𒑓𒑔𒑕𒑖𒑗𒑘𒑙𒑚𒑛𒑜𒑝𒑞𒑟𒑠𒑡𒑢𒑣𒑤𒑥𒑦𒑧𒑨𒑩𒑪𒑫𒑬𒑭𒑮

OtherNumber²³¹¼½¾৴৵৶.৸৹ ୲୳୴୵୶୷ ௰௱௲ ౸౹౺౻౼౽౾ ൰൱൲൳൴൵ ༪ ༫ ༬ ༭ ༮ ༯ ༰ ༱ ༲ ༳ ፩፪፫፬፭፮፯፰፱፲፳፴፵፶፷፸፹፺፻፼ ៰ ៱ ៲ ៳ ៴ ៵ ៶ ៷ ៸ ៹ ᧚⁰⁴⁵⁶⁷⁸⁹₀₁₂₃₄₅₆₇₈₉⅐⅑⅒⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞⅟↉①②③④⑤⑥⑦⑧⑨⑩⑪⑫⑬⑭⑮⑯⑰⑱⑲⑳⑴⑵⑶⑷⑸⑹⑺⑻⑼⑽⑾⑿⒀⒁⒂⒃⒄⒅⒆⒇⒈⒉⒊⒋⒌⒍⒎⒏⒐⒑⒒⒓⒔⒕⒖⒗⒘⒙⒚⒛⓪⓫⓬⓭⓮⓯⓰⓱⓲⓳⓴⓵⓶⓷⓸⓹⓺⓻⓼⓽⓾⓿❶❷❸❹❺❻❼❽❾❿➀➁➂➃➄➅➆➇➈➉➊➋➌➍➎➏➐➑➒➓ ⳽ ㆒ ㆓ ㆔ ㆕ ㈠㈡㈢㈣㈤㈥㈦㈧㈨㈩㉈㉉㉊㉋㉌㉍㉎㉏㉑㉒㉓㉔㉕㉖㉗㉘㉙㉚㉛㉜㉝㉞㉟㊀㊁㊂㊃㊄㊅㊆㊇㊈㊉㊱㊲㊳㊴㊵㊶㊷㊸㊹㊺㊻㊼㊽㊾㊿꠰꠱꠲꠳꠴꠵𐄇𐄈𐄉𐄊𐄋𐄌𐄍𐄎𐄏𐄐𐄑𐄒𐄓𐄔𐄕𐄖𐄗𐄘𐄙𐄚𐄛𐄜𐄝𐄞𐄟𐄠𐄡𐄢𐄣𐄤𐄥𐄦𐄧𐄨𐄩𐄪𐄫𐄬𐄭𐄮𐄯𐄰𐄱𐄲𐄳𐅵𐅶𐅷𐅸𐆊𐆋𐋡𐋢𐋣𐋤𐋥𐋦𐋧𐋨𐋩𐋪𐋫𐋬𐋭𐋮𐋯𐋰𐋱𐋲𐋳𐋴𐋵𐋶𐋷𐋸𐋹𐋺𐋻 𐌠𐌡𐌢𐌣 𐡘𐡙𐡚𐡛𐡜𐡝𐡞𐡟 𐡹𐡺𐡻𐡼𐡽𐡾𐡿 𐢧𐢨𐢩𐢪𐢫𐢬𐢭𐢮𐢯 𐣻𐣼𐣽𐣾𐣿 𐤖𐤗𐤘𐤙𐤚𐤛 𐦼𐦽𐧀𐧁𐧂𐧃𐧄𐧅𐧆𐧇𐧈𐧉𐧊𐧋𐧌𐧍𐧎𐧏𐧒𐧓𐧔𐧕𐧖𐧗𐧘𐧙𐧚𐧛𐧜𐧝𐧞𐧟𐧠𐧡𐧢𐧣𐧤𐧥𐧦𐧧𐧨𐧩𐧪𐧫𐧬𐧭𐧮𐧯𐧰𐧱𐧲𐧳𐧴𐧵𐧶𐧷𐧸𐧹𐧺𐧻𐧼𐧽𐧾𐧿 𐩀𐩁𐩂𐩃𐩄𐩅𐩆𐩇 𐩽𐩾 𐪝𐪞𐪟 𐫫𐫬𐫭𐫮𐫯 𐭘𐭙𐭚𐭛𐭜𐭝𐭞𐭟 𐭸𐭹𐭺𐭻𐭼𐭽𐭾𐭿 𐮩𐮪𐮫𐮬𐮭𐮮𐮯 𐳺𐳻𐳼𐳽𐳾𐳿 𐹠𐹡𐹢𐹣𐹤𐹥𐹦𐹧𐹨𐹩𐹪𐹫𐹬𐹭𐹮𐹯𐹰𐹱𐹲𐹳𐹴𐹵𐹶𐹷𐹸𐹹𐹺𐹻𐹼𐹽𐹾 𑁒𑁓𑁔𑁕𑁖𑁗𑁘𑁙𑁚𑁛𑁜𑁝𑁞𑁟𑁠𑁡𑁢𑁣𑁤𑁥 𑇡𑇢𑇣𑇤𑇥𑇦𑇧𑇨𑇩𑇪𑇫𑇬𑇭𑇮𑇯𑇰𑇱𑇲𑇳𑇴 𑜺𑜻 𑣪𑣫𑣬𑣭𑣮𑣯𑣰𑣱𑣲 𖭛𖭜𖭝𖭞𖭟𖭠𖭡𝍠𝍡𝍢𝍣𝍤𝍥𝍦𝍧𝍨𝍩𝍪𝍫𝍬𝍭𝍮𝍯𝍰𝍱 𞣇𞣈𞣉𞣊𞣋𞣌𞣍𞣎𞣏🄀🄁🄂🄃🄄🄅🄆🄇🄈🄉🄊🄋🄌


Печально то, что консоль Win32 не отображает астральные символы
Себастьян,

4
Если я правильно помню, к сожалению, в .NET Regexне поддерживает не-BMP символы. Так что в конце проверка символов> 0xffff с регулярным выражением бесполезна.
xanatos

-1

\ d проверяет все Unicode, в то время как [0-9] ограничен этими 10 символами. Если всего 10 цифр, вы должны использовать. Другие я рекомендую использовать \ d , Потому что пишу меньше.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.