\ d jest mniej wydajny niż [0-9]

1246

Zrobiłem komentarz wczoraj na odpowiedź, gdzie ktoś użył [0123456789]w wyrażeniu regularnym zamiast [0-9]lub \d. Powiedziałem, że prawdopodobnie bardziej efektywne jest użycie specyfikatora zakresu lub cyfry niż zestawu znaków.

Postanowiłem to dzisiaj przetestować i ku mojemu zaskoczeniu odkryłem, że (przynajmniej w silniku regex C #) \dwydaje się być mniej wydajny niż którykolwiek z dwóch pozostałych, które nie wydają się bardzo różne. Oto mój wynik testu ponad 10000 losowych ciągów 1000 losowych znaków, przy czym 5077 faktycznie zawiera cyfrę:

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

Jest to dla mnie niespodzianka z dwóch powodów:

  1. Myślałem, że zakres zostanie wdrożony znacznie wydajniej niż zestaw.
  2. Nie rozumiem, dlaczego \djest gorszy niż [0-9]. Czy jest coś więcej \dniż tylko skrót [0-9]?

Oto kod testowy:

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;
        }
    }
}
weston
źródło
178
Może \dzajmuje się lokalizacjami. Na przykład hebrajski używa liter do cyfr.
Barmar
37
To interesujące pytanie właśnie dlatego, \dże nie oznacza tego samego w różnych językach. Na przykład w Javie \drzeczywiście pasuje tylko 0-9
Ray Toal
17
@Barmar Hebrajski nie używa normalnie liter do cyfr, a raczej te same cyfry łacińskie [0-9]. Litery mogą być zastępowane cyframi, ale jest to rzadkie użycie i zarezerwowane na specjalne warunki. Nie spodziewałbym się, że parser wyrażeń regularnych będzie pasował do כ"ג יורדי סירה (z כ"ג będącym substytutem dla 23). Ponadto, jak widać w odpowiedzi Siny Iravanian, litery hebrajskie nie pojawiają się jako prawidłowe dopasowania dla \ d.
Yuval Adam
7
Przeniesienie kodu Westona na Javę daje: - Regex \ d wziął 00: 00: 00.043922 wynik: 4912/10000 - Regex [0-9] wziął 00: 00: 00.073658 wynik: 4912/10000 167% pierwszego - Regex [ 0123456789] wziął 00: 00: 00.085799 wynik: 4912/10000 195% pierwszego
Lunchbox

Odpowiedzi:

1565

\dsprawdza wszystkie cyfry Unicode, a [0-9]ogranicza się do tych 10 znaków. Na przykład cyfry perskie۱۲۳۴۵۶۷۸۹ , są przykładem cyfr Unicode, które są dopasowane \d, ale nie [0-9].

Możesz wygenerować listę wszystkich takich znaków, używając następującego kodu:

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());

Co generuje:

0123456789 ٠١٢٣٤٥٦٧٨٩۰۱۲۳۴۵۶۷۸۹߀߁߂߃߄߅߆߇߈߉०१२३४५६७८ ০১২৩৪৫৬৭৮৯੦੧੨੩੪੫੬੭੮੯૦૧૨૩૪૫૬૭૮૯ ০১২৩৪৫৬৭৮৯੦੧੨੩੪੫੬੭੮੯૦૧૨૩૪૫૬૭૮૯ ୦୧୨୩୪୫୬୭୮୯ ௦௧௨௩௪௫௬௭௮௯౦౧౨౩౪౫౬౭౮౯೦೧೨೩೪೫೬೭೮೯൦൧൨൩൪൫൬൭൮൯๐๑๒๓๔๕๖๗๘๙໐໑໒໓໔໕໖໗໘໙༠༡༢༣༤༥༦༧༨༩၀၁၂၃၄၅၆၇၈၉႐႑႒႓႔႕႖႗႘႙០១២៣៤៥៦៧៨៩ ᠐᠑᠒᠓᠔᠕᠖᠗᠘᠙ ᥆᥇᥈᥉᥊᥋᥌᥍᥎᥏ ᧐᧑᧒᧓᧔᧕᧖᧗᧘᧙ ᭐᭑᭒᭓᭔᭕᭖᭗᭘᭙᮰᮱᮲᮳᮴᮵᮶᮷᮸᮹᱀᱁᱂᱃᱄᱅᱆᱇᱈᱉᱐᱑᱒᱓᱔᱕᱖᱗᱘᱙꘠꘡꘢꘣꘤꘥꘦꘧꘨꘩꣐꣑꣒꣓꣔꣕꣖꣗꣘꣙꤀꤁꤂꤃꤄꤅꤆꤇꤈꤉꩐꩑꩒꩓꩔꩕꩖꩗꩘꩙0123456789

