Indenter les lignes par espaces

Une entrée vide ou uniquement blanche est rejetée avec une erreur invalid_input claire pour que l’automatisation ne traite jamais un collage vide comme une indentation réussie. Le chemin est une logique de chaînes pure et déterministe—sans réseau, sans graines aléatoires, sans horloge—de sorte que l’exécuteur gratuit du navigateur et l’API prépayée renvoient le même JSON à chaque appel.

Ce que signifie l’indentation par ligne avec des espaces et quand l’utiliser

La plupart des éditeurs indentent une sélection en insérant des espaces ou des tabulations au début de chaque ligne sélectionnée ; cette capacité fait le même travail sous forme de transformation ciblée et prête pour l’API. Une entrée entièrement vide ou uniquement blanche est une erreur dure : il n’y a pas de document indenté significatif à renvoyer, et les clients doivent le traiter comme invalid_input plutôt qu’un succès à zéro ligne.

Comment appeler l’API et ce que contient la réponse

La valeur spaces doit être un entier fini de zéro à deux cents inclus. Préférez envoyer le corps multiligne brut plutôt que de rejoindre les lignes à l’avance si vous voulez une sémantique réelle par ligne. Envoyez un corps JSON avec le champ string obligatoire text (alias input, value, string, s, content et body) et le champ entier obligatoire spaces (alias n, indent, count, amount et pad). Le texte doit être non vide après un trim global des blancs et ne doit pas dépasser cent mille caractères afin qu’une seule requête n’épuise pas la mémoire du Worker ou du navigateur sur d’énormes collages. En cas de succès, la réponse renvoie input comme la chaîne d’origine envoyée, spaces comme l’entier normalisé appliqué, text comme le résultat entièrement indenté joint avec LF, line_count comme le nombre de lignes après découpe (y compris les vides), lines comme un tableau ordonné des chaînes de ligne indentées, chars_before et chars_after comme les longueurs des chaînes d’origine et indentée, chars_added comme le nombre de caractères introduits par les préfixes au total (typiquement line_count multiplié par spaces, ajusté si la normalisation des sauts a raccourci l’original), et message comme un bref résumé en anglais qui indique le nombre de lignes, spaces et caractères ajoutés. Une validation échouée—text manquant, valeur non string, charge trop grande, contenu vide après trim global, ou spaces invalide—renvoie invalid_input et n’est jamais facturée. Le tarif est un $0.002 forfaitaire par requête réussie avec l’unité item. À l’intégration, assert sur text ou lines pour le contenu indenté, comparez éventuellement chars_added pour les régressions, et traitez invalid_input comme une erreur client sur les formulaires vides plutôt qu’un événement de facturation.

Conseils pratiques, limites et recherches associées

Les contrôles aller-retour pour les tests sont simples : envoyez deux lignes courtes avec spaces égal à quatre et attendez que chaque ligne commence par quatre espaces ; envoyez une ligne vide entre du contenu et confirmez que cette ligne vide porte aussi le même préfixe ; envoyez délibérément une chaîne vide ou uniquement des espaces pour confirmer invalid_input et le message demandant une chaîne non vide ; envoyez un spaces négatif ou un flottant pour confirmer invalid_input sur le champ de compte. Si vous devez retirer les blancs en tête et en fin de chaque ligne plutôt qu’ajouter des espaces, utilisez l’outil frère de trim par ligne ; si vous devez remplir une seule chaîne à une largeur totale avec un caractère de remplissage à gauche ou à droite, utilisez le pad de chaîne ; si vous avez besoin de JSON avec indentation structurelle, utilisez un formateur JSON. Les tâches en échec qui renvoient invalid_input ne consomment pas le solde prépayé, ce qui maintient bon marché la validation de formulaires et les tests négatifs de CI. Respectez les plafonds de caractères et de spaces documentés ci-dessus lors de l’envoi de grands dumps via l’API.