Dotaz: Nelze smazat ani otevřít soubor s kódováním windows

[Kloban]

Mám zip soubor, ve kterém je uloženo pdf s názvem

�kol 2..pdf

Když ho rozbalím, nejde spustit, smazat prostě nic (hlásí: "Soubor nebo složka /home/daniel/Plocha/�kol 2..pdf neexistuje.").

Dá se to obejít tak, že ho rozbalím a pak ho na to stejné místo rozbalím znovu, v tu chvíli se mě zeptá jestli ho chcu přepsat, nebo přejmenovat, když ho přejmenuji na jiný název, problém je pryč, soubor je v pořádku.
Kde je chyba, že si debian wheezy prostředí kde 4.10 nedokáže poradit s tak banálním problémem. Máte někdo podobnou zkušenost?

Díky Dan

---

---

Odpovědi

[NN]

Diakritika ale neni vubec banalni problem. Proto se ji kazdy snazi pokud mozno vyhnout..

[chrono]

Ten zip súbor obsahuje aj názov súboru v utf-8 kódovaní (to rozšírenie je v zip formáte dostupné už 7 rokov a napr. unzip ho podporuje niekoľko rokov)? Ak nie, tak neexistuje spôsob, akým by sa dalo určiť, aké kódovanie sa pre tie názvy má použiť.

[Kloban]

Název zip souboru je v pohodě. Ale název pdf v něm bude zřejmě ve windows kódování, protože soubor byl na windows vytvořen.

[misch]

Vždyť píše že "to rozšírenie je v zip formáte dostupné už 7 rokov" :). To se opravdu netýkalo názvu ZIPu samotného, ale názvů souborů v něm obsažených :)

[Ash]

Grafické nástroje se soustředí na uživatelskou přívětivost, funkčnost zaostává, ale chybou bych to přímo nenazýval, je to "něco za něco". V 99.9% to můžete naklikat a zbytek holt nejde. Pro smazání lze použít příkaz rm, pro přejmenování mv a pro spuštění třeba okular soubor.pdf. V konzoli můžete i detailně zanalyzovat jak se ten soubor vlastně přesně jmenuje. Jinak chyba bude asi v tom zip archivu, který neobsahuje správný typ kódování jména souboru, pokud vůbec.

[Kloban]

V příkazovém řádku nemám jak napsat název soubory když začíná "�". I když tam ten název s tímto znakem zkopíruji, tak to neprojde. Napíše že to není název složky ani souboru.

[Petr Šobáň]

Protože tam asi není jenom ten znak � ale i nějaký jiný znak který se nezobrazí.

[skvedo]

Místo toho neznámého znaku použijte otazník. Ten zastoupí jakýkoliv znak. Dejte si ale pozor, aby jste ve stejné složce neměl soubor, který se bude lišit pouze prvním symbolem, pak by prováděné akce směřovali i na ten druhý soubor.

[Kloban]

Díky. To mě nějak nenapadlo.
Každopádně mi takto bude chodit úkol ze školy každých čtrnáct dní, takže to hold v řádku vždycky přejmenuju.

[potato]

holt, pokud tomu nechceš vzdávat hold.

[sestka vlevo dole]

V tom pripade by mohl pomoci prikaz ls -b, ktery vypise nazvy v backslash notaci a umozni i copy/paste pro prejmenovani.

[Kloban]

ls -b vypíše:

\332kol\ 2..pdf

Když se ale snažím se souborem pracovat pod tímto názvem tak to nefunguje (píše - soubor neexistuje).

[luminofor]

Takze rm \332kol\ 2..pdf ho nesmaze?

[Ash]

Určitě ne, proč by to dělal, bash není C. Příkaz ls umí vypsat názvy v C notaci, což je jistě chválihodné, ale bash na vstupu neinterpretuje C notaci, na to byste musel mít nějaké rm -b, což nemáte, i když by se asi hodilo.

[Ash]

Ale vlastně asi by mohlo zabrat rm $'\332kol\ 2..pdf'

