Import from SplashID 7.2.5 to 1Password v5

JFitness
JFitness
Community Member

Hi,

I want to trial 1Password ad SplashID doesn't have a free option to sync across multiple devices but I can't find any info about importing in to 1Password 5 for iOS8.

V4 instructions refer to an Import option but I can't see anything in v5.

Please advise.

Comments

  • JFitness
    JFitness
    Community Member

    Right, I've now installed 1password 4 on my Win8.1 laptop so have the import option. But 1password can not see my SplashID export.

    SplashID export is v3 as required and encoding is utf-8. File is saved to my desktop. When I import from 1password it can't see that file on my desktop. "All files" is selected and it can see all other files and folders. File extension of SplashID export is .vid.

    Any suggestions?

  • Hi @JFitness‌

    1Password for iOS does not have import capabilities. Either our Mac or Windows product would be required to perform an import from a 3rd party product.

    The Mac documentation for this can be found here:

    And the Windows documentation can be found here:

    Please let us know how it turns out. Thanks!

    Ben

  • Vassilis Dimarelos
    Vassilis Dimarelos
    Community Member
    edited October 2014

    I am another user of SplashID now testing the trial version of 1Password 5 for Mac. I followed your guide but the import process fails. Not one password can be imported after the .vid file is correctly named and saved as UTF 8. Any ideas?

    PS: I post this to the iOS thread, but I am using the Mac version of your program.

  • Stephen_C
    Stephen_C
    Community Member

    @MrC‌ is the expert on import and has written some invaluable importers for 1P. I'm sure he'll be along soon to tell you where you can pick up a copy of the relevant one.

    Stephen

  • MrC
    MrC
    Volunteer Moderator

    Hi @Vassilis Dimarelos,

    Let's see if we can get you further along. This conversion utility might work for you.

  • Vassilis Dimarelos
    Vassilis Dimarelos
    Community Member

    Thank you for the help! Your conversion utility worked fine with my splashID data file and minimal record cleaning is required. However, some records in Greek did not transfer correctly, although I saved the original splashID file in UTF-8 format. Anyway, this is a minor issue. Thanks again and I hope your work become part of the 1Password app.

  • Thanks for the update Vassillis, and the for assist @MrC!

  • MrC
    MrC
    Volunteer Moderator

    Good to hear you made progress.

    However, some records in Greek did not transfer correctly, although I saved the original splashID file in UTF-8 format.

    If you could get me a sample entry or two that contain Greek, that failed to convert correctly, I'll take a look at the converter. You could just create two records, and export those two into a VID file.

  • Vassilis Dimarelos
    Vassilis Dimarelos
    Community Member

    Here is a .vid file with a couple of records that contain Greek letters. https://www.dropbox.com/s/b2cqcwk8rzg4l9m/records.vid?dl=0

  • MrC
    MrC
    Volunteer Moderator
    edited October 2014

    Thanks for the sample records. Can you tell me which version of SplashID these came from, and what your process was for converting to UTF8? The converter is expecting the MacRoman encoding, so this is why rhe Greek Unicode symbols are being mangled.

  • MrC
    MrC
    Volunteer Moderator
    edited October 2014

    I spent a little time investigating this problem with your Greek characters. It turns out your sample data helped me to fix a bug in the converter, for a case which I wasn't aware could happen (if you didn't see error output from the converter, your data didn't trigger the problem, so no worries).

    Here's the problem with SplashID - it seems unable to make up its mind as to which encoding to use. It normally uses MacRoman, and will do so, provided there are no characters larger than those supported by MacRoman. But here's where things go horribly wrong. It upgrades to UTF-8 when necessary, but only for those records that require it. Other records remain in MacRoman. This is horribly broken, as a file needs to be in a single encoding format - and the SplashID chimeric CSV export is not only non-standard, but broken by design because it arbitrarily switches encoding on a per-row basis.

    I can add a command line option to allow you to select the encoding you desire, since most customer's data would likely not contain too many of the special characters in MacRoman (see the special characters values 128 and above here: http://en.wikipedia.org/wiki/Mac_OS_Roman). The converter can default to MacRoman as it does now, and you could override it to use UTF-8 and then only the few special MacRoman characters you might have would be botched.

    Feedback anyone?

  • I used SplashID 7.2.1 and I saved the file to UTF-8 by opening it in TextEdit (Yosemite).

    I surely can't help you with technical details, but what if the converter used only the UTF-8 format for all splashID files? Wouldn't that solve the issue with non English records?

  • MrC
    MrC
    Volunteer Moderator

    Thanks Vassilis,

    The converter could choose to use UTF-8 for all, but then conversion would be wrong from some other subset of users, so a user has to pick his poison. The SplashID export is simply ambiguous. It is not clear to me how well SplashID handles its own imports under such circumstances, but if it does handle the data correctly, it is because it examines each row of data and looks for key encoding characters. This is not something I can easy change, as the converter relies on a CSV module to read the row, and that row-reading code does the decoding (I specify the character encoding, and it is static). And just converting your SplashID export file to UTF-8 won't take care of converting the MacRoman characters into UTF-8 Unicode.

    You could try updating your SplashID if you care, but I think you are already done. SplashID needs to update their VID output file to be a single encoding, preferable UTF-8 or UTF-16.

This discussion has been closed.