Skip to content

Conversation

@michal-kurz
Copy link

No description provided.

Resolvesgoogle#69 for JavaScript Sometimes we can find a common prefix that runs into the middle of a surrogate pair and we split that pair when building our diff groups. This is fine as long as we are operating on UTF-16 code units. It becomes problematic when we start trying to treat those substrings as valid Unicode (or UTF-8) sequences. When we pass these split groups into `toDelta()` we do just that and the library crashes. In this patch we're post-processing the diff groups before encoding them to make sure that we un-split the surrogate pairs. The post-processed diffs should produce the same output when applying the diffs. The diff string itself will be different but should change that much - only by a single character at surrogate boundaries.
I'm not sure that I made the right assumptions about Python3's Unicode handling when I made the first patch to it. By constructing the specific `diffs` output I created a sequence of code units that `diff_main` in Python3 would _not_ have made because it's operating on Unicode code points natively when finding the common prefix. Therefore I do not think that the Python3 library experienced this problem as the others did. Nonetheless it _has_ been reporting the diff length differently than in other languages and I have left that change in there. Of note, it doesn't look like we have true harmony between the languages despite the appearance of such. The `lua` wiki page makes this clear, but at least with Python we have the ability to harmonize the meaning of the lengths and I have done that in this change.
```bash java \ -jar path/to/closure-compiler-v20191027.jar \ --js_output_file=diff_match_patch.js \ diff_match_patch_uncompressed.js ```
In the previous iteration of this patch we were only properly handling cases where a new surrogate pair was inserted in between two existing pairs whose high surrogates all matched. Unfortunately when swapping characters or performing any edits where we delete a surrogate pair the patch failed because it only carried the trailing high surrogate over to the next group instead of distributing it to any insert _and_ delete groups following an equality group. In this patch I've updated the JavaScript library to properly distribute the trailing high surrogate.
…lves Because sometimes we get a patch that was built in Python or another library that will happily URI-encode half of a surrogate pair.
There's no need to validate the entire range of input integers. Using `digit16()` will be faster and give us more precise validation.
Python can be compiled in "narrow" mode or "wide" mode which determines how wide the internal string units are. In narrow mode we have UCS-2 code units and higher-order Unicode code points will be stored as surrogate pairs. In wide mode we have UCS-4 code units and so all Unicode code points will be stored as a single item in the string. This patch incorporate a decision based on the internal string width to run the native-looking `toDelta` or the _encoded_ version. In the _encoded_ version we explicitly encode the string to `utf-16be` for consistency sake with the other libraries. We _could_ always run the encoded version but I suspect that the native version will be faster and many deployments will be running narrow mode.
In testing with `speedtest.py` I found no significant performance impact for running the "native" narrow-mode `toDelta()` compared to running the fully-encoding version that operates on bytes. For the sake of simplicity I'm removing the narrow version.
@michal-kurzmichal-kurzforce-pushed the fix-surrogate-pairs-in-text-fns branch from 254688b to cab92fcCompareOctober 4, 2022 23:03
overwrittenDiffsCounter++;
}

returndiffs.splice(0,overwrittenDiffsCounter)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you help me understand what's going on here with overwrittenDiffsCounter? at a glance it looks like we're overwriting the diff operations starting at the first one and then removing those all at the end.

in my head this should be scanning through the array and potentially modifying the current and previous diff objects, but not removing the front of the list of them.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if it's not easy to do this in-place then I suppose bringing back the array cloning, as you initially proposed, might be a practical solution 🤷‍♂️

@michal-kurzmichal-kurzforce-pushed the fix-surrogate-pairs-in-text-fns branch from cab92fc to 08e5792CompareOctober 4, 2022 23:53
@michal-kurzmichal-kurzforce-pushed the fix-surrogate-pairs-in-text-fns branch from d9948ae to 7751a1cCompareOctober 7, 2022 13:27
@michal-kurzmichal-kurzforce-pushed the fix-surrogate-pairs-in-text-fns branch from b441d1b to 0e8f62aCompareOctober 9, 2022 19:36
@dmsnell
Copy link
Owner

@michal-kurz I left some feedback in one of your merged PRs about checking for string input on isHighSurrogate and isLowSurrogate. I'll wait to do more here until giving you a chance to think that over. I wish I had more focus time to dedicate to this and so I hope I'm being helpful enough in the meantime.

@dmsnelldmsnellforce-pushed the issues/69-broken-surrogate-pairs branch from d681ef6 to 50f1542CompareJanuary 30, 2024 23:54
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@michal-kurz@dmsnell