Sina Iravanian
źródło
121
Oto pełna lista cyfr, które nie są 0-9: fileformat.info/info/unicode/category/Nd/list.htm
Robert McKee
8
@weston Unicode ma 17 samolotów z 16 bitami każdy. Najważniejsze postacie znajdują się w płaszczyźnie podstawowej, ale niektóre znaki specjalne, głównie chińskie, znajdują się w płaszczyznach uzupełniających. Radzenie sobie z tymi w C # jest nieco denerwujące.
CodesInChaos
9
@RobertMcKee: Nitpick: Pełny zestaw znaków Unicode ma w rzeczywistości 21 bitów (17 płaszczyzn po 16 bitów każdy). Ale oczywiście 21-bitowy typ danych jest niepraktyczny, więc jeśli używasz typu danych 2-bitowego, to prawda, że ​​potrzebujesz 32-bitowego.
śleske,
3
Zgodnie z tym artykułem Wikipedii , Konsorcjum Unicode oświadczyło, że limit 1114112 punktów kodowych (od 0 do 0x010FFFF) nigdy nie zostanie zmieniony. Odsyła do strony unicode.org, ale nie znalazłem tam tego oświadczenia (prawdopodobnie właśnie go przegapiłem).
Keith Thompson,
14
Nigdy nie zostanie zmieniony - dopóki nie będą musieli go zmienić.
Robert McKee
271

Podziękowania dla ByteBlast za zauważenie tego w dokumentacji. Wystarczy zmienić konstruktor wyrażeń regularnych:

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

Daje nowe czasy:

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
weston
źródło
11
Czego RegexOptions.ECMAScriptzrobić?
laurent
7
Z opcji wyrażeń regularnych : „Włącz zachowanie wyrażenia zgodne z ECMAScript”.
chrisaycock
28
@ 0xFE: Niezupełnie. Ucieczki Unicode są nadal ważne w ECMAScript( \u1234). To „tylko” stenograficzne klasy znaków, które zmieniają znaczenie (jak \d) i skrócone właściwości (/) Unicode, które znikają (jak \p{N}).
Tim Pietzcker,
9
To nie jest odpowiedź na pytanie „dlaczego”. Jest to odpowiedź „napraw objawy”. Wciąż cenna informacja.
usr
Ogólnie rzecz biorąc, Regrex obsługuje dopasowanie Unicode. Ale ECMAScript nie. Dlatego przy użyciu RegexOptions.ECMAScript pasuje tylko do ascii, tj. 0-9.
lzlstyle
119

Od Czy „\ d” w wyrażeniu regularnym oznacza cyfrę? :

[0-9]nie jest równoważne z \d. [0-9]dopasowuje tylko 0123456789znaki, podczas gdy \ddopasowania [0-9]i inne znaki cyfrowe, na przykład cyfry wschodnioafrykańskie٠١٢٣٤٥٦٧٨٩

