Fórum Root.cz
Hlavní témata => Server => Téma založeno: rado3105 21. 12. 2012, 11:53:18
-
Na disku, ktory mam ako ulozisko ak skopirujem nejake subory z windows prostredia zobrazuju sa nespravne a je potrebne ich premenovat. Pravdepodobne to je tym ze windows je 1250 a linux ma defaultne utf-8. Je mozne nejako nastavit prostredie aj pre cp-1250 aj utf-8? vdaka
-
http://lmgtfy.com/?q=samba+cp1250
-
Praveze to nie je problem len samby...vlastne momentalne som vybral dany disk a pripojil do linuxu a znaky nespravne zobrazene, cize som v prostredi desktopu....
Tieto subory pravdepodobbe vznikli skopirovanim z windowsackych masin cez ssh. Znaky su zobrazene roznymi stvorcekmi....a nie je mozne ich citanie az po prepisani...Rad by som tomu predisiel aby sa to zobrazovalo spravne ci uz pri kopirovani cez ssh alebo na serveri....
popripade ako zabezpecit sucasne zobrazovanie utf-8 aj cp-1250 alebo ako premenit cp-1250 do utf-8?
-
skusil som toto:
convmv -r --notest -f cp1250 -t utf8 /media/wd3tb/ostatne/Humor
a problem je zo š a č....inak vsetko vyzera ze robi spravne, ale š a č prehodi do paragrafov a inych blbosti...
-
Na zálohování pro připojení do Win7 používám něco takového:
sudo mount.cifs //"$mpointserver" "$mpointclient" -o \
username="$username1",\
password="$password1",\
iocharset=utf8,\
uid="$uid01",\
gid="$gid01",\
dir_mode=0775,\
file_mode=0664,\
nounix,\
noserverino >/dev/null
-
Praveze to nie je problem len samby...vlastne momentalne som vybral dany disk a pripojil do linuxu a znaky nespravne zobrazene, cize som v prostredi desktopu....
Nechapu pointu.
Tieto subory pravdepodobbe vznikli skopirovanim z windowsackych masin cez ssh. Znaky su zobrazene roznymi stvorcekmi....a nie je mozne ich citanie az po prepisani...Rad by som tomu predisiel aby sa to zobrazovalo spravne ci uz pri kopirovani cez ssh alebo na serveri....
popripade ako zabezpecit sucasne zobrazovanie utf-8 aj cp-1250 alebo ako premenit cp-1250 do utf-8?
Filesystém neřeší kódování názvu souborů - co mu předám, to tam prdne. Když vytvořím soubor s názvem 0x01 0x02 0x03, tak s tam prostě bude jmenovat. Jak název 0x01 0x02 0x03 zobrazit, to už je otázkou jiných částí OS. Čili soubory a kódování spolu nijak nesouvisí.
Takže není jiné řešení, než zjistit, kdo, jak a proč tam ty soubory s podivným kódováním vytvořil. Pokud je tam nahrál přez ssh, je potřeba to řešit na úrovni ssh. Pokud přes sambu, musí se to řešit konfigurací samby.
Takže žádné "současné zobrzování X a Y" neexistuje.
A co se týče toho "přemenění X na Y", tak to se udělat dá. Prostě se jméno souboru zmení z řetězce kódovaného v X na řetězec kódovaný v Y. Je ale potřeba myslet na to, že když potom na ten soubor někdo šáhne tím způsobem, kterým ho tam nahrál, bude mít zase zmršené kódování on, protože očekává, že názvem soubru je řetězec kódovaný v X.
-
Nerozumieme sa, zle som sa vyjadril. Uzivatelia, ktori tam nahravaju subory maju windowsy, tam subory ktore sa modifikuju alebo vytvoria v tomto prostredi su v cp1250. Tento subor nahraju na server a server ho nevie spravne citat, kedze pozna len utf-8. cp-1250. Mozno keby som ich namountoval ako cp1250 slo by to, lenze problem je ze na danom disku su aj cp1250 a utf-8. Takze najvhodnejsie by bolo vyhladat a prekonvertovat nazvy suborov z cp1250 do utf8. Ten convmv to robi presne ako si predstavujem problem je ze nevie zobrazit š a č a prepise ich nespravne.
Viete pomoct ako prekonvertovat cp1250 do utf8 a zobrazit vsetko spravne vratane š a č?
-
Ať to popisuješ jak to popisuješ, pořád to vypadá na špatně nastavenou sambu. Pokud je správně nastavenéné kódování s cmb.conf, tak je naprosto jedno, jestli ukládá na disk, kde je utf-8 či iso-8859-2 ... české znaky se musí zobrazit prostě správně. Na zbytku disku můžeš mít soubory i v tom utf-8 a vždy by si u obojího měl vidět diakritiku správně a to jak z Windows, tak z Linuxu.
-
samba sluzi len ako read(takze cez sambu sa nic nezapisuje).
Zapisuje sa cez ssh.
Disk som vybral zo servera, pripojil k desktopu(tu mam xubuntu) a znaky sa zobrazuju nespravne. Ako to je mozne?
-
No tak tady bude asi problém v tom ssh. Já ssh používám nad sambou (kde je definována ona konverze kódování), nikdy mne nenapadlo pokusit se o to přímo. No přijde mi to logické, že to nefunguje. Ukládáš CP-1250 do UTF-8 bez koverze, takže výsledkem musí být nesmyslné znaky po uložení. On už prostě špatně ukládá ... to se potom špatně čte. Když to uděláš pře sambu, tak sambě řekneš, před ukládáním převeď do utf-8 a před načtením převeď do CP1250, proto to oba systémy vidí dobře. Jinak předpokládám, že v konzoli na linuxu Ti české znaky funfují správně.
-
http://i46.tinypic.com/2rmblg9.png
takto to vyzera...
-
Nerozumieme sa, zle som sa vyjadril. Uzivatelia, ktori tam nahravaju subory maju windowsy, tam subory ktore sa modifikuju alebo vytvoria v tomto prostredi su v cp1250. Tento subor nahraju na server a server ho nevie spravne citat, kedze pozna len utf-8. cp-1250. Mozno keby som ich namountoval ako cp1250 slo by to, lenze problem je ze na danom disku su aj cp1250 a utf-8. Takze najvhodnejsie by bolo vyhladat a prekonvertovat nazvy suborov z cp1250 do utf8. Ten convmv to robi presne ako si predstavujem problem je ze nevie zobrazit š a č a prepise ich nespravne.
Viete pomoct ako prekonvertovat cp1250 do utf8 a zobrazit vsetko spravne vratane š a č?
Já myslím, že já ti rozumím dobře. V opačném směru nevím, jestli není nějaký šum :)
Ještě jednou: zapsat název souboru v patřičném kódování musí ta aplikace, která soubory vytváří - protože OS prostě do názvů souborů nezasahuje - jak mu název aplikace předá, tak se zapíše na disk. "Uživatelé zapisují soubory" neznamená nic jiného, že spouští nějaký klientský program, který komunikuje s nějakým serverovým programem, kterému řekne "tady ti posílám soubor stčskrz" - když to "č" zakóduje jako 0x86 a serverový program ho nepřekóduje, tak se na disku vytvoří soubor "str[0x86]skrz". Když ho zakóduje jako 0x87, tak se vytvoří "str[0x87]skrz". Pokud klientský OS zobrazuje 0x86 jako "č" a serverové programy zobrazují 0x86 jako "ž", tak v serverových programech uvidíš soubor "stržskrz" a v klientských uvidíš "strčskrz". Na disku ale každopádně není nic jiného než "str[0x86]skrz".
Čili pokud ti jde opravdu jenom o zápis souborů přes scp z Windows, potom musíš problém řešit na úrovni scp - buď scp server na Linuxu, nebo scp klient na Windows musí názvy souborů správně překódovat. A pokud soubory potom čteš přes sambu, musí názvy zase samba překódovat zpět. OS do toho nijak nemluví a nemá s tím víceméně nic společného (kromě toho, že programům předává default formou locales).
-
V konzoel su taktiez znaky nespravne....
-
Nerozumieme sa, zle som sa vyjadril. Uzivatelia, ktori tam nahravaju subory maju windowsy, tam subory ktore sa modifikuju alebo vytvoria v tomto prostredi su v cp1250. Tento subor nahraju na server a server ho nevie spravne citat, kedze pozna len utf-8. cp-1250. Mozno keby som ich namountoval ako cp1250 slo by to, lenze problem je ze na danom disku su aj cp1250 a utf-8. Takze najvhodnejsie by bolo vyhladat a prekonvertovat nazvy suborov z cp1250 do utf8. Ten convmv to robi presne ako si predstavujem problem je ze nevie zobrazit š a č a prepise ich nespravne.
Viete pomoct ako prekonvertovat cp1250 do utf8 a zobrazit vsetko spravne vratane š a č?
Já myslím, že já ti rozumím dobře. V opačném směru nevím, jestli není nějaký šum :)
Ještě jednou: zapsat název souboru v patřičném kódování musí ta aplikace, která soubory vytváří - protože OS prostě do názvů souborů nezasahuje - jak mu název aplikace předá, tak se zapíše na disk. "Uživatelé zapisují soubory" neznamená nic jiného, že spouští nějaký klientský program, který komunikuje s nějakým serverovým programem, kterému řekne "tady ti posílám soubor stčskrz" - když to "č" zakóduje jako 0x86 a serverový program ho nepřekóduje, tak se na disku vytvoří soubor "str[0x86]skrz". Když ho zakóduje jako 0x87, tak se vytvoří "str[0x87]skrz". Pokud klientský OS zobrazuje 0x86 jako "č" a serverové programy zobrazují 0x86 jako "ž", tak v serverových programech uvidíš soubor "stržskrz" a v klientských uvidíš "strčskrz". Na disku ale každopádně není nic jiného než "str[0x86]skrz".
Čili pokud ti jde opravdu jenom o zápis souborů přes scp z Windows, potom musíš problém řešit na úrovni scp - buď scp server na Linuxu, nebo scp klient na Windows musí názvy souborů správně překódovat. A pokud soubory potom čteš přes sambu, musí názvy zase samba překódovat zpět. OS do toho nijak nemluví a nemá s tím víceméně nic společného (kromě toho, že programům předává default formou locales).
Tak este raz sa pytam je mozne cp1250 prekonvertovat do utf-8. Neriesme to ako sa to tam dostalo...ale zaujima ma ako to prekonvertovat, nech to je vsetko utf-8....
Je to vlastne mozne? Dakujem
-
V konzoli jsou znaky nespravne, to jsem pochopil, ale pise ti konzole znaky spravne? Jde o to, že jestli i v konzoli ti diakritika píše špatně, můžeš mít špatně nastavené locales pro konzoli a soubory tam mohou mít znaky správně, pak je konverze možná a poměrně jednoduchá.
-
Tak este raz sa pytam je mozne cp1250 prekonvertovat do utf-8. Neriesme to ako sa to tam dostalo...ale zaujima ma ako to prekonvertovat, nech to je vsetko utf-8....
Je to vlastne mozne? Dakujem
Píšu to nějak nesrozumitelně, nebo v čem je problém? Ptáš se mě, jestli jde název souboru změnit z "str[0x86]skrz" na "str[0x87]skrz"? Ano, to jde - říká se tomu přejmenování souboru.
-
Já jsem přehlédl ten screen ... tady jedině ten convmv ... ale to jsi psal, že nepomáhá.
-
Já jsem přehlédl ten screen ... tady jedině ten convmv ... ale to jsi psal, že nepomáhá.
Jestli convmv mrší názvy souborů, tak mu byly předány špatné parametry (na disku je jiné kódování než jaké jsem mu zadal jako výchozí, popř. OS používá jiné kódování než jaké jsem mu zadal jako cílové).
...a to jsme právě u toho, že je potřeba vědět, jakým způsobem tam byly ty názvy vytvořeny. Ale to rado nechce řešit, tak to asi bude každá rada drahá :)
-
Mirku, teď teoretická otázka ... když si označí jeden ten otazník a nechá ho přejmenovat na správné písmeno, přejmenuje tím všechny otazníky, nebo jen ten správný? Myslel jsem třeba na Gwenrename ... to asi nevyjde, viď?
-
Mirku, teď teoretická otázka ... když si označí jeden ten otazník a nechá ho přejmenovat na správné písmeno, přejmenuje tím všechny otazníky, nebo jen ten správný? Myslel jsem třeba na Gwenrename ... to asi nevyjde, viď?
Gwenrename neznám. Ale s otazníky bych moc nepracoval - jako otazník se obvykle zobrazuje něco, co program neví, jak zobrazit. Takže jako (stejný) otazník se můžou zobrazovat různé odlišné znaky.
Já bych to udělal tak, že bych se prvně snažil zjistit, v jakém kódování ty názvy jsou. Pokud by se mi to nepodařilo, použil bych pro convmv nějaké nejbližší kódování - třeba to cp1250. A těch pár znaků, které by byly zmršené, bych napravil ručně napsaným skriptíkem, třeba v Pythonu. Je to prasárna, ale co, jinak to dost dobře nejde, pokud mám něco kódované neznámým způsobem.
Ještě by možná stálo za to zkusit kódování CP852 a iso-latin-2, ty se občas někde taky z různých důvodů můžou objevit.
-
Přesně to jsem si myslel. Pravdou je, že chyba vznikla při zapisování. Proto to teď oba systémy vidí špatně. Ale nabízí se otázka, mám disk připojenej v UTF-8, ukládám na něj CP1250 bez konverze do UTF-8, jako co to uloží? Podle mne jako CP1250, ale jelikož je disk připojenej jako UTF-8 tak to potom i Windows čtou jako UTF-8, proto špatné znaky. A linux má nastavené UTF-8 a je to uložené v CP1250, proto špatné znaky. Potom je ale nelogické, že by convmv nezabral u dvou znaků. Někde je asi chyba :-D
-
Přesně to jsem si myslel. Pravdou je, že chyba vznikla při zapisování. Proto to teď oba systémy vidí špatně. Ale nabízí se otázka, mám disk připojenej v UTF-8, ukládám na něj CP1250 bez konverze do UTF-8, jako co to uloží? Podle mne jako CP1250, ale jelikož je disk připojenej jako UTF-8 tak to potom i Windows čtou jako UTF-8, proto špatné znaky. A linux má nastavené UTF-8 a je to uložené v CP1250, proto špatné znaky. Potom je ale nelogické, že by convmv nezabral u dvou znaků. Někde je asi chyba :-D
pavel presne ako pisete....
-
V konzole pise znaky dobre, nie je to sposobene chybou v locale, je to prense ako pise pavel...linuxy su defaultne samizda v utf-8, windowsy cp-1250, ked sa to kopiruje tak sa to nejako poskodia locale, alebo len system nepozna cp-1250...problem je, ze ked chcem v linuxe dany subor so zlym nazvom kopirovat - nejde, takze nemam ani ako overit ci ho otvori spravne vo windowse ako cp1250. Ako zistit aky to je typ kodovania?
-
skusil som convmv so vstupny cp852 a funguje... je mozne nejako automaticky detegovat typ kodovania nasledne kovertovat?
-
Proto to teď oba systémy vidí špatně.
To těžko - ten, který to zapsal, by to viděl správně.
Ale nabízí se otázka, mám disk připojenej v UTF-8, ukládám na něj CP1250 bez konverze do UTF-8, jako co to uloží?
No to je právě to, o čem jsem psal - a zjevně nesrozumitelně, nebo nevím :)
Nemáš "disk připojenej v UTF-8". Jenom máš soubory na disku zapsané v kódování UTF-8.
ukládám na něj CP1250 bez konverze do UTF-8, jako co to uloží?
Můžeš si to vyzkoušet třeba pomocí toho Pythonu. Řetězec "čert" se v CP1250 zakóduje jako E8 65 72 74, zatímco v Unicode jako C4 8D 65 72 74:
>>> for b in bytearray(u"čert","utf8"): print "%X"%b
C4
8D
65
72
74
>>> for b in bytearray(u"čert","cp1250"): print "%X"%b
E8
65
72
74
Takže pokud na disk zapíšeš soubor s názvem E8 65 72 74 a budeš se ho snažit dekódovat jako řetězec v Unicode, vyjde ti v tomhle případě (kurnik, příklad jsem zvolil blbě! ;) neplatný utf-8 řetězec, který se nejspíš zobrazí jenom jako "ert" nebo "?ert":
>>> bytearray([0xe8,0x65,0x72,0x74]).decode("utf-8")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe8 in position 0: invalid continuation byte
-
Jenom máš soubory na disku zapsané v kódování UTF-8.
Přesněji *názvy souborů* zapsané atd.
-
Prostě codepage je UTF-8 ;-) však si rozumíme.
-
Prostě codepage je UTF-8 ;-) však si rozumíme.
No ale to se týká jenom zobrazování (a řazení apod.) Netýká se to zapisování na disk. Klidně můžeš mít deset adresářů, v jednom mít soubory s názvy v UTF-8 kódování, v jiném s iso-8859-2 kódováním, ve třetím ...atd... Akorát teda jenom jeden adresář se ti bude zobrazovat tzv. "správně" - a bude to právě ten, který má názvy souborů kódovány tak, jak máš aktuálně nastavené zobrazování (locales). Takže můžeš klidně přepínat mezi deseti různými locales a postupně budeš vidět "správně" soubory v jednom z těch deseti adresářů.
-
skusil som convmv so vstupny cp852 a funguje... je mozne nejako automaticky detegovat typ kodovania nasledne kovertovat?
Ty máš vlastně na tom disku soubory i ve správném kódování ... hele, tohle bych raději rozdělil ručně. Přijde mi to jako nejbezpečnější.
-
Prostě codepage je UTF-8 ;-) však si rozumíme.
No ale to se týká jenom zobrazování (a řazení apod.) Netýká se to zapisování na disk. Klidně můžeš mít deset adresářů, v jednom mít soubory s názvy v UTF-8 kódování, v jiném s iso-8859-2 kódováním, ve třetím ...atd... Akorát teda jenom jeden adresář se ti bude zobrazovat tzv. "správně" - a bude to právě ten, který má názvy souborů kódovány tak, jak máš aktuálně nastavené zobrazování (locales). Takže můžeš klidně přepínat mezi deseti různými locales a postupně budeš vidět "správně" soubory v jednom z těch deseti adresářů.
A to je přesně jeho současný stav. Má tam "správné" soubory v UTF-8 a "nesprávné" v cp852 na jednom disku a chtěl by zautomatizovat převod. Já mu poradil ruční oddělení na "správné" a "nesprávné". Přijde mi to jako nejbezpečnější. Ale určitě to lze nějakým scriptem zautomatizovat, leč bez zálohy bych to raději nezkoušel, aby nepokazil i ty "správné".
-
Jinak chyba je ta, že při zápisu z Windows to neprochází konverzí do správného kódování. Což v smb.conf nastavují parametry unix charset a dos charset alespoň já to tak mám. On to prostě poslal přímo přes SSH bez samby, což jsem ani netušil, že lze, ale budiž. Tady podle mne vzniklo to špatné zobrazování.
-
A to je přesně jeho současný stav. Má tam "správné" soubory v UTF-8 a "nesprávné" v cp852 na jednom disku a chtěl by zautomatizovat převod. Já mu poradil ruční oddělení na "správné" a "nesprávné". Přijde mi to jako nejbezpečnější. Ale určitě to lze nějakým scriptem zautomatizovat, leč bez zálohy bych to raději nezkoušel, aby nepokazil i ty "správné".
No to by právě musel líp položit dotaz. Pokud má adresář, o kterým ví, že jsou tam jenom soubory v jednom určitým kódování, tak to není problém, pokud to potřebuje provést jenom jednorázově a nové soubory tohodle typu se mu tam už objevovat nebudou.
-
A to je přesně jeho současný stav. Má tam "správné" soubory v UTF-8 a "nesprávné" v cp852 na jednom disku a chtěl by zautomatizovat převod. Já mu poradil ruční oddělení na "správné" a "nesprávné". Přijde mi to jako nejbezpečnější. Ale určitě to lze nějakým scriptem zautomatizovat, leč bez zálohy bych to raději nezkoušel, aby nepokazil i ty "správné".
No to by právě musel líp položit dotaz. Pokud má adresář, o kterým ví, že jsou tam jenom soubory v jednom určitým kódování, tak to není problém, pokud to potřebuje provést jenom jednorázově a nové soubory tohodle typu se mu tam už objevovat nebudou.
Přesně.
-
A to je přesně jeho současný stav. Má tam "správné" soubory v UTF-8 a "nesprávné" v cp852 na jednom disku a chtěl by zautomatizovat převod. Já mu poradil ruční oddělení na "správné" a "nesprávné". Přijde mi to jako nejbezpečnější. Ale určitě to lze nějakým scriptem zautomatizovat, leč bez zálohy bych to raději nezkoušel, aby nepokazil i ty "správné".
No to by právě musel líp položit dotaz. Pokud má adresář, o kterým ví, že jsou tam jenom soubory v jednom určitým kódování, tak to není problém, pokud to potřebuje provést jenom jednorázově a nové soubory tohodle typu se mu tam už objevovat nebudou.
Přesně.
vacsina - 98% suborov je utf-8, par ich je cp-1250, cp852...len to nemam ako zistit, jedine rucne skusat....a robit to na tisickach textovych komunetoch a hudobnych suboroch...asi nie je riesenie....
nebavme sa o sambe...subory sa tam dostali ze windowsak sa pripojil cez ssh na dany server a skopiroval tam subory cez winscp....
Dufam sa uz riadne chapeme. I ked to mohlo byt este z cias z roku 2001 ked som sa hraval s madrakom...a viem ze bol problem s nazvami resp. locales vacsi ako teraz...neviem...ale to je jedno...
Existuje nejake riesenie ktore by mi naslo subory ktore su cp852 a ktore cp1250? ale asi nie....
-
takze niekde nejde ani cp-1250, cp852, cp1250 ani ten latin, co by este mohlo byt pre ceske a slovenske nazvy?
-
vacsina - 98% suborov je utf-8, par ich je cp-1250, cp852...len to nemam ako zistit, jedine rucne skusat....a robit to na tisickach textovych komunetoch a hudobnych suboroch...asi nie je riesenie....
nebavme sa o sambe...subory sa tam dostali ze windowsak sa pripojil cez ssh na dany server a skopiroval tam subory cez winscp....
Dufam sa uz riadne chapeme. I ked to mohlo byt este z cias z roku 2001 ked som sa hraval s madrakom...a viem ze bol problem s nazvami resp. locales vacsi ako teraz...neviem...ale to je jedno...
Existuje nejake riesenie ktore by mi naslo subory ktore su cp852 a ktore cp1250? ale asi nie....
Existuje, jmenuje se to enca
-
Existuje, jmenuje se to enca
S texty délky názvů souborů to těžko může fungovat.
-
takze niekde nejde ani cp-1250, cp852, cp1250 ani ten latin, co by este mohlo byt pre ceske a slovenske nazvy?
iso-8859-2, ale z windows je to velmi nepravděpodobné. Předpokládám, že když budeš mít adresář cp852, že v něm nebudeš mít soubory v jiném kódování, takže by to neměla být taková tragédie. Ovšem, jestli tomu tak není, tak Bůh s Tebou a hodně štěstí. Neber to jako výsměch, ale spíš, jako lítost.