Openlibrary: Corregir títulos de libros con Unicode destrozado

Ambos registros provienen de archive.org.

He mirado los archivos _marc.xml en archive.org. La última hora de modificación de ambos archivos marc.xml es en 2007 y estos recrods se crearon en 2008. Parece que el problema está en el script que analizó esos títulos.

Hay miles de registros de importación MARC en los que los caracteres acentuados se han alterado o se han manipulado incorrectamente. Otro escenario común es que los acentos u otras marcas diacríticas han sido reemplazadas por un espacio antes o después de la vocal.

Ver por ejemplo:

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

Tanto en el autor como en el título, la diéresis se ha cambiado a un espacio después de la vocal. El registro MARC vinculado se muestra correctamente en el navegador.

¿Deberíamos considerar la reimportación? ¿Y es # 149, que también hace referencia a https://bugs.launchpad.net/openlibrary/+bug/598204 , una dependencia?

Algunos los he encontrado recientemente: https://openlibrary.org/works/OL17670297W
https://openlibrary.org/works/OL17677126W
múltiples obras de este autor:
https://openlibrary.org/authors/OL2450531A/Matthieu_Joseph_Bonaventure_Orfila

https://openlibrary.org/search?q=title%3A+%22 © ♭% 22 & mode = everything Aún encuentra más de 17 millones de coincidencias. Esto para "é", probablemente la letra acentuada más común. Las ediciones como 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 no deben ser necesariamente manuales.

@hornc re su comentario del 8 de mayo, esos trabajos se crearon a partir de ediciones creadas a partir de la importación
https://openlibrary.org/show-records/ia : b28044277_0001
y
https://openlibrary.org/show-records/ia : b2202010x
Hasta que se fijen en los registros MARC de ia, la reimportación no tiene ningún valor a menos que la importación haga que pasen por la normalización.

@LeadSongDog es interesante, la pantalla MARC a la que enlaza muestra los caracteres distorsionados, pero si hace clic en la representación XML https://ia800202.us.archive.org/34/items/b28044277_0001/b28044277_0001_marc.xml, la e acentuada se muestra correctamente . ¿Puede haber un problema con los tipos de codificación configurados incorrectamente? Lo retomaré en breve, el nuevo cliente de openlibrary se encuentra ahora en un estado en el que se puede utilizar para realizar correcciones de datos en masa.

@LeadSongDog Es posible que haya descubierto cómo está sucediendo el destrozo, en este ejemplo marc xml
https://ia600208.us.archive.org/25/items/b2202010x/b2202010x_marc.xml

la tumba de "Secours à donner" se muestra correctamente en codificación utf-8

a-grave es U + 00E0, que en binario (notación pitónica) es \xC3\xA0

si esos bytes se interpretaron como MARC8 y se "convirtieron", C3 convierte en el símbolo de copyright y 'A0' se convierte en un espacio, que es exactamente lo que vemos en las páginas OL con "Secours © donner"

Ahora creo que estos registros MARC tienen codificaciones de caracteres utf-8, pero se importaron a OL como si fueran MARC8, lo que explica la alteración.

Hice la conversión MARC8 manualmente desde las tablas que se encuentran aquí https://memory.loc.gov/diglib/codetables/45.html Necesitaré usar yaz o algo para probar esto correctamente, pero esto proporcionará una buena ruta para corregir los errores MARC mediante programación.

Sé que hay otros errores de manipulación de Unicode que afectan a los registros importados de Amazon, pero creo que se debe a una conversión incorrecta de los conjuntos de caracteres de Windows o ISO.

Gracias por tu comentario @LeadSongDog , al tratar de averiguar si los registros MARC eran realmente incorrectos o no, creo que me he topado con la causa raíz del problema.

@hornc ¿ alguna actualización sobre la resolvimos este problema?

El problema definitivamente no está resuelto. Cuando se corrige el script de importación, lo más probable es que sea necesaria la sugerencia de @bfalling de reimportar.

Desde el punto de vista del triaje, probablemente sería útil obtener un recuento real. "Miles" no es un porcentaje muy grande de 25 millones de ediciones.

¿Se ha resuelto esto con nuestros cambios de Python 3 o alguien puede proporcionar pasos para reproducir en Python 3?

Bueno, https://openlibrary.org/books/OL12903648M/Etudes_Conomiques_De_L 'Ocde ciertamente no está arreglado, pero tal vez hemos terminado de cavar el hoyo ...
Había al menos tres clases de problemas:

1. Mala importación de buenos datos
2. Importación literal de datos incorrectos
3. Datos incorrectos en el lugar de casos antiguos de 1 o 2 desde que se solucionó.
   El paso a py3 arreglará como máximo el número 1.

¿Pasos para reproducir el problema de clase 1?

Los ejemplos anteriores son mejores que el más reciente de los cuales es una importación de datos de Amazon cutre (que no se debe importar).
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_pro2tre_%C2CA%

Si se ha solucionado el error, la reimportación de los registros debería dar como resultado la codificación correcta. Entonces, la tarea simplemente se convierte en reimportar los millones de registros corruptos.

La búsqueda que se decía que devolvía más de 17 millones de registros antes: https://openlibrary.org/search?q=title%3A+%22%C2%A9%E2%99%AD%22&mode=everything
ahora devuelve 23,4 millones de resultados, pero creo que en realidad es un error separado y solo está devolviendo todos los trabajos en la base de datos.

@tfmorris Como https://openlibrary.org/search?q=title%3A+%22+%22&mode=todo obtiene el mismo resultado, parece que sí, es un caso simple de búsqueda de título para una cadena efectivamente en blanco.

Creé # 4223 para el error de búsqueda.