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

Question

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

1203

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

Я решил проверить это сегодня и, с удивлением обнаружил, что (по крайней мере, в двигателе с регулярным выражением С#) \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

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

Я бы подумал, что диапазон будет реализован намного эффективнее, чем набор.
Я не понимаю, почему \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;
        }
    }
}

weston 18 май 2013, в 08:35

Источник

166

Возможно \d имеет дело с локалями. Например, иврит использует буквы для цифр.
Barmar 18 май 2013, в 07:20
1

По сути, когда вам приходится иметь дело с Юникодом, тогда он будет намного медленнее (поскольку он должен делать больше проверок).
nhahtdh 18 май 2013, в 08:14
6

связанные: stackoverflow.com/a/6479605/674039
wim 18 май 2013, в 15:04
35

Это интересный вопрос именно потому, что \d не означает одно и то же на разных языках. Например, в Java \d действительно соответствует только 0-9
Ray Toal 18 май 2013, в 17:59
15

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

Это не в JavaScript, к вашему сведению: jsperf.com/d-and-09-in-regex
Afshin Mehrabani 20 май 2013, в 11:10
1

В случае, если кому-то интересно, это, кажется, странно относится и к Java, хотя и в меньшей степени. [0123456789] на ~ 4% быстрее, чем \ d, для файла 6 Мб с кучей случайного мусора, предварительно скомпилированными шаблонами, тысячами итераций. Средняя продолжительность для 0123456789: 466,46 мс (стандартное отклонение: 19,78). И \ d: среднее значение: 484,35 мс (стандартное отклонение: 25,98).
Nim 20 май 2013, в 15:52
6

Портирование кода 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% от первого
Lunchbox 22 май 2013, в 16:35
0

@ Lunchbox спасибо, я ожидал, что это будет порядок.
weston 22 май 2013, в 17:56
0

Преждевременная оптимизация - корень всего зла.
Isaac Rabinovitch 23 май 2013, в 18:45
0

@IsaacRabinovitch Просто чтобы вы знали, что ваши изменения были отклонены, потому что теги не должны появляться в вопросах, а вопрос уже помечен как c #
weston 23 май 2013, в 19:52
0

@IsaacRabinovitch и в ответ на вашу цитату, это просто верно в 97% случаев!
weston 23 май 2013, в 19:56
1

\ d требуется меньше нажатий кнопок, поэтому лучше: D
David Grinberg 05 июнь 2013, в 20:05
0

@lunchbox период прогрева не закончен - цифры еще не надежны.
Thorbjørn Ravn Andersen 03 июнь 2014, в 16:20

Показать ещё 12 комментариев

Теги:

c#

performance

regex

6 ответов

253

Кредит 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

weston 18 май 2013, в 11:36

10

Что делает RegexOptions.ECMAScript ?
laurent 20 май 2013, в 01:36
5

Из параметров регулярного выражения : «Включить ECMAScript-совместимое поведение для выражения».
chrisaycock 20 май 2013, в 01:58
83

По сути, я думаю, что это устраняет поддержку Unicode.
0xFE 20 май 2013, в 03:33
26

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

Это не ответ на вопрос «почему». Это ответ «исправить симптомы». По-прежнему ценная информация.
usr 29 май 2013, в 16:52
0

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

Показать ещё 4 комментария

109

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

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

İsmet Alkan 18 май 2013, в 08:13

48

Согласно: msdn.microsoft.com/en-us/library/20bw873z.aspx If ECMAScript-compliant behavior is specified, \d is equivalent to [0-9].
User 12345678 18 май 2013, в 07:30
2

да, я не прав или это предложение по ссылке говорит об обратном. «\ d соответствует любой десятичной цифре. Это эквивалентно шаблону регулярного выражения \ p {Nd}, который включает стандартные десятичные цифры 0–9, а также десятичные цифры ряда других наборов символов».
İsmet Alkan 18 май 2013, в 07:51
3

