[cstex] OFF TOPIC - Vyřešeno: Problém s kódováním souboru (různé znakové sady pohromadě???)

[Jaroslav Hajtmar]

Dobrý den.
Soukromě jsem konzultoval svůj problém s panem Olšákem  - nezdálo se mu, 
že by jeho řešení nefungovalo.
Poté, co jsem mu zaslal svá data, tak se je pokusil zpracovat svým 
skriptem a úspěšný výsledek se opravdu dostavil - celý výstup byl 
správně kódován  v UTF-8.

Následně po zaslání mých logů přišel pan Olšák na to, že na mém počítači 
to nefungovalo z toho důvodu, že jsem neměl správně vygenerován formát 
Csplainu, který by dokázal správně pracovat s UTF8. Poté, co jsem vše 
napravil a správně vygeneroval formáty pro CsPlain a pdfCsPlain, tak se 
konverze úspěšně zdařila i na mém počítači.

V aktuální verzi TL2012 není ještě v CsPlainu podpora UTF8 implicitně 
nastavena. Proto jsem udělal následující:

1. Stáhnul jsem od pana Olšáka soubor 
http://petr.olsak.net/ftp/cstex/base/csplain.tar.gz, který jsem rozbalil 
do své distribuce TeXlive 2012 a zaktualizoval...
2. Následně jsem vygeneroval nový formát csplainu, který pracuje s UTF8 
soubory. Návod na http://petr.olsak.net/ftp/cstex/doc/cstexman.pdf (str. 19)
3. Spustil jsem skript pana Olšáka a zpracoval jím příslušný soubor.

Po ukončení skriptu byl ve výstupním SQL souboru text kódovaný UTF8...
Vše tedy funguje přesně tak jak pan Olšák napsal.

Jak uvádí pan Olšák: "Drobný problémek je jen fakt, že místo prázdných 
řádků se tam zjevily \par. To ovšem dokáže šikovný uživatel odstranit 
pomocí najdi-nahraď v editoru případně místo původního návodu definuje:

   \def\viprintline{{\def\par{}\immediate\write\ofile{\tmp}}}


Panu Olšákovi jsem poslal dva DUMP soubory. Ten druhý mi vygeneroval 
správce serveru a na něm si TeX vylámal zuby, neboť soubor měl velmi 
dlouhé řádky (jeden řádek tam měl dokonce kolem 1.4 M znaků!) Když jsem 
ovšem nechal editorem automaticky zalomit řádky, tak následně i tento 
cca 11MB soubor šel dekódovat a opravdu výsledek byl čitelný ....

Závěr: Můj OFF TOPIC problém, který s TeXem vůbec nesouvisel šel díky 
radě pana Olšáka a prostřednictvím CsPlainu úspěšně vyřešit!!!

Děkuji všem za jejich názory a rady, zejména panu Olšákovi za netradiční 
řešení, které se mi dozajista bude někdy jindy hodit - na zkomolené 
DUMPY SQL databází občas narážím - ovšem ne tak rozsáhlé, jako tomu bylo 
tentokrát ...

Ještě jednou díky a jsem s pozdravem
J.Hajtmar




