File>Import into current database> default still Windows 1252

[ajbelle]

JabRef version <3.2> on <Windows 7>

Steps to reproduce:

1. File>Import into current database> select 'utf8 encoded'.bib (Use the file you a viewing)
2. The import inspection dialog, and Possible duplicate entries so the imported file with coding corruption. eg: ° = ° ©=© “=“ ...
3. My guess is that the direct import has been changed from the OS default on the Window build to utf8, but when importing into the current database it is routing via the OS default encoding.
4. Reformatting the import.bib with text editor to CP1252 fixes the problem.

Possible relevant post are issue #262 @oscargus , UTF8 import from bib file , and #1080 ,but resolution is beyond me. There seem to have been edits here by @lenhard

Repeat: file opens fine, but File>Import into current database> or File>Import into new database> sees utf8 encoded file read as CP1252.

[Siedlerchr]

Maybe related? #1080

PS @ajbelle, when referencing issues/prs, just type # followed by the number instead of the full url

[ajbelle]

Yes quite possible @Siedlerchr, and that was one of the links (I have corrected them, THX). My impression is the 'issue' is not a coding bug, but is a systems level ommision or fault, but I am a non-programming user, so that is just my guess .

[koppor]

What is the encoding of the opened database? My guess is that it is CP1252 instead of UTF8.

Related #558.

[lenhard]

If you are using JabRef 3.2 then it cannot be caused by #1080 since this change is only available in the current development version.

[ajbelle]

Thank you @lenhard I am actually running JabRef_windows-x64_3_3dev--snapshot--2016-03-25--livesearch--55fc5f2 which exhibited the fault, but backloaded V3.2 and it is identical. I checked V2.1 and same problem. That is why I suspect it is an omisison in the Windows build that has been there for a long time. I didn't want to confuse my post that it is a development build bug.

Your point that it doesn't seem to be #1080 is valid.

[tobiasdiez]

It seems to be fixed in the current development version. Probably as a result of #1207. @ajbelle can you please double check that the issue is indeed fixed? Thanks!

[stefan-kolb]

This should be fixed in current master. Please try the latest build from http://builds.jabref.org/master.
Please reopen the issue with additional information if the problem persists.

[ajbelle]

Sorry Gents, too busy to help further beyond this post. @tobiasdiez I checked and I do not think anything has changed. Installed Ver3.4 just then, and saved my .bib file (no errors detected and very fast save). Then openned it with Ver2.1 and tried saving (takes a long time). It returned the same as my original report with rogue "#" being detected.

Due to the apparent time this checking takes it should be part of the |Quality>Clean up entries> menu option, if it is ever re-implemented IMHO.

[matthiasgeiger]

@ajbelle this comment is not really related to this issue, is it?

A general comment: We changed a lot of stuff in the last year, but opening files saved with version 2.X in a version 3.X should always be possible.
However, the other way round is NOT expected to be working - especially not if features like groups are used which are not part of "standard bibtex".

[ajbelle]

Yes @matthiasgeiger, you are right. The reason ver2.1 identified the issue was in #1188 which merged with this one. It picked it up when I openned my .bib with old ver2.1 install by mistake, making me think something was no longer being checked. As I said, ver2.1 takes a lot longer to save (bad) but may save future grief when BibTeX wont typeset (Good, especially with LyX that 'hides' BibTeX faults). The issue is not with retrospective compatibility, it is about current functionality. I personally will open in PDE and fix it, so it was purely a "does anyone on the team care/know about this" notification. @ tobiasdiez asked me to check and I did. I hope it helps work out what has been done. I will be offline for several months now.

[DesBw]

I am having this issue right now on a Mac. I imported a fairly large (3300 entries) library to it. I have waited for more than an hour. Jabref still on "saving database...".

I have to discard all the fixed I did.
Has anyone find a solution for this?

[matthiasgeiger]

Hi Dellu,
what exactly is your problem (as various things are discussed in this report)? And which JabRef Version are you using?

[DesBw]

I am using the latest version: 3.6. But, I now manage to fix it. The problem seems with the text encoding in Jabref. Importing UTF-8 library into the ISO-8859 format was causing the trouble, I guess. It is saving fine now.