此问题已在 ol-tech 邮件列表中报告。
I don't know how widespread this problem is, but I noticed that these
two records have messed up book titles, but if you click through to
the associated MARC records on IA, the titles get rendered correctly.
http://openlibrary.org/books/OL7155555M/The_M%C2%A9%C3%98alavik%C2%A9%C3%98agnimitra
http://openlibrary.org/books/OL7165183M/The_Vikramorva%C2%A9%C3%98s%C2%A9%C4%90iyam
anandology
所有16条评论
这两个记录都来自archive.org。
我查看了 archive.org 上的 _marc.xml 文件。 marc.xml 文件的最后修改时间是 2007 年，这些记录是在 2008 年创建的。看起来问题出在解析这些标题的脚本上。
anandology
于 2012-01-23
有数以千计的 MARC 导入记录，其中重音字符已被错误处理或处理不正确。 另一种常见情况是重音或其他变音符号已被元音前后的空格替换。
见例如：
http://openlibrary.org/authors/OL4459814A/Heinrich_Schro_der
http://openlibrary.org/works/OL10684450W/Tonbandgera_te-Messpraxis
http://openlibrary.org/show-records/talis_openlibrary_contribution/talis-openlibrary-contribution.mrc :299045317:529
在作者和书名中，元音后的元音变音都变成了空格。 链接的 MARC 记录在浏览器中正确显示。
amillar503
于 2012-06-04
我们应该考虑重新进口吗？ 并且是#149，它也引用了https://bugs.launchpad.net/openlibrary/+bug/598204 ，一个依赖项？
bfalling
于 2016-09-22
我最近发现的一些： https :
https://openlibrary.org/works/OL17677126W
该作者的多部作品：
https://openlibrary.org/authors/OL2450531A/Matthieu_Joseph_Bonaventure_Orfila
hornc
于 2017-05-08
https://openlibrary.org/search?q=title%3A+%22 ©♭%22&mode=everything 仍然可以找到超过 1700 万个匹配项。 这表示“é”，可能是最常见的重音字母。 像https://openlibrary.org/books/OL26303038M/Anatomie_générale_appliquée_à_la_physiologie_et_à_la_médecine?b=3&a=1&_compare=Compare&m=diff这样的编辑不一定是手动的。
LeadSongDog
于 2017-10-30
@hornc 是您 5 月 8 日的评论，这些作品是根据导入创建的版本创建的
https://openlibrary.org/show-records/ia :b28044277_0001
和
https://openlibrary.org/show-records/ia :b2202010x
在 ia MARC 记录中修复它们之前，重新导入没有任何价值，除非导入使它们通过规范化
LeadSongDog
于 2017-11-01
@LeadSongDog有趣的是，您链接到的 MARC 显示显示的字符是乱码，但是如果您点击 XML 表示https://ia800202.us.archive.org/34/items/b28044277_0001/b28044277_0001_marc.xml重音 e's 显示正确. 编码类型设置不正确可能有问题？ 我很快就会拿起这个，新的 openlibrary-client 现在处于可以用来进行批量数据更正的状态。
hornc
于 2017-11-03
@LeadSongDog我可能已经弄清楚了重整是如何发生的，在这个例子中是 marc xml
https://ia600208.us.archive.org/25/items/b2202010x/b2202010x_marc.xml
"Secours à donner" 的墓志铭以 utf-8 编码正确显示
a-grave 是 U+00E0，在二进制（pythonic 符号）中是\xC3\xA0
如果这些字节被解释为 MARC8 并“转换”，则C3成为版权符号，而 'A0' 成为一个空格，这正是我们在带有“Secours © donner”的 OL 页面上看到的
我现在认为这些 MARC 记录具有 utf-8 字符编码，但被导入到 OL 就好像它们是 MARC8，这解释了重整。
我从这里找到的表格中手动进行了 MARC8 转换https://memory.loc.gov/diglib/codetables/45.html我需要使用 yaz 或其他东西来正确测试它，但这将提供一个很好的路径以编程方式修复 MARC 错误。
我知道还有其他 unicode mangling 错误会影响 Amazon 导入的记录，但我认为这是从 Windows 或 ISO 字符集的错误转换造成的
感谢您的评论@LeadSongDog ，在试图弄清楚 MARC 记录是否真的错误时，我想我偶然发现了问题的根本原因！
hornc
于 2017-11-04
@hornc关于 MARC mangling 的任何更新和/或我们是否解决了这个问题？
mekarpeles
于 2018-03-13
问题肯定没有解决。 当导入脚本修复后， @bfalling建议重新导入很可能是必要的。
从分类的角度来看，获得实际计数可能会很有用。 “数千”在 2500 万个版本中所占的比例并不是很大。
tfmorris
于 2018-03-14
这是否通过我们的 Python 3 更改解决了，或者有人可以在 Python 3 上提供重现步骤吗？
cclauss
于 2020-12-06
好吧https://openlibrary.org/books/OL12903648M/Etudes_Conomiques_De_L 'Ocde 肯定不是固定的，但也许我们已经完成了挖洞......
至少有三个问题类别：
- 好数据的错误导入
- 不良数据的字面导入
- 自修复以来，旧案例 1 或 2 中的不良数据就位。
迁移到 py3 最多只能修复数字 1。
LeadSongDog
于 2020-12-06
重现问题类别 1 的步骤？
cclauss
于 2020-12-06
较早的示例比最近的示例要好，后者是从糟糕的亚马逊数据（我们不应该导入）中导入的。
https://openlibrary.org/books/OL7165183M/The_Vikramorva%C2%A9%C3%98s%C2%A9%C4%90iyam
https://openlibrary.org/authors/OL4459814A/Heinrich_Schro_der
https://openlibrary.org/books/OL13956174M/Tonbandgera_te-Messpraxis
https://openlibrary.org/books/OL26280693M/Secours_%C2%A9_donner_aux_personnes_empoisonn%C2%A9%E2%99%ADes_ou_asphyxi%C2%A9%E2%99%ADes_suivis_des_moyens2%C%ArecConnat
如果错误已修复，重新导入记录应该会产生正确的编码。 然后任务就变成了重新导入数百万条损坏的记录。
之前声称返回 17+ 百万条记录的搜索： https ://openlibrary.org/search?q & mode
现在返回 2340 万个结果，但我认为这实际上是一个单独的错误，它只是返回数据库中的所有作品。
tfmorris
于 2020-12-06
@tfmorris由于https://openlibrary.org/search?q=title%3A+%22+%22&mode=everything得到相同的结果，似乎是的，这是标题搜索有效空白字符串的简单情况。
LeadSongDog
于 2020-12-06
我为搜索错误创建了 #4223。
tfmorris
于 2020-12-07
相关问题
BrittanyBunk
·
4评论
BrittanyBunk
·
4评论
cdrini
·
5评论
Pratyush1197
·
3评论
cdrini
·
4评论