Použití antiword -f s UTF-8

[mpro]

Program antiword, ktorého textový výstup umožňuje pri použití prepínača -f označenie základného formátovania textu (napr. /kurzíva/, *tučný rez*, _podtrhnuté písmo_) funguje len v prípade, ak nie je použité výstupné kódovanie UTF-8 (či už prostredníctvom locales, alebo prepínačom antiwordu -m UTF-8).

V dokumentácii (man antiword) sa takéto obmedzenie nikde neuvádza. Preto pre naše naše texty používam naledovný postup:

Kód: [Vybrat]

antiword -f -m cp1250 subor.doc | uconv -f cp1250 -t UTF-8 > subor.txt

čo však spôsobuje problémy so znakmi, ktoré nepokrýva kódovanie cp1250 (a 8859-2 toho pokrýva ešte menej).

Je nejaká možnosť, napríklad nastavením premenných prostredia (LANG, LC_*), či inak, mať funkčný prepínač -f aj pri -m UTF-8?

[Reklama]

[alex6bbc]

a co jinym programem prevest text na jine kodovani, prohnat antiwordem a zase prekodovat.

[mpro]

Žiaľ navrhované riešenie so zmenou kódovania v doc súbore nie je uskutočniteľné, problémom nie je vnútorné kódovanie, ale to ktoré sa objaví na výstupe (či už pomocou nastavenia systémového parametra LANG, alebo pomocou prepínača antivordu -m). Aj tak však ďakujem za reakciu.

[RDa]

Kdyz pres total commander hledam v .doc souborech, tak zaklikavam vzdy "unicode" - protoze .doc je interne ukladan jako UTF16, resp. to, co je 16-bit varianta wide char ve win api.

Takze bych prvne zkusil antiwordem produkovat tento "doc nativni" 16bit format a pres iconv to prevest na UTF8.

*v doc lze hledat, v .docx coz je zipovanej tato moznost neni, bez nejake 3rd party indexace. Takze ackoliv docx je otevrenejsi format.. v pouziti je horsi (pro mne)

[mpro]

Ďakujem za nasmerovanie, ale antiword pravdepodobne produkuje len výstupy s kódovaním, ktoré má v txt súboroch v /usr/share/antiword/ alebo ~/.antiword, kde sú k dispozícii len nasledovné kódovacie tabuľky:

8859-10.txt
8859-11.txt
8859-13.txt
8859-14.txt
8859-15.txt
8859-16.txt
8859-1.txt
8859-2.txt
8859-3.txt
8859-4.txt
8859-5.txt
8859-6.txt
8859-7.txt
8859-8.txt
8859-9.txt
cp1250.txt
cp1251.txt
cp1252.txt
cp437.txt
cp850.txt
cp852.txt
cp862.txt
cp864.txt
cp866.txt
koi8-r.txt
koi8-u.txt
MacCyrillic.txt
MacRoman.txt
roman.txt
UTF-8.txt


V manuálových stránkach je uvedené toto (čo potvrdzuje aj to čo bolo v odpovedi):

-m mapping file
              This  file is used to map Unicode characters to your local char‐
              acter set.  The default mapping file depends on the locale.

Samotný antiword funguje bez problémov aj s výstupom do UTF-8, akurát v tomto prípade nefunguje vyznačovanie formátovania, ktoré je popísané pre voľbu -f:

-f     Output in formatted text form. That  means  that  bold  text  is
              printed  like *bold*, italics like /italics/ and underlined text
              as _underlined_.

Jedná sa o starší a dnes už nevyvýjaný program, ktorý je však dodnes prístupný v repoch distribúcií (pre Debian/Ubuntu stačí použiť apt-get install antiword).

[Reklama]

[RDa]

Diky za dalsi info - koukam ze to mam v Gentoo taky, takze po uprave zdrojaku - zakomentovani te divne vyjimky na return pokud je to UTF8, ve formatovaci funkci...

Kód: [Vybrat]

--- a/fmt_text.c        2024-01-26 18:59:37.689266225 +0100
+++ b/fmt_text.c        2024-01-26 18:59:58.457266545 +0100
@@ -51,10 +51,10 @@
                return;
        }

