Fórum Root.cz
Hlavní témata => Server => Téma založeno: jknapek 17. 08. 2017, 10:45:56
-
Zdravím,
chtěl bych se zeptat, zda je v dnešní době nutné /výhodou pro běžného uživatele Win pojmenovávat adresáře a soubory bez háček, čárek, mezer.
Je k tomu v dnešní době nějaký důvod? Může někdy soubor s háčkem "zaskřípat"? Např. při obnově dat?
Nastoupil jsem k novému zaměstnavateli a místní IT toto pravidlo vynucuje - nikde jsem doposud toto nezažil...
Díky za info.
Jarda
-
s těma mezerama: když potom předáváte název souboru nějaké commandlinové utilitce, musíte ho uzavřít do uvozovek, aby bylo pochopeno, že je to jeden název
co se týče diakritiky, může být plno problémů: například při uploadování souboru na web a pak pokusy se na něj odkazovat...
-
Diakritika může být problém.
- Odkazy na webu/intranetu
- Code page může být různá na různých pobočkách / u různých zákazníků (Widle se k UTF8 ještě nedopracovaly)
- Po rozbalení archivu z W se při diakritice na Linuxu rozsypou jména souborů
- Možnost problémů s některým SW, třeba kvůli nestandardním dialogům,...
-
Je k tomu spousta duvodu. Jakmile neco takovyho chces nekomu poslat, nasdilet, preulozit, otevrit z jinyho systemu, ....
Dokonce specielne ve widlich jsou primarnim duvodem ... prave widle. Protoze soudruzi v M$ se rozhodli, ze jeden charset nestaci, takze pokud hodlas zcela jakkoli v cemkoli neco takovyho pouzivat, tak musis neustale resit, jestli je to z GUI nebo z CMD nebo ... protoze pokazdy dostanes jiny kodovani. Widle pro cestinu pouziva samo win-1250, potom pouzivaji unicode (pozor, nikoli utf-8, ale UTF16) a pak samozreme jeste cp852. A jaky kodovani dostanes je zavisly na tom, z ktery strany do toho lezes ...
-
Když Ti někdo zabalí (= většinou zazipuje) adresář se soubory s nabodeníčky (nejlépe ještě s dalšími podadresáři), tak se z toho v linuxu po..., když se to budeš snažit někde rozbalit.
A je jedno, jestli z cli, nebo nějakým klikátkem z GUI...
-
Sám se tato pravidla, která vyžadují Vaši ajťáci, snažím vždy dodržovat na všech systémech, kde nějak pojmenovávám soubory - člověk nikdy neví.
-
V systémech, které pracují v UTF-8 by to být problém neměl (Win NT 4.0+).
Stává se ale, že menší, specializované systémy (nejčastěji z USA) na to nejsou připravené, a neumějí si s tím poradit.
V dnešní době by se na tom nemělo lpět bez konkrétního důvodu (stejně jako na formátu jmen souborů pro DOS 8+3), ale často se důvod najde.
Někdy bývá v IT nastavené pravidlo tak, aby byl subset znaků použitelný pro více OS, pak se nejčastěji vychází z POSIXU.
V praxi, kdybych nastoupil k zaměstnavateli, tak bych to nejprve respektoval. Kdybych ani po cca 3-6 měsících neviděl důvod pro takové pravidlo, inicioval bych změnu pravidla.
-
V systémech, které pracují v UTF-8 by to být problém neměl (Win NT 4.0+).
Windows nepoužívají UTF-8, jak již řečeno výše.
Někdy bývá v IT nastavené pravidlo tak, aby byl subset znaků použitelný pro více OS, pak se nejčastěji vychází z POSIXU.
Nevím o tom, že by POSIX vynucoval cokoli jiného než že název nesmí obsahovat "/".
V praxi, kdybych nastoupil k zaměstnavateli, tak bych to nejprve respektoval. Kdybych ani po cca 3-6 měsících neviděl důvod pro takové pravidlo, inicioval bych změnu pravidla.
Uživatel nemusí důvod vidět. Může to být např. proto, že nějaký interní systém (NFS, zálohování apod.) má s takovými soubory problém.
-
Nevím o tom, že by POSIX vynucoval cokoli jiného než že název nesmí obsahovat "/".
Aha, myslel jste "fully portable filenames", tak to jo.
-
Nevím, jak na Widlích… Ale v moderním operačním systému mi takové pravidlo přijde jak z minulého století.
Diakritiku používám běžně. U mezer se trochu zamýšlím a někdy je nahrazuji pomlčkami nebo podtržítky – nikoli kvůli tomu, že by to nefungovalo (to fungovat prostě musí, jinak je někde chyba a měla by se opravit), ale kvůli pohodlnosti – když s nějakými soubory pracuji často z příkazové řádky a nechce se mi psát "\ " nebo dávat název do uvozovek.
Každopádně tohle je na uživateli – co mu vyhovuje, co se mu bude líp používat. Pokud něco takového nařizuje správce systému, tak to značí spíš jeho neschopnost (nebo nefunkčnost toho systému).
-
Kromě webu by s diakritikou neměl být žádný problém. Windows jsou vnitřně v UTF16, stejně tak naprostá většina aplikací. Problém je, pokud je zapotřebí používat staré aplikace, které nepodporují unicode.
Ani v archivu není důvod, aby byl problém s diakritikou. I ten obyčejný ZIP podporuje od roku 2006 UTF8. Pokud to někde blbne, tak je to nejspíš zkomprimované nějakým šmejdem.
Ale nedivím se, že je někde takováto politika. Předchází to problémům do budoucna.
-
Nevím, jak na Widlích… Ale v moderním operačním systému mi takové pravidlo přijde jak z minulého století.
Co je moderní operační systém? Windows to plně podporují od verze NT 4.0, tedy od roku 1996. Zbytek je na vendorech, a i v GNU/Linux najdu dost příkladů, kdy to nefunguje správně ani dnes.
Nebo jak jste to myslel?
-
Windows to plně podporují od verze NT 4.0
Jasný. Plně. Akorát sem tam převedou anglický text na čínštinu, ale to je detail :))) https://en.wikipedia.org/wiki/Bush_hid_the_facts
-
Jasný. Plně. Akorát sem tam převedou anglický text na čínštinu, ale to je detail :))) https://en.wikipedia.org/wiki/Bush_hid_the_facts
:) ano, to je kouzelný bug :))). Přesto, v té době bylo UTF-8/16 např. v GNU/Linux poměrně nezvyklé, default byl en_US.ISO-8859-1, v CZ prostředí pak cs_CZ.ISO-8859-2, a do praxe se UTF8 dostával až později, a později než na Windows. Tím nechci zpochybňovat světlé (ale bolestivé) výjimky.
-
... Windows to plně podporují od verze NT 4.0, tedy od roku 1996. ...
jiste ... psal si nekdy ve widlich script? Treba takovou blbost jako kopii z jednoho folderu do druhyho? A jak ze to to ten nodepad s tema nabodenickama ulozi? Nojooo ... windows-1250 ... a zkusil si to pak i zpusit? Z commandline? Jo? A fungovalo to? Tezko vid... kdyz tam ti widle vracej cp852.
Jeste vetsi legrace to je, kdyz napises binarku ... protoze tam musis pocitat s tim, ze to bude spousteny ruznejma zpusobama ... a podle toho ti to bude vrace ruzny vysledky. Fakt parada.
-
jiste ... psal si nekdy ve widlich script? Treba takovou blbost jako kopii z jednoho folderu do druhyho? A jak ze to to ten nodepad s tema nabodenickama ulozi? Nojooo ... windows-1250 ... a zkusil si to pak i zpusit? Z commandline? Jo? A fungovalo to? Tezko vid... kdyz tam ti widle vracej cp852.
Jeste vetsi legrace to je, kdyz napises binarku ... protoze tam musis pocitat s tim, ze to bude spousteny ruznejma zpusobama ... a podle toho ti to bude vrace ruzny vysledky. Fakt parada.
Ano, to máte pravdu, ale filesystem a knihovny na to připravené byly. Pojďme uhasit flame, to byla reakce na Frantu a jeho narážku na moderní operační systém. V devadesátých jsem scriptoval jak ve Windows, tak v Linuxu, a obojí mělo své. Asi už jsem moc senilní, ale neumím rozlišit, co z toho bych měl považovat za moderní systém... Snad jedině z toho, co jsem v té době poznal můžu vyřadit VAX/VMS, který, jestli se pamatuju, UTF nepodporoval vůbec.
-
Mám problém v irb v ruby v terminálu na Mac OS X. když chci napsat třeb ů, tak mi to napíše \U+FFC5\U+FFAF. Co to sakra je? to ani není UTF32. Dělá to u ů a ť a dalších(2x U+), u jiných to dělá "jen" 1xU+ :(č,ř) Navíc, v uvozovkách se to vyhodnotí jako nic:
irb(main):009:0> '\U+FFC5\U+FFAF'
=> ""
Takže adresáře mi to přečte dobře (` Dir.open("Downloads").entries`), ale už s nimi nejde pracovat.
Proč to má takovéhle haluze při zpracování písmen?
-
Mám problém v irb v ruby v terminálu na Mac OS X. když chci napsat třeb ů, tak mi to napíše \U+FFC5\U+FFAF. Co to sakra je? to ani není UTF32. Dělá to u ů a ť a dalších(2x U+), u jiných to dělá "jen" 1xU+ :(č,ř) Navíc, v uvozovkách se to vyhodnotí jako nic:
irb(main):009:0> '\U+FFC5\U+FFAF'
=> ""
Takže adresáře mi to přečte dobře (` Dir.open("Downloads").entries`), ale už s nimi nejde pracovat.
Proč to má takovéhle haluze při zpracování písmen?
Prostě v tom fontu, co používá terminál, nejsou ty konkrétní znaky, tak to místo nich vyhazuje náhradu. Vyměň font.
Jinak to samozřejmě není UTF32, je to UTF8. To funguje trochu jinak, je tam pro znaky mimo ASCII sekvence dvou nebo několika bytů, který spojí plusem. A v těch uvozovkách to nebere jako kód znaku, ale jako řetězec.
-
Notepad to uloží tak, jak si to zvolíš. Já bych volil Unicode.
A že autodetekce kódování může selhat, je možná úsměvné, ale žádná tragedie to není. Dá se to zvolit ručně.
Mimochodem - on ten notepad fakt někdo používá? ;)
-
A že autodetekce kódování může selhat, je možná úsměvné, ale žádná tragedie to není. Dá se to zvolit ručně.
Když se program tváří, že něco umí a ve skutečnosti to tragickým způsobem neumí, tak to není úsměvné, ale je to osina v (_|_), jako ostatně polovina věcí na Windows.
-
Když se program tváří, že něco umí a ve skutečnosti to tragickým způsobem neumí, tak to není úsměvné, ale je to osina v (_|_), jako ostatně polovina věcí na Windows.
Určitě tu nechci hájit kvalitu woken, ale toto je úplně zbytečný flame.
Tuhle kravinu opravili před více než deseti lety...
-
Určitě tu nechci hájit kvalitu woken, ale toto je úplně zbytečný flame.
Tuhle kravinu opravili před více než deseti lety...
Opravili a neopravili. Podle odkazu nekde vyse zmenili v Notepadu metodu detekce kodovani, ale neopravili knihovnu, kterou drive Notepad k detekci pouzival. Vysledkem je, ze v Notepadu to chodi, ale SW, ktery pouziva tu knihovnu, je na problem stale nachylny.
-
Opravili a neopravili. Podle odkazu nekde vyse zmenili v Notepadu metodu detekce kodovani, ale neopravili knihovnu, kterou drive Notepad k detekci pouzival. Vysledkem je, ze v Notepadu to chodi, ale SW, ktery pouziva tu knihovnu, je na problem stale nachylny.
Řeč byla o tak zásadní komponentě voken jako je Notepad :D
Ano, heuristika se může splést, dokumentace k tomu říká jasně "These tests are not foolproof." Ale k tomu snad ani není třeba vzdělání nebo inteligence, aby to člověk pochopil :)
-
Řeč byla o tak zásadní komponentě voken jako je Notepad :D
To je mozne, nicmene spravnou cestou je oprava tak zasadni komponenty, jako je systemova knihovna. Urcite ne dalsi widlacky workaround v SW, ktery na te knihovne stavi.
-
To je mozne, nicmene spravnou cestou je oprava tak zasadni komponenty, jako je systemova knihovna. Urcite ne dalsi widlacky workaround v SW, ktery na te knihovne stavi.
Notepad - software, který staví na knihovně advapi32.dll :) :) :)
Začíná to tu být čím dál zábavnější. ;)
Asi by nebyl problém to vylepšit, stačilo by upravit statistiky. S takhle malým vzorkem textu bude ale vždycky problém, není tam ani odřádkování.
Nevím, proč to nevylepší, možná drží zpětnou kompatibilitu. Ale spíš jim to je jedno. Je to okrajová funkce, pochybuji, že ji někdo soudný používá.
-
Je to okrajová funkce, pochybuji, že ji někdo soudný používá.
To je mozne, ale potiz je v tom, ze se nejedna o pristup k opravam chyb, ktery by byl spise vyjimecny. Oni chyby radsi prohlasi za ficuru a nechaji. Mozna proto, ze by se pak posralo hafo SW, ktere jiz maji implementovane vselijake uchylne workaroundy.
-
ů, tak mi to napíše \U+FFC5\U+FFAF.
Prostě v tom fontu, co používá terminál, nejsou ty konkrétní znaky, tak to místo nich vyhazuje náhradu.
EE. Problém výše je POUZE v irb. Normálně v terminálu bez problémů (v pythonu taky), jdou vypisovat i vkládat v pohodě ščť...., dokonce i příkaz ruby funguje OK:
user$ ruby -e 'print "\xC3\xA1á" =>> vypíše áá
Problém je tedy vstup - po stisku klávesy á (písmeno v UTF-8 je C3 A1) se zobrazí \U+FFC3\U+FFA1 -> a dokonce backspace se chová jinak, protože nemaže po znacích ( U,+,F,F,C,3,\,U,+,F,F,A,1,). ale po těch Učkách" ( \U+FFC3,\U+FFA1)
, tedy irb musí nějak motat kódování. ale vypisovat umí správně, pokud "nějak vstup dostane")
-
Nastoupil jsem k novému zaměstnavateli a místní IT toto pravidlo vynucuje - nikde jsem doposud toto nezažil...
Muze to byt (krome problemu, o kterych se zminuji predrecnici) taky proto, aby ten soubor bez problemu zpracoval kolega ze zahranici. Ja vim, neni problem napriklad dostat soubor s azbukou (cyrilici) v nazvu, ale jsem si docela jisty, ze budou problemy napriklad pri vyhledavani atd. (tedy ja bych je mel :p a to azbuku umim)