Openlibrary: Исправить названия книг с искаженным Unicode

Обе эти записи были получены с сайта archive.org.

Я просмотрел файлы _marc.xml на archive.org. Время последнего изменения обоих файлов marc.xml - 2007 год, а эти повторные роды были созданы в 2008 году. Похоже, проблема связана со сценарием, который анализировал эти заголовки.

Существуют тысячи записей импорта 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 правильно отображается в браузере.

Стоит ли рассматривать повторный импорт? И является ли № 149, который также ссылается на https://bugs.launchpad.net/openlibrary/+bug/598204 , зависимостью?

Некоторые из них я нашел недавно: https://openlibrary.org/works/OL17670297W
https://openlibrary.org/works/OL17677126W
несколько работ этого автора:
https://openlibrary.org/authors/OL2450531A/Matthieu_Joseph_Bonaventure_Orfila

https://openlibrary.org/search?q=title%3A+%22 © ♭% 22 & mode = everything По-прежнему находит более 17 миллионов совпадений. Это для "é", вероятно, самая распространенная буква с ударением. Редактирование вроде 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 не обязательно должно выполняться вручную.

@hornc re вашего комментария от 8 мая, эти работы были созданы из редакций, созданных при импорте
https://openlibrary.org/show-records/ia : b28044277_0001
и
https://openlibrary.org/show-records/ia : b2202010x
Пока они не будут исправлены в записях ia MARC, повторный импорт не имеет смысла, если импорт не прошел через нормализацию.

@LeadSongDog интересно, отображение MARC, на которое вы перейдете к XML-представлению https://ia800202.us.archive.org/34/items/b28044277_0001/b28044277_0001_marc.xml, подчеркнутое e отображается правильно . Может быть проблема с неверно заданными типами кодировки? Я скоро подойду об этом, новый клиент openlibrary сейчас находится в состоянии, когда его можно использовать для внесения массовых исправлений в данные.

@LeadSongDog Возможно, я понял, как происходит искажение, в этом примере marc xml
https://ia600208.us.archive.org/25/items/b2202010x/b2202010x_marc.xml

a-grave "Secours à donner" правильно отображается в кодировке utf-8

a-grave - это U + 00E0, что в двоичной (питонической нотации) равно \xC3\xA0

если эти байты были интерпретированы как MARC8 и «преобразованы», C3 становится символом авторского права, а 'A0' становится пробелом, что мы и видим на страницах OL с помощью «Secours © donner»

Теперь я думаю, что эти записи MARC имеют кодировку символов utf-8, но были импортированы в OL, как если бы они были MARC8, что объясняет искажение.

Я выполнил преобразование MARC8 вручную из таблиц, найденных здесь https://memory.loc.gov/diglib/codetables/45.html. Мне нужно будет использовать yaz или что-то еще, чтобы проверить это должным образом, но это обеспечит хороший путь для программного исправления ошибок MARC.

Я знаю, что есть другие ошибки искажения Unicode, влияющие на импортированные записи Amazon, но я думаю, что это из-за неправильного преобразования из кодировок Windows или ISO.

Спасибо за ваш комментарий @LeadSongDog , пытаясь выяснить, действительно ли записи MARC были неправильными или нет, я думаю, что наткнулся на основную причину проблемы!

@hornc есть ли обновления по

Вопрос точно не решен. Когда сценарий импорта исправлен, скорее всего, потребуется @bfalling, предлагающий

С точки зрения сортировки, вероятно, было бы полезно получить фактическое количество. «Тысячи» - не очень большой процент от 25 миллионов изданий.

Была ли эта проблема решена с помощью наших изменений Python 3 или кто-нибудь может предоставить инструкции по воспроизведению на Python 3?

Что ж, https://openlibrary.org/books/OL12903648M/Etudes_Conomiques_De_L 'Окде, конечно, не исправлено, но, возможно, мы закончили копать яму ...
Было как минимум три класса проблем:

1. Плохой импорт хороших данных
2. Буквальный импорт неверных данных
3. Имеются неверные данные из старых случаев 1 или 2, которые были устранены.
   Переход на py3 не более чем исправит номер 1.

Шаги по воспроизведению класса проблемы 1?

Предыдущие примеры лучше, чем самый последний, который является импортом из дрянных данных Amazon (которые нам не следует импортировать).
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_moyens%E2%99%ADes_suivis_des_moyens_propres9

Если ошибка была исправлена, повторный импорт записей должен привести к правильной кодировке. Тогда задача просто сводится к повторному импорту миллионов поврежденных записей.

Поиск, который, как утверждалось, ранее возвращал более 17 миллионов записей: https://openlibrary.org/search?q=title%3A+%22%C2%A9%E2%99%AD%22&mode=everything
теперь возвращает 23,4 млн результатов, но я думаю, что на самом деле это отдельная ошибка, и он просто возвращает все работы в базе данных.

@tfmorris Поскольку https://openlibrary.org/search?q=title%3A+%22+%22&mode=everything дает тот же результат, похоже, что да, это простой случай поиска заголовка по фактически пустой строке.

Я создал # 4223 для ошибки поиска.