Bug 126940 - corrupt copy paste from base to calc containing russian symbols
Summary: corrupt copy paste from base to calc containing russian symbols
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected) release
Hardware: All Windows (All)
: medium normal
Assignee: Mike Kaganski
Whiteboard: target:6.4.0
: 39124 130434 (view as bug list)
Depends on:
Reported: 2019-08-15 11:03 UTC by Dmitry Mikhailov
Modified: 2020-02-10 17:42 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

screenshots (65.29 KB, application/x-zip-compressed)
2019-08-15 11:03 UTC, Dmitry Mikhailov
test base (11.25 KB, application/vnd.sun.xml.base)
2019-08-15 11:13 UTC, Dmitry Mikhailov
copy paste db records (66.04 KB, image/png)
2019-08-15 11:39 UTC, Oliver Brinzing
screenshot (129.52 KB, image/jpeg)
2019-08-15 12:21 UTC, Dmitry Mikhailov
screenshot (130.31 KB, image/jpeg)
2019-08-15 12:30 UTC, Dmitry Mikhailov
screenshot (147.01 KB, image/jpeg)
2019-08-15 13:15 UTC, Dmitry Mikhailov

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Mikhailov 2019-08-15 11:03:19 UTC
Created attachment 153406 [details]

1. create any table with varchar field.
2. add any new records with russian symbols
3. copy entire table (or any query of it)
4. paste it to the calc table

way to get around this problem is to save calc table in csv format using CP1252 code page and then reopen it with CP1251 codepage
Comment 1 Dmitry Mikhailov 2019-08-15 11:13:29 UTC
Created attachment 153407 [details]
test base
Comment 2 Oliver Brinzing 2019-08-15 11:39:42 UTC
Created attachment 153409 [details]
copy paste db records

i cannot reproduce with LO and attached test.odb:

- open test.odb
- select Tables -> test
- select all & copy
- open new spreadsheet & paste
Comment 3 Dmitry Mikhailov 2019-08-15 12:21:28 UTC
Created attachment 153412 [details]

I see no difference but another locale
Comment 4 Dmitry Mikhailov 2019-08-15 12:30:42 UTC
Created attachment 153413 [details]

changing locale doesn't affect behavior
Comment 5 Dmitry Mikhailov 2019-08-15 13:15:18 UTC
Created attachment 153414 [details]

change the system locale settings for Java from German to Russian

Click Start, then Control Panel
Click Clock, Language and Region
Windows 10, Windows 8: Click Region 
The Region and Language options dialog appears.
Click the Administrative tab
Under the Language for non-Unicode programs section, click Change system locale and select russian language.
Click OK
Restart the computer to apply the change.
Comment 6 Mike Kaganski 2019-08-15 13:39:08 UTC
Confirmed with Version: (x64)
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded

Using Paste as HTML produces normal paste.
The problem seems to be is that when current system language for non-unicode applications is Russian, the *copy* code in Base produces RTF clipboard content that uses short character codes (not Unicode) to encode characters in current locale charset (like {\ql\fs20\f1\cf0\cb1 \'f1\'f3\'ed\'f3\'eb \'e3\'f0\'e5\'ea\'e0 \'f0\'f3\'ea\'f3 \'e2 \'f0\'e5\'ea\'f3\cell}), and at the same time, does not set any default charset information; then on paste (using RTF by default), the RTF import code treats the no-default-charset RTF as Win1252.
Comment 7 Mike Kaganski 2019-08-15 19:06:34 UTC
Comment 8 Commit Notification 2019-08-16 06:02:22 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":


tdf#126940: export ansicpg in RTF when copying database

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 9 Mike Kaganski 2019-08-16 06:12:26 UTC
*** Bug 39124 has been marked as a duplicate of this bug. ***
Comment 10 Ming Hua 2020-02-10 17:42:23 UTC
*** Bug 130434 has been marked as a duplicate of this bug. ***