Comment puis-je effectuer une opération «commence par» sensible à la culture à partir du milieu d'une chaîne?

J'ai une exigence qui est relativement obscure, mais j'ai l'impression que cela devrait être possible en utilisant la BCL.

Pour le contexte, j'analyse une chaîne de date / heure dans Noda Time . Je maintiens un curseur logique pour ma position dans la chaîne d'entrée. Ainsi, alors que la chaîne complète peut être «3 janvier 2013», le curseur logique peut être sur le «J».

Maintenant, je dois analyser le nom du mois, en le comparant à tous les noms de mois connus pour la culture:

• Sensible à la culture
• Insensibilité à la casse
• Juste à partir du point du curseur (pas plus tard; je veux voir si le curseur "regarde" le nom du mois candidat)
• Rapidement
• ... et j'ai besoin de savoir par la suite combien de caractères ont été utilisés

Le code actuel pour ce faire fonctionne généralement, en utilisant CompareInfo.Compare. C'est effectivement comme ça (juste pour la partie correspondante - il y a plus de code dans la vraie chose, mais ce n'est pas pertinent pour la correspondance):

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

Cependant, cela dépend du fait que le candidat et la région que nous comparons ont la même longueur. Bien la plupart du temps, mais pas très bien dans certains cas particuliers. Supposons que nous ayons quelque chose comme:

// 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";

Maintenant, ma comparaison échouera. Je pourrais utiliser IsPrefix:

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

mais:

• Cela m'oblige à créer une sous-chaîne, ce que je préfère éviter. (Je considère Noda Time comme une bibliothèque système; l'analyse des performances peut très bien être importante pour certains clients.)
• Il ne me dit pas à quelle distance faire avancer le curseur par la suite

En réalité, je soupçonne fortement ce ne sera pas venu très souvent ... mais je voudrais vraiment que je fasse la bonne chose ici. J'aimerais aussi vraiment pouvoir le faire sans devenir un expert Unicode ou l'implémenter moi-même :)

(Élevé en tant que bogue 210 dans Noda Time, au cas où quelqu'un voudrait suivre une conclusion éventuelle.)

J'aime l'idée de normalisation. Je dois vérifier cela en détail pour a) l'exactitude et b) les performances. En supposant que je puisse le faire fonctionner correctement, je ne sais toujours pas comment cela vaudrait la peine d'être changé - c'est le genre de chose qui ne se produira probablement jamais dans la vraie vie, mais qui pourrait nuire aux performances de tous mes utilisateurs: (

J'ai également vérifié la BCL - qui ne semble pas non plus gérer cela correctement. Exemple de code:

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");
        }
    }
}

Changer le nom du mois personnalisé en juste "lit" avec une valeur de texte "bEd" analyse très bien.

D'accord, quelques points de données supplémentaires:

• Le coût d'utilisation Substringet IsPrefixest important mais pas horrible. Sur un échantillon de "Vendredi 12 avril 2013 20:28:42" sur mon ordinateur portable de développement, cela change le nombre d'opérations d'analyse que je peux exécuter en une seconde d'environ 460K à environ 400K. Je préfère éviter ce ralentissement si possible, mais ce n'est pas trop mal.

• La normalisation est moins faisable que je ne le pensais - car elle n'est pas disponible dans les bibliothèques de classes portables. Je pourrais potentiellement l'utiliser uniquement pour les versions non PCL, ce qui permettrait aux versions PCL d'être un peu moins correctes. Le succès des tests de normalisation ( string.IsNormalized) réduit les performances à environ 445 000 appels par seconde, ce avec quoi je peux vivre. Je ne suis toujours pas sûr qu'il fasse tout ce dont j'ai besoin - par exemple, un nom de mois contenant "ß" devrait correspondre à "ss" dans de nombreuses cultures, je crois ... et la normalisation ne fait pas cela.

Je vais d'abord considérer le problème de plusieurs <-> un / plusieurs casemappings et séparément de la gestion de différentes formes de normalisation.

Par exemple:

x heiße y
  ^--- cursor

Correspond heissemais déplace trop le curseur 1. Et:

x heisse y
  ^--- cursor

Correspond heißemais déplace le curseur 1 trop moins.

Cela s'appliquera à tout caractère qui n'a pas de simple mappage un-à-un.

Vous devez connaître la longueur de la sous-chaîne qui correspond réellement. Mais Compare, IndexOf..etc jeter ces informations. Cela pourrait être possible avec des expressions régulières, mais l'implémentation ne fait pas le pliage complet de la casse et ne correspond donc pas ßau ss/SSmode insensible à la casse même si .Compareet.IndexOf fait. De toute façon, il serait probablement coûteux de créer de nouvelles expressions régulières pour chaque candidat.

