Dotaz: Hromadná úprava textových souborů

[DWD]

Mám uloženo hodně html souborů, ale v kódování, které mi moc nevyhovuje. Zobrazuje se mi to v prohlížeči sice dobře, ale přesto bych to raději předělal do jiné znakové sady. Je to ve iso-8859-2 a já bych to chtěl předělat do kódování UTF-8. To by nebyl problém upravit. Udělal bych to tak, že bych soubor otevřel v KWrite, nastavil KWrite, ať je text čitelný, potom bych ještě přepsal tag meta ze iso-8859-2 na UTF-8 a potom dal soubor uložit a zvolil uložit ve UTF-8. Postup funguje, už jsem to zkoušel. Problém je ale v tom, že těch html souborů je několik set a upravovat všechny pojednom je práce pro vraha. Takže bych raději použil nějaký příkaz nebo skript, který zadám jednou a už se mi to všechno upraví hromadně. Příkaz pro hromadný převod kódování html (textových) souborů a příkaz pro přepsání určitého řetězce znaků ve více html (textových) souborech hromadně. Existuje něco takového? A názvy souborů a adresářů aby zůstaly zachované. Komplikované to mám ještě tím, že v te složce, ve které mám ty html soubory, mám taky několik různých podadresářů a taky v nich jsou html soubory. Takže celou tu hromadu souborů bych potřeboval předělat.

Kde jsem vlastně k těm souborům přišel. Na http://www.jakpsatweb.cz/download.html jsem si stáhnul celý web Jak psát web.

Odpovědi

[Filip Jirsák]

Kódování upravíte např. pomocí iconv, hlavičku v souboru pak pomocí sedu.

[okar]

Odpověděl Filip. Jen bych dodal, že pokud je soubor správně označený tagem, tak je nesmysl konvertovat to do UTF-8. Kromě toho, že to bude kousek větší nic navíc nezískáte.

[DWD]

Musím to převést do UTF-8, a to ikdyž ty soubory, které mám ve iso-8859-2, jsou označené správně tágem na iso-8859-2. Protože když mám soubory v jiném kódování, než je UTF-8, tak ikdyž mám správný tág, tak v dokumentu otevřeném v Konqueroru mi všechny URLy (na obrázky, na kaskádové styly, a hrefy a podobně) fungují správně, jenom pokud v názvu některáho nadřazeného adresáře nejsou mezery, háčky a podobně. A to ikdyž jde o nadřazený adresář, který není obsažený v URLech dokumentu. O tomto problému jsem už psal v blogu v článku HTML a kódování.

K sedu jsem se ještě nedostal, ale už jsem zkoušel skript na převod te znakové sady, ale má to ještě chybu: Původní soubor má původní název a překódovaný soubor má změněný název (za názvem připsanou jedničku) a já bych to chtěl spíš obráceně (původní název pro překódovaný soubor), aby mi nepřestalo fungovat to, že jednotlivé dokumenty navzájem odkazují. Nebo by dokonce nevadilo přepsat soubory úplně bez vzniku nového souboru. Původní soubory mám stejně pro jistotu někde okopírované.

Tady je ten skript.

for F in $(find $1 -iname "*.html")
do
        if [ -f $F ]; then
                iconv -f iso-8859-2 -t utf-8 $F > ${F}1
                mv ${F}1 $F
        fi
done

[ollaf]

Pokud někdo používá nabodeníčka, mezery a podobně v URL, tak patří do pakárny. Je to zvěrstvo. Nevím sice, co to je Konqueror, zřejmě něco z KDE, ale ani se nedivím, že mu nechtějí fungovat odkazy z nabodeníčky v jiné sadě, než kterou má nastavenou. Až se přejde na UTF-32, tak to budete zase předělávat?

[Filip Jirsák]

Snad do té doby bude Konqueror opraven a bude pro kódování znaků v souborovém systému používat znakovou sadu systému, nikoli stránky, kde odkaz našel. Jinak – co nabodeníčka nebo mezery, dnes se běžně používají názvy souborů, které nesplňují konvenci 8 znaků jména + 3 znaky přípony. Ó jaká hrůza.

[ollaf]

