Datenbank- und SQL-Werkzeuge

Verbindungszeichenfolge analysierenZiel und Parameter prüfen, bevor die Konfiguration wechselt

Ziel und Parameter prüfen, bevor die Konfiguration wechselt

Verbindungszeichenfolge analysieren

Verbindungszeichenfolge

Verarbeitung im Browser ohne Verbindungen oder gespeicherten Verlauf. Der Quelleditor enthält Ihren Originaltext.

Ergebnis

Dialekt und Ausgabe

Die Maskierung gilt für Ergebnisse, Vorschauen und Exporte. Deaktivieren Sie sie ausdrücklich, um Originalwerte anzuzeigen und zu kopieren. Datenbank- und Hostnamen bleiben sichtbar.

Nur Syntaxprüfung: keine Verbindung, DNS/TXT-, Umgebungs- oder Parameterwirkungsprüfung. JDBC unterstützt PostgreSQL und einfache MySQL-URLs; andere Anbieter und erweiterte Hostformen sind ausgeschlossen.

Bis zu 100.000 UTF-16-Eingabeeinheiten, 100 Hosts, 1.000 Parameter und 1.200.000 Ausgabeeinheiten. Die Textvorschau zeigt höchstens 20.000 Einheiten; Exporte sind vollständig.

Analysierte Felder

Schema
postgresql
Benutzername
***
Passwort
***
Datenbank / Redis-Index
app
Standardport (keine ermittelte Konfiguration)
5432
Bedeutung von + in der Abfrage
Wörtliches +
Hosts — ein host[:port] pro Zeile
db.example.com:5432 backup.example.com

Geordnete Parameter

NameWert
sslmode***

1 / 1 angezeigt; Exporte enthalten das vollständige Ergebnis.

2 Hosts und 1 Parameter analysiert.

Eine Verbindungszeichenfolge analysieren hilft beim Wechsel zwischen Entwicklungs- und Produktionsumgebung: Stimmen Host, Datenbank und Port mit der beabsichtigten Verbindung überein? Die Zerlegung macht diese Bestandteile einzeln lesbar.

Für eine JDBC URL gelten andere Details als für native URIs. Wählen Sie den passenden Dialekt, lesen Sie die Verbindungsparameter und bearbeiten Sie einen getrennten Entwurf. Die ursprüngliche Datenbank Verbindung bleibt bis zum Anwenden im Eingabefeld erhalten.

Verbindungszeichenfolge analysieren: warum?

Verbindungsziel ohne offene Zugangswerte prüfen

Verbindungszeichenfolge analysieren bedeutet hier auch, die Ausgabe gezielt zu begrenzen: Benutzername, Passwort und sämtliche Parameterwerte sind zunächst maskiert. Hosts und Datenbanknamen bleiben für den Vergleich sichtbar.

Eine Verbindung zerfällt in Host- und Datenbankfelder, während Zugangsdaten und Parameterwerte verdeckt bleiben.

Änderungen vor dem Ersetzen beurteilen

Der Entwurf erzeugt aus dekodierten Feldern eine neue, prozentkodierte Zeichenfolge. Erst nach der Vorschau wird sie übernommen. Einmaliges Rückgängigmachen stellt Eingabe und Ergebnis gemeinsam wieder her.

Bearbeitete Felder ergeben eine Vorschau der neuen Zeichenfolge mit einem Rückweg zum Original.

Änderungen bewusst vorbereiten

01

Den Dialekt an der Syntax erkennen

postgres:// und postgresql:// verwenden native PostgreSQL-URI-Regeln. JDBC-Präfixe wählen Treibersyntax. mysql:// bildet einen begrenzten Ausschnitt der MySQL-Shell-Syntax ab; ähnliche Zeichenfolgen sind nicht automatisch gleichwertig.

02

Feldwerte und kodierte Abfrage unterscheiden

Hosts stehen einzeln als host[:port] in einer Zeile; IPv6-Adressen erhalten eckige Klammern. Zugangsdaten und Datenbank werden dekodiert eingegeben, die Abfrage als bereits kodierte key=value-Paare.

03

Nur aktuelle Ergebnisse exportieren

Die automatische Analyse wartet 350 ms. Ausgeschaltet stehen die Schaltfläche und Ctrl/Cmd+Enter bereit. Geänderte Eingaben sperren alte Exporte; nach Änderungen am Entwurf muss die Vorschau neu erzeugt werden.

Bestandteile mit ihrem Kontext

Mehrere Hosts einzeln lesen

Native PostgreSQL-URIs, Standard-MongoDB und unterstützte JDBC-Formen können einfache Hostlisten enthalten. Ein angezeigter Standardport beschreibt eine Konvention, keine aus der Umgebung ermittelte Konfiguration.

Ungültige Kodierung erkennen

Fehlerhafte Prozentsequenzen und ungültiges UTF-8 werden abgelehnt. Beim Erstellen werden reservierte Zeichen innerhalb der jeweiligen Komponente kodiert, damit beispielsweise ein Passwort keine neue Trennstelle erzeugt.

Parameter als geordnete Einträge