@ByteBlast спасибо, используя конструктор: var rex = new Regex(regex, RegexOptions.ECMAScript); делает их практически неразличимыми с точки зрения производительности.
weston 18 май 2013, в 07:53
2

о, так или иначе, спасибо всем. этот вопрос оказался для меня очень полезным.
İsmet Alkan 18 май 2013, в 07:54
0

@ Weston: Я думаю, было бы неплохо, если бы вы опубликовали новое время в форме ответа (или отредактировали свой вопрос, но я думаю, что это может быть ответом).
nhahtdh 18 май 2013, в 08:20
0

@nhahtdh сделано
weston 18 май 2013, в 09:39
3

Пожалуйста, не «просто копируйте» ответы на другие вопросы. Если вопрос дубликат, отметьте его как таковой.
BoltClock♦ 18 май 2013, в 12:00
1

Кроме того, вы можете захотеть процитировать оригинальный текст, а не просто копировать его, как это обычно делается при использовании контента, который вы не написали сами.
slhck 18 май 2013, в 12:02
1

вопрос не повторяется, но ответ уместен. заявил, что я копирую, но теперь я вижу, что это неправильная структура для этого. спасибо за редактирование и помощь.
İsmet Alkan 18 май 2013, в 12:20

Показать ещё 7 комментариев

15

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

Обновление

