Encodeur de mot de passe pour fichiers de configuration

Échappez un mot de passe pour JSON, YAML, TOML, XML, .properties Java, INI, chaînes de connexion URL et littéraux SQL afin qu’il soit relu sans changement.

Collez le résultat comme valeur du paramètre. YAML utilise des apostrophes si possible, TOML une chaîne littérale si possible, la forme URL encode en pourcent chaque octet sauf A–Z a–z 0–9 - . _ ~, et SQL double les apostrophes (SQL standard ; MySQL avec l’échappement par barre oblique inverse activé exige aussi de doubler \).

S'exécute entièrement dans votre navigateur. Vos données ne sont jamais envoyées.

Qu'est-ce que Encodeur de mot de passe pour fichiers de config ?

Collez un mot de passe et obtenez-le correctement échappé pour huit formats de configuration à la fois : JSON, YAML, TOML, XML, .properties Java, INI, URL/chaînes de connexion et littéraux de chaîne SQL. Chaque sortie est relue exactement comme la valeur d’origine.

Comment utiliser Encodeur de mot de passe pour fichiers de config

  1. Saisissez le mot de passe dans le champ Mot de passe.
  2. Trouvez le format voulu dans la liste.
  3. Copiez la valeur échappée avec son bouton Copier.
  4. Collez-la comme valeur dans votre configuration.

Exemple

Entrée
p@ss'w"rd$1
Sortie
JSON "p@ss'w\"rd$1"
YAML 'p@ss''w"rd$1'
TOML "p@ss'w\"rd$1"
XML p@ss'w"rd$1
URL p%40ss%27w%22rd%241
SQL 'p@ss''w"rd$1'

Quand utiliser Encodeur de mot de passe pour fichiers de config

Utilisez-le chaque fois qu’un secret entre à la main dans un fichier de configuration ou une chaîne de connexion. Préférez un gestionnaire de secrets ou des variables d’environnement pour les secrets de production.

Comment fonctionne Encodeur de mot de passe pour fichiers de config

JSON utilise JSON.stringify. YAML utilise un scalaire entre apostrophes (avec '' pour ') sauf si des caractères de contrôle imposent des guillemets doubles. TOML utilise une chaîne littérale 'string' si possible, sinon une chaîne basique avec les échappements \" \\ et \uXXXX. XML échappe & < > " ' et les tabulations/retours à la ligne en références de caractères. .properties échappe \, =, :, #, !, une espace initiale et le non-ASCII en \uXXXX. L’userinfo d’URL encode en pourcent tous les octets sauf A–Z a–z 0–9 - . _ ~. SQL double les apostrophes. INI n’a pas d’échappement standard : les valeurs avec " ou retours à la ligne sont signalées comme non sûres.

Cas d'utilisation courants

  • Mettre un mot de passe contenant @ et : dans une URL de connexion PostgreSQL ou MongoDB
  • Ajouter un secret dans un fichier YAML Kubernetes ou Ansible
  • Échapper un mot de passe dans un fichier application.properties de Spring
  • Insérer un utilisateur de test avec une instruction SQL

Questions Fréquentes

Pourquoi encoder les mots de passe en URL dans les chaînes de connexion ?

Des caractères comme @, :, / et # ont un sens spécial dans les URL ; un @ non encodé fait prendre une partie du mot de passe pour l’hôte.

Le littéral SQL est-il à l’abri des injections ?

C’est un échappement SQL standard correct, mais préférez toujours les requêtes paramétrées dans le code applicatif.

Pourquoi INI est-il signalé comme non sûr pour certaines valeurs ?

INI n’a aucun moyen standard d’échapper les guillemets doubles ou les retours à la ligne, et les analyseurs diffèrent : l’outil refuse plutôt que de deviner.

Explorer d'autres catégories