Namen und Werte bleiben in einer Liste erhalten. Im MongoDB-Node-Dialekt darf nur readPreferenceTags mehrfach auftreten. Unbekannte Optionen werden nicht gegen den Eigenschaftenkatalog eines Treibers geprüft.

Einheitliche Maskierung der Ausgabe

Alle Parameterwerte sind anfangs verborgen, auch eingebettete URLs und Tokens. Nur gewöhnliche ASCII-Bezeichner bleiben als Parameternamen sichtbar. Nach ausdrücklichem Offenlegen enthalten auch Kopien und Downloads die Werte.

Grenzen der Syntax und Ausgabe

Begrenzte Auswahl an Syntaxformen
PostgreSQL unterstützt leere Hosts, einfache Hostlisten und prozentkodierte Socket-Hosts. MySQL-URIs erlauben einen TCP-Host. JDBC ist auf PostgreSQL und MySQL begrenzt; die Kurzform jdbc:postgresql:database gehört dazu. JDBC-PostgreSQL-Optionsnamen müssen gewöhnliche ASCII-Bezeichner sein; prozentkodierte Namen sind ausgeschlossen.
Erweiterte MySQL-Hostformen bleiben ausgeschlossen
JDBC MySQL unterstützt einfache, durch Kommas getrennte Hosts. Zugangsdaten in der Authority sind auf einen Host beschränkt. address-Deskriptoren, gruppierte Unterlisten, loadbalance und replication werden abgelehnt.
Pluszeichen werden je nach Dialekt gelesen
In JDBC-, MongoDB-Node- und Redis-Python-Abfragen bedeutet + ein Leerzeichen. Native PostgreSQL- und MySQL-URI-Abfragen behalten das Pluszeichen. Für ein eindeutiges Plus in den ersten Formaten verwenden Sie %2B.
Keine Verbindung oder DNS-Auflösung
mongodb+srv benötigt einen DNS-Host ohne Portangabe. Das Werkzeug fragt keine SRV/TXT-Einträge ab und prüft weder Anmeldung noch TLS oder Serveroptionen. Umgebungsvariablen und Zugangsdaten-Dateien werden nicht gelesen.
Die ursprüngliche Eingabe bleibt lesbar
Der ursprüngliche Text bleibt sichtbar. Benutzername und Passwort im Entwurf sind zunächst verdeckt. Der Abfragetext ist bei aktiver Maskierung schreibgeschützt; erst nach ausdrücklichem Ausschalten lassen sich seine Originalwerte bearbeiten. Host- und Datenbanknamen werden nicht auf Geheimnisse geprüft.
Feste Grenzen für vollständige Ergebnisse
Maximal 100.000 UTF-16-Einheiten Eingabe, 1.000 Parameter und 100 Hosts sind zulässig. Die Ausgabe darf 1.200.000 Einheiten umfassen. Die Vorschau zeigt höchstens 20.000 Einheiten; Exporte enthalten das vollständige akzeptierte Ergebnis.

Verbindungszeichenfolge analysieren: Fragen

Wie behandle ich Sonderzeichen im Passwort einer PostgreSQL-URL?

Kodieren Sie nur das Passwortfeld, nicht die ganze Zeichenfolge: @ wird %40, # wird %23. Im Entwurf verwenden Sie das dekodierte Passwort. Ein bereits kodierter Wert würde sein Prozentzeichen erneut kodieren.

Wie ist eine PostgreSQL-Verbindungs-URL aufgebaut?

Eine übliche Form ist postgresql://user:password@host:5432/database?sslmode=require. Zugangsdaten, Port und weitere Teile können fehlen. Mit Verbindungszeichenfolge analysieren sehen Sie den vorhandenen Text; effektive Werte aus der Umgebung werden nicht ergänzt.

Was bedeutet +srv in einer MongoDB-Verbindungszeichenfolge?

Ein Treiber ermittelt darüber Server aus DNS-SRV-Einträgen und liest unterstützte TXT-Optionen. Das ist ein eigenes Format und kein Zusatz für eine beliebige localhost-Adresse. Verwenden Sie den SRV-Namen Ihrer Bereitstellung.

Was bedeutet die letzte Zahl in einer Redis-URL?

In redis://host:6379/12 bezeichnet 12 einen Datenbankindex, keinen Namen. Ob der Index verfügbar ist, hängt von Bereitstellung und Konfiguration ab. Das Werkzeug prüft das nicht durch eine Verbindung.

Warum darf eine mongodb+srv-URI keinen Port enthalten?

Die Dienstports stammen aus SRV-Einträgen. Eine zusätzliche Angabe wie :27017 ist daher ungültig. Verwenden Sie den tatsächlichen SRV-Host ohne Port oder eine Standard-mongodb://-URI mit der passenden Hostliste.

Einen Analysefehler gefunden?

Die nächste Konfiguration prüfen

Verbindungszeichenfolge analysieren, das Ziel vergleichen und Änderungen getrennt vorbereiten: Prüfen Sie die Vorschau vor dem Anwenden und behalten Sie die Möglichkeit, einmal zurückzugehen.