İsmet Alkan
źródło
49
Według: msdn.microsoft.com/en-us/library/20bw873z.aspx If ECMAScript-compliant behavior is specified, \d is equivalent to [0-9].
Użytkownik 12345678
2
tak, czy się mylę lub to zdanie z linku mówi coś przeciwnego. „\ d dopasowuje dowolną cyfrę dziesiętną. Jest to odpowiednik wzorca wyrażenia regularnego \ p {Nd}, który obejmuje standardowe cyfry dziesiętne 0–9, a także cyfry dziesiętne szeregu innych zestawów znaków.”
İsmet Alkan
3
@ByteBlast dzięki, korzystanie z konstruktora: var rex = new Regex(regex, RegexOptions.ECMAScript);sprawia, że ​​wszystkie są prawie nie do odróżnienia pod względem wydajności.
weston
2
och w każdym razie dziękuję wszystkim. to pytanie okazało się dla mnie świetną nauką.
İsmet Alkan
3
Proszę nie „po prostu kopiować” odpowiedzi z innych pytań. Jeśli pytanie jest duplikatem, oznacz je jako takie.
BoltClock
20

Dodatek do górnej odpowiedź od Sina Iravianian , tutaj jest wersja .NET 4.5 (ponieważ tylko tego wyjścia podpory wersja UTF16, cf pierwszych trzech linii) jego kod, wykorzystując pełną gamę punktów kodowych Unicode. Z powodu braku odpowiedniego wsparcia dla wyższych samolotów Unicode, wiele osób nie jest świadomych zawsze sprawdzania i włączania wyższych samolotów Unicode. Niemniej jednak czasami zawierają ważne postacie.

Aktualizacja

Ponieważ \dnie obsługuje znaków innych niż BMP w wyrażeniach regularnych (dzięki xanatos ), tutaj wersja, która korzysta z bazy znaków znaków 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();
}

Uzyskanie następujących wyników:

DecimalDigitNumber 0123456789٠١٢٣٤٥٦٧٨٩۰۱۲۳۴۵۶۷۸۹߀߁߂߃߄߅߆߇߈߉०१२३४५६७८ ९ ০১২৩৪৫৬৭৮৯੦੧੨੩੪੫੬੭੮੯૦૧૨૩૪૫૬૭૮૯ ୦୧୨୩୪୫୬୭୮୯ ௦௧௨௩௪௫௬௭௮௯౦౧౨౩౪౫౬౭౮౯೦೧೨೩೪೫೬೭೮೯൦൧൨൩൪൫൬൭൮൯ ௦௧௨௩௪௫௬௭௮௯౦౧౨౩౪౫౬౭౮౯೦೧೨೩೪೫೬೭೮೯൦൧൨൩൪൫൬൭൮൯ ෦෧෨෩෪෫෬෭෮෯ ๐๑๒๓๔๕๖๗๘๙໐໑໒໓໔໕໖໗໘໙༠༡༢༣༤༥༦༧༨༩၀၁၂၃၄၅၆၇၈၉႐႑႒႓႔႕႖႗႘႙០១២៣៤៥៦៧៨៩ ᠐᠑᠒᠓᠔᠕᠖᠗᠘᠙ ᥆᥇᥈᥉᥊᥋᥌᥍᥎᥏ ᧐᧑᧒᧓᧔᧕᧖᧗᧘᧙᪀᪁᪂᪃᪄᪅᪆᪇᪈᪉᪐᪑᪒᪓᪔᪕᪖᪗᪘᪙ ᭐᭑᭒᭓᭔᭕᭖᭗᭘᭙᮰᮱᮲᮳᮴᮵᮶᮷᮸᮹᱀᱁᱂᱃᱄᱅᱆᱇᱈᱉᱐᱑᱒᱓᱔᱕᱖᱗᱘᱙꘠꘡꘢꘣꘤꘥꘦꘧꘨꘩꣐꣑꣒꣓꣔꣕꣖꣗꣘꣙꤀꤁꤂꤃꤄꤅꤆꤇꤈꤉꧐꧑꧒꧓꧔꧕꧖꧗꧘꧙꧰꧱꧲꧳꧴꧵꧶꧷꧸꧹꩐꩑꩒꩓꩔꩕꩖꩗꩘꩙꯰꯱꯲꯳꯴꯵꯶꯷꯸꯹0123456789 𐒠𐒡𐒢𐒣𐒤𐒥𐒦𐒧𐒨𐒩 𑁦𑁧𑁨𑁩𑁪𑁫𑁬𑁭𑁮𑁯 𑃰𑃱𑃲𑃳𑃴𑃵𑃶𑃷𑃸𑃹 𑄶𑄷𑄸𑄹𑄺𑄻𑄼𑄽𑄾𑄿 𑇐𑇑𑇒𑇓𑇔𑇕𑇖𑇗𑇘𑇙 𑋰𑋱𑋲𑋳𑋴𑋵𑋶𑋷𑋸𑋹 𑓐𑓑𑓒𑓓𑓔𑓕𑓖𑓗𑓘𑓙 𑙐𑙑𑙒𑙓𑙔𑙕𑙖𑙗𑙘𑙙 𑙐𑙑𑙒𑙓𑙔𑙕𑙖𑙗𑙘𑙙 𑛀𑛁𑛂𑛃𑛄𑛅𑛆𑛇𑛈𑛉 𑣠𑣡𑣢𑣣𑣤𑣥𑣦𑣧𑣨𑣩 𑣠𑣡𑣢𑣣𑣤𑣥𑣦𑣧𑣨𑣩 𖩠𖩡𖩢𖩣𖩤𖩥𖩦𖩧𖩨𖩩 𖭐𖭑𖭒𖭓𖭔𖭕𖭖𖭗𖭘𖭙𝟎𝟏𝟐𝟑𝟒𝟓𝟔𝟕𝟖𝟗𝟘𝟙𝟚𝟛𝟜𝟝𝟞𝟟𝟠𝟡𝟢𝟣𝟤𝟥𝟦𝟧𝟨𝟩𝟪𝟫𝟬𝟭𝟮𝟯𝟰𝟱𝟲𝟳𝟴𝟵𝟶𝟷𝟸𝟹𝟺𝟻𝟼𝟽𝟾𝟿

