Як я можу виконати чутливу до культури операцію "починаючи з" із середини рядка?

У мене є вимога , яке є відносно неясним, але він відчуває , як це повинно бути можливо з допомогою BCL.

Для контексту я аналізую рядок дати / часу в Noda Time . Я підтримую логічний курсор для свого положення у вхідному рядку. Таким чином, хоча повна рядок може бути "3 січня 2013 року", логічний курсор може бути на "J".

Тепер мені потрібно проаналізувати назву місяця, порівнявши її з усіма відомими культовими назвами місяців:

• Культурно-чутливо
• Випадок безчутливий
• Просто з точки курсору (не пізніше; я хочу дізнатися, чи курсор "дивиться" ім'я місяця кандидата)
• Швидко
• ... і мені потрібно знати після цього, скільки символів було використано

Поточний код , щоб зробити це , як правило працює, використовуючи CompareInfo.Compare. Це ефективно так (тільки для відповідної частини - у реальній справі більше коду, але це не стосується матчу):

internal bool MatchCaseInsensitive(string candidate, CompareInfo compareInfo)
{
    return compareInfo.Compare(text, position, candidate.Length,
                               candidate, 0, candidate.Length, 
                               CompareOptions.IgnoreCase) == 0;
}

Однак це залежить від кандидата та регіону, який ми порівнюємо, однакової довжини. Штрафують більшу частину часу, але в деяких особливих випадках не штрафують. Припустимо, у нас є щось на кшталт:

// U+00E9 is a single code point for e-acute
var text = "x b\u00e9d y";
int position = 2;
// e followed by U+0301 still means e-acute, but from two code points
var candidate = "be\u0301d";

Зараз моє порівняння провалиться. Я можу використовувати IsPrefix:

if (compareInfo.IsPrefix(text.Substring(position), candidate,
                         CompareOptions.IgnoreCase))

але:

• Це вимагає, щоб я створив підрядку, якої я б дуже хотів уникати. (Я переглядаю Noda Time настільки ефективно, як системна бібліотека; аналіз ефективності може бути важливим для деяких клієнтів.)
• Це не говорить мені, як далеко рухати курсор згодом

Насправді я дуже підозрюю, що це не дуже часто виникає ... але я дуже хотів би зробити це правильно. Я також дуже хотів би це зробити, не ставши експертом Unicode або не реалізуючи це сам :)

(Визначено як помилка 210 за Noda Time, якщо хтось хоче виконати будь-який можливий висновок.)

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

Я також перевірив BCL - який, здається, не справляється з цим належним чином. Приклад коду:

using System;
using System.Globalization;

class Test
{
    static void Main()
    {
        var culture = (CultureInfo) CultureInfo.InvariantCulture.Clone();
        var months = culture.DateTimeFormat.AbbreviatedMonthNames;
        months[10] = "be\u0301d";
        culture.DateTimeFormat.AbbreviatedMonthNames = months;

        var text = "25 b\u00e9d 2013";
        var pattern = "dd MMM yyyy";
        DateTime result;
        if (DateTime.TryParseExact(text, pattern, culture,
                                   DateTimeStyles.None, out result))
        {
            Console.WriteLine("Parsed! Result={0}", result);
        }
        else
        {
            Console.WriteLine("Didn't parse");
        }
    }
}

Змінення користувацької назви місяця на просто "ліжко" із текстовим значенням "bEd" добре аналізує.

Гаразд, ще кілька точок даних:

• Вартість використання Substringта IsPrefixзначна, але не жахлива. На вибірці "П’ятниця 12 квітня 2013 20:28:42" на моєму ноутбуці для розробки він змінює кількість операцій розбору, які я можу виконати за секунду, приблизно від 460K до приблизно 400K. Я б скоріше уникав цього уповільнення, якщо це можливо, але це не дуже погано.

• Нормалізація менш здійсненна, ніж я думав - тому що вона не доступна в бібліотеках портативних класів. Я потенційно міг би використовувати його лише для збірок, що не належать до PCL, дозволяючи збірці PCL бути менш правильними. Результативність тестування на нормалізацію ( string.IsNormalized) знижує продуктивність приблизно до 445 КЛ в секунду, з чим я можу жити. Я все ще не впевнений, що він робить все, що мені потрібно - наприклад, назва місяця, що містить "ß", повинна відповідати "ss" у багатьох культурах, я вважаю ... і нормалізація цього не робить.

