The reason this occurs for handsontable (and not most other apps) is that handsontable is doing a .replace(/\x20/gi, ' ')
in function _dataToHTML(input)
.
This function creates an html representation of the data for placement on the clipboard, and is called only during onCopy
and onCut
(instanceToHTML(instance)
is called to generate html for the browser representation of the data).
You could argue that only \xA0
should be replaced with a
, or perhaps neither should be. I think it’s harder to argue for replacing \x20
, even though it makes sense in the context of generating a browser representation of the data.
If you look at the documentation for both \x20
and \xA0
, you’ll see the html representation of the former is NOT
I believe the correct code would be to replace line:
var parsedCellData = (0, _mixed.isEmpty)(cellData) ? '' : cellData.toString().replace(/</g, '<').replace(/>/g, '>').replace(/(<br(\s*|\/)>(\r\n|\n)?|\r\n|\n)/g, '<br>\r\n').replace(/\x20/gi, ' ').replace(/\t/gi, '	');
with
var parsedCellData = (0, _mixed.isEmpty)(cellData) ? '' : cellData.toString().replace(/</g, '<').replace(/>/g, '>').replace(/(<br(\s*|\/)>(\r\n|\n)?|\r\n|\n)/g, '<br>\r\n').replace(/\t/gi, '	');
Sending spaces in their original text representation (whether it be \xA0 or \x20) allows Excel and other apps to resolve the html to a regular space in its target representation. The only difference seems to be Excel turns on cell wrapping if it’s a regular space. This is acceptable, and probably desirable in most cases.