LIBCAS / ARCLib

ARCLib – komplexní řešení pro dlouhodobou archivaci digitálních (knihovních) sbírek
GNU General Public License v3.0
4 stars 1 forks source link

Selhání ingestu kvůli diakritice v názvu souborů #100

Closed kerschfilip closed 3 years ago

kerschfilip commented 4 years ago

Dobrý den, zdá se, že obsahuje-li SIP soubory, které mají v názvu diakritiku, dojde v ArcLibu k problémům již při rozbalování zipu.

Viz například ARCLIB_000001310 Message: MALFORMED Stack trace:

java.lang.IllegalArgumentException: MALFORMED
    at java.util.zip.ZipCoder.toString(ZipCoder.java:58)
    at java.util.zip.ZipFile.getZipEntry(ZipFile.java:583)
    at java.util.zip.ZipFile.access$900(ZipFile.java:60)
    at java.util.zip.ZipFile$ZipEntryIterator.next(ZipFile.java:539)
    at java.util.zip.ZipFile$ZipEntryIterator.nextElement(ZipFile.java:514)
    at java.util.zip.ZipFile$ZipEntryIterator.nextElement(ZipFile.java:495)
    at cz.cas.lib.arclib.utils.ZipUtils.unzipSip(ZipUtils.java:40)
    at cz.cas.lib.arclib.service.WorkerService.copySipToWorkspace(WorkerService.java:468)
    at cz.cas.lib.arclib.service.WorkerService.processIngestWorkflow(WorkerService.java:214)
    at cz.cas.lib.arclib.service.WorkerService.lambda$startProcessingOfIngestWorkflow$2(WorkerService.java:141)
    at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140)
    at cz.cas.lib.arclib.service.WorkerService.startProcessingOfIngestWorkflow(WorkerService.java:138)
    at sun.reflect.GeneratedMethodAccessor995.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:343)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
    at org.springframework.aop.interceptor.AsyncExecutionInterceptor.lambda$invoke$0(AsyncExecutionInterceptor.java:115)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.lang.Thread.run(Thread.java:748)
yantom commented 3 years ago

Problém je že ZIP je zakódovaný v Cp437 (windows default) ale systém ho očekává v UTF-8. Při nestandartních znacích to způsobuje danou chybu. Možná řešení: 1) pokud taková chyba nastane propagovat ji (tak jako teď jen s jasnější chybovou hláškou) 2) respektovat vstupní kódování ale u nás ukládat v UTF-8 -> důsledek je ten že při exportu z ARCLib bude mít daný balík jiný hash než původní který byl dodán do transfer area 3) respektovat vstupní kódování a u nás používat stejné -> bylo by nutné najít všechna místa v kódu kde se používá knihovna pro zip/unzip (nejen ARCLib ale i Archival Storage) a kódování zde pohlídat (nyní se počítá s UTF-8)

Kloníme se k řešení č. 1. Předpokládám že systémy z nichž balíky v překladišti pochází budou plodit ZIP v UTF-8 (a také snad s rozumnou názvovou konvenci souborů/složek). Kromě zmínených komplikací v bodě 2 resp. 3 je problémový ještě fakt že ze ZIP souboru nedokážeme zpětně určit jakým kódováním jsou entries zakódovány. V případě bodu 2 resp. 3 by šlo tedy o řešení typu pokus-omyl - nejprve zkusit UTF-8 a v případě chyby Cp437. Jiné kódování by ale stále způsobilo chybu. Musel by se udělat výčet všech kódování které se mají zkoušet.

yantom commented 3 years ago

Bude řešeno 1. způsobem.

kerschfilip commented 3 years ago

Otestováno, ARCLib nyní v tomto případě vrací hlášku, která napovídá v čem může být problém. Díky moc a issue zavírám