nicht angemeldet
Das is was für cgi-tüftler oder fortgeschrittenen - bitte helft mir!
hye leute,
http://127.0.0.1/cgi-bin/links/add.cgi/german
wenn ich diese url eingäbe, wie kann ich dann in der add.cgi den letzten teil (german) abfragen?
nit dem env{script-name) hab ich es schon versucht, aber der gibt die url nur bis zu add.cgi aus...
@location = split(///,$ENV{'SCRIPT_NAME'}); $language = $location[4];
ich brauche das ganze umd der cgi datei zu sagen, in welcher sprache sie aufgerufen wird....
wisst ihr ne besser möglichkeit?
von http://127.0.0.1/cgi-bin/links/add.cgi?language=german
halt ich nicht viel, da dem cgi später noch andere daten zugepostet werden, da kommt dann ein durcheinander raus, ausserdem würde die admin.cgi auch nicht mehr funktionieren, denn die bekommt daten in unterschielichster form übermittelt...
wie regle ich das am besten mit den formularen?
http://127.0.0.1/cgi-bin/links/add.cgi/german?id=yw&name=abc....
oder so
http://127.0.0.1/cgi-bin/links/add.cgi?id=yw&name=abc..../german
vielleicht weiss jemand von euch ne tolle lösung...
-
Hi Bogus!
http://127.0.0.1/cgi-bin/links/add.cgi/german
wenn ich diese url eingäbe, wie kann ich dann in der add.cgi den letzten teil (german) abfragen?ich glaube, Deine gesuchte Info steht in der
Umgebungsvariablen PATH_INFO.
Normalerweise macht man derartige URL's auch, wenn
z.B. add.cgi eine Datei zum Download zurueckgibt und
man den Default-Dateinamen zum Download festlegen will.Viele Grüße!
Andreas-
ich glaube, Deine gesuchte Info steht in der
Umgebungsvariablen PATH_INFO.danke dir, ich hab einige $env variablen ausprobiert, und die path_info hat mir das german zurückgegeben.
half alles nichts, denn ich kann kein require setzten in der ford
require "......links.pl/german";das findet er nicht,
trotzdem danke, ich muss das ganze noch mal überdenken
cu
-
-
hye leute,
von http://127.0.0.1/cgi-bin/links/add.cgi?language=german
Genau das ist es. Der Standardweg.
halt ich nicht viel, da dem cgi später noch andere daten zugepostet werden, da kommt dann ein durcheinander raus, ausserdem würde die admin.cgi auch nicht mehr funktionieren, denn die bekommt daten in unterschielichster form übermittelt...
Wieso Durcheinander? Wenn die admin.cgi dann nicht mehr funktioniert, solltest Du vielleicht dort etwas feilen, anstatt alles andere daran anzupassen.
wie regle ich das am besten mit den formularen?
http://127.0.0.1/cgi-bin/links/add.cgi/german?id=yw&name=abc....
oder so
http://127.0.0.1/cgi-bin/links/add.cgi?id=yw&name=abc..../germanWenn Du die Fragezeichenversion verwendest, ist es doch alles dasselbe, egal ob per Formular oder direkte URL-Angabe.
vielleicht weiss jemand von euch ne tolle lösung...
Ich arbeite zufaellig gerade an einem aehnlichen Problem. Dabei habe ich die Funktion InitQuery gebaut, die den QUERY_STRING in den globalen Hash %query reinparst. Dann kannst Du z.B. mit $query{'language'} drauf zugreifen. Vorsicht! Die hiernach gepostete Funktion habe ich aber modifiziert, um Deinem Problem naeherzukommen; sie ist nicht getestet (nicht mal auf korrekte Syntax).
sub InitQuery() {
my @args;
my ($field, $value);%query = ();
@args = split(/&/, $ENV{'QUERY_STRING'});
for (@args) {
$_ =~ s/%3D/=/gi; # aeltere Browser uebergeben unter Umstaenden %3D statt =
($field, $value) = split(/=/, $_);
$value =~ s/+/ /g; # + durch Leerzeichen ersetzen
$value =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge; # Hexa-Angaben -> echte Zeichen
$query{$field} = $value;
}
}Du solltest insbesondere testen, was passiert, wenn die uebergebenen Daten (was halt im Formular eingegeben wurde) selbst ein oder mehrere = enthalten. Please post any results in this forum. Wenn Du trotzdem lieber die add.cgi/german -Variante bevorzugst, denn schau mal in den beiden letzten Archiv-Dateien, vor kurzem hatte glaube ich mal jemand was dazu geschrieben.
Calocybe
-
Hi!
von http://127.0.0.1/cgi-bin/links/add.cgi?language=german
Genau das ist es. Der Standardweg.
halt ich nicht viel, da dem cgi später noch andere daten zugepostet werden, da kommt dann ein durcheinander raus, ausserdem würde die admin.cgi auch nicht mehr funktionieren, denn die bekommt daten in unterschielichster form übermittelt...
Wieso Durcheinander? Wenn die admin.cgi dann nicht mehr funktioniert, solltest Du vielleicht dort etwas feilen, anstatt alles andere daran anzupassen.
Ich denke, daß sich die beiden Varianten nicht so wahnsinnig unterscheiden. Wenn ich mal davon ausgehe, daß der Query-String schon eingelesen ist (oder ich nutze CGI.pm), macht es nicht denn Unterschied im Aufwand, ob ich nun einen Query-Parameter oder eine Umgebungsvariable abfrage. Generische mag die Lösung mit dem Pfad sein, da ich dann wohl am wenigsten mit anderen Werten aus dem Formular kollidiere. Andererseits kann ich einen Sprachwert aus dem Query-String auch im Formular einsetzen, und so den Formularanwender die Möglichkeit geben, die Sprache zu wechseln. Also ... jeder wie er mag!
wie regle ich das am besten mit den formularen?
http://127.0.0.1/cgi-bin/links/add.cgi/german?id=yw&name=abc....
oder so
http://127.0.0.1/cgi-bin/links/add.cgi?id=yw&name=abc..../germanWenn Du die Fragezeichenversion verwendest, ist es doch alles dasselbe, egal ob per Formular oder direkte URL-Angabe.
Zuerst ist der Pfad (inkl. german) anzugeben. Dann kommt das ? mit den nachfolgenden Parametern.
Ich arbeite zufaellig gerade an einem aehnlichen Problem. Dabei habe ich die Funktion InitQuery gebaut, die den QUERY_STRING in den globalen Hash %query reinparst. Dann kannst Du z.B. mit $query{'language'} drauf zugreifen. Vorsicht! Die hiernach gepostete Funktion habe ich aber modifiziert, um Deinem Problem naeherzukommen; sie ist nicht getestet (nicht mal auf korrekte Syntax).
sub InitQuery() {
my @args;
my ($field, $value);%query = ();
@args = split(/&/, $ENV{'QUERY_STRING'});
for (@args) {
$_ =~ s/%3D/=/gi; # aeltere Browser uebergeben unter Umstaenden %3D statt =
($field, $value) = split(/=/, $_);
$value =~ s/+/ /g; # + durch Leerzeichen ersetzen
$value =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge; # Hexa-Angaben -> echte Zeichen
$query{$field} = $value;
}
}Du solltest insbesondere testen, was passiert, wenn die uebergebenen Daten (was halt im Formular eingegeben wurde) selbst ein oder mehrere = enthalten. Please post any results in this forum. Wenn Du trotzdem lieber die add.cgi/german -Variante bevorzugst, denn schau mal in den beiden letzten Archiv-Dateien, vor kurzem hatte glaube ich mal jemand was dazu geschrieben.
Ein = in den Parametern macht doch kein Problem, da dieses innerhalb des Query-Stings durch den Hexwert kodiert ist. Das Programm splittet ja auch erst am = und ersetzt dann alle Hexangaben durch die entsprechenden Zeichen (z.B. das =). Für die Kodierung der Eingaben ist im übrigen der Browser zuständig.
Gruß,
Jörk-
Hi!
sub InitQuery() {
my @args;
my ($field, $value);%query = ();
@args = split(/&/, $ENV{'QUERY_STRING'});
for (@args) {
$_ =~ s/%3D/=/gi; # aeltere Browser uebergeben unter Umstaenden %3D statt =
($field, $value) = split(/=/, $_);
$value =~ s/+/ /g; # + durch Leerzeichen ersetzen
$value =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge; # Hexa-Angaben -> echte Zeichen
$query{$field} = $value;
}
}Du solltest insbesondere testen, was passiert, wenn die uebergebenen Daten (was halt im Formular eingegeben wurde) selbst ein oder mehrere = enthalten. Please post any results in this forum. Wenn Du trotzdem lieber die add.cgi/german -Variante bevorzugst, denn schau mal in den beiden letzten Archiv-Dateien, vor kurzem hatte glaube ich mal jemand was dazu geschrieben.
Ein = in den Parametern macht doch kein Problem, da dieses innerhalb des Query-Stings durch den Hexwert kodiert ist. Das Programm splittet ja auch erst am = und ersetzt dann alle Hexangaben durch die entsprechenden Zeichen (z.B. das =). Für die Kodierung der Eingaben ist im übrigen der Browser zuständig.
Vergiss nicht die Zeile $_ =~ s/%3D/=/gi; ! Sie wandelt noch vor dem split() alle als %3D uebergebenen = in ein richtiges = um. Ich habe das gamacht, weil ich es mit MS IE 3 schon erlebt habe, dass er, falls man das Script mit einer HREF aufruft, eben das = als zum Dateinamen zugehoerig betrachtet und daher in das %3D umgewandelt hat. Das Problem, das ich jetzt bei dieser Zeile vermutet habe, ist: Beinhaltet der Wert (das was hinter dem = steht) seinerseits auch ein =, kommen demnach also mehrere %3D's im $_ vor, werden nach dieser Zeile wieder mehrere = dort stehen, und es ist zu befuerchten, das split() auf die Schnauze faellt (ich weiss ja nicht, wie es ganz genau arbeitet); es muesste in diesem Fall ja mehr als nur zwei Skalare zurueckliefern. Inzwischen ist mir aber ne ganze billige Abhilfe fuer das Problem eingefallen: Lasse das g als Option weg, also nur
$_ =~ s/%3D/=/i; dann wird nur das erste Auftreten von %3D ersetzt und alles sollte in Butter sein (denk ich jetzt mal).(Hoffentlich nicht zu kompliziert formuliert),
Calocybe-
Hi!
sub InitQuery() {
my @args;
my ($field, $value);%query = ();
@args = split(/&/, $ENV{'QUERY_STRING'});
for (@args) {
$_ =~ s/%3D/=/gi; # aeltere Browser uebergeben unter Umstaenden %3D statt =
($field, $value) = split(/=/, $_);
$value =~ s/+/ /g; # + durch Leerzeichen ersetzen
$value =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge; # Hexa-Angaben -> echte Zeichen
$query{$field} = $value;
}
}Du solltest insbesondere testen, was passiert, wenn die uebergebenen Daten (was halt im Formular eingegeben wurde) selbst ein oder mehrere = enthalten. Please post any results in this forum. Wenn Du trotzdem lieber die add.cgi/german -Variante bevorzugst, denn schau mal in den beiden letzten Archiv-Dateien, vor kurzem hatte glaube ich mal jemand was dazu geschrieben.
Ein = in den Parametern macht doch kein Problem, da dieses innerhalb des Query-Stings durch den Hexwert kodiert ist. Das Programm splittet ja auch erst am = und ersetzt dann alle Hexangaben durch die entsprechenden Zeichen (z.B. das =). Für die Kodierung der Eingaben ist im übrigen der Browser zuständig.
Vergiss nicht die Zeile $_ =~ s/%3D/=/gi; ! Sie wandelt noch vor dem split() alle als %3D uebergebenen = in ein richtiges = um. Ich habe das gamacht, weil ich es mit MS IE 3 schon erlebt habe, dass er, falls man das Script mit einer HREF aufruft, eben das = als zum Dateinamen zugehoerig betrachtet und daher in das %3D umgewandelt hat. Das Problem, das ich jetzt bei dieser Zeile vermutet habe, ist: Beinhaltet der Wert (das was hinter dem = steht) seinerseits auch ein =, kommen demnach also mehrere %3D's im $_ vor, werden nach dieser Zeile wieder mehrere = dort stehen, und es ist zu befuerchten, das split() auf die Schnauze faellt (ich weiss ja nicht, wie es ganz genau arbeitet); es muesste in diesem Fall ja mehr als nur zwei Skalare zurueckliefern. Inzwischen ist mir aber ne ganze billige Abhilfe fuer das Problem eingefallen: Lasse das g als Option weg, also nur
$_ =~ s/%3D/=/i; dann wird nur das erste Auftreten von %3D ersetzt und alles sollte in Butter sein (denk ich jetzt mal).Was aber, wenn in $_ so was wie 'test=a%3Db' steht? Dann kommt doch wieder ein String mit mehreren '=' in das split! Hier solltes Du am split ein wenig rumfeilen:
($field, $value) = split(/=/, $_, 2);
Durch die 2 gibst Du an, daß nur 2 Teilstrings erzeugt werden sollen, also nur einmal gesplittet wird. Weitere '=' im value bleiben dann unberücksichtigt.Jörk
-
Hallo mal wieder.
Was aber, wenn in $_ so was wie 'test=a%3Db' steht? Dann kommt doch wieder ein String mit mehreren '=' in das split!
Richtig. Habe ich auch gerade gemerkt. Wie gesagt, ich hatte das nicht getestet, aber jetzt musste ich es doch nutzen und da habe ich es getestet.
»» ($field, $value) = split(/=/, $_, 2);
Durch die 2 gibst Du an, daß nur 2 Teilstrings erzeugt werden sollen, also nur einmal gesplittet wird. Weitere '=' im value bleiben dann unberücksichtigt.
Aah, gut. Ich habe es anders gemacht:
$_ =~ s/=|%3D/=/i;
Das ersetzt das erste Auftreten eines [= oder %3d] durch =.Calocybe
-
-
-
-
Hallo Calocybe,
von http://127.0.0.1/cgi-bin/links/add.cgi?language=german
Genau das ist es. Der Standardweg.Es gibt aber auch Programme, bei denen das tatsaechlich anders ist, zum Beispiel bei mSQL. Wenn man das zu mSQL gehoerende CGI-Verarbeitungs-Script (heisst w3-msql oder so aehnlich) aus HTML aufruft, lautet das beispielsweise so:
http://127.0.0.1/cgi-bin/w3-msql/ParameterIch hab das anfangs nie verstanden bzw. konnte mir gar nicht vorstellen, dass der Slash als Parameter-Trennzeichen erkannt wird und nicht sofort als Verzeichnistrennzeichen interpretiert wird.
Irgendwie funktioniert es aber.Kann jemand vielleicht mal sagen, was der Unterschied zwischen URL-Parameteruebergabe via "?" und via "/" ist?
viele Gruesse
Stefan Muenz-
Hallo Stefan!
von http://127.0.0.1/cgi-bin/links/add.cgi?language=german
Genau das ist es. Der Standardweg.Es gibt aber auch Programme, bei denen das tatsaechlich anders ist, zum Beispiel bei mSQL. Wenn man das zu mSQL gehoerende CGI-Verarbeitungs-Script (heisst w3-msql oder so aehnlich) aus HTML aufruft, lautet das beispielsweise so:
http://127.0.0.1/cgi-bin/w3-msql/ParameterIch hab das anfangs nie verstanden bzw. konnte mir gar nicht vorstellen, dass der Slash als Parameter-Trennzeichen erkannt wird und nicht sofort als Verzeichnistrennzeichen interpretiert wird.
Irgendwie funktioniert es aber.Kann jemand vielleicht mal sagen, was der Unterschied zwischen URL-Parameteruebergabe via "?" und via "/" ist?
Der Trick an der ganzen Sache ist, daß der Server sich den Verzeichnis-Baum ein wenig genauer anschaut. Wenn also z.B. ein Aufruf /a/b/c/d an den Server herangetragen wird, dann merkt dieser schon, daß b kein Directory, sondern ein Ausführbares Skript ist. Alles was hinter dem Skriptnamen ($ENV{'SCRIPT_NAME'}) angegeben wurde wird kurzerhand in die Umgebungsvariable PATH_INFO gelegt. Natürlich nur bis zu einem eventuellen ?, da hier ja die CGI-Parameter im eigentlichen Sinne anfangen ($ENV{'QUERY_STRING'}).
Das Parameter-Handling via ? ist sicherlich in sofern einfacher einzusetzen, als das die Kodierung von Sonderzeichen, sowie die Angabe von mehreren Parametern vorgegeben ist. Ich denke auch nicht, daß man einen Browser davon überzeugen kann, ein Formular in /-Notation (wie auch immer die aussehen mag) zu versenden ...
Das Handling via / ist eigentlich den Skript-Bauern selbst überlassen. Aus dem Bauch heraus würde ich sagen, daß man hiermit gut nach Sprachversionen trennen kann. Eine Anwendung, die ich auch schon mal hatte, war, hierduch ein Verzeichnis angeben zu lassen, aus dem Template-Dateien verwendet werden sollten ...
Mag sein, daß man über die / Notation auch virtuelle Verzeichnisse auf dem Server aufbauen kann. In diesem Falle würden sich dann relative Links aus einer skriptgenerierten Datei (xx/german/index.html) auch auf diese Pfade beziehen (grafik/bild.gif). Diese können dann vom Skript nach herzenslust bedient werden. Lokalisierte Varianten, Zufallsgenerator, Counter, Datenbankzugriffe, .....
Könnte ja also sein, daß die Verwendung der /-Notation auch mal nutzbringend und vor allen Dingen vorteilhaft gegenüber der ?-Notation eingesetzt werden kann ...
Jörk
-
Hallo Jörk!
vielen Dank fuer diese Infos - da hast Du wirklich Licht in ein Dunkel gebracht, das wohl noch selten so ausgeleuchtet wurde :-)
viele Gruesse
Stefan Muenz-
Vielleicht dient diese "form" der parameteruebermittlung aber auch nur der einfachkeit.
wenn ich den paratmeter mit.../add.cgi/german übergebe, kann sich der query_string in der cgi vollkommen auf das form input konzentrieren.
die angabe könnte zb. so aussehen
..../add.cgi?ID=1&Title=keiner&URL=eine/german
damit hole ich mein daten-input aus dem query_string und die sprache aus dem path_info
kurzgesagt kann man auf diese weise, voneinander unabhängige parameter bzw. daten an das cgi übermitteln.
welchen vorteil das ganze auch immer haben mag.
das ganze funktioniert auch bereits, nur haut die sache mit
require "xyz/links.pl/german";
nicht hin, denn der require aufruf sucht dann nach einer datei german im verzeichnis links.plwarum das wohl hier anders ist??????????????????
cu
-
Hi !
..../add.cgi?ID=1&Title=keiner&URL=eine/german
Ich meine ja, daß nur .../add.cgi/german?... funktioniert. Die andere Variante habe ich noch nie probiert. Wenn ich in einem Formular .../add.cgi/german als ACTION angebe. Wird auch sicherlich diese Form der Übergabe verwendet ...
welchen vorteil das ganze auch immer haben mag.
Halt jeder wie er mag ;-)
das ganze funktioniert auch bereits, nur haut die sache mit
require "xyz/links.pl/german";
nicht hin, denn der require aufruf sucht dann nach einer datei german im verzeichnis links.plwarum das wohl hier anders ist??????????????????
Hier handelt es sich ja auch um zwei völlig unterschiedliche Aufruf-Arten. Beim CGI-Aufruf hängt ja immer noch der Server dazwischen, der die URL auseinanderrupft - zur Unterstützung schaut er dazu halt auch noch mal in die Directories um festzustellen, daß /german nur ein Anhängsel ist.
require hingegen dient dazu, Libraries/Module in Perl einzubinden. Hier kommt niemand dazwischen, um festzustellen, daß nur der erste Teil des Pfades ernst gemeint war ...
Hier solltest Du dann eher auf Perl-Eigenheiten zurückgreifen, um entsprechende Parameter zu übergeben. Eine Lösung die aber beides bedient ist aber ohne entsprechende if-Konstrukte sicher nicht möglich!Wozu möchtest Du denn dieses require nutzen?
Jörk
-
Wozu möchtest Du denn dieses require nutzen?
Jörk
es ruft die konfigrutationsdatei für die jeweilige sprache auf....
-
-
-
-
-
-
-
Hi!
http://127.0.0.1/cgi-bin/links/add.cgi/german
wenn ich diese url eingäbe, wie kann ich dann in der add.cgi den letzten teil (german) abfragen?Wie soll das überhaupt funktionieren?
Wenn Du "/german" dranhängst, wird doch ein Script "german" im Verzeichnis "add.cgi" gesucht!nit dem env{script-name) hab ich es schon versucht, aber der gibt die url nur bis zu add.cgi aus...
Eigentlich erstaunlich genug, daß er überhaupt auf's richtige Script zugegriffen hat...
von http://127.0.0.1/cgi-bin/links/add.cgi?language=german
halt ich nicht viel, da dem cgi später noch andere daten zugepostet werden, da kommt dann ein durcheinander raus, ausserdem würde die admin.cgi auch nicht mehr funktionieren, denn die bekommt daten in unterschielichster form übermittelt...
Wäre aber der beste Weg.
Und wo ist das Problem mit admin.cgi? Wenn das wie üblich so programmiert ist, daß die Variablen in einem Hash landen (siehe Antwort von Calocybe), wird $xyz{"language"} schlimmstenfalls einfach ignoriert...wie regle ich das am besten mit den formularen?
http://127.0.0.1/cgi-bin/links/add.cgi/german?id=yw&name=abc....
oder so
http://127.0.0.1/cgi-bin/links/add.cgi?id=yw&name=abc..../germanAm besten mit <INPUT TYPE=hidden NAME=language VALUE=german>...
vielleicht weiss jemand von euch ne tolle lösung...
Zur Not würde ich 'n anderes Trennzeichen nehmen, weil '/' nunmal für Pfade gebraucht wird.
'Ne andere Möglichkeit wäre, zwei verschiedene Scripts in zweierlei Pfaden (also z.B. "german/add.cgi" und "english/add.cgi") zu verwenden. Wenn du willst, kannst du (nur unter Unix) ja einen Link setzten, und dann die Pfad-Varialbe (á la Andreas Bierhals) abfragen...Ciao,
Mirko-
Wie soll das überhaupt funktionieren?
Wenn Du "/german" dranhängst, wird doch ein Script "german" im Verzeichnis "add.cgi" gesucht!Da muss ich DICH enttaueschen, es funktioniert sehrwohl. hasste soeinen aufruf noch nie gesehen?
das german bekommt man übrigens mit dem path_info zurück, da der / noch dabei ist, muss man eben einen split machen,
leider hilft mir das ganze trotzdem nichts, da ich kein require auf diese weise setzten kann....
cu
-