Importovat zip soubory

[Karel Hovorka]

No description provided.

[Karel Hovorka]

Odteď Zpěvník importuje i .zip soubory a prohledává je pro soubory s příponou .xml, .txt a .pro.

[Former user]

Rád bych toto znovu otevřel. O této záležitosti jsme si teď psali. Vy pracujete na Macu, jestli jsem správně pochopil, ale děláte i pro Woknaře. Tyto systémy mají každý jiné kódování názvů souborů, takže logicky Váš import nenačte obsah mého zipu s diakritikou, protože tam vidí sypaný čaj, a samozřejmě opačně, já nevidím správně obsah Vašeho zipu. Nejen já mám názvy souborů s diakritikou, navíc já to neovlivním, takhle si soubory pojmenovává program Songbook od Linkesoftu (a není radno to měnit). Proto prosím, abyste import upravil, aby uměl načítat i z Unicode. Rád bych provozoval jedna data pod oběma programy. Martin Bambuch

[Karel Hovorka]

Tenhle projekt dělam na macu i linuxu, ale podstatné je, jak si s tím zipem poradí java a android.

Ten původní `ZIP.zip` úplně spadne na `java.lang.IllegalArgumentException: MALFORMED`. Pokud nastavim přímo UTF-8 nebo UTF-16(LE/BE) kódování unicodu, tak taky padne na stejnou chybu (pravděpodobně je UTF-8 default). Pokud nastavim na CP1250, názvy souborů jsou špatně, ale aspoň import proběhne. Pokud víte, v kterém kódování ty názvy jsou (pokud to vůbec unicode je, nedovedu si představit, že by se kódoval jinak než skrz UTF8/UTF16 a navíc výsledné rozbité kódování spíš naznačuje nějakou starší znakovou sadu), tak to vyzkoušim.

‌

To je jeden problém - vůbec zjistit kódování.

Druhý problém je, že možnost specifikovat kódování jede na androidu od 7.x, takže u starších se bude muset fallbacknout na původní, kde není specifikováno.

Název souboru používam jen na generování ID songu (+ příponu, abych rozhodl, jestli importovat jako xml anebo chordpro), ale jak to tak vidim, bude lepší místo toho ho generovat z návu songu + autora a ten název vůbec nepoužívat, pokud to bude tak problémové. Pokud ale import bude padat na MALFORMED, tak nepomůže ani tohle.

‌

Tohle jsou druhy chyb, které bude třeba trochu zažít a otestovat chování v reálu. Jestli třeba aspoň při CP1250 vesměs import vždycky projde a tím pádem to bude ok a nebude se řešit reálnej název souborů.

‌

‌

[Karel Hovorka]

Taky pomůže verze windows a program na zipování. Z těch snad někde dohledam přímo použité kódování.

[Karel Hovorka]

Původní ZIP.zip je kódováno CP852, to už je historická záležitost:

https://cs.wikipedia.org/wiki/CP852

Java a android bez parametrů předpokládají UTF-8, což je dnes tak nějak standard, dřív to bylo CP437. Vzhledem k tomu, že nejde snadno podporovat víc formátu - po chybě nejde import automaticky opakovat a nejde snadno dělat něco jako “pokus-omyl”, tak to necham na UTF-8 a budu vyžadovat ZIP soubory, které toto splňují.

Teoreticky by se dalo udělat, že by se proud dat duplikoval a já bych mohl pokus opakovat, bylo by to ale pracné a náročné na paměť a u větších souborů by nejspíš Zpěvník padl na nedostatek paměti.

Takže zipovat tak, aby názvy souborů byly kódovány skrz UTF-8 do unicode anebo neobsahovaly diakritiku.

‌

[Former user]

Věnoval jsem včera docela dlouhou dobu různým programům ve Windows ve snaze vyrobit požadovaný ZIP soubor, bohužel ani cmd line SFK ZIP nebyl úspěšný. Rozhodl jsem si tedy na tuto záležitost rezignovat. Děkuji za odpovědi.

[Karel Hovorka]

Škoda, mě to trvalo udělat víc než 1 večer.

Když už command line řešení, tak by šlo určitě udělat jednoduchý skript, který by souborům odstranil z názvu diakritiku. Tím pádem by se nemusel řešit problém se zipem.

[Former user]

Tak jsem se zastyděl 😀 Podle mne nejlíp a nejjednodušeji funguje pro woknaře nabootovat do live linuxu a tam to zkomprimovat. Vyzkoušeno na ElementaryOS a zcela bez problémů.

[Karel Hovorka]

Trochu oklikou, ale hlavně že to jede Zkusim si pohrát s .bat souborem, kterej by odstraňoval diakritiku, až budu mít práci na windows.