Я розгляну проблему багатьох <-> одного / багатьох кейс-файлів спочатку та окремо від обробки різних форм нормалізації.

Наприклад:

x heiße y
  ^--- cursor

Відповідає, heisseале потім занадто сильно переміщує курсор 1. І:

x heisse y
  ^--- cursor

Відповідає, heißeале потім переміщує курсор 1 занадто менше.

Це стосується будь-якого символу, який не має простого відображення один на один.

Вам потрібно було б знати довжину підрядки, яка насправді відповідала. Але Compare, IndexOf.. і т.д. викиньте цю інформацію. Це може бути можливим з регулярними виразами , але реалізація не робить повний випадок складання і тому не відповідає , ßщоб ss/SSв режимі без урахування регістру , навіть якщо .Compareі .IndexOfробити. І, мабуть, було б дорого створити нові реджекси для кожного кандидата в будь-якому випадку.

Найпростішим рішенням цього є просто внутрішнє зберігання рядків у складеній формі, а також бінарне порівняння зі складними кандидатами. Тоді ви можете перемістити курсор правильно, .Lengthоскільки курсор призначений для внутрішнього подання. Ви також отримуєте більшу частину втраченої продуктивності від того, що не користуєтесь CompareOptions.IgnoreCase.

На жаль , немає ні одного випадку , функції складки вбудованої і корпус складного бідняка не працює , або тому , що немає повного відображення випадку - ToUpperметод не включається ßв SS.

Наприклад, це працює в Java (і навіть у Javascript), задавши рядок, що знаходиться у звичайній формі C:

//Poor man's case folding.
//There are some edge cases where this doesn't work
public static String toCaseFold( String input, Locale cultureInfo ) {
    return input.toUpperCase(cultureInfo).toLowerCase(cultureInfo);
}

Приємно відзначити, що порівняння випадків ігнорування Java не робить повне складання справ, як C # CompareOptions.IgnoreCase. Таким чином, у цьому відношенні вони протилежні: Java робить повне складання реєстру справ, але просте складання справ - C # робить просту карту справи, але повне складання справ.

Тому, ймовірно, вам потрібна бібліотека сторонніх розробників, щоб скласти рядки перед їх використанням.

Перш ніж робити що-небудь, ви повинні бути впевнені, що ваші рядки в нормальній формі C. Ви можете скористатися цим попереднім швидким перевіркою, оптимізованим під латинським сценариєм:

public static bool MaybeRequiresNormalizationToFormC(string input)
{
    if( input == null ) throw new ArgumentNullException("input");

    int len = input.Length;
    for (int i = 0; i < len; ++i)
    {
        if (input[i] > 0x2FF)
        {
            return true;
        }
    }

    return false;
}

Це дає помилкові позитиви, але не хибні негативи, я не сподіваюсь, що він взагалі сповільнить 460k синтаксичних аналізів при використанні символів латинського сценарію, хоча це потрібно виконувати в кожному рядку. При хибному позитиві ви б використовували, IsNormalizedщоб отримати справжній негатив / позитив і лише після цього нормалізувати, якщо це необхідно.

Перевірте, чи відповідає це вимозі ..:

public static partial class GlobalizationExtensions {
    public static int IsPrefix(
        this CompareInfo compareInfo,
        String source, String prefix, int startIndex, CompareOptions options
        ) {
        if(compareInfo.IndexOf(source, prefix, startIndex, options)!=startIndex)
            return ~0;
        else
            // source is started with prefix
            // therefore the loop must exit
            for(int length2=0, length1=prefix.Length; ; )
                if(0==compareInfo.Compare(
                        prefix, 0, length1, 
                        source, startIndex, ++length2, options))
                    return length2;
    }
}

compareInfo.Compareвиконує лише один раз, sourceрозпочатий з prefix; якщо цього не сталося, то IsPrefixповертається -1; в іншому випадку довжина символів, використаних у source.

Однак я не маю жодної ідеї, окрім збільшення length2за 1допомогою наступного випадку:

var candidate="ßssß\u00E9\u0302";
var text="abcd ssßss\u0065\u0301\u0302sss";

