HTTPS / G-Server

[Assertor]

Hallo Jens,

Zitat von Jens Hartmann:

es ist immer wieder schön mit Euch. Ich habe jetzt mal gesucht und dabei festgestellt, das so Zeichen wie '+' etc. auch zu diesem Problem führen. Die Lösung ist mir auch klar.
[...]
Gibt es irgendwo eine Übersicht der Sonderzeichen und deren Umwandlung.

Spar Dir das, binde einfach die Unit IdURL ein und nutze es so:
s := TIdURI.URLEncode(mystring);

Gruß,
Assertor

[Jens Hartmann]

Danke für den Tip,

allerdings Funktioniert das nicht. Das Funktion Ersetzt mir die Leerzeichen nicht mit einem %20 etc. Diese müssen aber im String enthalten sein, da ich diesen sonst nicht senden kann.

Die Telefonanlage, benötigt diese Zeichen, um diese wieder in Leerzeichen umwandeln zu können.

Gruß Jens

[Assertor]

Hallo Jens,

Zitat von Jens Hartmann:

Danke für den Tip,

allerdings Funktioniert das nicht. Das Funktion Ersetzt mir die Leerzeichen nicht mit einem %20 etc. Diese müssen aber im String enthalten sein, da ich diesen sonst nicht senden kann.

Die Telefonanlage, benötigt diese Zeichen, um diese wieder in Leerzeichen umwandeln zu können.

Das ist schon klar, URLEncode sollte die Range außerhalb des darstellbaren ASCII Bereichs eigentlich vollständig kodieren (also auch Leerzeichen zu %20). Da scheint es wieder so einen Sonderfall beim Space zu geben (Indy Kompatibilitätsgründe?)...

Dann am besten Dein Space-Replace mit dem URLEncode() kombinieren. Das sollte gehen.

Gruß,
Assertor

[Jens Hartmann]

Das ist leider so. Die Funktion ist zwar OK, aber der Fehler ist bei dem Zeichen + z.B. genauso. Die Decode Funktion ist leider auch nicht besser.

Habe das ganze jetzt mit StringReplaced gelöst. Allerdings weiß ich nicht, welche Zeichen noch Problem verursachen.

Gruß Jens

[Assertor]

Hallo Jens,

Zitat von Jens Hartmann:

Das ist leider so. Die Funktion ist zwar OK, aber der Fehler ist bei dem Zeichen + z.B. genauso. Die Decode Funktion ist leider auch nicht besser.

Habe das ganze jetzt mit StringReplaced gelöst. Allerdings weiß ich nicht, welche Zeichen noch Problem verursachen.

Also irgendwas stimmt da nicht: Nehme ich ein frisches Delphi 2010 mit der Release Version von Indy (das dürfte doch Deine Konfiguration sein?), dann funktioniert es für das Leerzeichen:

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
begin
  Memo1.Lines.Text := TIdURI.URLEncode('http://127.0.0.1:8801/cgi-bin/gadgetapi?cmd=SetDisplay&device=101&contentsOfDisplay=MeinText abc +');
end;

Ausgabe:

Code:

http://127.0.0.1:8801/cgi-bin/gadgetapi?cmd=SetDisplay&device=101&contentsOfDisplay=MeinText%20abc%20+

Das "+" wird aber von Indy tatsächlich, bewußt nicht kodiert. Die Parametertrennung zu kodieren hatte früher den Benutzern zu viele Probleme gemacht.

Zu dem Bereich der gültigen Chars: Alles außerhalb US-ASCII muß kodiert werden (siehe http://www.ietf.org/rfc/rfc1738.txt).

Gruß,
Assertor

[Jens Hartmann]

Zitat von Assertor:

Also irgendwas stimmt da nicht: Nehme ich ein frisches Delphi 2010 mit der Release Version von Indy (das dürfte doch Deine Konfiguration sein?), dann funktioniert es für das Leerzeichen:

Das kann sein, bei mir leider nicht, ich nutze allerdings Delphi 2007. Ich habe das jetzt nochmal identisch zu deinem Code aufgebaut und den Text in eine Memo schreiben lassen. Leerzeichen sind Leerzeichen und nicht %20.

Danke übrigens für die Liste

Gruß Jens

[Assertor]

Hallo Jens,

keine Ursache. Im Fließtext des RFC steht in der Mitta ca., wie encodiert werden muß.

Mit Deiner Delphi Version bin ich im Post verrutscht, mein Fehler

Mit der alten Indy Version wird das nichts, also nimm ruhig StringReplace o.ä. Bei dem eingeschränkten Zeichensatz könntest Du auch eine Positivliste machen (a..z, A..Z, 0..9 und ein paar Sonderzeichen), alles andere fliegt raus bzw. wird wie das Leerzeichen URL-encoded.

Viele Grüße,
Assertor