Excel has a proper encryption (not very strong) build in, but i couldn't find a method to read "password-protected" Excel files from Perl. maybe you have more luck, since that would be the easiest way.

on the other hand, if you have realy strong nerves, you can code some VBA snippet, which encodes the value of a cell with a common encryption, you can also use from within Perl.

i'm afraid, there is no Perl interpreter included in Excel.

At any rate, to do this you will need OpenSSL for Win32 (the binaries). Note: You can use whatever encryption tools you want. This example uses OpenSSL.

You will need to learn how to encrypt something with it unless you already know how or are doing it some other way.

I used:

C:\Temp\openSSL\bin>openssl enc -aes-256-cbc -a -salt -in foo.txt -out
+ file.enc
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
*****
[download]

C:\Temp\openSSL\bin>type file.enc
U2FsdGVkX19MZ5n8Rb41XIrAuhwtlBUPPWhbvSe4b0J3Wfj8QRRwqCxuqTG69Ta9
[download]

Now, your only 'problem' is convincing Excel to spit out a text file with the data:

use Win32::OLE;
   
    my ($filename) = "F:\\Incidents.xls";
    my ($nextStep) = q|mysystem.cgi?f=incidents_show|;
    my ($csv) = ".\\data\\_csv\\incidents.csv";
    if(-f $filename)
     { 
       my(@fnStat) = stat($filename);
       my(@csvStat)= stat($csv);
       
       if($fnStat[9] > $csvStat[9]) {
         my($obj) = Win32::OLE->new("Excel.Application");
        $obj->Workbooks->Open (q|F:\Incidents.xls|);
        if (-f q|c:\data\_csv\incidents.csv|) {unlink(q|c:\data\_csv\i
+ncidents.csv|) or die "Cannot unlink the incidents.csv file!"};
        $obj->ActiveWorkbook->SaveAs(q|C:\data\_csv\incidents.csv|, 6)
+;
        $obj->ActiveWorkbook->Close(0);
        $obj->Quit();
         "The Incident.xls file has been recently modified and the exc
+el file has been created!  <a href=\"$nextStep\">Click</a>";
       }
       else
       {
         "File is okay. Proceed to CSV. <a href=\"$nextStep\">Click</a
+>";
       }
      } 
      else 
      { "Could not find Incidents.xls!"};
[download]

The above code checks to see whether the file on the local disk is older than the spreadsheet's last modification time. If so, it initiates the download.

Now you can shell out to OpenSSL to encrypt that file. A possible vulnerability with this method -- having a Perl script encrypt a separate file -- is that you will have to maintain the password inside of your perl script somewhere. Perhaps there is an encryption method where you wouldn't need a shared password, like PGP? I'm not sure. Try Google. Update: Here is some more on passwords with OpenSSL

There are some nice ideas in this post. However, the user of the Excel spread sheet does not necessarily have Perl on their PC and they won't want to be downloading encryption software to their PC. I think that the solution lies in using VB script. I will need to think about it a little bit more. Does anyone know of a bit of Perl code that encrypts and reads back the encrypted text. I could use that as a basis for producing the VB script and corresponding Perl script.

There are various ways to make a perl script a binary executable on a windoze PC (link to get you started). If you take advantage of one of those options, the person would not need to install perl, nor encryption software other than the one you provide.

-Scott

If you use email as your way of transportation of files, you could think of using PGP or GPG as a way to do public-private key encryption-type things.

Another option is to have excel spew its data into a cvs, then encrypt that file using whatever method you wanted so long as it was reversable.

And finally, a bit of VBA like Taulmarill wrote above could be used to export the file in an encrypted way, but this is probably the most complicated and slowest option to code. (meaning getting the code working will take the longest, I'm not attempting to make predictions of which option is going to be the fastest once written).

-Scott

Update: The Email encryption eXile has suggested above is also a good option I hadn't thought of. It reminded me of yet another option: Is the remote user using VPN to connect back to you? If so, the network is already encrypted, and you wouldn't need to encrypt that file before transmitting.