Netřeba být ironický. To, že filesystém umožňuje použít v názvu souboru cokoliv, včetně třeba ASCII 0x07, ještě neznamená, že je rozumné dávat znak pro zvonek do názvu souboru. Nevidím důvod proč se linuxhujeři musejí chlubit tím, že i v linuxu se soubor může jmenovat podle textu prvního odstavce dokumentu, jak to dělá jeden nejmenovaný textový procesor. Kdyby dodržovali primitivní zásady, tak tady nemusel být tento dotaz ani tato diskuse!!!

BTW, spíš než češtinu a mezery v názvech souboru bych uvítal, kdybych mohl mít v adresáři více různých souborů se stejným názvem. To nedovede ani linux, ani widle.

[Michal Kubeček]

Uvítal? A jak byste si představoval, že by se to mělo chovat? Co by se mělo stát, když byste na takové jméno zavolal open(), execve(), stat(), unlink() atd.? Jméno souboru je identifikátorem, kterým se na něj odkazujete, takže je potřeba, aby bylo jednoznačné.

[ollaf]

Chovalo by se to normálně. Blbost je právě to, že je jméno souboru identifikátorem. Když mám deset verzí souboru, tak musím každou pojmenovat jinak. Přitom by se měly jmenovat stejně, lišit se jenom datem, velikostí a samozřejmě inody. Že si programátoři fs nedovedou představit, jak to vyřešit, to je jejich neschopnost. Volba jména souboru jako identifikátoru měla opodstatnění před čtyčiceti lety. Formát 8.3 názvu a číslovaní v extenzi, jak si pamatujeme z dosu v 1.0. Jenže dnes se soubor jmenuje třeba jako celý první půlstránkový odstavec v .docu. To je blbost sama o sobě, je zřejmé, že název je atribut patřící někam do metadat! Vsaďte se, že za pět let s tím přijde google jako s novou geniální myšlenkou.

Je to stejné, jako kdyby si někdo před padesáti léty vybral jako identifikátor souboru datum a creation time (proč ne, vždyť tenkrát nemohly mít dva soubory v jednom kompu stejný creation time). Dnes by jste mi pak na otázku, proč sakra nemohou mít dva soubory stejný čas odpověděl dotazem jak si představuju open() a execve().

[Michal Kubeček]

Jenže to, co popisujete, se dá zařídit i jinak. A zase převratně nová myšlenka to není…

[l4m4]

Pokud chceš databázi, ne souborový systém, tak používej databázi a vytvoř si indexy nad čímkoli, co si vymyslíš, napiš si k tomu KIOslave (z příkazové řádky to bude stejně nepoužitelné) a můžeš být happy. Nebo, když ti jde o ty .docy, se zeptej Microsoftu, kdy konečně vydá Longhorn -- má to v něm být jedna z hlavních fíčur.

Já ale naopak chci, aby /etc/shadow byl právě jeden a pro každého stejný soubor.

To je blbost sama o sobě, je zřejmé, že název je atribut patřící někam do metadat!

Ano, tato věta je blbost sama o sobě. Název souboru je identifikátor. Titulek wordovského dokumentu jsou náhodná metadata, která většina souborů nemá a která nemá smysl jakkoli korelovat s názvem souboru.

[lertimir]

Právě neúspěch verzovacích file systémů je dobrý identifikátor toho, že většině tento přístup nevyhovuje. Jedna se základních vlastnosti souboru je jeho atomičnost. Tedy, že sám nese úplnou informaci. všechny pokusy vázat k němu externí metainformaci neuspěly, protože při přenosu mezi různými filesystémy, při kopírováními různými aplikacemi, při různých přenosech různými síťovými protokoly, by bylo nutné zaručit, že se metainformace mudou také korektně přenášet. Nemyslím si, že existuje síla, která by přiměla všechny se domluvit na kompatibilních metainformacích. jediná společně používaná vnější informace je název souboru jako jednoznačný identifikátor.

[Radovan]

Název souboru je "human interface", systém ho má někde v /dev/null, takže pokud se ti slovní pojmenovávání souborů nelíbí (nebo jsi terminátor), tak si je třeba čísluj, to se na některých systémech muselo dělat ještě v druhé půlce osmdesátých let, takže to nic převratně nového za pár let nebude. Možná tak pro žabáky co před pěti lety vstali z nočníku :-P

[ollaf]

