I previously reported that even though it’s not documented anywhere and RefWorks support couldn’t tell me it, RefWorks had a problem importing UTF-8 including “decomposed” characters, and the solution was to apply Unicode Normalized Form C to your data before sending to RefWorks.
But it gets trickier. I can’t even begin to imagine how this can possibly be so, but my experiments seem to indicate…. while Refworks is normally fine with having an import callback URL be an https url…. for certain UTF-8 data (but not all UTF-8) data, if you normalize it first with NFC, then send it to Refworks import… it works if your callback URL is http, but not if your callback URL is https.
I seriously can’t even begin to imagine why this should make any difference to the RefWorks software. I am not happy with RefWorks right now.
Here’s the letter I just sent to RefWorks:
I determined, as you recall, that taking my UTF-8 data and applying Unicode Normalizing Form C to it generally makes it import properly.
Also, in general Refworks import can normally accept a ‘callback url’ that is https.
However, for some reason _certain_ (but not all UTF-8) data, even when put in NFC form, still causes Refworks to error — but only when the callback is https, not when it’s http.
I can think of no good reason https vs http ought to make any difference at all on your end.
Compare:
Works fine:
Produces Refworks error:
Other imports without diacritics work fine.
I know you guys in support can do nothing about this, but these undocumented RefWorks bugs are becoming increasingly frustrating and time-consuming for me, this is really unfortunate, and significantly increases our Total Cost of Ownership for Refworks.
Bibliographic Wilderness 