Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug.
On the other hand, it seems you're using an old version of LibreOffice.
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.

Created attachment 131367 [details]
Sample file containing UTF-8 text with CRLF newlines

To trigger the bug correctly, open this file with a text editor capable of maintaining both the UTF-8 encoding and the CRLF newline style. Copy the contents and paste them into any Calc cell to open the text import window. You can also see the difference in encoding detection if you try to open the file from Calc, and you see the text import window but with the data coming from a file instead of from the clipboard.

Yes, I noticed I was a bit behind in updating while filing the bug report. I updated to last stable 5.2.5.1 (I've had a few probs with fresh releases so I stick to stable ones), reproduced the bug again, and added a sample text.

I changed the version number and the status to unconfirmed until someone else can reproduce the bug.

Note that the bug only triggers when pasting the text from the clipboard, not when importing from a file, which I find weird.

Reproduced.

Tried with v. 3.6, but it does not separate the utfs, only says "Unicode".

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha0+
Build ID: ed0e8f970ff552e75222dc92ed2879aa3b3e5851
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on March 4th 2016

I tried with 5.4.7_Win_x64 with the attachment I made a year ago, ANSI encoding with Windows CRLF endlines.

The results are the same, the bug is still there. Incorrect detection of the encoding, even if there are no characters that can be interpreted as UTF-16.

Note that the extra added empty lines are shown only in the import panel; if applying the import, the text is imported correctly. It's only in the import panel where the problem lies. However as I said in my initial bug report, working with characters beyond the 7-bit ASCII gave me problems with importing, and rendered strange characters, so it's not only a cosmetic bug. There's something wrong in the detection of the encoding, and in how LibreOffice reencodes such text for internal usage.

Are you really sure that the encoding is different from UTF-16 without CRLF and with CR or LF oly?

https://opengrok.libreoffice.org/xref/core/sc/source/ui/dbgui/scuiasciiopt.cxx?r=a5c04cbf#380

https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/viewfun5.cxx?r=18a8cac5#346

It looks to me that these code suggests, regardless of Whatever encoding and line-separator we use, pasting will open dialog with UTF-16 set as encoding.

It also looks to me whatever encoding you use on your text editor doesn't affect in what encoding Windows stores string data to its clipboard.

typo: oly => only

I have tried the attached text with NotePad++, NotePad, PSPad and with Wordpad. All of them put more than one type into the clipboard. The type "Unicode Text Format" is provided by all of these apps. That is UTF-16. Then I have changed the line ends to LF. Again copying results in a type "Unicode Text Format" in the clipboard. If LibreOffice takes this clipboard flavor, the selection UTF-16 in the dialog is correct.

I have used "Free Clipboard Viewer 3.0" to examine the clipboard.

Do you have got an application, which does not put "Unicode Text Format" into clipboard?

Hmm, it's true that there is something weird about the attachment. Linux command "file" says:
sample utf-8 crlf text.txt: ASCII text, with CRLF line terminators

However, Kate editor opens it as UTF-8.

If I use the program enca like this:
enca -L none sample.txt

It says:
7bit ASCII characters
  CRLF line terminators

>sample utf-8 crlf text.txt: ASCII text, with CRLF line terminators
However, Kate editor opens it as UTF-8.

If all the characters are in U+0000 to U+00FF, US-ASCII and UTF-8 are completely identical. so there is nothing strange in this behavior.

I suggest to close it NOTABUG. This is something about wrong expectations. OP expects that when pasting, the text has the same encoding as when it's copied in original program. But that's incorrect, as himajin100000 and Regina rightfully note in comment 7 and comment 9. The expectation that changing UTF-16 to UTF-8 on paste (step 5 in comment 0) would result in "correct" behaviour is also wrong, and step 6 shows that. The bottom line in the description was:

> If you don't touch anything and the text doesn't include any UTF-8 character
> combinations which translate to an UTF-16 character, nothing happens.
> However until I noticed this problem, sometimes I had strange characters in
> my text imports, which might have been caused by this problem. I can't provide
> any specific text string to trigger that problem but I am pretty sure it exists.

... which is mixing two completely unrelated things: OP has some unspecified problem, and suspects that it has something with the observed inconsistencies between OP's expectations and the correct behaviour. The real problem is completely unrelated.

Thanks, let's close