Verzovací fs asi nejsou úplně to, co jsem měl na mysli. Také nestojím o to, mít více verzí /etc/shadow. Děkuji za diskusi.

Co se týče jednoznačnosti jména souborů, zvláště při přenosu mezi platformami, tak bych rád připomenul vfat! Linux používá čtyři způsoby, jak zobrazit jméno daného souboru (lower, Win95, winnt a mixed) a to ještě existuje krátká verze. A taky to jde. Zřejmě se vychází vstříc těm z nás, kteří nemají rádi pravidla a tvrdí, že dodržování zásad je ohrožením jejich osobních svobod. (Teda moc to nejde, protože od té doby, co existuje automout removable disků to různé distribuce připojují s různými parametry a výsledkem je směs souborů s různými velikostmi písmen - "KRATKY.JPG" vedle "Dlouhy nazev.jpg". To je na mrtvici. Hlavně, že nejsou zásady. A že se řeší prkotiny typu gnome-shell.)

Ostatně kolega měl na widlích na ploše několik souborů se stejným jménem. Nešly smazat, nešly přejmenovat a pokud se udělalo copy/paste tak se objevil další duplikát...

Já na svých fs budu nadále používat Nazvy_souboru_bez_hacku_a_mezer a nebudu muset neustále řešit nějaké input cp, output cp, vypalování atd. atd.

[Filip Jirsák]

Pouze ASCII 8.3 je také primitivní zásada, kterou kdyby lidé dodržovali, neexistoval by tenhle dotaz. A co teprve kdyby přestali používat hloupé názvy souborů, a používali normálně číslo inode, tím by se vyřešilo mnoho dalších problémů. Jenže název souboru je identifikátor pro člověka, tak je přirozené, že si ho člověk bude chtít pojmenovat podle sebe, a ne dodržovat nějaké „zásady“, které jsou dobré leda tak pro počítač. Pokud je v nějakém programu chyba, je rozumné tu chybu opravit – ne dodržovat zásady, které zabrání potenciálně jakékoli chybě programu. Když budete takové zásady používat, nespustíte vůbec počítač – co když bude v OS chyba, že vám při bootování smaže všechna data… Ostatně unixové systémy umožňují v názvu souboru používat jakýkoli bajt kromě lomítka odjakživa.

[Michal Kubeček]

Ostatně unixové systémy umožňují v názvu souboru používat jakýkoli bajt kromě lomítka odjakživa.

… a nulového …

[DWD]

Pokud někdo používá nabodeníčka, mezery a podobně v URL, tak patří do pakárny. Je to zvěrstvo. Nevím sice, co to je Konqueror, zřejmě něco z KDE, ale ani se nedivím, že mu nechtějí fungovat odkazy z nabodeníčky v jiné sadě, než kterou má nastavenou.

Samozřejmě, že je pravda, že by se v URL html dokumentu neměly používat mezery, háčky a podobné blbosti. Proto, když si vytvářím vlastní html dokument, tak se takovým znakům v těch URLech vyhýbám. Ale mám vyzkoušené, že pokud mám ten html dokument v jiném kódování, než UTF-8, tak stačí, abych kterýkoliv nadřazený adresář pojmenoval názvem, obsahující mezery, háčky, dlouhé písmena a podobně, už je problém, a to ikdyž se jedná o adresář, který se v URL dokumentu neuvádí, ale o některý nadřazený adresář. Přesto se může způsobit, že ty url přestanou v některých prohlížečích fungovat (v mém případě v Konqueroru, zatímco v Mozille Firefoxu to nevadí). Příklad: Je stránka, která se jmenuje jmeno-1 a vedle ni složka, která se jmenuje jmeno1_soubory a v te složce je obrázek, které se jmenuje obraz.png. Ta stránka jmeno1, i ta složka jmeno1_soubory jsou umístěné ve společném adresáři nova-slozka. V te stránce je relativní odkaz na ten obrázek <img src="jmeno1/obraz.png">. Tento odkaz funguje správně. Pokud ale tu stránku mám v jiném kódování, než UTF-8, tak ikdyž tag meta skutečnému kódování odpovídá, už je problém, pokud složku nova-slozka přejmenuji například na nová složka nebo jinak s nevhodnými znaky, nebo kterýkoliv ještě nadřazenější adresář přejmenuji s těmi nevhodnými znaky. To potom Konqueror neumí zobrazit ten html soubor tak, aby se načetl i ten obrázek. A to ikdyž s nevhodnými znaky pojmenuji složku, která se v URL dokumentu neuvádí. A problém se netýká jenom obrázků.

