Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Evernote] Internal Evernote note links are not converted to Obsidian Links #653

Open
AltoRetrato opened this issue Oct 3, 2024 · 7 comments

Comments

@AltoRetrato
Copy link

After importing from Evernote into Obsidian, links for notes point to evernote:///view/[...] instead of being converted to Obsidian links.

In my case, a quick search in Obsidian for "evernote:///view/" showed 1.277 results...

Obsidian 1.6.7, Yarle 6.15.1, Windows 11.

@akosbalasko
Copy link
Owner

Hi @AltoRetrato ,
Could you pls share the config that you used? And the version of Evernote you use for export. Thanks a lot!

@AltoRetrato
Copy link
Author

Evernote 10.107.3-win-ddl-public (20240924143738) - Editor: v179.3.0 - Service: v2.11.0

Yarle config (renamed to JSON to be able to upload it here):
yarle_20241003_185804.config.json

Thanks!

@akosbalasko
Copy link
Owner

@AltoRetrato ,
And the log itself about the execution pls.
thank you!

@AltoRetrato
Copy link
Author

AltoRetrato commented Oct 4, 2024

I did not save the log after the first conversion and couldn't find it saved anywhere, so I converted everything again using all default configuration values. Since I used the defaults (which include "keepEvernoteLinkIfNoNoteFound": false), there are no more evernote:///view/[...] links. However, I still have incorrect internal links that point to non-existing notes.

It seems the main issue is that, in Evernote, the note links (e.g., <a href="evernote:///view/aaaaaaa/bbb/cccccccc-cccc-cccc-cccc-cccccccccccc/dddddddd-dddd-dddd-dddd-dddddddddddd/">Evernote alternatives</a>) use a note ID that is not included in the note attributes within the exported .enex files. Therefore, any program relying solely on the data in the .enex files can only "guess" which note to link to based on the text inside the anchor tag, which is not necessarily the actual name of the note it points to. When the link text matches the note name, the link works correctly; otherwise, it either points to a wrong note or to a non-existing one.

The only real solutions to this issue I can think of seem to be:

  • Having Evernote modify its software to include note IDs in the .enex files, and addressing other issues as well, such as exporting the correct note titles instead of defaulting to "Untitled Note" (I have 46 such cases in my .enex files, even though they are correctly named in the program).
  • Using the Evernote API instead of .enex files to convert the data to Markdown.
  • Reading data directly from the Evernote local databases

EDIT: a quick Python script to analyze the vault produced:

Results
  Scanned notes         : 2,965
  Empty notes           : 0
  Internal links        : 7,827
  Invalid internal links: 1,009

@akosbalasko
Copy link
Owner

Hi @AltoRetrato ,
Thanks for the details and insights, yeah, your conclusion is 100% correct. I checked 2/3 of the proposed solutions months and years ago, but unfortunately non of them can be achieved:
"Having Evernote modify its software" - it's a closed company, feature request can be raised (as far as I remember I did it so, years ago), but there is no quarantee that anything will happen anytime.
"API" - it's closed for newcomers too, I cannot have access to Evernote via API.

"Reading data" - that's a good point, I try to check it out soon.
Thank you!

@AltoRetrato
Copy link
Author

https://github.com/vzhd1701/evernote-backup uses the Evernote API to do a full local backup of notes and notebooks in a SQLite DB, including the guid of each note and notebook. I'll later write a script to export from that DB to Markdown.

A kind of hack-ish alternative would be to use the Evernote web API to get the same data.

@AltoRetrato
Copy link
Author

FWIW, I requested API access and receive my key in about 48 hours.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants