 | 1 | initial version |
It's not clear that the concept of a CSV of all fields is well-defined.
A row of a CSV file is just a Comma-Separated sequence of Values; there are no tags to indicate what the values are values of. A CSV row, containing the values of all the fields in a packet, would just be a sequence of values, with no indication what those values signify - and not all rows would have the same number of values.
If you used the first row as a table of field names, to solve that problem, that would require that the first row have the name of each field that appears in a packet in the file, and that elements in subsequent rows may be empty (if the fed in question isn't in the packet corresponding to that row). It might also require either that a field name may appear more than once in the first row, to handle packets with more than one instance of a field.
There is currently no code in Wireshark to do that.
One thing i found wierd is that, if I choose the json or plain text as an export format, the packet byte is in the file, it does not work with csv file.
What do you mean by "the packet byte(s)"? What's exported as JSON are the packet fields; what's shown is the value, in a somewhat human-readable form, which isn't necessarily the raw bytes.
What's exported as CSV are the columns; the columns have the advantage that there is a fixed set of columns specified, so that you don't have the problems I mentioned above with CSV dumping of packet fields.
I.e., there is a reason why CSV export is different from JSON or PDML exports.
For plain text exports, which are intended for humans to read, you can choose to export the columns as displayed in the packet list pane, the packet details as displayed in the packet details pane, or the raw hex/characters dump as displayed in the hex/characters dump pane; more than one of those can be chosen.