Přestože by v těch stažených stránkách neměly být URL s nevhodnými znaky, chtěl jsem ty stránky předělat do UTF-8, abych předešel problému, který jsem popsal.

[ollaf]

Děkuji za vysvětlení.

Konqueroru a KDE se budu i nadále vyhýbat...

[2X4B-523P]

nepoužívej ani Linux, tam se minimálně jedna chyba taky najde... vlastně nejlepší bude HW bez systému...

[ollaf]

Huš!

[Radovan]

Myslím že třídička děrných štítků se dneska už bude těžko shánět

[Sten]

Není důvod nepoužívat v URL ne-ASCII znaky, URL to umožňuje a třeba Wikipedie s tím nemá nejmenší problém. Problém je ale v tom, že zatímco HTTP URL je vždy v UTF-8, tak file URL může být v libovolné kódové stránce a pro prohlížeč může být obtížné detekovat, kterou má použít.

Btw. který Konqueror máte? Teď jsem to zkusil v KDE 4.6.1 a tam to funguje tak, že Koqueror použije kódování z locales, takže váš problém nenastane.

[Bilbo]

Třeba wikipedie používá komplet unicode v URL vcelku všude (tam ale může být problém, že bez nabodeníček by to nemuselo být jednodnačné, např. Prace (což je vesnice na moravě) vs. Práce) - a myslím si, že kdyby to tak nepoužívali, museli by řešit pak asi horší problémy.

Ale je spousta situací, kdy je lepší se nebodeníčkům v názvech/url vyhnout.

Osobně u sebe v názvech souborů nabodeníčka nepoužívám a pokud mi něco zvnějšku dorazí s nabodeníčky, pustím na to detox a nabodeníčka jsou fuč :)

[pavlix]

Prace (což je vesnice na moravě) vs. Práce)

Mechanismus na řešení homonym už wikipedia dávno má, takže by se jen vztáhnul i na toto. Ale moc elegantní by to nebylo.

[pavlix]

Konverze do UTF-8 se hodí už jen pro budoucí úpravy, člověk pak není omezen nedostatečnou znakovou sadou a nemusí používat unikódové znakové entity.

[lertimir]

součástí českého TeXu je jíž asi 15 let prográmek cstocs který provádí jakékoliv převody mezi českými kódováními jaké jsem kdykoliv potřeboval. Neudělá vyměnu tagu meta. To by šlo udělat v awk nebo v sed nebo myslím že něco takového by se dalo napsat i perlu

perl -pi -w -e 's/search/replace/g;' *.html

[DWD]

Nebude rozumnější, když všechny soubory a složky budu pojmenovávat bez mezer, háčků, dlouhých písmen a tak dále? Neměl bych si zkontrolovat v počítači v uživatelském adresáři všechny soubory a složky, jaké mají názvy a nevhodné znaky opravím? Dá to hodně práce, ale možná se vyhnu problémům, které by asi mohly někdy nastat. Co když svoje dokumenty, které si vypálím jako data, budu prohlížet v jiném počítači, ve kterém aplikace a prostředí můžou být nastavené na jinou znakovou sadu, než v mojem počítači. Potom budou soubory a složky vypadat nepřehledně, snad nepůjdou ani otevřít, nepůjdou kopírovat, pálit a podobně. Částečně jsem se s podobným problémem už setkal. Například jsem si něco stáhnul z Ulož to, rozbalil a získal jsem hromadu souborů a složek, jenomže názvy některých souborů a složek obsahovaly nevhodné znaky, které pravděpodobně v počítači toho, kdo to na Ulož to uložil, byly normálně čitelné, zatímco u mě některé názvy čitelné nebyly, zřejmě používal jinou znakovou sadu, než já. (Jakou znakovou sadu používal, jsem mohl zjistit pomoci příkazu, jako ls /cesta/ke/stazenym/souborum > vypis.txt a potom zjistit, v jaké znakové sadě se mi vytvořil ten textový soubor s výpisem.) Názvy stažených souborů a složek jsem musel opravit, protože jinak vypadaly nepřehledně, blbě se vypalovaly, nešly kopírovat na flashku a podobné problémy.