[Michy]

Přesněji rm $'\332kol 2..pdf' nebo rm $'\332'kol\ 2..pdf s ohledem na apostrofy není potřeba escapovat mezeru, stačí vypsat C notací to nepovedené Ú.

[Kloban]

Taky vyzkouším... Aspoň se dozvím něco novýho.

[rastos]

Len tak pre zaujímavosť, čo vypíše

ls *"kol 2..pdf" |od -t x1

?

P.S.: to sú tam fakt dve bodky?

[Kloban]

Ano, jsou tam dvě bodky. Ta první totiž značí řadovou číslovku.

Příkaz vypsal toto:

0000000 da 6b 6f 6c 20 32 2e 2e 70 64 66 0a
0000014

Co to značí?

[rastos]

To sú hexa kódy znakov toho súboru. Keďže, "6b 6f 6c" je "kol", tak ten prvý znak má len jeden bajt s kódom 0xda, čo je "Ú" v nasledovných kódovaniach CP1250 CP1252 CP1254 CP1258 CSN_369103 DEC-MCS IBM1004 IBM1129 IBM1163 IBM922 ISO-8859-1 ISO-8859-10 ISO-8859-14 ISO-8859-15 ISO-8859-16 ISO-8859-2 ISO-8859-3 ISO-8859-4 ISO-8859-9 ISO-8859-9E ISO-IR-197 ISO-IR-209 SAMI-WS2 VISCII - z čoho realistické je asi najskôr CP1250 alebo ISO-8859-2

Mno, skrátka by som tipol, že pri správnom fonte a nastavení locale by to mohlo zafungovať.

[petr_p]

A nebo se použije convmv.

[Ash]

On ten nazev souboru taky nezacina timto znakem. To bude nejaky sileny znak ze znakove sady, ktera nema potrebne fonty v systemu (treba korejstina) nebo vubec neexistuje. Nemate vybalovat soubor zabaleny silenym hnusem fialovym, ktery se pod windows nenamahal se spravnym kodovanim, protoze prece vsichni maji windows :)

Pouzivam tento postup: vypsat inode souboru a smazat pomoci odkazu na tento inode:

ls -i
130997 �kol 2..pdf
find . -inum 130997 -delete

[Šangala]

Pravděpodobně to nepomůže (z podstaty věci to zaberte jen na něco), ale můžete to zkusit rozbalit pomocí unzip -U files.
Je to standardní problém, ale vězte, že na Win jsou na za určitých okolností mnohem hůř, když dostanou soubor s diakritikou (v utf-8) zabalený v archivu zip v Linux-u (ten kdo balí soubory s no-ascii znaky do obyč zip-u, by potřeboval „nakopnout“ a je jedno na kterém OS - ministerstva s oblibou ).
Rozumnou a bezplatnou multiplatformní alternativou řešící tyto problémy je používat 7zip (myšleno hlavně na Win), ten dokonce zvládne na Win rozbalit i složky/soubory s názvem con, prn, nul či com2 i ze .zip archivu (,které integrované copy&paste na win tiše ignoruje).
Nejlépe je to řešeno na androidu (nevím díky čemu, nebo jestli je to by-default), kde znakovou sadu pro názvy rozbalovaných souborů lze zvolit.

[Šangala]

Jo jinak, jak jsem napsal, je to standardní problém, takže mé standardní řešení je (což jsem opomněl napsat):
Standardně jej nepotřebuji smazat ale hlavně přejmenovat a dále používat , takže si vytvořím nějaký adresář a tam si jej případně zkopíruji a hlavně rozbalím, takže tam nejsou jiné soubory než z toho archivu.
V terminálu pomocí cd nacestuji do tohoto adresáře (pominu-li, že i předchozí dělám v terminálu ;)) a pak pomocí mv to přejmenuji.
Výpis z terminálu (pomocí touch si ten soubor vytvářím):

