Importing .csv file
I used an unsupported password manager for many years. I exported the data into a .csv file and re-arranged the data in the order set forth in the instructions then saved it as a .csv file. When I import the file, I get one log in with all the data in a long list of numbered fields. What am I doing wrong?
thank you
Comments
-
Hi, @Kin206.
Just to confirm, you arranged your exported CSV data with instructions here:
How can I import data from another application?
The reason for your failing CSV import could be a newline issue similar to what I mentioned elsewhere. A possible workaround is to convert newline characters in the CSV file from CR (Carriage return) to LF (Line feed). A GUI utility to do that is available here:
linebreak - LineBreak is a simple utility for Mac OS X that converts line breaks in text documents.
I hope that will work for you. We'd appreciate your feedback and also seeing a sample of the failed import (see post #4 in that other topic) if you'd like to email us one. Thanks!
0 -
This suggestion seems to need a more detailed explanation. For example, does it matter whether the character set for the file is ANSI (Windows), ASCII (DOS), Macintosh, UTF-8, UTF-16, etc.? Once that is clear, if LineBreak is the recommended approach, please explain precisely how one should use it. For example, which of its conversion options should be chosen: Unix, Mac, or DOS? Given the near absence of feedback provided by LineBreak, what other commonly available tools do you recommend for assuring the file is formatted to fit 1PW's requirements? For example, how can one use TextEdit or Microsoft Word or Pages to accomplish the task, and how does one know whether the file is formatted correctly before attempting to import it into 1PW?
0 -
OK, I think I've answered my own question, at least in part.
Through a bit of trial and error, I've determined that the Macintosh character set will work. LineBreak will work if you allow it to convert the file to Unix ("\n") format. Alternatively, I was able to get TextWrangler to do the same thing using its "Save As…" command and selecting "Unix (LF)" for "Line breaks:". Even MS Word can work, if you open the .CSV file, then "Save As…" a Plain Text file, selecting "end each line with a Line Feed", and then renaming the resulting file in Finder from a .TXT extension to a .CSV extension (ignoring Finder's complaint).
But the real trick is in getting a "clean" CSV file to start with. And that's not necessarily an easy task.
Let me back-up and say that I've maintained my own password database for many years. It's accumulated over 950 records (passwords and the like), for entries associated with everything from website logins, to driver's license numbers, to IP addresses for LAN resources, the codes for combination locks, ad nauseum. Close to 300 of those records have been identified as "inactive", so the pile is still huge, but not quite as large as it seems. Nevertheless, there is no way I would ever consider manually re-entering the data from these records, especially since it should be so trivially easy for a tool such as 1PW to import them (with pronounced emphasis on "should be…"), and especially since 1PW (version 4!!!) advertised over 2 months ago, when I bought it, that it could adeptly handle imports in CSV format.
But for some fine reason, the developers had different ideas. For example, through a ton of additional trial and error, I've discovered that none of the imported fields can contain a long (em) dash (–) character. Likewise, none of the fields (except, perhaps even better reasons, the Notes field) can contain a backslash () character. And although completely understandable, I've not found where the developers explain that no field can contain a double quote (") character (of course, other than those inserted in the conversion to CSV).
I'm also not clear why the developers have thus far failed to inform users of ANY of these requirements, or to discover these requirements themselves in response to all the feedback about users having trouble importing in CSV format. Even the double-quote issue is silly, given that 1PW's import algorithm easily can check for extraneous double quotes (e.g., when importing 5 fields, there should be 5 pairs of double-quotes, for a total of precisely 10 double quotes). 1PW could at least count the number of double-quotes it sees in each record that should provide 10, and alert the user if it finds 11, 12, or more of them.
Yet instead of intelligently informing the user of any of these sorts of problems with their data and how to correct it, 1PW simply beeps at the user, or pops a dialog helpfully informing that it imported zero records, or perhaps 1. How sweet.
Come on agile-folk. This shouldn't be that hard to figure out. Why must a user do it for you?
0 -
To summarize, when importing "Login" data, in the fields/columns for Title/Account, Identifier/Username, Password, and Notes (I didn't test the URL field), 1PW can't handle:
double quote: "
long dash: –
backslash: \ (except Notes can handle this character for some reason).Anyone else want to test the "Credit Card", "Software", or "Secure Notes" imports?
0 -
I'm not sure if it is inherent in the CSV format, but I've also discovered that single quotes (') won't work in any of the above-identified fields either.
0 -
Thanks a lot !!! Ive been searching a lot for a solution and finally your explanation made it easy. It is amazing that this problem persists and there is no warning about it in the documentation.
0 -
Hi @fjvillegas,
I'm glad the explanation here was helpful. Can you describe any specific problems that still persist with CSV importing in 1Password 4? And which version is it?
The 4.2 update has CSV importer improvements addressing issues reported in this and other topics. We'll be updating the documentation to reflect those changes and, of course, want to fix any remaining bugs. :)
0
