Lze zvolit puvodni znakovou sadu pri rozbalovani, kterou byl stary archiv balen?

[miro_]

Potreboval jsem na U22-mate na RPI4 rozbalit '.zip', asi 0.5G soubor, s nazvy nekterych souboru v cestine.
Archiv byl vytvoren v 2016 v XP.
Pri rozbaleni se mi takto 'kur*i' nazvy souboru v cestine:
 napr.: 'temoclanky-panadon-Jak na pýesn‚ mØýen¡ teploty.pdf'.
Archiv byl rozbalen cca OK az na nazvy souboru v cestine .
 Zkusil jsem rozbaleni v Xarchiver.
Ten se ale pri rozbalovani se sekne, zrejme na nejakych slozitych adresarovych strukturach !
Podobne ale spatne pojmenovana rozbalene soubory: 
 napr. 'RF a Wi-Fi spбnaЯ Sonoff RFR2.pdf'.

[ramael]

Zkus v terminálu:

Kód: [Vybrat]

bsdtar -tvvf 'tvuj.zip'
pokud to ukáže výpis jaký sis představoval tak písmenko t vyměň písmenkem x:

Kód: [Vybrat]

bsdtar -xvvf 'tvuj.zip'


[zeleno]

Roky používam WinRAR cez Wine a diakritikou nie je problém. Otázkou je, čím to bolo spakované v tom XP
https://i.postimg.cc/fyPJB250/WinRAR2.png

[miro_]

'bsdtar' to nejak zcivilizuje, ale neni to ono. Viz. prilohy,.  Po rozbaleni je soubor stale citelny jako '.pdf' presto ze vypada jako by nemel extension.
'winrar ' to rozbali podobne spatne. Viz priloha.

Zip soubor byl  vytvoren pres 'Ztree' v XP profesional verze 2002.
Bohuzel asi tato verze XP nebo Ztree  ma nejakou chybu, a nehlida povoleny pocet vnoreni vytvorenych adresaru.
Zrejme proto se v XP i Ztree rozbalovani v prubehu zhrouti.
V U22-mate to rozbalit jde, az na preorane nazvy souboru s diakritikou.
Ceske textove soubory normalne neuzivam, tak nevim jak by to dopadlo.

Zkousel jsem jeste rozbaleni temito zpusoby porovnat v FreeFileSync. Jen data z U22 zip a Winrar jsou identicka.
 

[ramael]

A copak vypíše toto?:

Kód: [Vybrat]

bsdtar -tvvf 'tvůj.zip' | iconv -f WINDOWS-1250 -t UTF-8
Popřípadě místo WINDOWS-1250 zkusit nějaké to CP1250 nebo ISO_8859-2

[miro_]

Tvoje dalsi navrhy nejdou.
To by platilo mozna pro data souboru ale ne  pro jmeno jmeno souboru !
To neni v systemu bezny text !

Zkousel jsem nejak prenest spatne jmeno souboru do terminalu, jak je zobrazeno v dir caja viz. priloha1.
Takove jmeno  prenest (copy) do terminalu nelze  a tedy ani volat v  'iconv' !
Pak to dopadne  takto viz. priloha2.

[JirkaZ]

Zkus doinstalovat ark a rozbalit to v něm.

Jinak se opět (už asi po miliónté) ukazuje, jaká čuňárna je používání diakritiky v názvech souborů a/nebo adresářů.

[ramael]

Tvoje dalsi navrhy nejdou.
To by platilo mozna pro data souboru ale ne  pro jmeno jmeno souboru !
To neni v systemu bezny text !

Zkousel jsem nejak prenest spatne jmeno souboru do terminalu, jak je zobrazeno v dir caja viz. priloha1.
Takove jmeno  prenest (copy) do terminalu nelze  a tedy ani volat v  'iconv' !
Pak to dopadne  takto viz. priloha2.