[Filip Jirsák]

Souborový systém ISO 9660 v základní verzi znaky s diakritiky vůbec nepodporuje, rozšíření Joliet naopak definuje, že se jména souborů ukládají v UCS-2. Takže zrovna v případě vypálení je problém s názvy souborů minimální, protože tam je způsob kódování znaků jasný.

[DWD]

Příkaz sed -i 's/stare/nove/g' soubor nahradí všechny slova staré slovy nové. Vyzkoušel jsem to zatím u jednoho souboru a funguje to. Ale co když budu chtít nahradit slova, které obsahuje i lomítka a podobně? To by se potom mohlo mydlit s lomítkama, které jsou součásti původního příkazu. Například budu chtít všechny slova stary/papir nahradit slovy nove/papiry. Co potom? Půjde to vůbec? Třeba takto to půjde asi těžko: sed -i 's/stary/papir/nove/papiry/g' soubor

[Ash]

Jsou dvě možnosti, buď escapovat lomítka, nebo použít jiný znak, který se ve výrazech moc nevyskytuje (lze téměř cokoliv, já často volím čárku, někdo dává hash (#) apod.)

sed -i 's/start\/papir/nove\/papiry/g' soubor
sed -i 's,start/papir,nove/papiry,g' soubor
sed -i 's#start/papir#nove/papiry#g' soubor

[Patrik Uhrak]

sed -e 's/stary\/papir/novy\/papir/g' subor

Mozno by bola vhodna prirucka k sed-u. ;)

[Patrik Uhrak]

Ospravedlnujem sa, ash to tu vysvetlil a najma pre polhodinou. Nedal som refresh stranky. :)

[Bilbo]

Takže zrovna v případě vypálení je problém s názvy souborů minimální, protože tam je způsob kódování znaků jasný.

Teoreticky, ovšem v praxi když někdo něco vypaluje, šance že vypalovací program z lokální místní znakové sady (dnes obvykle UTF-8, ale dříve tam mohlo být leccos) to do toho UCS-2 převede dobře (t.j. ne jako paznaky) se ani zdaleka neblíží 100% (byť je to lepší než kdysi, kdy správně vypálená diakritika byla spíše vyjímka)

[pavlix]

Ono i obyčejné NTFS je v tomto směru oproti linuxovým systémům úžasně napřed.

[Ash]

V jakém směru? Nějaká souvislost s vypalováním, ISO 9660 či Joliet? :D Nechápu lidi co mají v dnešní době problém s diakritikou, to musí být v hlavě.

[pavlix]

Nechápu lidi co mají v dnešní době problém s diakritikou, to musí být v hlavě.

Běžné linuxové FS nemají definované kódování názvů souborů. Lze se maximálně tvářit, že mají (UTF-8 je přece už všude, ne?). NTFS má definované kódování názvů souborů.

Jakákoli souvislost s 9660 je čistě náhodná.

[Ash]

Jo tohle, ano, toto omezení NTFS opravdu obsahuje. Osobně jsem rád, že mi nikdo nepřikazuje, jaké je to jediné správné kódování™, které mám používat.

[Filip Jirsák]

UTF-16 není zas tak marné kódování, dají se v něm uložit všechny znaky Unicode. To je dost volné omezení. Jinak by ale nebylo nutné, aby linuxové souborové systémy měly nějaké kódování nastavené napevno – úplně by stačilo, kdyby použité kódování bylo uloženo někde v metadatech souborového systému. Momentálně se název souboru bere jen jako posloupnost bajtů, a je na aplikaci (nebo knihovně), v jakém kódování ty bajty bude interpretovat.

[Michal Kubeček]

dají se v něm uložit všechny znaky Unicode

A to je také prakticky jediná jeho výhoda. Jinak UTF-16 téměř unikátním způsobem sdružuje téměř všechny nevýhody ostatních kódování.

[Sten]

Kódování v linuxových souborových systémech je také dané: bere se z locales. Proto taky linuxové souborové systémy nejsou úplně vhodné pro výměnná média, tam je lepší (i z dalších důvodů) UDF.

[Filip Jirsák]

Kódování v linuxových souborových systémech je také dané: bere se z locales.

