(Not a question for TS for now)
I’ve tried exporting a Vault as CSV, with the aim to verify if the number of items in one of my folders = number of items in mSecure. To my surprise, Export as CSV does not really exports as CSV, but instead adds new lines for each of the fields. In short, what I would expected to be a row, depending on the number of Custom Fields is now 4 rows. Has anybody seen this behavior and had an interaction with TS that explained why this happens? If not I’ll contact TS.
(PS: all this because there’s no item count per folder in any of the apps…amazing usability miss from my PoV)
Custom fields are contained within a single text string (using the double-quote " as a separator). If this text string contains name/value pairs for more than one custom field, then each such name/value pair is separated by a linefeed character (LF = ASCII character 0x0A). In contrast, the End-of-Line separator in .CSV files (in Windows) is the combination carriage return + linefeed (CRLF = ASCII 0x0D0A).
If you open the .CSV file in a text editor such as Notepad, it is impossible to visually distinguish between the new lines created by LF vs. CRLF, so it may look like your .CSV has extra rows. However, if you open the .CSV file in Excel, then you will will see that the LF characters that separate custom field data is not creating extra rows.
I don’t know what TS is, but hopefully the above information helps you figure out the problem.
hi @grb ,
Thanks for jumping in.
Sorry, I did the stuff I hate most, using acronyms without explaining. TS= Technical Support (Bitwarden’s)
I observed now that LF is indeed set between custom fields and indeed CRLF is set between custom fields.
My Excel (v 2211, part of Microsoft 365) however interprets the LF the same as CRLF in my Windows 11, so I get one row per LF unfortunately.
Regardless, in all my years of parsing custom input formats in all sort of enterprise apps this is the first time I see such an approach. I don’t get it why a more classic separator can’t be used.
I assume the above is a typo, and that you meant CRLF is set between rows.
That is quite odd. I can’t make heads or tails of the Office version numbering – my Build on Office365 is showing as 16.0.16012.42302, and this version does interpret LF as a newline within a spreadsheet cell.
Using LF inside text fields is “classic” for the .CSV format, though. The same method will be used to represent line breaks in “notes” fields. If you use a different type of separator for the custom fields, then you will have problems if that separator character appears in the name or value for one of the custom fields, or if the separator character appears anywhere in a “notes” field — you’d have to introduce some scheme for escaping the separator character, and it would quickly become a mess.
In your Excel version, can you create a line break inside a text cell (e.g., by using Alt+Enter)? If so, when you export the spreadsheet as a .CSV, how is the line break represented?
I found my full excel version: Microsoft® Excel® for Microsoft 365 MSO (Version 2211 Build 16.0.15831.20098) 64-bit . So it seems we see the same LF=newline (assuming there wasn’t a typo)
That problem if the separator appears in the value has been solved since ages. It can be messy on the implementation if it’s not designed properly, but a good developer can reuse the tens of examples on the internet on this topic to achieve something easier to the user.
On mSecure they use as item separator ;
For a normal value they see this: Sursa|0|Amazon;Garantie|0|
If you add ; in the value they add double quotes: Sursa|0|Amazon;“Garantie|0|;”
If you add | in the value they don’t add anything: Sursa|0|Amazon;Garantie|0|||
Nice output that is so easy on the eye. Also, I do understand that for parsing reasons it does not really matter, but if there’s a way to design something both technically functional AND easily human readable I’ll always implement both.
As a funny thing in Bitwarden the Desktop UI stops the current separator (LF) to be added as a value. (ALT+010).
Based on the above result, and your answer #2 in the previous post, I don’t understand why your version of Excel would interpret a LF character within a pair of " separators as an end-of-line when importing from .CSV. To be clear, my version of Excel does not create a new row in the spreadsheet table where such LF characters appear; instead, it creates multiple lines of text inside a spreadsheet cell (the same effect that can be created manually using Alt+Enter).
Your point about coding parsers that can accommodate other separators is well taken, but one of the points I was making is that “Notes” fields can also contain line breaks, so if you are trying to prevent line breaks in vault data that has been exported as a .CSV, you would have to replace LF characters in all notes with your preferred separator (and escape any instances of the separator that appear in the text). This may be easy enough to implement in the Bitwarden export code, but I think this would create difficulties when importing data from other password managers. Customized import filters are not available for every existing password manager data format, and some of the available import filters do not work perfectly — in such cases, the user has to manually condition the .CSV data before importing into Bitwarden. So, to get to my point, if a user is manually preparing a .CSV file for import, they will probably find it difficult to do the conversion of line breaks and escaping of existing instances of the separator character. Thus, I think that using the standard LF separator is the most robust implementation, even if it can look ugly when opening the .CSV in a text editor (and apparently, certain versions of Excel?!).
Sorry to pick up an old topic. I struggled with multi-line notes as well. Excel showing them always as new rows, breaking the csv completely and making it unusable.
The solution for me was to change the exported csv with notepad++. Replacing the “,” with “;” and excel accepts the multi-line notes correctly.