var count=
    culture.CompareInfo.IsPrefix(text, candidate, 5, CompareOptions.IgnoreCase);

оновлення :

Я спробував трохи покращити перф., Але не доведено, чи є помилка в наступному коді:

public static partial class GlobalizationExtensions {
    public static int Compare(
        this CompareInfo compareInfo,
        String source, String prefix, int startIndex, ref int length2, 
        CompareOptions options) {
        int length1=prefix.Length, v2, v1;

        if(0==(v1=compareInfo.Compare(
            prefix, 0, length1, source, startIndex, length2, options))
            ) {
            return 0;
        }
        else {
            if(0==(v2=compareInfo.Compare(
                prefix, 0, length1, source, startIndex, 1+length2, options))
                ) {
                ++length2;
                return 0;
            }
            else {
                if(v1<0||v2<0) {
                    length2-=2;
                    return -1;
                }
                else {
                    length2+=2;
                    return 1;
                }
            }
        }
    }

    public static int IsPrefix(
        this CompareInfo compareInfo,
        String source, String prefix, int startIndex, CompareOptions options
        ) {
        if(compareInfo.IndexOf(source, prefix, startIndex, options)
                !=startIndex)
            return ~0;
        else
            for(int length2=
                    Math.Min(prefix.Length, source.Length-(1+startIndex)); ; )
                if(0==compareInfo.Compare(
                        source, prefix, startIndex, ref length2, options))
                    return length2;
    }
}

Я перевірив конкретний випадок, і порівняння приблизно до 3.

Це реально можливо без нормалізації та без використання IsPrefix.

Нам потрібно порівняти однакову кількість текстових елементів на відміну від тієї ж кількості символів, але все ж повернути кількість відповідних символів.

Я створив копію MatchCaseInsensitiveметоду з ValueCursor.cs в Noda Time і трохи змінив її, щоб її можна було використовувати в статичному контексті:

// Noda time code from MatchCaseInsensitive in ValueCursor.cs
static int IsMatch_Original(string source, int index, string match, CompareInfo compareInfo)
{
    unchecked
    {
        if (match.Length > source.Length - index)
        {
            return 0;
        }

        // TODO(V1.2): This will fail if the length in the input string is different to the length in the
        // match string for culture-specific reasons. It's not clear how to handle that...
        if (compareInfo.Compare(source, index, match.Length, match, 0, match.Length, CompareOptions.IgnoreCase) == 0)
        {
            return match.Length;
        }

        return 0;
    }
}

(Просто включений для довідки, це код, який не буде порівняти належним чином, як ви знаєте)

У наступному варіанті цього методу використовується StringInfo.GetNextTextElement, який надається рамкою. Ідея полягає в тому, щоб порівняти текстовий елемент за текстовим елементом, щоб знайти відповідність, а якщо знайдено, повернути фактичну кількість відповідних символів у вихідному рядку:

// Using StringInfo.GetNextTextElement to match by text elements instead of characters
static int IsMatch_New(string source, int index, string match, CompareInfo compareInfo)
{
    int sourceIndex = index;
    int matchIndex = 0;

    // Loop until we reach the end of source or match
    while (sourceIndex < source.Length && matchIndex < match.Length)
    {
        // Get text elements at the current positions of source and match
        // Normally that will be just one character but may be more in case of Unicode combining characters
        string sourceElem = StringInfo.GetNextTextElement(source, sourceIndex);
        string matchElem = StringInfo.GetNextTextElement(match, matchIndex);

        // Compare the current elements.
        if (compareInfo.Compare(sourceElem, matchElem, CompareOptions.IgnoreCase) != 0)
        {
            return 0; // No match
        }

        // Advance in source and match (by number of characters)
        sourceIndex += sourceElem.Length;
        matchIndex += matchElem.Length;
    }

    // Check if we reached end of source and not end of match
    if (matchIndex != match.Length)
    {
        return 0; // No match
    }

    // Found match. Return number of matching characters from source.
    return sourceIndex - index;
}

Цей метод працює чудово, щонайменше, відповідно до моїх тестових випадків (які в основному просто тестують пару варіантів рядків, які ви надали: "b\u00e9d"і "be\u0301d").

