#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2012
    Posts
    2
    Rep Power
    0

    Perl cgi converting characters


    I have a perl cgi script is converting ascii character 160 to asci character 239,191, & 189. In my webpage, I am setting a variable to use character 160 and assigning it to a form variable. When I post it, perl is converting those characters. Does anyone know why? I was using a different non perl cgi program with the exact same web page and it was working fine.

    (160) - character 160.
    basically if I send 1(160)2(160)3 from the webpage, my saved post variable will look like 1(239)(191)(189)2(239)(191)(189)3.

    Here is the code:

    #!c:/perl/bin/perl.exe
    # print "Content-type: text/html\n\n";
    ##
    {
    use CGI qw/:standard/;
    #
    $bfile="c:\\TEMP\\UPLOAD\\$$.env";
    open (UPLOAD,">$bfile") || Error ();
    print UPLOAD "QUERY_STRING=",$ENV{"QUERY_STRING"},"\n";
    print UPLOAD "HTTP_COOKIE=",$ENV{"HTTP_COOKIE"},"\n";
    print UPLOAD "SERVER_NAME=",$ENV{"SERVER_NAME"},"\n";
    print UPLOAD "PATH_INFO=",$ENV{"PATH_INFO"},"\n";
    print UPLOAD "REMOTE_ADDR=",$ENV{"REMOTE_ADDR"},"\n";
    print UPLOAD "REQUEST_METHOD=",$ENV{"REQUEST_METHOD"},"\n";
    close (UPLOAD);
    $bfile="c:\\TEMP\\UPLOAD\\$$.qry";
    open (UPLOAD,">$bfile") || Error ();
    foreach my $name (param()){
    print UPLOAD "\n";
    $value = param($name);
    $value =~ s/\r/%FD/g;
    $value =~ s/\n//g;
    print UPLOAD $name,"=",$value;
    }
    close (UPLOAD);
    chdir 'c:\udt' or die 'Bad directory';
    my $file = `udt process $$ type`;
    $file =~ s/.*?(Content.*)$/$1/gsi;
    print "$file\n";

    }
  2. #2
  3. !~ /m$/
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    May 2004
    Location
    Reno, NV
    Posts
    4,258
    Rep Power
    1810
    I think what you are running into is that the CGI.pm module unescapes any HTML entities automatically. Some characters are not allowed to be part of a URL, so your browser converts them before uploading, and then they are made normal by the perl script when they are received.

    So, it raises a lot of issues, and a lot of questions. We haven't seen the web form; don't know how you are inserting a raw character between data; don't know the purpose of the script. I guessed at the entities conclusion based on you searching for raw data (%FD) from your form.

    Rather than trying to get at the encoded data before unescaping, you might want to rethink your approach of using the 160 character as a delimiter. That's in the extended ASCII zone; a place you will see conflicting definitions.

    Probably no need for a delimiter at all. You can upload an array of data directly from a form using named input fields.
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2012
    Posts
    2
    Rep Power
    0
    That tells me a lot actually. I am not going to get into why I am using 160 because it would be a huge undertaking to change it. I think what I need is the code to unescape the string before it is output to a file. The lines below:
    $value = param($name);
    $value =~ s/\r/%FD/g;
    $value =~ s/\n//g;

    Need to change to something like:
    $value = param($name);
    $value= unescape($value);

    What is the syntax for the above?

    Is this the correct approach?

    I think the udt is doing the unescape and obviously not properly. I can remove that from that app and using the perl one.

IMN logo majestic logo threadwatch logo seochat tools logo