Desktop: Resolves #6570: Fixed broken image links #6590
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Tests fails when there are ASCII characters in paths.
laurent22
reviewed
Jun 26, 2022
|
Thanks for the fix! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #6570.
When using the WYSIWYG editor, full paths to images are encoded using the
encodeURIfunction. Non-ASCII characters contained in the path are changed. By example,ébecomes'%C3%A9'. If changes are made using the WYSIWYG editor, image paths must be translated back to joplin resource id when the note is saved. The translation is using regex to find paths to resources in the note and then translate them.However, there is an issue if the path contains non-ASCII characters. The regex tries to match a path not encoded with
encodeURI, thus it will not match resources paths. For instance, it will try to find path containingécharacter, but the note contains a path with'%C3%A9'. Thus the link will not be translated back. If the note is synchronized to another device, the link will not be valid.This was fixed by encoding the paths with
encodeURIbefore the matching. Note that I replaced themarkdownUtils.escapeLinkUrlwhich was used to encode spaces. It works becauseencodeURIalso encodes spaces.markdownUtils.escapeLinkUrlalso encodes parenthesis, but I don't think it is useful in this case.