Dne 13.2.2013 21:47, Jaroslav Hajtmar napsal(a):
> Dobry den.
> Zkoušel jsem reseni pana Olsaka, ale nedopadlo to ..
> Asi bude problém v tom, jak psal pan Wagner.
> Pozadal jsem spravce o nove zaslani zalohy a bylo to stejne.
>
> Podarilo se mi ale experimentovanim docilit toho, ze jsem to nakonec 
> rozchodil. Musel jsem nastavit volbu ANSI pri importu dat do databaze.
> Ackoliv ta cestina v tom sql souboru byla ve vetsine pripadu zmrsena, 
> tak import probehl OK a web se tvari normalne ...
>
> Kazdopadne diky vsem za rady...
> Obzvlaste mne zaujalo reseni pana Olsaka. Nikdy by mne napadlo pouzit 
> TeX jako konvertor ...
>
> Diky vsem a preji pekny den.
> Jarda Hajtmar
>
>
> Dne 13.2.2013 7:57, Petr Olsak napsal(a):
>>
>> Což tak využít \input micodes?
>>
>> ------------------
>>
>> \input opmac
>>
>> \newwrite\ofile
>> \immediate\openout\ofile=outfile.txt
>>
>> \input mixcodes
>>
>> \def\viprintline{\immediate\write\ofile{\tmp}}
>>
>> \verbinput (-) infile.txt
>>
>> \end
>>
>> -----------------
>>
>> Po zpracování tohoto souboru csplainem (aspoň ve verzi Nov. 2012)
>> dostanete v outfile.txt kopii souboru infile.txt, ovšem s tím, že 
>> bude celý v UTF8, třebaže infile.txt obsahoval směs kódování.
>>
>> Zdravím
>>
>> Petr Olšák
>>
>>
>>
>> On Tue, 12 Feb 2013, Jaroslav Hajtmar wrote:
>>
>>> Dobrý den.
>>>
>>> Velmi se omlouvám za off-topic, ale vzhledem k tomu, že je mezi vámi 
>>> mnoho expertů, tak se pokusím vás požádat o radu.
>>>
>>> Vyexportoval jsem jednomu kamarádovi velkou MySQL databázi v níž 
>>> bylo zřejmě mnoho různě kódovaných tabulek. Některá data byla zřejmě 
>>> kódovaná CP1250, něco v UTF-8, dost stará data celkem kolem 12MB dat.
>>> Vtuto chvíli mám dump databáze ve formátu sql - je to textový 
>>> soubor, který když otevřu PSPadem, tak je část textu zcela nečitelná...
>>>
>>> Bohužel je již hosting i s databází již zrušen, takže už nemám 
>>> možnost provést DUMP databáze metodou per-partes.
>>>
>>> Zkoušel jsem vydumpovaný soubor dekódovat různými metodami - zapínat 
>>> a vypínat automatické rozpoznání kódování, zapínat a vypínat různá 
>>> kódování tak, abych několik z tabulek (ke konci souboru) nějakým 
>>> způsobem zachránil, abych mohl zpět ta data zapsat do databáze tak 
>>> aby byla čitelná...
>>>
>>> Jsou to pro mne velmi důležitá data a teď jsem docela nahraný. 
>>> Zkoušel jsem i odmazat úvodní část dat a pak ta zbývající data nějak 
>>> načíst s automatickým rozpoznáním kódování, ale pořád niczásadního. 
>>> Drobný úspěch jsem zaznamenal, když malá (editorem vyřízlá) část 
>>> souboru se najedkou jeví jako čitelná, nicméně nejsem schopen už tu 
>>> akci nějak zopakovat.
>>>
>>> Neznáte, prosím, nějaký SW, který by to dokázal nějak přechroustat a 
>>> oddělit od sebe různá kódování atd?
>>> Lze nějakým editorem "vyříznout" část dat a uložit to tak aby tam 
>>> zůstalo jen to kódování které potřebuju?
>>> Nebo aspoň nějaký nápad, co by se s tím dalo dělat...
>>>
>>> Díky za případné rady a ještě jednou se omlouvám za off topic
>>>
>>> Jarda Hajtmar
>>>
>>> _______________________________________________
>>> csTeX mailing list
>>> csTeX at cs.felk.cvut.cz
>>> http://lists.felk.cvut.cz/mailman/listinfo/cstex
>>>
>>>
>>
>>
>> _______________________________________________
>> csTeX mailing list
>> csTeX at cs.felk.cvut.cz
>> http://lists.felk.cvut.cz/mailman/listinfo/cstex
>
> _______________________________________________
> csTeX mailing list
> csTeX at cs.felk.cvut.cz
> http://lists.felk.cvut.cz/mailman/listinfo/cstex