Openlibrary: Perbaiki judul buku dengan Unicode yang rusak

Kedua catatan ini berasal dari archive.org.

Saya telah melihat file _marc.xml di archive.org. Waktu modifikasi terakhir dari kedua file marc.xml adalah pada tahun 2007 dan rekaman ini dibuat pada tahun 2008. Sepertinya masalahnya adalah pada skrip yang menguraikan judul-judul tersebut.

Ada ribuan catatan impor MARC di mana karakter beraksen telah rusak atau ditangani secara tidak benar. Skenario umum lainnya adalah bahwa aksen atau tanda diakritik lainnya telah diganti dengan spasi sebelum atau sesudah vokal.

Lihat misalnya:

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

Baik pada pengarang maupun judul, umlaut diubah menjadi spasi setelah vokal. Catatan MARC yang ditautkan ditampilkan dengan benar di browser.

Haruskah kita mempertimbangkan untuk mengimpor kembali? Dan #149, yang juga merujuk https://bugs.launchpad.net/openlibrary/+bug/598204 , ketergantungan?

Beberapa yang saya temukan baru-baru ini: https://openlibrary.org/works/OL17670297W
https://openlibrary.org/works/OL17677126W
beberapa karya oleh penulis ini:
https://openlibrary.org/authors/OL2450531A/Matthieu_Joseph_Bonaventure_Orfila

https://openlibrary.org/search?q=title%3A+%22 ©♭%22&mode=everything Masih menemukan lebih dari 17 juta kecocokan. Ini untuk "é", kemungkinan huruf beraksen yang paling umum. Pengeditan seperti 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 tidak harus manual.

@hornc kembali komentar 8 Mei Anda, karya-karya itu dibuat dari edisi yang dibuat dari impor
https://openlibrary.org/show-records/ia :b28044277_0001
dan
https://openlibrary.org/show-records/ia :b2202010x
Sampai mereka diperbaiki dalam catatan MARC ia, tidak ada nilai dalam mengimpor ulang kecuali impor membuat mereka melewati normalisasi

@LeadSongDog menarik, tampilan MARC yang Anda tautkan untuk menunjukkan karakter yang kacau, tetapi jika Anda mengklik representasi XML https://ia800202.us.archive.org/34/items/b28044277_0001/b28044277_0001_marc.xml tampilan e beraksen dengan benar . Mungkin ada masalah dengan jenis penyandian yang tidak diatur dengan benar? Saya akan mengambil ini segera, klien perpustakaan terbuka baru sekarang dalam keadaan di mana ia dapat digunakan untuk melakukan koreksi data massal.

@LeadSongDog Saya mungkin sudah tahu bagaimana mangling terjadi, dalam contoh ini marc xml
https://ia600208.us.archive.org/25/items/b2202010x/b2202010x_marc.xml

kuburan "Secours donner" ditampilkan dengan benar dalam penyandian utf-8

a-grave adalah U+00E0, yang dalam biner (notasi pythonic) adalah \xC3\xA0

jika byte tersebut ditafsirkan sebagai MARC8 dan "dikonversi", C3 menjadi simbol hak cipta, dan 'A0' menjadi spasi, persis seperti yang kita lihat di halaman OL dengan "Secours © donner"

Saya sekarang berpikir catatan MARC ini memiliki pengkodean karakter utf-8, tetapi diimpor ke OL seolah-olah mereka adalah MARC8, yang menjelaskan mangling.

Saya melakukan konversi MARC8 secara manual dari tabel yang ditemukan di sini https://memory.loc.gov/diglib/codetables/45.html Saya harus menggunakan yaz atau sesuatu untuk menguji ini dengan benar, tetapi ini akan memberikan jalur yang baik untuk memperbaiki kesalahan MARC secara terprogram.

Saya tahu bahwa ada kesalahan mangling unicode lain yang memengaruhi catatan impor Amazon, tetapi saya pikir itu berasal dari konversi yang salah dari rangkaian karakter Windows atau ISO

Terima kasih atas komentar Anda @LeadSongDog , dalam mencoba mencari tahu apakah catatan MARC benar-benar salah atau tidak, saya pikir saya telah menemukan akar penyebab masalah!

@hornc ada pembaruan tentang MARC mangling dan/atau jika kami menyelesaikan masalah ini?

Masalah ini pasti tidak terselesaikan. Ketika skrip impor diperbaiki, saran @bfalling untuk mengimpor ulang kemungkinan besar akan diperlukan.

Dari sudut pandang triase, mungkin akan berguna untuk mendapatkan hitungan yang sebenarnya. "Ribuan" bukanlah persentase yang sangat besar dari 25 juta edisi.

Apakah ini telah diselesaikan dengan perubahan Python 3 kami atau dapatkah seseorang memberikan langkah-langkah untuk mereproduksi pada Python 3?

Nah https://openlibrary.org/books/OL12903648M/Etudes_Conomiques_De_L 'Ocde tentu tidak diperbaiki, tapi mungkin kita sudah selesai menggali lubangnya...
Setidaknya ada tiga kelas masalah:

1. Impor data bagus yang buruk
2. Impor literal dari data yang buruk
3. Data buruk di tempat dari kasus lama 1 atau 2 sejak diperbaiki.
   Pindah ke py3 paling banyak akan memperbaiki nomor 1.

Langkah-langkah untuk mereproduksi masalah kelas 1?

Contoh sebelumnya lebih baik daripada yang terbaru yang merupakan impor dari data Amazon jelek (yang tidak boleh kita impor).
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_propres_%C2%A9_9%CA%BECtre

Jika bug telah diperbaiki, mengimpor ulang catatan akan menghasilkan penyandian yang benar. Kemudian tugasnya hanya mengimpor kembali jutaan catatan yang rusak.

Pencarian yang diklaim mengembalikan 17+ juta catatan sebelumnya: https://openlibrary.org/search?q=title%3A+%22%C2%A9%E2%99%AD%22&mode=everything
sekarang mengembalikan 23,4 juta hasil, tetapi saya pikir itu sebenarnya adalah bug yang terpisah dan itu hanya mengembalikan semua pekerjaan di database.

@tfmorris Sebagai https://openlibrary.org/search?q=title%3A+%22+%22&mode=everything mendapatkan hasil yang sama, tampaknya ya, ini adalah kasus sederhana pencarian judul untuk string kosong yang efektif.

Saya membuat #4223 untuk bug pencarian.