Так как \d не поддерживает символы без BMP в regex (спасибо 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 012345678901234567890123456789߀߁߂߃߄߅߆߇߈߉012345678 9 01২345678901234567890123456789 ୦୧୨୩୪୫୬୭୮୯ 0123456789012345678901234567890123456789 ෦෧෨෩෪෫෬෭෮෯ 012345678901234567890123456789012345678901234567890123456789 ᠐᠑᠒᠓᠔᠕᠖᠗᠘᠙ ᥆᥇᥈᥉᥊᥋᥌᥍᥎᥏ ᧐᧑᧒᧓᧔᧕᧖᧗᧘᧙᪀᪁᪂᪃᪄᪅᪆᪇᪈᪉᪐᪑᪒᪓᪔᪕᪖᪗᪘᪙ ᭐᭑᭒᭓᭔᭕᭖᭗᭘᭙᮰᮱᮲᮳᮴᮵᮶᮷᮸᮹᱀᱁᱂᱃᱄᱅᱆᱇᱈᱉᱐᱑᱒᱓᱔᱕᱖᱗᱘᱙꘠꘡꘢꘣꘤꘥꘦꘧꘨꘩꣐꣑꣒꣓꣔꣕꣖꣗꣘꣙꤀꤁꤂꤃꤄꤅꤆꤇꤈꤉꧐꧑꧒꧓꧔꧕꧖꧗꧘꧙꧰꧱꧲꧳꧴꧵꧶꧷꧸꧹꩐꩑꩒꩓꩔꩕꩖꩗꩘꩙ ꯰꯱꯲꯳꯴꯵꯶꯷꯸꯹0123456789?????????? ?????????? ?????????? ?????????? ?????????? ?????????? ?????????? ?????????? ?????????? ?????????? ?????????? ?????????? ????????????????????????????????????????????????????????????

LetterNumber

ᛮᛯᛰⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩⅪⅫⅬⅭⅮⅯⅰⅱⅲⅳⅴⅵⅶⅷⅸⅹⅺⅻⅼⅽⅾⅿↀↁↂↅↆↇↈ〇〡〢〣〤〥〦〧〨〩〸〹〺ꛦꛧꛨꛩꛪꛫꛬꛭꛮꛯ ????????????????????????????????????????????????????? ?? ????? ???????????????????????????????????????????????????????????????????????????????????????????????????????????????

OtherNumber ²³¹¼½¾৴৵৶.৸৹ ୲୳୴୵୶୷ ௰௱௲ ౸౹౺౻౼౽౾ ൰൱൲൳൴൵ ༪ ༫ ༬ ༭ ༮ ༯ ༰ ༱ ༲ ༳ ፩፪፫፬፭፮፯፰፱፲፳፴፵፶፷፸፹፺፻፼ ៰ ៱ ៲ ៳ ៴ ៵ ៶ ៷ ៸ ៹ ᧚⁰⁴⁵⁶⁷⁸⁹₀₁₂₃₄₅₆₇₈₉⅐⅑⅒⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞⅟↉①②③④⑤⑥⑦⑧⑨⑩⑪⑫⑬⑭⑮⑯⑰⑱⑲⑳⑴⑵⑶⑷⑸⑹⑺⑻⑼⑽⑾⑿⒀⒁⒂⒃⒄⒅⒆⒇⒈⒉⒊⒋⒌⒍⒎⒏⒐⒑⒒⒓⒔⒕⒖⒗⒘⒙⒚⒛⓪⓫⓬⓭⓮⓯⓰⓱⓲⓳⓴⓵⓶⓷⓸⓹⓺⓻⓼⓽⓾⓿❶❷❸❹❺❻❼❽❾❿➀➁➂➃➄➅➆➇➈➉➊➋➌➍➎➏➐➑➒➓ ⳽ ㆒ ㆓ ㆔ ㆕ ㈠㈡㈢㈣㈤㈥㈦㈧㈨㈩㉈㉉㉊㉋㉌㉍㉎㉏㉑㉒㉓㉔㉕㉖㉗㉘㉙㉚㉛㉜㉝㉞㉟㊀㊁㊂㊃㊄㊅㊆㊇㊈㊉㊱㊲㊳㊴㊵㊶㊷㊸㊹㊺㊻㊼㊽㊾㊿꠰꠱꠲꠳꠴꠵?????????????????????????????????? ???????????????????????????????????????????? ???? ???????? ??????? ????????? ????? ?????? ???????????????????????????????????????????????????????????????? ???????? ?? ??? ????? ???????? ???????? ??????? ?????? ??????????????????????????????? ???????????????????? ????? ??????????????? ?? ????????? ????????????????????????? ??????????????????????

Sebastian 13 сен. 2013, в 10:14

0

Печально то, что консоль Win32 не отображает астральные символы
Sebastian 27 май 2014, в 21:57
4

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

0

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

dengkai 11 март 2016, в 11:36

-13

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

Например, если я хочу, чтобы Regex находил IP-адреса, я предпочел бы \d, чем [0123456789] или даже [0-9] представлять любую цифру.

Вообще говоря, в моем использовании Regex, функция, если важнее скорости.

Faizal 08 фев. 2015, в 21:36

1

Хотя это может повлечь за собой небольшое наказание, это можно сделать один раз, прежде чем сравнивать шаблон с любой входной строкой. Таким образом, сложность по времени составляет O(1) , а не O(n) , (где n - длина входной строки.) Короче говоря, влияние в лучшем случае минимально.
jpaugh 06 март 2018, в 18:28

Ещё вопросы

Возможно \d имеет дело с локалями. Например, иврит использует буквы для цифр.
По сути, когда вам приходится иметь дело с Юникодом, тогда он будет намного медленнее (поскольку он должен делать больше проверок).
Это интересный вопрос именно потому, что \d не означает одно и то же на разных языках. Например, в Java \d действительно соответствует только 0-9
@ Бармар Иврит обычно не использует буквы для цифр, а те же цифры латинских цифр [0-9]. Буквы могут быть заменены цифрами, но это редкое использование и зарезервировано для специальных терминов. Я не ожидал бы, что синтаксический анализатор регулярных выражений будет соответствовать ג"ג יורדי סירה (с כ"ג вместо 23). Кроме того, как видно из ответа Сины Ираванян, ивритские буквы не отображаются в качестве действительных совпадений для \ d.
Это не в JavaScript, к вашему сведению: jsperf.com/d-and-09-in-regex
В случае, если кому-то интересно, это, кажется, странно относится и к Java, хотя и в меньшей степени. [0123456789] на ~ 4% быстрее, чем \ d, для файла 6 Мб с кучей случайного мусора, предварительно скомпилированными шаблонами, тысячами итераций. Средняя продолжительность для 0123456789: 466,46 мс (стандартное отклонение: 19,78). И \ d: среднее значение: 484,35 мс (стандартное отклонение: 25,98).
Портирование кода 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% от первого
@ Lunchbox спасибо, я ожидал, что это будет порядок.
Преждевременная оптимизация - корень всего зла.
@IsaacRabinovitch Просто чтобы вы знали, что ваши изменения были отклонены, потому что теги не должны появляться в вопросах, а вопрос уже помечен как c #
@IsaacRabinovitch и в ответ на вашу цитату, это просто верно в 97% случаев!
\ d требуется меньше нажатий кнопок, поэтому лучше: D
@lunchbox период прогрева не закончен - цифры еще не надежны.
Из параметров регулярного выражения : «Включить ECMAScript-совместимое поведение для выражения».
По сути, я думаю, что это устраняет поддержку Unicode.
@ 0xFE: Не совсем. \u1234 Unicode все еще допустимо в ECMAScript ( \u1234 ). Это «просто» классы сокращенных символов, которые меняют значение (например, \d ), и сокращенные сокращения свойств / сценариев Unicode (например, \p{N} ).
Это не ответ на вопрос «почему». Это ответ «исправить симптомы». По-прежнему ценная информация.
Как правило, Regrex поддерживает сопоставление юникода. Но ECMAScript нет. Следовательно, при использовании RegexOptions.ECMAScript он соответствует только ascii, то есть 0-9.
Согласно: msdn.microsoft.com/en-us/library/20bw873z.aspx If ECMAScript-compliant behavior is specified, \d is equivalent to [0-9].
да, я не прав или это предложение по ссылке говорит об обратном. «\ d соответствует любой десятичной цифре. Это эквивалентно шаблону регулярного выражения \ p {Nd}, который включает стандартные десятичные цифры 0–9, а также десятичные цифры ряда других наборов символов».
@ByteBlast спасибо, используя конструктор: var rex = new Regex(regex, RegexOptions.ECMAScript); делает их практически неразличимыми с точки зрения производительности.
о, так или иначе, спасибо всем. этот вопрос оказался для меня очень полезным.
@ Weston: Я думаю, было бы неплохо, если бы вы опубликовали новое время в форме ответа (или отредактировали свой вопрос, но я думаю, что это может быть ответом).
Пожалуйста, не «просто копируйте» ответы на другие вопросы. Если вопрос дубликат, отметьте его как таковой.
Кроме того, вы можете захотеть процитировать оригинальный текст, а не просто копировать его, как это обычно делается при использовании контента, который вы не написали сами.
вопрос не повторяется, но ответ уместен. заявил, что я копирую, но теперь я вижу, что это неправильная структура для этого. спасибо за редактирование и помощь.
Печально то, что консоль Win32 не отображает астральные символы
Если я правильно помню, к сожалению, в .NET Regex не поддерживает не-BMP символы. Так что в конце проверка символов> 0xffff с регулярным выражением бесполезна.
Хотя это может повлечь за собой небольшое наказание, это можно сделать один раз, прежде чем сравнивать шаблон с любой входной строкой. Таким образом, сложность по времени составляет O(1) , а не O(n) , (где n - длина входной строки.) Короче говоря, влияние в лучшем случае минимально.

