Fórum Root.cz
Hlavní témata => Software => Téma založeno: mpro 25. 01. 2024, 20:42:09
-
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:
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?
-
a co jinym programem prevest text na jine kodovani, prohnat antiwordem a zase prekodovat.
-
Ž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.
-
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)
-
Ď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).
-
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...
--- 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
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
-
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.
-
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:
antiword -f -m UTF-8 subor.doc | sed 's/\xC5\x20/Š/g' > subor.txt
-
@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.
-
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):
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:
/* 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.
-
@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)
-
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.
-
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
-
Ď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 (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.