Tak to je v praxi, ale je to špatně – chceme „kódování souborového systému“, ale máme „kódování aktuálně spuštěného programu“. Můžete na jednom systému spustit programy s různými locale, názvy souborů jsou ale na disku typicky uloženy v jednom kódování. Druhá možnost by byla ukládat kódování názvu souboru do rozšířených atributů, to mi ale připadá zbytečné – nenapadá mne reálný případ, kdy by bylo vhodné mít v jednom souborovém systému různá kódování názvů souborů.

[Sten]

Na druhou stranu by to znamenalo, že by se každý dotaz na souborový systém musel prohnat přes iconv (asi do UTF-8) a stejně tak všechna jména souborů. Takže by to mohlo dopadnou takhle:

open("jméno v ISO", "r")
 -> iconv "jméno v ISO" "jméno v UTF"
 -> syscall(open)
    -> kódování souborového systému = ISO
    -> iconv "jméno v UTF" "jméno v ISO"

A máte tu dva překlady, které jsou ale úplně zbytečné.

Btw. dneska stejně všechny distribuce používají UTF-8, takže se ukazuje, že je to zbytečné.

[pavlix]

Kódování v linuxových souborových systémech je také dané: bere se z locales.

Protiřečíš si.

[Bilbo]

Osobně s diakritikou dnes problém nemám dokud se soubor drží na linuxových systémech (XFS, EXT3), případně na NTFS (externí disky), tak to prostě funguje. Ale jakmile nahraju soubor na flashku (kde je FAT32) tak se obvykle diakritika rozmrví.

[Ash]

V zásadě by mělo stačit flašku montovat se správnými parametry, ne? Ale chápu že i pokud to problém řeší tak to může být obtěžující mount -o codepage=852,iocharset=utf8 /dev/flaška /mnt/flaška.

[Bilbo]

Teoreticky jo, ale pokud ty správné parametry nepoužije i druhá strana (což může být jednak linux, jednak třeba i Mac nebo windowsy, občas i různá zařízení typu televize nebo video s USB portem, kde není naprosto žádná kontrola nad mount parametry - pokud tam uvnitř teda vůbec je Linux) tak často diakritika končí zmršená.

Pokud potřebuju výjimečně někam dostat soubory i s diakritikou, tak je zabalím něčím (např. 7-zip) u čeho vím, že to s unicode názvy nemá problém, ale jinak radši bez diakritiky.

[Ash]

Aha, zmiňoval jsi že problém vznikne "jakmile nahraju soubor na flašku", tak jsem na to reagoval. Samozřejmě pokud Ti ho někdo donese zmršený tak to je jiná.

[Bilbo]

Tím jsem myslel, že když ho nahraju od sebe, tak ho tam ještě vidím dobře, ale jakmile je ta flashka u někoho jiného, tak tam už je to vidět blbě. I když opačně (na cizím systému někdo nahraje na moji flashku soubor z diakritikou a já pak u sebe vidím paznaky) to bohužel "funguje" často stejně.

[lertimir]

přece původní dotaz je: Jak změnit obsah souborů z jednoho kódování na jiný batchovým způsobem, včetně meta tagu u html? Ne jak změnit názvy souborů.

[Ash]

Doporučil bych to udělat nějak jednoduše, čili:

1. celý adresář zkopírovat (použijte mc nebo jiný váš oblíbený filemanager) třeba do adresáře novyroot
2. pak na všechny soubory v tom adresáři poštvat find spolu s recode nebo iconv (podle toho co máte po ruce)

   find novyroot -type f -exec recode iso-8859-2..utf-8 {} \;
   nebo
   find novyroot -type f -exec iconv -f iso8859-2 -t utf-8 {} \;

3. nakonec na soubory o kterých víte že chcete změnit tag (lze i na všechny, pokud tam tag není tak se nic nestane) použít find v kombinaci se sedem

   find novyroot *.html -exec sed -i -e "s/starytag/novytag/" {} \;

Nezapomeňte než začnete na zálohu, kterou nebudete mazat dřív, než budete mít jistotu že to máte dobře :)

[Ash]

Asi bych dal přednost recode, u iconv byste asi musel vytvářet nový soubor (v novém kódování) čili to je v mém "manuálu" špatně. recode překódovává in place takže pro vás bude jednodušší.