Sina Iravanian · Accepted Answer · 2013-05-18T08-34-00.000Z

1552

Лучший ответ

\d проверяет все цифры в Unicode, а [0-9] ограничивается этими 10 символами. Например, цифры Persian, ۱۲۳۴۵۶۷۸۹, являются примером цифр 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

Sina Iravanian 18 май 2013, в 08:34

114

Вот более полный список цифр, которые не являются 0-9: fileformat.info/info/unicode/category/Nd/list.htm
Robert McKee 18 май 2013, в 07:29
2

Круто, хотя должен быть UInt16 ? Кроме того, эта ссылка от Роберта показывает символы выше \uFFFF которые меня удивили, я думал, что это всего лишь 16 бит. Так что ваш код не найдет их, например, \ u104A0.
weston 18 май 2013, в 07:47
8

@ Weston Unicode имеет 17 самолетов по 16 бит в каждом. Наиболее важные символы находятся в базовой плоскости, но некоторые специальные символы, в основном китайские, находятся в дополнительных плоскостях. Работа с теми, кто работает в C #, немного раздражает.
CodesInChaos 18 май 2013, в 07:55
0

@CodesInChaos: если быть точным, плоскость 2 предназначена для иероглифа (редкие символы), плоскость 1 содержит довольно много символов и древних сценариев.
nhahtdh 18 май 2013, в 08:18
1