La solution la plus simple à cela est de simplement stocker en interne les chaînes sous forme pliée en cas et de faire des comparaisons binaires avec les candidats pliés en cas. Ensuite, vous pouvez déplacer le curseur correctement avec juste .Lengthpuisque le curseur est pour la représentation interne. Vous récupérez également la plupart des performances perdues en n'ayant pas à utiliserCompareOptions.IgnoreCase .

Malheureusement, il n'y a pas de fonction de pliage de cas intégrée et le pliage de cas du pauvre homme ne fonctionne pas non plus car il n'y a pas de mappage complet de cas - la ToUpperméthode ne se transforme pas ßenSS .

Par exemple, cela fonctionne en Java (et même en Javascript), avec une chaîne de caractères au format normal 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);
}

Amusant de noter que la comparaison de casse ignorée de Java ne fait pas de pliage complet de cas comme C # CompareOptions.IgnoreCase . Donc, ils sont opposés à cet égard: Java fait un casemapping complet, mais un simple pliage de cas - C # fait un simple casemapping, mais un pliage complet de cas.

Il est donc probable que vous ayez besoin d'une bibliothèque tierce pour plier vos chaînes avant de les utiliser.

Avant de faire quoi que ce soit, vous devez vous assurer que vos chaînes sont au format normal C. Vous pouvez utiliser cette vérification rapide préliminaire optimisée pour le script latin:

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;
}

Cela donne de faux positifs mais pas de faux négatifs, je ne m'attends pas à ce qu'il ralentisse du tout 460k analyses / s lors de l'utilisation de caractères de script latin, même si cela doit être effectué sur chaque chaîne. Avec un faux positif, vous utiliseriezIsNormalized pour obtenir un vrai négatif / positif et seulement après cela normaliser si nécessaire.

Vérifiez si cela répond à l'exigence.:

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.Comparene fonctionne qu'une fois sourcecommencé avec prefix; sinon, IsPrefixrevient -1; sinon, la longueur des caractères utilisée dans source.

Cependant, je ne sais pas , sauf augmentation length2par 1le cas suivant:

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

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

mise à jour :

J'ai essayé d'améliorer un peu les performances, mais il n'est pas prouvé qu'il y ait un bogue dans le code suivant:

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;
    }
}

J'ai testé avec le cas particulier, et la comparaison jusqu'à environ 3.

Ceci est en fait possible sans normalisation et sans utiliser IsPrefix .

Nous devons comparer le même nombre d' éléments de texte par opposition au même nombre de caractères, mais toujours renvoyer le nombre de caractères correspondants.

J'ai créé une copie de la MatchCaseInsensitiveméthode à partir de ValueCursor.cs dans Noda Time et je l'ai légèrement modifiée afin qu'elle puisse être utilisée dans un contexte statique:

// 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;
    }
}

(Juste inclus pour référence, c'est le code qui ne se comparera pas correctement comme vous le savez)

La variante suivante de cette méthode utilise StringInfo.GetNextTextElement qui est fourni par le framework. L'idée est de comparer élément de texte par élément de texte pour trouver une correspondance et, si trouvé, retourner le nombre réel de caractères correspondants dans la chaîne source:

// 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;
}

Cette méthode fonctionne très bien au moins selon mes cas de test (qui testent simplement quelques variantes des chaînes que vous avez fournies: "b\u00e9d"et "be\u0301d").

Cependant, la méthode GetNextTextElement crée une sous-chaîne pour chaque élément de texte, de sorte que cette implémentation nécessite beaucoup de comparaisons de sous-chaînes - ce qui aura un impact sur les performances.

J'ai donc créé une autre variante qui n'utilise pas GetNextTextElement mais ignore à la place les caractères de combinaison Unicode pour trouver la longueur de correspondance réelle en caractères:

// 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;
}

Cette méthode utilise les deux assistants suivants:

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;
    }
}

Je n'ai fait aucun benchmark, donc je ne sais pas vraiment si la méthode la plus rapide est réellement plus rapide. Je n'ai pas non plus fait de tests prolongés.

Mais cela devrait répondre à votre question sur la façon d'effectuer une correspondance de sous-chaînes sensibles à la culture pour les chaînes pouvant inclure des caractères de combinaison Unicode.

Voici les cas de test que j'ai utilisés:

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),
};

Les valeurs de tuple sont:

1. La chaîne source (meule de foin)
2. La position de départ dans la source.
3. La chaîne de correspondance (aiguille).
4. La durée de match attendue.

L'exécution de ces tests sur les trois méthodes donne ce résultat:

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

Les deux derniers tests testent le cas où la chaîne source est plus courte que la chaîne de correspondance. Dans ce cas, la méthode originale (temps Noda) réussira également.