LetterNumber

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

OtherNumber²³¹¼½¾৴৵৶৷৸৹ ୲୳୴୵୶୷ ௰௱௲ ౸౹౺౻౼౽౾ ൰൱൲൳൴൵ ༪ ༫ ༬ ༭ ༮ ༮ ༯ ༱ ፩፪፫፬፭፮፯፰፱፲፳፴፵፶፷፸፹፺፻፼ ៰ ៱ ៱ ៲ ៳ ៳ ៵ ៶ ៷ ៸ ៹ ᧚⁰⁴⁵⁶⁷⁸⁹₀₁₂₃₄₅₆₇₈₉⅐⅑⅒⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞⅟↉①②③④⑤⑥⑦⑧⑨⑩⑪⑫⑬⑭⑮⑯⑰⑱⑲⑳⑴⑵⑶⑷⑸⑹⑺⑻⑼⑽⑾⑿⒀⒁⒂⒃⒄⒅⒆⒇⒈⒉⒊⒋⒌⒍⒎⒏⒐⒑⒒⒓⒔⒕⒖⒗⒘⒙⒚⒛⓪⓫⓬⓭⓮⓯⓰⓱⓲⓳⓴⓵⓶⓷⓸⓹⓺⓻⓼⓽⓾⓿❶❷❸❹❺❻❼❽❾❿➀➁➂➃➄➅➆➇➈➉➊➋➌➍➎➏➐➑➒➓ ⳽ ㆒ ㆒ ㆓ ㆓ ㆕ ㈠㈡㈢㈣㈤㈥㈦㈧㈨㈩㉈㉉㉊㉋㉌㉍㉎㉏㉑㉒㉓㉔㉕㉖㉗㉘㉙㉚㉛㉜㉝㉞㉟㊀㊁㊂㊃㊄㊅㊆㊇㊈㊉㊱㊲㊳㊴㊵㊶㊷㊸㊹㊺㊻㊼㊽㊾㊿꠰꠱꠲꠳꠴꠵𐄇𐄈𐄉𐄊𐄋𐄌𐄍𐄎𐄏𐄐𐄑𐄒𐄓𐄔𐄕𐄖𐄗𐄘𐄙𐄚𐄛𐄜𐄝𐄞𐄟𐄠𐄡𐄢𐄣𐄤𐄥𐄦𐄧𐄨𐄩𐄪𐄫𐄬𐄭𐄮𐄯𐄰𐄱𐄲𐄳𐅵𐅶𐅷𐅸𐆊𐆋𐋡𐋢𐋣𐋤𐋥𐋦𐋧𐋨𐋩𐋪𐋫𐋬𐋭𐋮𐋯𐋰𐋱𐋲𐋳𐋴𐋵𐋶𐋷𐋸𐋹𐋺𐋻 ㈠㈡㈢㈣㈤㈥㈦㈧㈨㈩㉈㉉㉊㉋㉌㉍㉎㉏㉑㉒㉓㉔㉕㉖㉗㉘㉙㉚㉛㉜㉝㉞㉟㊀㊁㊂㊃㊄㊅㊆㊇㊈㊉㊱㊲㊳㊴㊵㊶㊷㊸㊹㊺㊻㊼㊽㊾㊿꠰꠱꠲꠳꠴꠵𐄇𐄈𐄉𐄊𐄋𐄌𐄍𐄎𐄏𐄐𐄑𐄒𐄓𐄔𐄕𐄖𐄗𐄘𐄙𐄚𐄛𐄜𐄝𐄞𐄟𐄠𐄡𐄢𐄣𐄤𐄥𐄦𐄧𐄨𐄩𐄪𐄫𐄬𐄭𐄮𐄯𐄰𐄱𐄲𐄳𐅵𐅶𐅷𐅸𐆊𐆋𐋡𐋢𐋣𐋤𐋥𐋦𐋧𐋨𐋩𐋪𐋫𐋬𐋭𐋮𐋯𐋰𐋱𐋲𐋳𐋴𐋵𐋶𐋷𐋸𐋹𐋺𐋻 𐡘𐡙𐡚𐡛𐡜𐡝𐡞𐡟 𐡹𐡺𐡻𐡼𐡽𐡾𐡿 𐡹𐡺𐡻𐡼𐡽𐡾𐡿 𐢧𐢨𐢩𐢪𐢫𐢬𐢭𐢮𐢯 𐣻𐣼𐣽𐣾𐣿 𐣻𐣼𐣽𐣾𐣿𐣻𐣼𐣽𐣾𐣿𑇧𑇨𑇩𑇪𑇫𑇬𑇭𑇮𑇯𑇰𑇱𑇲𑇳𑇴 𑜺𑜻 𑣪𑣫𑣬𑣭𑣮𑣯𑣰𑣱𑣲 𖭛𖭜𖭝𖭞𖭟𖭠𖭡𝍠𝍡𝍢𝍣𝍤𝍥𝍦𝍧𝍨𝍩𝍪𝍫𝍬𝍭𝍮𝍯𝍰𝍱 𞣇𞣈𞣉𞣊𞣋𞣌𞣍𞣎𞣏🄀🄁🄂🄃🄄🄅🄆🄇🄈🄉🄊🄋🄌

Sebastian
źródło
Smutne jest to, że konsola Win32 nie wyświetla znaków astralnych
Sebastian
4
Jeśli dobrze pamiętam, niestety .NET Regexnie obsługuje znaków spoza BMP. W końcu sprawdzanie znaków> 0xffff za pomocą wyrażenia regularnego jest bezużyteczne.
xanatos
-1

\ d sprawdza cały Unicode, podczas gdy [0-9] jest ograniczony do tych 10 znaków. Jeśli masz tylko 10 cyfr, powinieneś użyć. Inni polecam używać \ d, ponieważ pisz mniej.

dengkai
źródło