-       if (eEncoding == encoding_utf_8) {
-               fprintf(pFile, "%.*s", (int)tStringLength, szString);
-               return;
-       }
+//     if (eEncoding == encoding_utf_8) {
+//             fprintf(pFile, "%.*s", (int)tStringLength, szString);
+//             return;
+//     }

        if (ucNbsp == 0) {
                ucNbsp = ucGetNbspCharacter();

me to funguje:

daniel@desktop ~/test $ antiword -m UTF-8 -f czech.doc

Kód: [Vybrat]

normal

*bold +ěščřžýáíé*

/italic +ěščřžýáíé/

_underline +ěščřžýáíé_

*/bold italic +ěščřžýáíé/*

*_bold underline +ěščřžýáíé_*

/_italic underline +ěščřžýáíé_/

*/_bold italic underline +ěščřžýáíé_/*

Prilozeny patch se da ulozit v Gentoo na specialni misto a bude aplikovan pri instalaci (emerge antiword):

/etc/portage/patches/app-text/antiword-0.37-r2/enable-utf8-formatting.patch

[mpro]

Veľmi pekne ďakujem, po odkomentovaní uvedených riadkoch vo fmt_text.c a preklade pomocou make all to funguje aj na mojom Ubuntu 22.04, akurát to budem musieť vyhodiť z apt balíka a nainštalovať lokálne pomocou sudo make install.

[mpro]

Pri testovaní upraveného antiwordu som narazil na príčinu vypnutia možnosti použiť parameter -f pri výstupnom UTF-8 kódovaní -- zatiaľ je to len pre znak Š, ktorý sa pri tomto výstupe zmení na xC5x20, čo som vyriešil pridaním filtra v sed:

Kód: [Vybrat]

antiword -f -m UTF-8 subor.doc | sed 's/\xC5\x20/Š/g' > subor.txt

[Regine Martin]

@Odpověď #3 kdy: 26. 01. 2024, 17:03:00 »
Microsoft nikdy NEužíval UTF-16, dokonce vždy doporučoval UTF-8 a nadále užívá UTF-8.

[RDa]

Problem spociva v tom, ze v tom fmt_text.c kodu, je nezalomitelna mezera kodovana jako ucNbsp = 0xA0.

Takze tato cast kodu najde A0 v tom UTF8 retezci blbe (protoze Š je 0x0160 = 0xC5 0xA0):

Kód: [Vybrat]

        pucStart = (UCHAR *)szString;
        pucLast = pucStart + tStringLength - 1;
        pucNonSpace = pucLast;
        while ((*pucNonSpace == (UCHAR)' ' || *pucNonSpace == ucNbsp) &&
               pucNonSpace > pucStart) {
                pucNonSpace--;
        }

a transformaci z 0xA0 (nbsp) na tu 0x20 mezeru ve tvem vystupu provede tento kod - pro vypis mezi formatovacimi tagy:

Kód: [Vybrat]

        /* 3: The text itself */
        while (pucByte <= pucNonSpace) {
                if (*pucByte == ucNbsp) {
                        (void)putc(' ', pFile);
                } else {
                        (void)putc((char)*pucByte, pFile);
                }
                pucByte++;
        }

v UTF8 rezimu, se NBSP prelozi z 0x00A0 na 0xC2 xA0 utf8 retezec (ktery mimochodem triggeruje ten samej problem jako vyse s Š, protoze obsahuje 0xA0 byte).

Takze je treba udelat opravu detekce NBSP a jeji transformace na mezeru, pro pripad multibyte kodovani (utf-8).

Pripadne ztransformovat NBSP na mezery (0xc2,0xa0 -> 0x20) drive a pak vyhodit ten detektor a aplikator NBSP.

[RDa]

@Odpověď #3 kdy: 26. 01. 2024, 17:03:00 »
Microsoft nikdy NEužíval UTF-16, dokonce vždy doporučoval UTF-8 a nadále užívá UTF-8.

Nekdo nezna historii ale zije jen posledni petiletkou?

Jmenuje se to UCS2 a jsou to fixne 16 bitove znaky.
The UCS-2 standard, an early version of Unicode, is limited to 65 535 characters.

https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows

Using the (now obsolete) UCS-2 encoding scheme at first, it was upgraded to the variable-width encoding UTF-16 starting with Windows 2000, allowing a representation of additional planes with surrogate pairs. However Microsoft did not support UTF-8 in its API until May 2019.

Before 2019, Microsoft emphasized UTF-16 (i.e. -W API)

[RDa]

Zde je reseni se zachovanim NBSP jako unicode symbolu (prevadet na mezeru se totiz musi jenom kdyz je 8-bit codepage .. ktera nema nbsp ale jen space).

Patch vuci puvodnimu zdrojaku, tj. nahrazuje predchozi upravy.

[RDa]

Jedná sa o starší a dnes už nevyvýjaný program, ktorý je však dodnes prístupný v repoch distribúcií (pre Debian/Ubuntu stačí použiť apt-get install antiword).

Ohledne patchu pro UTF-8 jsem informoval maintanera balicku v Gentoo - a udelal nam github repo s jemu znamymi zdrojaky a patchama. Tak jsem to forknul a poslal hezci modifikaci jako pull request - a jestli se to ujme, tak tvuj pozadavek bude dostupny casem vsem.. i v tom Debianu.

REF: https://github.com/grobian/antiword

[mpro]

Ďakujem za pomoc, pretože v C-čku sa veľmi neorientujem. Po aplikovaní patchu však už všetko behá tak ako má, a to aj na obstarožnom Mac OS X 10.4 s PPC procesorom, kde som to potreboval používať bez prekódovania.

Ak to niekmu pomôže, prikladám aj skripty pre bash, kde sa používa táto opatchovaná verzia antiwordu -- primárne sa jedná o prevod textov kníh z rtf do TeX-u (zfsme-rtf2tex je verzia pre Linux, zfsme-rtftotex zas pre Mac OS X). Všetko je to určené pre plainTeX, len sa používa súbor makier OPmac (je v každej TeX-ovej distribúcii) a súbor makier v priloženom súbore ZfSME.tex. Na adrese https://www.overleaf.com/read/qmybtpksbhps vzniká aj popis tohto balíka, ktorý však ešte nie je kompletný (k dnešnému dňu chýba popis asi 1/3 makier), ale už je tam kompletný popis bash skriptov.