Stupid Windows-1250 > mkdir kuk
Stupid Windows-1250 > cd kuk
Stupid Windows-1250 > touch $'\332kol 2..pdf'
Stupid Windows-1250 > ls 
?kol 2..pdf
Stupid Windows-1250 > ls -b 
\332kol\ 2..pdf
Stupid Windows-1250 > mv *kol\ 2..pdf úkol\ 2..pdf
Stupid Windows-1250 > ls 
úkol 2..pdf
Stupid Windows-1250 >

nebo (důležitá část):

Stupid Windows-1250 > mv *'kol 2..pdf' 'úkol 2..pdf'
Stupid Windows-1250 > ls
úkol 2..pdf
Stupid Windows-1250 >

Samozřejmně lze použít ? místo *, ale ono kolikrát těch klikiháků je tam více, takže je to tak snazší.
v tomto konkrétním případě bych tedy použil:

mv *.pdf Ukol_2.pdf

Ale pozor ať jste v tom speciálně vytvořeném adresáři, nicméně v případě mv se při nejednoznačnosti obvykle zas tam moc nestane (pokud tedy neexistuje cílový název souboru jako adresář).

[masomlejn]

Nešlo by použít detox?

[Šangala]

Možná, zkuste, ale nevidím k tomu důvod mv je „čistější-jasnější“ (detox je pro mě osobně buď složitá nebo nedostatečná utilita, které se vyhýbám).

[lertimir]

Nestačilo celou rozbalovací operaci provést přímo na flashce nebo jiném zařízení s FAT/NTFS flesystémem? Unzip by vytvořil vytvořil název, co je v zipu, který by správně mountlý filesystem interpretoval jako Ú a při kopii někam do linuxových filesystémů by se konverze na UTF-8 provedla automaticky. Alespoň mě se české názvy v CP1250 na moutlých NTFS a FAT systémech zobrazují správně.

[Šangala]

Co s tím budu „blbnout“, a mít někde flašku s NTFS, když to dojde e-mailem nebo se to stáhne ze stránek nějakého ministerstva… :) uživatel si to prdne na sdílený disk (samba), já se na to juknu opravím a je to…, ještě abych měl na serveru cosi widláckého :)

[Šangala]

PS: Vždyť je to strašně „pracné-náročné“ oproti jednomu mv.

[lertimir]

Je to asi věc názoru. Díky tomu, že značná část pracovních počítačů kolegů je pod Win, tak vždy mám flash, kterým bych mohl mezi nimi přenášet data a tedy s FAT. Tím pádem dost takto postižených souborů mám přímo na té flashi. Pokud mám nějaký z mailu, tak zastrčit flash, (auto)moutnout jej, nakopírovat na ni soubor, rozbalit jej na flashi a výsledek kopírovat/přesunout do cíle, (obvykle tohle udělám v Krusaderu na pár kliků) je pro mne jednodušší, než hledat jaké písmeno znamená \332 nebo případně 5 dalších diakritických znaků v souboru, nemluvě o tom, když jméno souboru v tom zipu pro dost lidí může mít 5-6 oddělených českých slov, je 30 i více znaků dlouhé a čistě pracnost napsání přesného mv se správně umístěnými otazníky je větší, než zkopírovat soubor na flash, rozbalit tam a kopírovat zpět.

[Šangala]

Příloha:

• pokusy.png (98282 bytů)

No to si piš, že je (to věc názoru) .
Dělám to maximálně několikrát do měsíce, a zatím nikoho nezajímal správný název souboru, bo si stejně ten 50 znaků dlouhý název přejmenují na sobě vlastní 60 znaků dlouhý a s úplně jinou diakritikou :).
Navíc ono to většinou jen „nefunguje“ jen na ty „auto-věci“ jako »otevření archivu z mailu/webu → otevření souboru v něm obsaženém bez mezi-uložení apod.«, takže často stačí jen rada, „ulož si to na disk, rozbal to a přejmenuj si to a už můžeš vesele klikat“.
Ale abych nebyl takový odmítač tvého řešení, tak jsem se rozhodl pobavit a k tvé idei jsem si dal své řešení:

