Unhandled special cases for internal note link conversion

[bumper314]

I've found some special cases where internal note links were not correctly updated by YARLE. This is because YARLE looks for an exact match to an internal link, yet there are special cases where that's not true. This isn't YARLE's fault, but YARLE can be updated to handle these cases which may help a lot of people, because it's infeasible for people to find/fix these links inside Evernote.

Anatomy of an Internal Link

A standard internal note link looks like evernote:///view/<user id>/<shard>/<guid>/<guid>/ where:

• user id is a number like 7189201
• shard is the character 's' + a number like "s181"
• guid is a uuid like 05e6d963-1010-486c-9ccf-191aed2dabb9

For example: evernote:///view/7189201/s181/05e6d963-1010-486c-9ccf-191aed2dabb9/05e6d963-1010-486c-9ccf-191aed2dabb9/

NOTE: The trailing slash is critical, the link will not work on Evernote 7.x for Mac without it.

ASIDE: I don't know why the guid is repeated, but I have experimented extensively with modifying these internal links to see what makes them tick and found it's highly dependent on the client version. For example, Evernote 7.2.3 on Mac will accept evernote:///view/<any number>/s<any number>/<guid>// (notice the second guid is removed, and the user id and shard are modified, but the trailing slash must remain). However, this link fails on Evernote 6.25.3 on Windows and Evernote 8.13.3 on Android.

The point is, it's possible for mal-formed internal note links to make it into notes, which work perfectly fine in Evernote, but trip of YARLE during conversion.

Special Cases

1. Internal links with bad User IDs

Evernote 6.8 had a bug which where every link has a user id of 2147483647 (which you might recognize as the largest 32-bit positive signed integer). So half of my internal links are evernote:///view/7189201/… and half are evernote:///view/2147483647/…, even though they point to the same note. YARLE fails to properly convert the latter because it's trying to exactly match the former.

Suggestions:
The solution here is to parse all internal links and use some heuristics to identify equivalency. I see in internal-links-rule.ts that you're simply matching any link with the evernote:// schema as an internal link, then saving the whole note link to a map. This check can be made more robust by…

1. Check for evernote:///view instead of just evernote://, because there are other link types based on the evernote:// schema, such as when accepting an invite to a Shared notebook. At one time there was an evernote:///search schema as well.

2. Parse the link and take the first guid as the identifier for this note, then compare links solely by their guid. This might even be able to replace your usage of getUniqueId() based on nanoid, but I'm not familiar enough with your code.

These changes will also pave the way to implementing #487 😉

2. Internal link to notes in a shared notebook

Internal links to notes in a shared notebook often have a slightly different format, again, depending on the client version:

For example evernote:///view/<user id of the share owner>/<shard of the share owner>/<guid>/<guid>/<different guid>

I don't know where this third different guid comes from, and some clients are fine without it and don't produce it when you copy a note link. Again, the point is, YARLE will currently fail to convert this type of link, and the solution is the same as 1. above (i.e. match based on the first guid instead).

3. External Links that are actually Internal Links

Evernote 8.13.3 on Android often inserts "external" note links like https://www.evernote.com/shard/s181/nl/7189201/05e6d963-1010-486c-9ccf-191aed2dabb9/ instead of internal note links using the evernote:///view schema. These links behave exactly like Internal links (when you click them, they open that note in Evernote on Android), but they show up as blue links and open a browser on Evernote for Mac or Windows.

You might want to add a configurable option for converting these links, but just as with 1. above, it's easy to parse the link to identify it's a note link (as opposed to an https://www.evernote.com/forums links, etc.) and take the guid, which indeed matches the guid you would get for an evernote:///view link.