übertragungsprobleme mit altem CGI file (bnbform.cgi)

[jurichebesta]

hallo allerseits,

habs letzte woche schon mal an anderer forumstelle probiert....jetzt weiss ich zumindest, dass ich wohl hier richtig bin. es geht um emailformulare in kyrillischer sprache (genauer: bulgarisch) mit charset UTF-8 im header.

die darstellung der formularinhalte ist einwandfrei, beim senden des formulars werden jedoch alle textfeld-inhalte umgewandelt, sodass nur noch seltsame zeichen beim empfänger ankommen. die zeicheninformationen gehen also beim übermitteln des emails verloren. die übergabe der daten geschieht durch ein altes perl script (bnbform v3.0) - das ergebnis schaut dann beim empfänger z.b. wie folgt aus:

On Tue Sep 29 18:53:56 2009,
The following information was submitted:
Host: 87.00000000
Text = ôÏÍÂÏÌÁ
úÁ ÄÁ ÓÅ ÚÁÐÏÚÎÁÅÔÅ ÐÒÁËÔÉÞÅÓËÉ É ÄÁ ÍÏÖÅÔÅ ÌÉÞÎÏ ÄÁ ÓÅ.
Firstname = ôÏÍÂÏÌÁ
Lastname = ôÏÍÂÏÌÁ
Company = ôÏÍÂÏÌÁ
submit_by = [email protected]
Phone = 0000000000

ich hab bereits sämtlich in frage kommende charsets getestet - immer das gleiche problem. wenn ich z.b. deutsche texte in die jeweiligen textfelder eintrage, kommt alles bestens beim jeweiligen empfänger an....das problem liegt wohl am cgi file.


hier die info vom provider:

" die zeile mit pack("c", .....)
sieht meiner meinung nach komisch aus,
zumal perldoc -f pack ne andere option fuer utf-8 characters vorschlaegt"


bin alles andere als ein perl-experte....kann man mit 1, 2 änderungen im bnbform.cgi was machen? oder brauch ich wirklich ein neues script?

wenns denn nicht anders geht, kennt jemand ein MIME-taugliches fertiges Mail-Forumular-Script, welches das jetzige leicht ersetzt (muss nicht perl sein)?



danke im voraus!




im anhang befindet sich ein kleines textfile mitm code des bnbform.cgi:

 

[struppi]

Welcher Anhang?

Das Problem kann daran liegen, dass die mails nicht mit der richtigen Kodierung verschickt werden.

 

[jurichebesta]

danke für deine antwort.

was genau meinst du damit "mit der richtigen Kodierung verschickt werden"?

bei mir sieht das so aus:

<form method="POST" action="http://www.domain.com/cgi-bin/bnbform.cgi" accept-charset="UFT-8">
<!-- hier folgen die Formularelemente -->
</form>

 

[XraYSoLo]

"accept-charset"? dieses attribut gibt es laut DTD gar nicht...wäre mir auch neu, dass man den zeichensatz über auszeichnung definieren kann.
wenn du was UTF-8 kodieren willst, ist utf8_encode() die einzig richtige wahl (gesetzt den fall, du verwendest PHP).

Nils aka XraYSoLo

 

[struppi]

danke für deine antwort.

was genau meinst du damit "mit der richtigen Kodierung verschickt werden"?

Naja, emails müssen auch kodiert werden. Welche haben diese?

 

[jurichebesta]

hab accept-charset="UFT-8" mal wieder rausgeschmissen...hattest natürlich recht, bring ja auch nix - die emails sind sowieso mit UTF-8 codiert.

bei allen emailformularen ist php eben nicht in verwendung - es handelt sich, wie gesagt, um ein uraltes perl script (bnbform.gci v3.0), welches am webserver liegt......die "normalen" emails kommen ja auch problemlos bei den empängern an - nur eben nix, was per unicode versendet wird.

ich denke, die einzige lösung ist wohl eine geeignete PHP-klasse und die mit einigen wenigen zeilen im code einbinden - dafür muss ich wohl an eine andere stelle hier im forum. bin alles andere als ein php experte....

vielen dank jedenfalls für deine mühe, juri

 

[struppi]

Ich weiß zwar nicht warum die nicht auf meine Frage reagierst, aber wenn du das Skript eh umbauen möchtest, ist es eigentlich auch egal.

Redest du eigentlich von diesem Skript
http://bignosebird.com/carchive/bnbform/bnbform.txt
Das ist zwar nicht schön, aber du kannst dort versuchen den Mailheader zu erweitern. In den Zeilen 516 ff. vor der Zeile wo subject ausgegeben wird

print MAIL  'Content-Transfer-Encoding: 8bit';
print MAIL  'Content-Type: text/plain; charset="utf-8"';

bring ja auch nix - die emails sind sowieso mit UTF-8 codiert.

Genau diese Aussage war falsch und deshalb hatte ich auch gefragt.

 

[jurichebesta]

hi struppi, danke für die promtpe antwort.

hab deine frage offensichtlich nicht ganz geknissen :-(

du hast auf jedenfall recht, es handelt sich um dieses script - nur sogar um die vorgänger-version! hier ein word-doc mitm script code:

http://www.ci-works.com/bnbform/bnbform-cgi.doc

und hier eines der formulare, wenns was bringt:

FIRMA


ich möchte auf jedenfall versuchen, den mailheader zu erweitern; wenn möglich - mal schauen, obs was bringt.....ich bin da unschuldig zum handkuss gekommen und müsste demnach sicher 100 (nicht funktionierende) uralt-emailformulare bearbeiten.


danke nochmals für deine hilfe, juri

habs übrigens eben mit der mailheader-erweiterung versucht....das ergebnis ist leider nach wie vor:

On Wed Oct 7 10:36:11 2009,
The following information was submitted:
Host: 87.219.104.43
Text = ИТО Ð¡Ð»Ð¾Ð²Ð°ÐºÐ¸Ñ Ð¸ Репулика Ð§ÐµÑ…Ð¸Ñ Ð¸Ð½Ñ„Ð¾Ñ€Ð¼Ð¸Ñ€Ð° за Ð½Ð¾Ð²Ð¸Ñ Ñи Ð¾Ñ„Ð¸Ñ Ð² БратиÑлава и за конференциÑта на тема "Ðовата Ð²Ð¸Ð·Ð¸Ñ Ð² Човешките реÑурÑи", коÑе ÑÑŠÑÑ‚Ð¾Ñ Ð² Ñловашката Ñтолица.
name = juri
submit_by = [email protected]

 

[struppi]

In dem Code von mir ist auch ein Fehler (ich hatte den aus einem anderen Programm kopiert, dass eine andere vorgehensweise hat) - es müssen in die Zeilen auch noch jeweils ein Newline Zeichen am Ende, dann funktioniert es auch (hab's probiert):

print MAIL "Content-Transfer-Encoding: 8bit\n";
    print MAIL "Content-Type: text/plain; charset=\"utf-8\"\n";

Ach noch was.
Ich hab den Fehler übrigens gefunden, weil ich gesehen habe, im Menü Ansicht > Zeichenkodierung (im Thunderbird), welche Zeichenkodierung die Mail hat. Das war das, wonach ich dich die ganze Zeit gefragt hatte. Da hättest du gesehen, dass die Mail immer in ISO dargestellt wurde, auch mit meinem fehlerhaften Code. Auf jeden Fall wären wir mit dieser Information früher fertig gewesen.

 

[jurichebesta]

also, ich kann mich nur nochmals bedanken für deine hilfe....probiers gleich nochmals aus it deinen neuen codes...

ich ging davon aus, dass durch das angeben von utf-8 im header bzw. freischalten von utf-8 seitens provider alles ok is. wie gesagt, bin zum ersten mal damit konfrontiert (als musiker normalerweise eher mit anderen "spezialproblemen" beschäftigt :-)

das sieht im cgi nun folgendermassen aus am ende:

  if ($SEND_MAIL ne "")
   {
     open (MAIL,"| $SEND_MAIL");
   }

    print MAIL "To: $to\n";
    print MAIL "From: $fromaddr\n";
    print MAIL "Reply-to: $replyaddr\n" if $replyaddr;
    print MAIL "X-Mailer: Perl Powered Socket Mailer\n";
    print MAIL "Subject: $subject\n\n";
    print MAIL "$message";
    print MAIL "\n.\n";
    print MAIL "Content-Transfer-Encoding: 8bit\n";
    print MAIL "Content-Type: text/plain; charset=\"utf-8\"\n";


 if ($SMTP_SERVER ne "")
  {


meld mich gleich nochmal. juri

klappt leider immer noch nicht.....die selben fehlerhaften zeichen wie in den letzten tagen. du sagtest, du hast es selbst probiert und es hat gefunkt?

wenn du mir eine emailadresse angibst, schick ich dir das gerne mal eine email in cc zu.

hier nochmals die info vom provider (vielleicht kannst du damit was anfangen?):

" die zeile mit pack("c", .....)
sieht meiner meinung nach komisch aus,
zumal perldoc -f pack ne andere option fuer utf-8 characters vorschlaegt"


...was auch immer damit gemeint sein mag - hab die zeile hier gefunden:

sub decode_vars
 {
  $i=0;
  read(STDIN,$temp,$ENV{'CONTENT_LENGTH'});
  @pairs=split(/&/,$temp);
  foreach $item(@pairs)
   {
    ($key,$content)=split(/=/,$item,2);
    $content=~tr/+/ /;
    $content=~s/%(..)/pack("c",hex($1))/ge;
    $content=~s/\t/ /g;
    $fields{$key}=$content;
    if ($key eq "data_order")
      {
       $content=~s/ //g;
       @sortlist=split(/,/,$content);
      }
    if ($key eq "required")
      {
       $content=~s/ //g;
       @mandatory=split(/,/,$content);
      }
   }
if  (
     ( ($fields{automessage}=~ /^([-\/\w.]+)$/ || $fields{automessage} eq "") &&
      ($fields{countfile}=~ /^([-\/\w.]+)$/ || $fields{countfile} eq "") &&
      ($fields{emailfile}=~ /^([-\/\w.]+)$/ || $fields{emailfile} eq "") &&
      ($fields{outputfile}=~ /^([-\/\w.]+)$/ || $fields{outputfile} eq "") )
        &&
     ( (substr($fields{automessage},0,1) ne "/") &&
       (substr($fields{countfile},0,1) ne "/") &&
       (substr($fields{emailfile},0,1) ne "/") &&
       (substr($fields{outputfile},0,1) ne "/") )
    )
    {$donothing=0;}
    else
     {
       print "Content-type: text/html\n\n sorry, invalid characters...\n";
       exit;
     }
}

Mod-Edit: Code-Tags hinzugefügt - Beim nächsten Mal bitte dran denken (XraYSoLo)

 

[struppi]

Wie ich schon schrieb, du musst die zusätzlichen Headerzeilen vor dem subject schreiben, so haben sie keine Wirkung. (wie du hättest sehen können, wenn du mal nach der mail kodierung gucken würdest)

Die Provider Info ist Unsinn, vergiß sie.

 

[jurichebesta]

hab die zusätzlichen headerzeilen vor dem subject eingefügt, doch leider...nix neues; immer noch das selbe problem. schade, stand schon in jubelpose bereit!

  if ($SEND_MAIL ne "")
   {
     open (MAIL,"| $SEND_MAIL");
   }

    print MAIL "To: $to\n";
    print MAIL "From: $fromaddr\n";
    print MAIL "Reply-to: $replyaddr\n" if $replyaddr;
    print MAIL "X-Mailer: Perl Powered Socket Mailer\n";
    print MAIL "Content-Transfer-Encoding: 8bit\n";
    print MAIL "Content-Type: text/plain; charset=\"utf-8\"\n";
    print MAIL "Subject: $subject\n\n";
    print MAIL "$message";
    print MAIL "\n.\n";

trotzdem noch eine frage: du hasts mit einem selbst kreierten formular probiert und es hat funktioniert?

Mod-Edit: Code-Tags hinzugefügt - Beim nächsten Mal bitte dran denken (XraYSoLo)

 

[struppi]

trotzdem noch eine frage: du hasts mit einem selbst kreierten formular probiert und es hat funktioniert?

Ja. Ich hab kyrillische Buchstaben verschickt, die genauso in der Mail dargestellt wurden.

Nach wie vor fehlt in deiner Fehlerbeschreibung die Kodierung der Mail.

Ach was ich grad sehe, probier es mal in dem du die Anführungszeichen um utf-8 wegmachst.

print MAIL "Content-Type: text/plain; charset=utf-8\n";

 

[jurichebesta]

klappt leider auch mit deinem letzten tipp immer noch nicht.

hab diese formulare nicht erstellt....wo genau lässt sich die kodierung feststellen? ich seh nur, dass im source-code utf-8 als charset angegeben ist und utf-8 nach meiner anfrage beim provider dann auch am webserver aktiviert wurde vorgestern.

vermutlich sind es aber keine MIME-Mails (weiss nicht wirklich, wie man das feststellt, aber das wären die momentanen infos dazu). laut provider ist dieses script nicht MIME-fähig.

hier noch ein statement:

"Ich würde einfach eine geeignete PHP-Klasse verwenden und die mit einigen wenigen Zeilen Code einbinden. Das hat nebenbei auch noch den Vorteil, dass man sie sehr individuell anpassen kann. In der Swift-Mailer-Dokumentation findest du diverse Beispiele zur Nutzung. Wenn du die minimal anpasst, bist du schon fertig und kannst dir recht sicher sein, dass die Mails den RFCs entsprechen und dein Script nicht für Mail-Injection anfällig ist."

oder lässt sich eine MIME-Implementierung leichter umsetzen? was meinst du?

 

[struppi]

Ich kann dir nur soviel sagen, dass ich das Skript mit deinem Formular ausprobiert habe und es hat einwandfrei funktioniert. Wie du die Kodierung im Thunderbird rausfindest hatte ich dir schon geschrieben, aber ich weiß nicht welches Mailprogramm du nutzt. Ist das überhaupt utf-8 Fähig?

 

[jurichebesta]

ich persönlich nutze am windows pc auch thunderbird und am mac greif ich eigentlich direkt per div. webclients auf meine konten zu...

aber um mein emailprogramm gehts ja auch gar nicht, sonst bräucht ich dieses ja nur dementsprechend konfigurieren und die sache hat sich - die formulare sollten eben überall leserlich ankommen, ohne wenn und aber. ich teste die formulare deshlab seit tagen ausschliesslich über div. externe empfänger (freunde, kollegen).

wie gesagt, ich hab mir dieses problem nicht ausgesucht; muss aber durch. leider.

ich wollte zumindest versuchen, direkt im perl script was zu ändern....deine tipps waren auch gut und logisch, jedoch klappts nach wie vor nicht. is mir ein rätsel. ich versuchs mal über einen anderen server.

danke ein weiters mal für deine unbeugsame unterstützung - weiss ich zu schätzen!

schönen abend!

 

[struppi]

Du scheinst es nach wie vor nicht zu verstehen, wie du die Zeichen siehst, liegt an der Kodierung. Das was du uns zeigst ist die Kodierung der utf-8 Zeichen in ISO, d.h. dein Programm zeigt die richtigen Zeichen falsch an.

Das liegt entweder an dem Programm oder an der Art wie - in diesem Fall - die Kodierung angegeben wird.

Wenn du Thunderbird hast kannst du unter dem Menüpunkt Ansicht > Zeichenkodierung sehen in welcher kodierung die momentan email angezeigt wird. genau danach frage ich dich seit mehreren Tagen, weil genau das das einzige Problem in dieser Sache ist und ich frage mich, warum du mir darauf nicht antworten willst, was dort dein Programm anzeigt?

 

[jurichebesta]

es hat geklappt! zumindest bei mir! ch glaub, ich spinne! endlich....

zeichencodierung ist utf-8 bei mir laut thunderbird.....nicht schlecht - bislang haben sämtliche emails eben nicht funktioniert, auch gestern noch nicht. es scheint auch im outlook zu klappen (laut einer wiener kollegin).

ich werd noch verschiedene tests machen...schaut aber gut aus.

hast eine flasche wein gut! danke nochmals!

 

[struppi]

Was'ne schwere Geburt
Danke - aber ich bin Biertrinker ;)