Français

Texte et outils quotidiens · Boîte à outils de texte

Pourquoi un outil de recherche et de remplacement doit survivre à une expression régulière à moitié typée

· Pourquoi c'est important

rechercher et remplacer expressions régulières édition de texte

Une expression régulière incomplète à côté du texte qui reste inchangé en toute sécurité
Illustration vectorielle originale de ToolAcre

La saisie d'un motif est incrémentielle, donc une parenthèse ouvrante isolée est un état normal ; cet article soutient que protéger la compilation, laisser le texte intact et proposer l'annulation sont des fonctionnalités d'exactitude et non de polissage.

L'outil qui a vidé la boîte sur un support déséquilibré : comment une seule frappe peut détruire une heure de nettoyage

Une boîte de recherche et de remplacement contient souvent un travail qui a pris beaucoup plus de temps à assembler que le modèle de recherche à côté. Si une expression incomplète peut traverser l'interface, effacer l'éditeur ou laisser son état incertain, l'outil a rendu la saisie de modèles plus dangereuse que la tâche de nettoyage qu'il était censé simplifier.

Le référentiel ne documente pas un incident spécifique au cours duquel ToolAcre a effacé une heure de travail, de sorte que cette histoire ne peut pas être présentée comme un fait. L'exigence défendable est de toute façon plus forte : le texte utilisateur doit rester inchangé chaque fois que la compilation du modèle échoue, quelle que soit la quantité de texte présente ou le temps de préparation.

L'échec destructeur qu'un outil de recherche et de remplacement doit éviter

Les expressions régulières ne sont généralement pas saisies en une seule frappe parfaite. Une personne tape une parenthèse ouvrante avant sa parenthèse fermante, ou démarre une classe de caractères avec une parenthèse ouvrante avant d'ajouter ses membres. À ces moments-là, le champ contient un modèle syntaxiquement incomplet même si le processus d'édition se déroule normalement.

Traiter cet état temporaire comme un comportement utilisateur exceptionnel produit un éditeur fragile. La réponse utile est un retour immédiat et local : montrez que le modèle actuel ne peut pas être compilé, préservez tous les autres champs et laissez la prochaine frappe le réparer. Une erreur d’expression régulière non valide doit décrire le brouillon actuel et non mettre fin au flux de travail.

Les modèles incomplets sont normaux lors de l'écriture d'une expression régulière

ToolAcre achemine chaque recherche fournie par l'utilisateur via `compilePattern`. Les recherches littérales échappent d'abord aux métacaractères des expressions régulières, tandis que le mode Regex utilise directement la source fournie. La compilation se produit à l'intérieur d'un bloc `try` et l'échec renvoie un modèle nul plus une chaîne d'erreur au lieu de permettre à l'exception JavaScript de s'échapper dans l'interface.

Ce résultat contrôle le chemin de remplacement. Lorsque la compilation signale une erreur, `findReplace` renvoie le texte original, zéro remplacement et l'erreur. Il ne tente pas de recherche ou de réécriture partielle. La garde protège donc à la fois la stabilité de l'interface et l'intégrité des données : aucun modèle valide signifie aucune mutation du contenu de l'éditeur.

Signaler ce qui s'est passé – pourquoi un décompte de remplacements après chaque exécution est le contrôle d'intégrité le plus rapide

Un remplacement réussi peut toujours être logiquement erroné. Une expression large peut correspondre à plus de dates que prévu, tandis qu'une option de casse ou une limite de mot entier peut réduire l'ensemble à zéro. ToolAcre compte les correspondances avant d'appeler le remplacement de chaîne standard et renvoie ce numéro avec le texte réécrit, rendant la portée visible après chaque exécution.

Le décompte est une vérification rapide de la cohérence plutôt qu'une preuve que chaque correspondance était souhaitable. Si douze enregistrements étaient attendus et que le résultat indique 1 ou 1,200, arrêtez et inspectez le modèle avant de copier la sortie. Un chiffre précis transforme de vagues soupçons en une raison concrète pour annuler et réviser la recherche.

Annulation comme filet de sécurité - chaque transformation est réversible, avec une limite documentée de cinquante opérations

La sécurité de la compilation empêche les modèles non valides de modifier le texte, mais les modèles valides peuvent toujours exprimer une mauvaise intention. Annuler couvre cette deuxième catégorie. Text Toolkit enregistre les transformations afin qu'un remplacement effectué puisse être annulé une fois que le décompte des résultats ou la sortie révèlent que la recherche était trop large, trop étroite ou mal regroupée.

La limite d'historique documentée est de cinquante opérations, donc l'annulation est un tampon de travail plutôt qu'un contrôle de version permanent. Utilisez-le pour expérimenter par petites étapes, mais ne le traitez pas comme un stockage d’archives. Pour les documents importants, conservez l'original séparément et copiez le résultat final uniquement après avoir examiné le texte et le nombre de remplacements.

Exemple pratique : créer un modèle de reformatage de date caractère par caractère et regarder l'erreur apparaître et disparaître sans perdre de texte

Pensez à changer les dates du `2024-01-02` au `02/01/2024`. Activez Regex et commencez par une parenthèse ouvrante. À cet instant, le moteur du navigateur signale une expression non valide, ToolAcre fait apparaître le message et le texte reste intact. Ajoutez `\d{4}` et la parenthèse fermante, et cette première année capturée devient valide.

Continuez jusqu'à ce que la recherche soit `(\d{4})-(\d{2})-(\d{2})`, puis utilisez `$3/$2/$1` comme remplacement. Les trois captures réorganisent l'année, le mois et le jour sans retaper chaque ligne. Exécutez Remplacer tout, comparez le nombre signalé avec les lignes attendues et annulez immédiatement si un texte numérique sans rapport correspond également.

Ce que cela ne couvre pas : problèmes de performances des regex tels qu'un retour en arrière catastrophique sur des entrées énormes

La protection contre la compilation traite les erreurs de syntaxe, et non la durée d'exécution des expressions valides. Un modèle peut être compilé avec succès mais revenir en arrière fortement sur une entrée particulière. Étant donné que le remplacement s'exécute sur le thread principal, une expression pathologique appliquée à un document volumineux peut toujours empêcher l'onglet du navigateur de répondre même si aucune exception n'a été levée.

L'outil effectue également Remplacer tout plutôt que de parcourir les correspondances individuellement, et il ne prévisualise pas les correspondances en surbrillance avant la mutation. Ces limites rendent les données de test étroites et le nombre de remplacements importants. Validez une expression peu familière sur un petit échantillon représentatif avant de l’appliquer à l’unique copie d’un document volumineux.

Ce qu'il faut retenir : Text Toolkit traite les modèles non valides comme des informations et non comme des échecs, afin que vous puissiez expérimenter en toute sécurité.

Un modèle incomplet est une information sur un état d'édition, et non une preuve que l'utilisateur a échoué. ToolAcre conserve cette distinction dans ses valeurs de retour : la compilation peut signaler une erreur sans lancer, le remplacement peut signaler zéro changement sans toucher à la source, et une opération réussie peut signaler exactement le nombre de correspondances qu'elle a réécrites.

Cette conception prend en charge l'expérimentation sans prétendre que les expressions régulières sont inoffensives. Conservez les entrées en cas d'échec de la compilation, inspectez les décomptes après le succès et utilisez l'annulation lorsqu'un modèle valide était conceptuellement erroné. Ensemble, ces comportements rendent la recherche et le remplacement suffisamment prévisibles pour les utilisateurs occasionnels d'expressions régulières qui ont plus besoin de commentaires que de punition pour une expression à moitié tapée.