Fórum Ubuntu CZ/SK
Ubuntu pro osobní počítače => Software => Téma založeno: miro_ 30 Března 2024, 11:01:49
-
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'.
-
Zkus v terminálu:
bsdtar -tvvf 'tvuj.zip'
pokud to ukáže výpis jaký sis představoval tak písmenko t vyměň písmenkem x:bsdtar -xvvf 'tvuj.zip'
-
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 (https://i.postimg.cc/fyPJB250/WinRAR2.png)
-
'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.
-
A copak vypíše toto?:
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
-
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.
-
Zkus doinstalovat ark (https://launchpad.net/ubuntu/+source/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ářů.
-
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.
-
Zkus doinstalovat ark (https://launchpad.net/ubuntu/+source/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 nanonano 'blby nazev souboru s mezerama.txt'
Otevře se a pracuje vesele. Kdežto:nano blby nazev souboru s mezerama.txt
expanduje na 5 souborů:
blby
nazev
souboru
s
mezerama.txtA to je samozřejmě blbě. nano vytvoří 5 souborů s názvy blby, nazev, souboru, s, mezerama.txt
-
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.
-
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.
-
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.)
-
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: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:
unzip -l 'Matrjoška.zip'
unzip -l -O CP852 'Matrjoška.zip'