Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Should the "export as text" item be in an "Export Human-re

From: Sake Blok <sake@xxxxxxxxxx>
Date: Tue, 10 Apr 2012 08:53:18 +0200
On 9 apr 2012, at 17:31, Jaap Keuter wrote:

> On 04/07/2012 06:05 AM, Guy Harris wrote:
>> The mistake that caused this question to be asked:
>> 
>> 	http://ask.wireshark.org/questions/10000/how-to-get-the-txt-file-back-to-wireshark
>> 
>> might be due to people thinking that the result of an "Export" operation is something that contains the raw data from the packets and thus can be read into Wireshark.  (The question itself appears to have hoped that, even if it couldn't be read into Wireshark, it still contained the raw data, which, in this case, it didn't.)
>> 
>> Perhaps we should put the Export menu items for "as text" and "as PostScript" under a top-level menu item that more clearly indicates that the result of the operation will not be readable by Wireshark and can't necessarily even be converted into something readable by Wireshark?
>> 
>> The same applies for the "export as CSV" and "export as XML" operations; those aren't easily human-readable, but they're written in a form intended for programs *NOT* interested in the raw packet data (and not equipped to parse raw packet data) to process.
> 
> I can see the "Export / Import complementary" line of thinking (maybe I shouldn't have  created the Import...)

Nope, the import is definitely nice to have :-)

> . Anyways, this cannot end up in yet another top level menu, it's just not that sort of thing, it is a "File" operation.
> What could be done (and it already looks like it on !Windows, if I'm correct) is make it Print option. A print operation is less likely to be confused with something that can be re-imported (barring the guy feeding the printed output into the office printer/scanner to get PDFs, using OCR to get the text out, then trying to import this text).

How about making the default export options include all packet data and make sure the import function will then properly re-create the capture by reading the timestamps and parsing the hex data. That way export data will indeed be possible to import, unless someone fiddles with the default settings, but then he has only himself to blame :-)

I think people do not expect a .CSV or postscipt file to be re-importable, so we should be safe there....

Cheers,
Sake