modprobe brd rd_size=300000
fdisk /dev/ram1
 c, n, p, 1, <enter>, <enter>, w
mkntfs /dev/ram10
mount -t ntfs-3g /dev/ram10 /mnt/smaz

… a /mnt/smaz jsem použil k nakopírovaní a rozbalování (a pak jsem to zkusil i s fat-kou).
Ale jak uvidíš v příloze nic moc (a stejné je to, když tam vrazím „flašku“).
Zip jsem si vytvořil na W7 pomocí 7zip-u a zip.exe (asi nějaké verze, integrovaný „zip“ v exploreru se chová cca. stejně jako zip.exe…).
V obrázku (viz příloha):

• První řádek v obrázku je zobrazení v Nautilus-u a Explorer-u.
• Druhý tak to vidí/rozbalí File Roller (pomocí „normálního“ a integrovaného „zip-u“ další soubory do archivu neprojdou, tedy problém už při vytváření).
• Třetí řádek rozbaleno pomocí unzip (UnZip 6.00)

PS: Je pravdou, že „Správce archivů“ v Bubuntu se chová trochu jinak (v KDE4 jsem měl mnohem horší zkušenosti /odmítl to rozbalit/, ale je to určitě díky tomu, že to byla jedna z první verze čtyřky, kde nebylo možné ani používat připojení na sambu pro soubory s diakritikou (pokud byla UTF-8) /cca. doba SuSe 11.1/ a od té doby jsem to viděl vždy jen zkoušku a tyto věci jsem vůbec neřešil, takže nevím, je možné že se to chová inteligentněji jako např. na android-u…).
Ale stejně, kdo balí do zipu no-ascii názvy, potřebuje poprvé poučit a pak nakopnout…

[chrono]

Je otázne, či NTFS partícia pomôže (pretože, pokiaľ viem, tak tam sú názvy uložené v UTF-16, alebo v niečom podobnom). Rozumnejšie je asi mať FAT partíciu, ktorá sa pripojí so správnym kódovaním.

[Michy]

Přejmenování takhle blbě pojmenovaného souboru ti usnadní v terminálu např. mc (Midnight Commander) nebo nějaký okenní file manager, třeba Nautilus.

[marek_hb]

zkus to rozbalit přes gnomáckej "Archive Manager" - ostatní (Ark,Krusader a další) aspoň u mě na debianu neumí s takovouhle diakritikou pracovat a po rozbalení ji zmrší tak, že to po nich ani nejde smazat

tenhle "manager" vadné znaky nahradí něčím normálnějším

jinak v MC, nebo konzoli by to jít mělo

[marek_hb]

jo a vítej v jednom z nejmodernějších desktopových prostředí běžícím na operačním systému budoucnosti

[Kloban]

To mám chápat jako ironii?

[marek_hb]

ano

[chrono]

Všetky programy slúžiace na rozbaľovanie zip archívov robia presne to isté aj v iných OS (pretože programy vytvárajúce tie archívy tam vložia čokoľvek v akomkoľvek kódovaní).

[Matelko]

Jestli ti jde jenom o smazání tak dobře funguje BleachBit (čistič disku). Spustíš BleachBit Root dáš sešrotovat soubory, vybereš a dáš smazat. Až budeš vybírat hlásí sám u názvu souboru v závorce neplatné kódování. KDE 4.9 by snad už mělo umět s takovými soubory pracovat (přejmenovat) ale to nevím jistě.

[petr_p]