Jenže já ti psal o voze a ty něco jiného...
Výstup příkazu který jsem zadal je jen text! Jde o to jakou to má znakovou sadu! A ty se snažíš konvertovat soubor. To je samozřejmě špatně. Pak si všimni těch uvozovek co tam mám. To je proti expanzi. Expanze je to co se ti, a nejen Tobě stane a stává když nedáš jména s mezerama do jednoduchých uvozovek. Anebo když ty mezery neescapuješ. Takhle se soubory zkrátka nepřejmenovávají!
Plán:
Pokud bude výpis se správnou diakritikou, tak se buď použije unzip s parametrem -O jenže, to nepodporuje každá distribuce.
Nebo se budou názvy konvertovat pomocí rename nebo mv ve skriptu s bsdtar.
Nebo... možností je určitě více.

[ramael]

Zkus doinstalovat ark a rozbalit to v něm.

Jinak se opět (už asi po miliónté) ukazuje, jaká čuňárna je používání diakritiky v názvech souborů a/nebo adresářů.

Tak samo, že bez diakritiky je to lepší. Avšak, normálně to je nic proti ničemu pokud se používá utf-8. A ono to i na tom windowsu šlo přepsat aby nepoužíval jiná kódování v základu, ale rovnou utf-8. Zápisem do registru jeli widle (XPéčka) v utf-8 celý systém. Větší problém je dle mne s mezerama. On totiž i ten soubor s blbě konvertovaným názvem by měl jít otevřít, jen si dát bacha na ty mezery a potlačit uvozovkama expanzi. Mezera je totiž oddělovač argumentů a tím pádem i souborů. Příklad:
soubor blby nazev souboru s mezerama.txt chci otevřít třeba v nano

Kód: [Vybrat]

nano 'blby nazev souboru s mezerama.txt'
Otevře se a pracuje vesele. Kdežto:

Kód: [Vybrat]

nano blby nazev souboru s mezerama.txt
expanduje na 5 souborů:

Kód: [Vybrat]

blby
nazev
souboru
s
mezerama.txtA to je samozřejmě blbě. nano vytvoří 5 souborů s názvy blby, nazev, souboru, s, mezerama.txt

[JirkaZ]

ramael: jo, pohádku o UTF-8 poslouchám či čtu už vážně dlouho...

Jenže: svět je - jak známo - bohužel plnej widlous a ty až docela donedávna (jak opět známo) měly svoje kódování. A aby toho nebylo málo, tak nešlo jen o 1250, ale i o spoustu dalších variant.

No a Mařky Vomáčkojc, Vencové Vopršálkové a další megatuny podobných "expertů" to tam sázely a sázejí furt pryč, takže těch zpotvořených archivů je a ještě hodně dlouho bude bude záplava.

Mezera je kapitola sama pro sebe. Překvapivě ale třeba Kubuntu nebo prostě KDE jako takové si s ní odjakživa poradí už v základu, takže když už je nějakým čunětem v názvu souboru či adresáře vytvořená, tak se nekoná průšvih. Nemyslím tedy konzoli, tam jsou potřeba obezličky...

On tedy ani Linux sám o sobě nemá čisté svědomí. Zde jsou příklady názvů adresářů, co se u mě vytvořily "samy" (přesněji řečeno: vytvořil je nějaký program):

My Web Sites

PlayOnLinux's virtual drives

VirtualBox VMs

atd.

[ramael]

Mam nocni, tak jen z mobilu.
Jsem presvedcen, ze ty mezery zvadne kdejake DE, ne jen KDE. Ty uz si vse escapuji.
Avsak terminal tomu rozumi z podstaty veci jinak. A miro_ to pouzil v terminalu. Coz je dobre, jen to pouzil spatne.
Jinak souhlasim, ze microsoft do toho kodovani hazel (mozna jeste hazi) vidle. Je smutne kdyz se vsichni domluvi na nejakem standardu. A stejne si to clen udela po svem. A to plati treba i o GNOME ohledne Waylandu. Protoze ostatni implementace (KDE, WLROOTS based), jsou navzajem vicemene kompatibilni.
Ty nazvy slozek co jsi sem dal vytvari graficke programy. Jak uz jsem zminil jinde, linux je postaven na terminalu. Vse ostatni jsou jen graficke nadstavby ktere jsou uzivatelsky privetive. Avsak pri problemu je treba pouzit univerzalni vec - terminal a tam dodrzovat nejaka pravidla.