Правильный. Полный набор символов Юникода на самом деле является 32-разрядным (UTF32), но существует много способов его кодирования, чтобы его можно было представить с помощью 16-разрядного (UTF16) или 8-разрядного (UTF8) резервирования одной или нескольких записей в сдвигать части набора внутрь и наружу. UTF16 и UTF8 иногда принимают несколько символов для представления одного символа Unicode, что может значительно усложнить обработку.
Robert McKee 18 май 2013, в 08:45
0

связанный stackoverflow.com/a/6479605/674039
wim 18 май 2013, в 15:04
9

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

@sleske Неизбежно наступит день, когда символов 10FFFF недостаточно. UTF-8 и UCS-32 выживут в тот день (это просто вопрос отключения отклонения более широких символов), UTF-16 не выживет.
zwol 18 май 2013, в 21:38
0

@sleske Вы правы, пока. Они продолжают расширять символы Юникода, так что я определенно могу видеть момент времени, когда 21 бит недостаточно (хотя там много неиспользованного / неопределенного пространства). Мне проще думать о юникоде, требующем или когда-нибудь потребуется все 32-битные.
Robert McKee 19 май 2013, в 01:14
0

Каким шрифтом могут отображаться все эти символы? Даже Arial Unicode MS очень не хватает, как, например, Мьянма, Судан, Тай Там и другие персонажи.
Samuel Neff 20 май 2013, в 00:50
3

Согласно этой статье в Википедии , Консорциум Unicode заявил, что ограничение в 1114112 кодовых точек (от 0 до 0x010FFFF) никогда не изменится. Он ссылается на unicode.org, но я не нашел там заявления (возможно, я просто пропустил его).
Keith Thompson 20 май 2013, в 02:50
13

Это никогда не изменится - пока им не нужно это изменить.
Robert McKee 08 июль 2013, в 21:00
0

Я добавил ответ, чтобы решить проблему с точкой кода: stackoverflow.com/a/18781614/281306
Sebastian 10 янв. 2014, в 22:08
1

Этот ответ был добавлен в FAQ по регулярным выражениям Stack Overflow в разделе «Классы символов».
aliteralmind 10 апр. 2014, в 00:19
0

проверка до UInt16.MaxValue недостаточно, поскольку UInt16.MaxValue Unicode могут UInt16.MaxValue до 2 ^ 21-1
phuclv 22 июнь 2014, в 10:17
0

Вы не можете привести 32-битное значение (например, 0x010FFFF) к типу char, потому что тип .NET char хранит символы UTF-16, а не символы Unicode. (Символы за пределами первой плоскости Unicode хранятся в виде двух символов UTF-16 с использованием суррогатных пар.)
Mike Rosoft 31 янв. 2019, в 12:16

Показать ещё 14 комментариев