lookup failed for DOI

dwinston

I tried 10.1045/may2016-peng
My submitted debug output has Debug ID D734591064

Other Crossref DOIs (e.g. 10.7551/mitpress/11291.003.0008) seem to work fine.

link to crossref support thread -- all seems fine on their end: https://community.crossref.org/t/crossref-doi-not-loading-in-zotero/3246/4

adamsmith

Continued on the CrossRef forums for now. It is due to something weird (an improperly encoded unicode character) in their metadata and would be at a minimum tricky for us to fix.

dstillman

I think we can fix this. The character clearly shouldn't be there, but it's only failing because of some hacky bit of code added years ago using decodeURIComponent(escape()). I'm not sure why we did it that way? Why not just do item[field] = item[field].replace(/[\u0000-\u001F\u007F-\u009F]/g, "")?

adamsmith

As I recall it, decodeURIComponent(escape()) actually converts unicode escaped characters to the rendered character. Since we do with some frequency see escaped unicode in CrossRef data, we added that code.

And you can actually see that that's what's intended here:
The actual title is
Scientific Stewardship in the Open Data and Big Data Era — Roles and Responsibilities of Stewards and Other Major Product Stakeholders

so the dash belongs there, even though I assume it should be an em dash and not an "end of guarded area" character. In other cases, though, we actually need the escaped character to properly render the field.

dstillman

Ah, got it. Translation shouldn't just fail if it can't decode it, though, so it seems like we can just put a try/catch around that line and use the replace() line above? See #2959.