Nástroj unzip má přepínače -U a -UU, které zamezí vzniku ošklivých znaků při rozbalování. Ale jestli trváte na KDE, tak máte smůlu (Bug 165044 - Dolphin can't handle well files/folders with wrong encoding je 5 let známá chyba). Jinak jak už jsem psal, nástroj convmv umí převést kódování jmen souborů.

[petr_p]

A navíc vývojáři KDE se vyjádřili, že to je problém Qt, a ti řekli, že to nikdy neopraví:

@TheBlackCat: no, no one has the intention of ever fixing that in Qt. Broken filename encodings will be forever considered filesystem corruption.

[Šangala]

Přepínač -U jsem již uváděl, ale ani -U ani -UU zabere jen na omezené skupině znaků a naopak to spíše uškodí než pomůže.

Zde je ukázka, toto:

№7 by frenč Œ^⅓ − ∆x - 3ℓ.TXT
Groβe büro & eñe.TXT
¿Que trabacha, ¡HE!.TXT
Ůkol do školičky.TXT
W7snapshot.png
Žežule ze šlukující Jeane.txt

Zabalaené do zipu a následně rozbalené

Unzip > unzip diakritika.zip 2>/dev/null >/dev/null
Unzip > ls -1 diakritika
№7 by frenč Œ^⅓ − ∆x - 3ℓ.TXT
?e?ule ze ?lukuj?c? Jeane.txt
Groβe büro & eñe.TXT
?kol do ?koli?ky.TXT
¿Que trabacha, ¡HE!.TXT
W7snapshot.png
Unzip > rm -rf ./diakritika 
---------
Unzip > unzip -U diakritika.zip 2>/dev/null >/dev/null
Unzip > ls -1 diakritika
?e?ule ze ?lukuj?c? Jeane.txt
Gro#U03b2e b#U00fcro & e#U00f1e.TXT
?kol do ?koli?ky.TXT
#U00bfQue trabacha, #U00a1HE!.TXT
#U21167 by fren#U010d #U0152^#U2153 #U2212 #U2206x - 3#U2113.TXT
W7snapshot.png
Unzip > rm -rf ./diakritika 
---------
Unzip > unzip -UU diakritika.zip 2>/dev/null >/dev/null
Unzip > ls -1 diakritika
???7 by fren-? +?^??? ??? ???x - 3???.TXT
?e?ule ze ?lukuj?c? Jeane.txt
Gro+?e b++ro & e+?e.TXT
?kol do ?koli?ky.TXT
-+Que trabacha, -?HE!.TXT
W7snapshot.png
Unzip > rm -rf ./diakritika 

A jak je vidět problémy to nevyřeší, jen přidá

[petr_p]

Příloha:

• test.zip (1308 bytů)

Je možné, že se přepínač -U použije jen na názvy uložené v unicodu. Můj distribuční unzip-6.0 obsahuje patch, který archiv vytvořený zipem 3.0 správně escapuje:

$ find
.
./test
./test/#U00bfQue trabacha, #U00a1HE!.TXT
./test/#U21167 by fren#U010d #U0152^#U2153 #U2212 #U2206x - 3#U2113.TXT
./test/#U016ekol do #U0161koli#U010dky.TXT
./test/Gro#U03b2e b#U00fcro & e#U00f1e.TXT
./test/#U017de#U017eule ze #U0161lukuj#U00edc#U00ed Jeane.txt
./test/W7snapshot.png

[Šangala]

Přílohy:

• W7.png (9770 bytů)
• W7_2.png (9051 bytů)
• diakritika.zip (5302 bytů)
• diakritika_by_zip_nocomplete.zip (4565 bytů)

Takový zip ale z Windows nedostanete, ten je „Linux-ový“, pomocí 7zip-u je na W7 rozbalím OK, ale pomocí integrovaného zip-u z toho dostanu viz přiložený obrázek W7.png a rozbalený z řádku W7_2.png.
A přikládám dva zip-y z Windows (diakritika.zip vytvoženo 7zip-em, diakritika_by_zip_nocomplete.zip vytvořeno zip-ep, pomocí které projde jen něco).

[chrono]

Otázne je, prečo neuložili všetky názvy v UTF-8 kódovaní, veď aj tak si s tým starý program neporadí.

V Linuxe sa použije starý formád dát asi len pre názvy, ktoré sa dajú uložiť pomocou ASCII a všetky ostatné sú uložené pomocou UTF-8.

[petr_p]

Tak jsem si nastudoval problematiku. Není to o „linuxový“ nebo „windowsí“. PKWARE v září 2012 vydal novou specifikaci, která zavádí další pole, kam se název ukládá v UTF-8, a příslušný bit, který říká, že pole je použito. Celý problém tedy je, že integrovaný zip ve Windows (nevěděl jsem, že tam je něco takové je) tuto změnu ještě neimplementuje a do původního pole cpe, co mu zrovna přijde pod ruku (to znamená, že to není přenositelné ani mezi dvěma jazykovými mutacemi Windows :)

libzip přidal do vývojové verze příznak ZIP_FL_NAME_GUESS pro získání názvu, který později udělali výchozí. Nicméně, co jsem zkoušel, tak nefunguje. A je to proto, že nejprve zkusí ASCII, pak UTF-8 a nakonec CP437.

Bude třeba jim říct, ať to udělají z venku konfigurovatelné nebo ať použijí knihovnu libnatspec, která rozumně předpokládá, že protože archiv není přenositelný, tak se bude šířit jen v jednom jazykovém prostředí, tedy prostě z locale zjistí jazyk a znakovou sadu vybere tu, která se v daném jazyce používá ve Windows.

[chrono]

UTF-8 názvy boli pridané 28. 9. 2007

[Šangala]

Není to o „linuxový“ nebo „windowsí“ - podle mě je, bo z Linuxu je tam obvykle utf-8 a z win kombinace různých znak. sad (bo tam informace o znak sadě standardně není a švihne to tam, tak jak to zrovna je), takže na jednom systému je to přenositelné, křížem ne, a to že to není přenositelní za určitých okolností ani mezi jednotlivými verzemi Woken, jsem psal i na ministerstvo v naději, že to by mohl být argument a mohli by to přestat chrlit.
Dle mého názoru jsou jen dvě řešení, používat něco jiného (myslím, že nejmíň bolí právě 7zip), nebo prostě diakritiku nepoužívat (či ji před-odstranit při vytváření archivu), to že existují od 09/28/2007 nějaké „rozšíření“ je naprd, to probulbá všude až tak v roce 2022.

[Ash]

Pokud diakritiku nebudete používat, tak to neprobublá nikdy :)

