Problem with import from CSV to trial version
I am trying out a trial version (v6.2.1 on Mac 10.11.5) and want to test out the import from csv function so I can assess whether I would be able to bring across most of my data from my previous program (for which there is no dedicated importer).
I have created a csv file in Excel following the format specified for login items (title,URL,username,password,notes). I have no notes or custom fields. I understand that 'notes' is a required field, so I have ensured that every record ends with a comma. When I view the output cvs file in quickview or Numbers it shows the blank column at the end for potential notes, so I think I am achieving this format correctly.
In 1Password I use the import routine - 'Other' - 'Import a CSV file', item type = Login, vault = Primary. I then select the CSV file and click on Open. Each time the program beeps and returns me to the import dialog box with no error report or indication of what it dislikes about the file.
The file has 265 rows, with no column headers. The trial version is newly installed, so not expired.
Can anyone suggest what might be causing the problem, or where to look for some feedback from the program?
1Password Version: 6.2.1
Extension Version: Not Provided
OS Version: 10.11.5
Sync Type: Not Provided
Comments
-
Which program are you coming from?
0 -
I am using iAccounts by www.venticentostudio.it, which works well but has not been updated in a while so I suspect it will fall at some future iOS update.
0 -
There are not very good diagnostics for import failures. The most common cause is inconsistent number of columns across rows, or CSV quoting problems.
Try using the csv converter in the converter suite. Read the first thread, and the necessary parts of the README.pdf included in the package. Use the 1.09 version in Testing Bits.
0 -
Thank you; I will try this.
0 -
Let us know how everything goes! 8-)
0 -
Your suggestion has solved the problem - thank you.
The converter suite identified one corrupted character, but coped with it anyway. I presume the default import routine is not as capable. The problem was with a 'é', which was correctly exported by my existing program to the CSV file, but when I imported the CSV into Excel (2010 Windows version) it mangled the character. The converter program reported that '\xAE' could not be matched to UTF-8.
0 -
Thanks for reporting back your results. I'll keep in mind for future questions that a re-export from Excel may mangle the file export.
Did it import correctly into Excel?
0 -
The corruption was on import to Excel.
However I have done some more testing and I think I have narrowed down the cause. When I imported the text file output from my existing password program into Excel, I allowed Excel to use the default MS-DOS character encoding. If I re-run this step and force Excel to use UTF-8, the 'é' imports cleanly and then exports to a cvs file cleanly.
If I had remembered that I had at least one non-basic character in the text, I might have remembered to look out for UTC-8, but it was a long forgotten login amongst several hundred others.
0 -
Thanks @MyNameIsNotAvailable.
What you experienced is called Mojibake. Character encodings and conversions are very challenging at times.
Without any diagnostics, users are left in the dark and have no way to know why an import fails. I'm sure it will get better someday.
0 -
I’m so glad to see that MrC has been able to help you out here. It sounds like you’ve got all your data safely inside 1Password now. I hope that everything from here on goes smoothly, but if you have any questions, you know where to find us. :)
0
