Dotaz: Jak obnovit cp1250 ulozene jako utf8

[dementni.lojzik]

Ahoj, mel jsem text v cp1250 a kdosi mi jej otevrel a ulozil v utf8 (otevrel a ulozil v kwrite, kde je mam automaticky nastaveno utf8, tj. cp1250 se otevrelo jako utf8 a jako utf8 ulozilo), vysledkem je zcela nesmyslne kodovani. Nevite o nejakem programku, ktery by ten text dokazal opravit? (zkousel jsem treba recode, ale bez uspechu ) Diky

Odpovědi

[Prom]

kwrite 4.5.7.

zazalohuj si soubor !!! (milionkrat overena rada na zacatek)

spusti kwrite

najdi soubor ktery chce otevrit

vyber spravne kodovani v select boxu vpravo nahore vedle cesty k souboru v oteviracim dialogu

prohlidni text jestli to tak vyhovuje

dej uloz jako (save as)

vyber kodovani ktere chces (napr cp 1250) a uloz soubor

to je jen pro jistotu, ze by otazka byla takhle "jednoducha". predpokladam, ze si se spise dostal do zapekliteho problemu s tim, ze sis "spatne" otevrel soubor v CP1250 kodovani jako UTF8 a vznikle pa-znaky ulozil jako UTF8.

testnul jsem to v kwrite a vypada to s tebou zle - paznaky byly nahrazeny otaznickem, cili (skoro)veskera diakritika anulovana - zkus pres neco kouknout na kody paznaku (napr. xxd, vi etc), jestli jsou vsechny to same, nic s tim uz neudelas.

prom

[dementni.lojzik]

jj, je to ta zapeklitejsi varianta. Vsechny znaky nejsou stejne, ale stejne me nenapada zadny jednoduchy zpusob, jak to vratit zpet .... (jen tak naokraj, nestalo se to me, jen po me kdosi chce, abych mu s tim pomohl...debatu o tom, ze to asi nevyresim zakoncil tim, ze by mozna nebylo spatne kdyby zacal zalohovat

[Dag]

Pokud jsou ty paznaky na každý dikrický znak jiné, tak to jsem řešil ve Vim hromadnou náhradou. Ani to tak nebolelo.

[dementni.lojzik]

presneji receno, kody znaku nejsou stejne v dusledku cehoz nejsou uplne stejne pak ani ty paznaky, ale co jsem vypozoroval, pak jeden paznak obvykle odpovida dvoum pismenum, takze jednoducha nahrada asi taky fungovat nebude. Navic toto byla situace na testovacim vzorku, ktery jsem si vyrobil sam. Kdyz jsem se ted dival na pokazeny original, tak tam jsou vsechny znaky stejne... No, aspon vim, ze se nemusim dal snazit

[Dag]

Hmmm, tak to mi nějak došly "chytrý" rady.

[Filip Jirsák]

jeden paznak obvykle odpovida dvoum pismenum

To je UTF-8 – tam se většina českých znaků s diakritikou zapisuje jako dva bajty.

Ten text byl uložen až po nějaké úpravě (přidání textu), takže je teď část v UTF-8 a část ve Windows-1250? Pak můžete zkusit např. iconv z UTF-8 do Windows-1250 s tím, že neznámé znaky se budou ignorovat, a pak provést opačnou konverzi. Případně můžete zkusit recode nebo enconv, třeba si s tím některý poradí.

[Mortal]

uprimnou soustrast
bohuzel neporadim ale pochlubim se se svym nedavnym trapenim s kodovanim:

mysql dump kde byl text v iso8859-2 ulozen jako utf8
vyresit se mi to podarilo pouze tim, ze jsem dostal pristup do database
udelal jsem dump s default charset latin1, tim jsem dostal dump v kodovani latin2 potom jsem editoval dump a zmenil vytvareni tabulek z charset=latin1 na UTF8 a pak jsem to uspesne naimportoval tak jak jsem potreboval aby to bylo a aby se nerozhodila diakritika (do UTF8)

pragramatorovi kterej tuhle db vytvoril jsem dal hodne prezdivek :)

[frEon]

jj, tak stimhle sem si taky uzil svoje.

[Ash]

Vypadá to bledě, zkusil jsem totéž ve vimu a znaky "ěščřž" byly dokonale zničeny (nahrazeny 3f 3f 3f 3f 3f), znaky "ýáíé" to přežily, ale asi to i záleží na pozici v textu. Pochybuji že je nějaká možnost zpětného procesu.

[Jiří Poláček]

Jak se zdá, zpětná oprava není možná. Kwrite neinterpretovatelné znaky (což budou asi všechny mimo rozsah základního ASCII) zobrazí pomocí znaku �, který se také při uložení souboru uloží namísto původních znaků. Snad je zřejmé, že k takovéto surjekci inverzní zobrazení neexistuje.

Kýžený prográmek by musel hádat, což by možná ve spolupráci se slovníkem nemuselo být až tak neúspěšné, ještě to tak ale naprogramovat …

[Filip Jirsák]

Kwrite neinterpretovatelné znaky (což budou asi všechny mimo rozsah základního ASCII)

