\ d는 [0-9]보다 비효율적이다


1246

나는 누군가가 사용했던 답변에 어제 코멘트를 만든 [0123456789]A의 정규 표현식 보다는 [0-9]\d. 문자 세트보다 범위 또는 숫자 지정자를 사용하는 것이 더 효율적이라고 말했습니다.

나는 오늘 그것을 테스트하기로 결정했고 (C # 정규식 엔진에서) \d크게 다르지 않은 다른 두 엔진 보다 효율성이 떨어지는 것으로 놀랐 습니다. 다음은 실제로 숫자가 포함 된 5077의 1000 개의 임의 문자로 구성된 10000 개의 임의 문자열에 대한 테스트 결과입니다.

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로케일 다루고있다. 예를 들어 히브리어는 숫자로 문자를 사용합니다.
Barmar


37
이것은 \d다른 언어에서 동일한 것을 의미하지 않기 때문에 흥미로운 질문 입니다. 예를 들어 Java \d에서는 실제로 0-9 와만 일치
Ray Toal

17
@Barmar 히브리어는 일반적으로 숫자에 문자를 사용하지 않고 같은 라틴 숫자 [0-9]를 사용합니다. 문자는 숫자로 대체 될 수 있지만 이는 드문 용도이며 특수 용어로 예약되어 있습니다. 정규식 파서가 כגייררי סירה 와 일치 할 것으로 기대하지는 않습니다 (כ"ג는 23의 대체물 임). 또한 Sina Iravanian의 답변에서 볼 수 있듯이 히브리어 문자는 \ 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 %
도시락

답변:


1565

\d모든 유니 코드 숫자를 확인하지만 [0-9]이 10 자로 제한됩니다. 예를 들어, 페르시아 숫자 () ۱۲۳۴۵۶۷۸۹는와 일치 \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());

어떤 생성 :

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


121
다음은 0-9가 아닌보다 완전한 자릿수 목록입니다. fileformat.info/info/unicode/category/Nd/list.htm
Robert McKee

8
@weston Unicode에는 각각 16 비트의 17 개의 평면이 있습니다. 가장 중요한 문자는 기본 평면에 있지만 일부 특수 문자 (대부분 중국어)는 보조 평면에 있습니다. C #에서 다루는 것은 약간 성가신 일입니다.
코드 InChaos

9
@RobertMcKee : Nitpick : 전체 유니 코드 문자 세트는 실제로 21 비트입니다 (각각 16 비트의 17 개 평면). 물론 21 비트 데이터 유형은 실용적이지 않으므로 2의 거듭 제곱 데이터 유형을 사용하는 경우 32 비트가 필요합니다.
sleske

3
이 Wikipedia 기사 에 따르면 유니 코드 컨소시엄은 코드 포인트 1,114,112 (0 ~ 0x010FFFF)의 한도는 절대 변경되지 않을 것이라고 언급했습니다. 그것은 unicode.org에 연결되어 있지만 거기에서 진술을 찾지 못했습니다 (아마도 그냥 놓쳤습니다).
Keith Thompson

14
변경해야 할 때까지 절대 변경되지 않습니다.
Robert McKee

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합니까?
laurent

7
에서 정규 표현식 옵션 : "표현식을위한 ECMAScript 호환을 사용합니다."
chrisaycock

28
@ 0xFE :별로. 유니 코드 이스케이프는 여전히 ECMAScript( \u1234) 에서 유효합니다 . 의미 (예 :)를 변경하는 단축 문자 클래스 \d와 (예 :) 사라지는 유니 코드 속성 / 스크립트 문자 \p{N}입니다.
Tim Pietzcker

9
이것은 "왜"부분에 대한 답변이 아닙니다. "증상 수정"답변입니다. 여전히 귀중한 정보.
usr

일반적으로 Regrex는 유니 코드 일치를 지원합니다. 그러나 ECMAScript는 그렇지 않습니다. 따라서 RegexOptions.ECMAScript를 사용하는 경우 ASCII, 즉 0-9 와만 일치합니다.
lzlstyle

119

From 정규식의 "\ 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는 모든 10 진수와 일치합니다. \ p {Nd} 정규식 패턴과 같습니다. 여기에는 표준 10 진수 0-9와 다른 여러 문자 집합의 10 진수가 포함됩니다."
İsmet Alkan

3
@ByteBlast 덕분에 생성자를 사용하여 var rex = new Regex(regex, RegexOptions.ECMAScript);성능 측면에서 모두 구별 할 수 없게 만듭니다.
weston

2
어쨌든 모두 감사합니다. 이 질문은 저에게 훌륭한 학습으로 판명되었습니다.
İsmet Alkan

3
다른 질문의 답변을 "그냥 복사"하지 마십시오. 질문이 중복되는 경우 그와 같이 표시하십시오.
BoltClock

20

에 추가 상부 않음 로부터 시나 Iravianian은 여기 유니 코드 코드 포인트들의 전체 범위를 사용하여 자신의 코드 (제 산신 CF 해당 버전 지원의 UTF16 출력 보낸) 닷넷 4.5 버전이다. 더 높은 유니 코드 평면을 제대로 지원하지 않기 때문에 많은 사람들이 항상 상위 유니 코드 평면을 확인하고 포함하는 것을 인식하지 못합니다. 그럼에도 불구하고 그들은 때때로 중요한 인물들을 포함하고 있습니다.

최신 정보

\d정규식에서 비 BMP 문자를 지원하지 않기 때문에 ( xanatos 덕분에 ) 여기에 유니 코드 문자 데이터베이스를 사용하는 버전

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

LetterNumber

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

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


안타깝게도 Win32 콘솔에는 아스트랄 문자가 표시되지 않습니다.
Sebastian

4
corretly를 기억한다면 슬프게도 .NET Regex에서는 BMP가 아닌 문자를 지원하지 않습니다. 따라서 정규식으로 0xffff보다 큰 문자를 검사하는 것은 쓸모가 없습니다.
xanatos

-1

\ d는 모든 유니 코드를 검사하지만 [0-9]는이 10 자로 제한됩니다. 10 자리 숫자 인 경우 사용해야합니다. \ d , 사용하는 것이 적기 때문에 다른 것을 추천합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.