Однак метод GetNextTextElement створює підрядку для кожного текстового елемента, тому для цієї реалізації потрібно багато порівнянь підрядків - що матиме вплив на продуктивність.

Отже, я створив ще один варіант, який не використовує GetNextTextElement, а замість цього пропускає Unicode, що поєднує символи, щоб знайти фактичну довжину відповідності в символах:

// This should be faster
static int IsMatch_Faster(string source, int index, string match, CompareInfo compareInfo)
{
    int sourceLength = source.Length;
    int matchLength = match.Length;
    int sourceIndex = index;
    int matchIndex = 0;

    // Loop until we reach the end of source or match
    while (sourceIndex < sourceLength && matchIndex < matchLength)
    {
        sourceIndex += GetTextElemLen(source, sourceIndex, sourceLength);
        matchIndex += GetTextElemLen(match, matchIndex, matchLength);
    }

    // Check if we reached end of source and not end of match
    if (matchIndex != matchLength)
    {
        return 0; // No match
    }

    // Check if we've found a match
    if (compareInfo.Compare(source, index, sourceIndex - index, match, 0, matchIndex, CompareOptions.IgnoreCase) != 0)
    {
        return 0; // No match
    }

    // Found match. Return number of matching characters from source.
    return sourceIndex - index;
}

Цей метод використовує наступні два помічники:

static int GetTextElemLen(string str, int index, int strLen)
{
    bool stop = false;
    int elemLen;

    for (elemLen = 0; index < strLen && !stop; ++elemLen, ++index)
    {
        stop = !IsCombiningCharacter(str, index);
    }

    return elemLen;
}

static bool IsCombiningCharacter(string str, int index)
{
    switch (CharUnicodeInfo.GetUnicodeCategory(str, index))
    {
        case UnicodeCategory.NonSpacingMark:
        case UnicodeCategory.SpacingCombiningMark:
        case UnicodeCategory.EnclosingMark:
            return true;

        default:
            return false;
    }
}

Я не робив жодного розмітного стенду, тому не знаю, чи швидший метод насправді швидший. Також я не робив жодного розширеного тестування.

Але це повинно відповісти на ваше запитання про те, як виконати зіставлення чутливих до культури рядків для рядків, які можуть містити символи, що поєднують Unicode

Це тестові випадки, які я використав:

static Tuple<string, int, string, int>[] tests = new []
{
    Tuple.Create("x b\u00e9d y", 2, "be\u0301d", 3),
    Tuple.Create("x be\u0301d y", 2, "b\u00e9d", 4),

    Tuple.Create("x b\u00e9d", 2, "be\u0301d", 3),
    Tuple.Create("x be\u0301d", 2, "b\u00e9d", 4),

    Tuple.Create("b\u00e9d y", 0, "be\u0301d", 3),
    Tuple.Create("be\u0301d y", 0, "b\u00e9d", 4),

    Tuple.Create("b\u00e9d", 0, "be\u0301d", 3),
    Tuple.Create("be\u0301d", 0, "b\u00e9d", 4),

    Tuple.Create("b\u00e9", 0, "be\u0301d", 0),
    Tuple.Create("be\u0301", 0, "b\u00e9d", 0),
};

Значення кортежу:

1. Джерельний рядок (стог сіна)
2. Вихідне положення у джерелі.
3. Рядок відповідника (голка).
4. Очікувана тривалість матчу.

Запуск цих тестів за трьома методами дає такий результат:

Test #0: Orignal=BAD; New=OK; Faster=OK
Test #1: Orignal=BAD; New=OK; Faster=OK
Test #2: Orignal=BAD; New=OK; Faster=OK
Test #3: Orignal=BAD; New=OK; Faster=OK
Test #4: Orignal=BAD; New=OK; Faster=OK
Test #5: Orignal=BAD; New=OK; Faster=OK
Test #6: Orignal=BAD; New=OK; Faster=OK
Test #7: Orignal=BAD; New=OK; Faster=OK
Test #8: Orignal=OK; New=OK; Faster=OK
Test #9: Orignal=OK; New=OK; Faster=OK

Останні два тести перевіряють випадок, коли початковий рядок коротший, ніж рядок відповідності. У цьому випадку оригінальний метод (час Noda) також вдасться.