KWrite snad není tak primitivní editor, že by zvládl jen 7bitové ASCII. Ostatně tazatel sám píše o UTF-8, takže jiné znakové sady snad KWritu nedělají problémy. Běžný český text zapsaný ve Windows-1250 je platnou sekvencí UTF-8 znaků, takže by s ním editor neměl mít problém. Pouze nebude mít pro některé znaky v písmu odpovídající tvar znaku, ale o tom by se editor snad ani neměl dozvědět. A textový editor hodný takového označení snad dnes nebude používat nějakou vlastní množinu znaků, se kterými umí pracovat, ale zvládne pracovat s celou Unicode sadou (nebo alespoň s původní 2bajtovou sadou Unicode). Jediná skupina znaků, se kterou by si editor nemusel tímto způsobem poradit, jsou řídící znaky, ty jsou ale pro Windows-1250 i UTF-8 stejné.

Výsledný uložený text tedy podle mne lze pořád brát jako text ve Windows-1250, pouze se tam budou někde vyskytovat české znaky zapsané v UTF-8. Což by u většiny z nich neměl být problém, protože české znaky v UTF-8 budou při interpretaci jako Windows-1250 vypadat vždy jako dvojice znaků, přičemž první znak se v českých textech běžně nevyskytuje (měkké l, A s přehláskou atd.). Takže stačí tyto dvojice nahradit jejich ekvivalentem ve Windows-1250 a je hotovo. Otázka je, zda to zvládne některý z konverzních programů aniž by poškodil okolní text, nebo zda je lepší těch pár znaků nahradit nějak „ručně“ (tj. postupný nahrazování jednotlivých párů v nějakém editoru přes funkci vyhledej-a-nahraď, nebo sedem nebo něčím podobným).

[Ash]

Potud teorie. Prakticky třeba vim také není primitivní editor, ale znaky ěščřž při analogickém postupu (iso8859-2 otevřít jako utf-8 a uložit jako utf-8) nevratně zničil.

[Jiří Poláček]

Ano, Kwrite výborně zvládá desítky různých kódování. To nicméně není v rozporu s tím, že (nejen) znaky s diakritikou z cp1250 jsou v utf-8 neinterpretovatelné (možná náhodně některé n-tice takovýchto znaků vytvoří platný čínský znak).

A na základě této zkušenosti bych pochyboval, zda tyto znaky skutečně jsou platné – proč by potom editor při uložení (neboť zde je kámen úrazu) tyto znaky namísto původní hodnoty nahradil znakem, který použil pro zobrazení? Možná je celý zádrhel v tom, že do paměti si editor při otevírání souboru načte ty znaky, které skutečně zobrazí, takže je logické, že je potom i uloží. Odpovídá to tomu, že při změně kódování v editoru je soubor načítán z disku znovu a veškeré neuložené změny jsou ztraceny.

[Filip Jirsák]

To nicméně není v rozporu s tím, že (nejen) znaky s diakritikou z cp1250 jsou v utf-8 neinterpretovatelné (možná náhodně některé n-tice takovýchto znaků vytvoří platný čínský znak).

Máte pravdu, UTF-8 je mnohem „děravější“, než jsem si myslel – třeba „ř“ ve Windows-1250 (0xF8) nemůže být na začátku žádné UTF-8 sekvence. Když dekódování sekvence vede na nějaký např. čínský znak, bylo by to vpořádku, ale neplatná UTF-8 sekvence způsobí načtení neznámého znaku.

Možná je celý zádrhel v tom, že do paměti si editor při otevírání souboru načte ty znaky, které skutečně zobrazí

Pokud editor umí pracovat s kódováním znaků UTF-8, pak nejspíš umí zobrazit celé Unicode (nevidím důvod, proč by tomu mělo být jinak). Pochybuji o tom, že by editor při každé změně písma znovu kontroloval, zda zvolené písmo definuje všechny potřebné znaky a znaky chybějící v písmu v paměti nahradil neznámým znakem. Ostatně na to stačí udělat jednoduchý test – změnit u českého textu písmo na nějaké bez českých znaků a pak zpět – české znaky se znovu zobrazí. Takže mezi zobrazením textu v textovém editoru a jeho interní reprezentací v paměti takhle vzájemné ovlivňování nebude. Problém tedy není v tom, že by editor nějaký znak neuměl zobrazit, ale že některé sekvence bajtů českého textu ve Windows-1250 jsou neplatné sekvence znaků v UTF-8 (standard tomu říká „ill-formed“ sekvence) – editor se s tím vypořádá tak, že danou sekvenci načte jako nějaký speciální znak.

[Jiří Poláček]

Problém tedy není v tom, že by editor nějaký znak neuměl zobrazit, ale že některé sekvence bajtů českého textu ve Windows-1250 jsou neplatné sekvence znaků v UTF-8 … – editor se s tím vypořádá tak, že danou sekvenci načte jako nějaký speciální znak.

Asi jsem se předtím špatně vyjádřil, neboť přesně takto jsem to myslel S konkrétním fontem tato problematika samozřejmě vůbec nesouvisí.

[Petr Drlik]

Asi jsem měl štěstí, ale včera jsem potřeboval do GRAMPSu přenest stará data v kodování 1250. Také tam byly při otevřené aplikaci kwrite(utf8) samé otazníky, kosočtverce a jiné piškuntálie. Po načtení (defaultně nastaven utf8) souboru jsem změnil kodování na 1250 a soubor jsem uložil pod jiným názvem v kodovani utf8. Po načtení do GRAMPSu už vše v pořádku

[B0biN]

Take jsem hodne bojoval a hodne mi pomohlo

iconv --from-code=ISO-8859-1 --to-code=UTF-8 ./oldfile.htm > ./newfile.html

[dementni.lojzik]

Diky vsem za diskuzi. Takze bych uzavrel, ze obecne zpetna transformace neni mozna...