[miro_]

Udelal jsem pro test na XP maly testovaci adresar s podadresari  a txt soubory s daty v cestine.
Zavery jsou nasledujici:
- v XP tento testovaci podadresar sbaleny pres 'ztree'   po jeho rozbaleni 'rozipovanim-vykopirovani' primo XP je poradku.
- Zkusil jsem pres 'flesku' prenest testovaci '.zip' do W10.   Ve W10 je po 'rozipovanim-vykopirovani' vse rovnez v poradku !
 
  ! Preneseni testovaci rozbalene struktury pres sit  (sambou) do U22mate
   jsou cz pojmenovani vsech souboru  a podadresaru v poradku ale data souboru jsou spatne kodovana !
  ! Pri prenosu komprimovaneho testovaciho adresare z XP   do U22mate pres sit (sambou) jsou v U22 spatne
  jiz i cz jmena souboru i data souboru s cestinou !
Potvrzuje to ze pro prenosy mezi linux a win  je cestina  problem.

Jen dodatek k mezeram ve jmenech. Dle mych zkusenosti  je hlavni problem mezera na konci extension
 nebo ve jmenu  bez extension, kterou se mi obcas pri kopirovani jmen  souboru povede pridat.
 Pak samba a nektera aplikace (FreFileSync, ...) maji problem.
  Podobny problem dela nektery 'C' kompilator pri uzivani  '#ifdef jmeno\'. Mezera za '\' dela chybu v prekladu   
 (spatne se tento problem hleda).
 
- Jeste dodam k interpretaci pri kopirovani z obrazovky.
 To co mi vypisuje na obrazovce nejaka aplikace nebo  terminal zavisi na jeho interpretaci nactenych binarnich dat
 v nejakem bufferu, jak jej jeho autor resil.
 Dodnes se mi obcas hodi stare XP s UTF-8, kde mam  moznost pri 'debug' paketu v prenosech dat napr. z 485 atd.
 V techto XP je jeste funkcni editor ze systemu DOS  z 80-tych let 'e.exe' (nebo podobny 'aedit.exe').
 Tento editor umoznuje 'hledat' i 'editovat' hex znaky  pod  0x20  a nad '0x7f' vcetne 0x00.
 Obcas se mi to hodi (napr upravy "crlfcr" na "crlf", kdy je takto nekdy nasledujici text nezobrazen,
   vlozeni nebo nahrazeni "tabulatoru"  atd...
 Zatim jak resit podobne problemy v linuxu neznam. (Samozrejme to souvisi s uzivanim UTF-8).
 

Jenže já ti psal o voze a ty něco jiného...

Ja jsem jen chtel zkusit zda 'linux terminal' nahodou pres 'ctrl_c/v' nenatahuje pro tyto akce binarni data z bufferu.
 Tehdy by bral hex data z buferu mezi 'otagovanim', bez ohledu na uzite kodovani znaku.
 Je mozne ze jsem Tve prispevky zcela nepochopil.. 

Pro mne je timto testovanim problematika cz mezi win a linux uzavrena.
Prikladam testovaci '.zip' pro moznost vyzkouseni, nutno uzit i win ! , pozor zipovano v U22 !
(Zajimave, baleni '.7z' melo problem  ! Nejde prilozit. nemam chut problem '.7z' zkoumat.)

[ramael]

Já vím, už to bylo uzavřeno.
Nevím od jaké verze windowsu se to změnilo a proč to předtím bylo jinak. Pohrál jsem si s tím. Windows 11 používá nativně utf8. Windows XP a 7 zipuje v charsetu CP852. Což jestli si dobře pamatuju bylo kódování češtiny v cmd (obdoba terminálu).
Souhrnem, tohle funguje u mne na zip z win XP a 7:

Kód: [Vybrat]

unzip -l -O CP852 'test-cz.zip'
Na rozbalení se vynechá argument -l
Rozdíl v kódovaní na přiloženém zipu z win XP:

Kód: [Vybrat]

unzip -l 'Matrjoška.zip'
unzip -l -O CP852 'Matrjoška.zip'