[Šangala]

Na tom něco bude :)

[petr_p]

Kdyby to někoho zajímalo, tak včera vyšla libzip-0.11, která obsahuje podporu pro názvy uložené jako Unicode a také interpretuje neunicodové názvy jako CP437. Prý je to součástí (historické) specifikace.

[chrono]

Je celkom zaujímavé, že na podpore UTF-8 názvov začali pracovať pred 23 mesiacmi a dokončená bola pred 13 mesiacmi. :)

Inak keď sa tu podobná téma, s nefunkčnými názvami v zip archívoch, objavila minule, pozeral som špecifikáciu, či je tam určené, aké kódovanie sa má pri názvoch používať, nič také som tam nenašiel. Teda presnejšie, informácia o kódovaní CP437 sa objavila až vo verzii 6.3.0 (po tom, ako pridali UTF-8 kódovanie) a napr. vo verzii 6.2.2 sa o kódovaní nepíše nič.

[Matelko]

Tak jsem chvilku zkoušel. Thunar 1.6.2 umí taky přejmenovat neplatný kódování u souboru a stejně jako BleachBit 0.9.5 hlásí v závorkách neplatné kódování přímo u názvu souboru. Asi je lepší přepsat opravdu celý název souboru než jenom chybný znak.

Poznámka: Pokud jsem chtěl aby změnu názvu vzal na vědomí i Dolphin musel jsem ho vypnout a znovu spustit, jinak stále zobrazoval ten původní s chybným. FBReader jej spustil okamžitě po přejmenování Thunarem, ale možná to bylo tím, že neběžel na pozadí.

[Jajajaj]

mc (Midnight Commander) dokáže premenovať aj takéto súbory. Teraz nemám tu žiadny taký súbor, no sa mi zdá, že len pod root-om.