Encrypt/Decryption results in changed XML file

[smandoli9]

I am receiving an XML file (FTP) and importing it into an Access table using VBA. Works great! I haven't been using the MS XML Parser -- it's a flat file, I just substring and parse.

However, the next phase of development requires receiving the same file encrypted. I found a COM Wrapper program that works with PGP and lets me automatically decrypt the file from my VBA routine. Works great!

Now the problem. My file parsing code doesn't work with the new routine, because the decrypted file is SLIGHTLY different. Inet Explorer doesn't reveal the difference. Neither does MS Word with the hidden characters set to show. However, Notepad does show the difference. It has to do with line breaks, which are replaced by ASCII generic squares.

My VBA routine was just happily going through the file, importing one line (ONE LINE, get it?) at a time and stripping out the variable and the value. Now that the "current line" is tantamount to reading the whole file, it doesn't work.

So you're going to tell me to switch to the XML Parser, I expect. Okay, I will.

But has anybody ever run into this? Now why should cryption result in any alteration to the file? And by the way, do I have 100% assurance that the Parser will not have a problem with the file?

I don't find a Tek-Tips forum relating to encryption, but if anyone knows a resource, I'd like to know.

Scott

___________________________________

"In theory, there is no difference between theory and practice. But in practice, there is."

 

[chiph]

This shouldn't happen. Encryption in general would be worthless if decrypting a document produced a file different from the source (how could you trust that the contents hadn't been manipulated by a 3rd party then?).

Send your client an XML file via email, have them encrypt it, and send it back to you via your FTP site. If the file is the same when you open it as what you sent, then the problem isn't in the encryption.

What I suspect is happening is your client has changed the way they produce the XML file and is not telling you this.

BTW: XML files are valid with carriage-return-linefeeds as well as just linefeed characters. If you can't convince your client to change back, then you'll have to change your code to accept either.

Also BTW: Think about using a parser (SAX or a DOM) to read your file. String parsing & string concatenation is a huge hassle by comparison.

Chip H.

 

[smandoli9]

That seems clear to me. The checksum ought to be the same. I don't need to run the test you suggested -- for troubleshooting, the client sent two copies of the same file, one "en clair", the other encrypted. When I decrypted the latter and put the two side-by-side, they had this difference.

And the client has said the two files are produced differently, or on different servers (translation, who knows what procedural differences accrue).

I am trying right now to use MSXML 3 with Access 2000. And I am profoundly frustrated. I guess the help files didn't get registered, and I have no instructions on how to use DOMDocument and LoadXML.

So my new Thread should be titled: "How the heck do I use LoadXML in Access VBA?" I would think the Net would abound with tutorials on that but I'm coming up dry. Further suggestions on that tearfully solicited! (Do you know a good textbook? N. Bradley's XML Companion has nothing.)

 

[chiph]

Can't help you with MS Access.

But, as you've discovered, the help files for the MS XML parser don't get registered, so you can't just hit "F1". You'll need to create a shortcut to the .CHM file.

BTW, you want to declare your variables as DOMDocument30, not DOMDocument. When you move to the 4.0 parser, MS has dropped support for the version-independent way of declaring variables of that type. It'll save you time later.

Chip H.

 

[JustinEzequiel]

>>Now the problem. My file parsing code doesn't work with the new routine, because the decrypted file is SLIGHTLY different. Inet Explorer doesn't reveal the difference. Neither does MS Word with the hidden characters set to show. However, Notepad does show the difference. It has to do with line breaks, which are replaced by ASCII generic squares.
>>
>>My VBA routine was just happily going through the file, importing one line (ONE LINE, get it?) at a time and stripping out the variable and the value. Now that the "current line" is tantamount to reading the whole file, it doesn't work.

I am guessing that you are reading your file using the standard File I/O commands. Ex.,

Dim sLine As String
Dim sFile As String
Dim nFile As Integer

sFile = "c:\autoexec.bat"

nFile = FreeFile
Open sFile For Input As nFile
Do While Not EOF(nFile)
  Line Input #nFile, sLine

  ' your code here ----

Loop
Close nFile

the Line Input command can only read files line by line if the lines are separated by carriage-return/line-feed pairs.

this is the usual case for Windows text files.

for Unix text files, however, lines are separated by line-feed characters only.

what i found that works for reading both Windows and Unix files one line at a time is the following

Dim oTS As Object
Dim oFSO As Object
Dim sLine As String
Dim sFile As String

Set oFSO = CreateObject("Scripting.FileSystemObject")
Set oTS = oFSO.OpenTextFile(sFile)
Set oFSO = Nothing

Do While Not oTS.AtEndOfStream
  sLine = oTS.ReadLine

  ' your code here ----

Loop

Set oTS = Nothing

 

[smandoli9]

HEY! Great help from you guys!
JustinEzequiel: I will give it a try.
ChipH: I didn't realize I could even open a .CHM directly, so you helped me out of a greater depth of ignorance than you may have expected. Actually with JE's help, I may escape true XML parsing for another day ... but if not, you have given me the other path I needed.

T H A N K S !!!