Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Byte order mark a %&

8 views
Skip to first unread message

Calabek Pavel

unread,
Aug 11, 2016, 3:20:52 PM8/11/16
to
Zdravím konferenci,

Používám texlive 2013 (a zatím ho měnit nehodlám). Zjistil jsem následující. Textový soubor kódovaný v UTF8 může na svém začátku obsahovat tzv. byte-order mark, tj. byty 0xEF 0xBB 0xBF (a některé editory (např. MS Notepad) jej tam rády přidávají jako signalizaci UTF8). Při zpracování TeXem je takto označený soubor bez problémů zpracován a tyto znaky problémy nepůsobí a vynechají se. Bohužel však působí problémy, pokud se používá na začátku souboru %& pro určení TeXového překladače (jak to umožňuje texlive). V tomto případě TeX nepřepne na příslušný překladač (protože soubor opravdu nezačíná %&). Zatím mi to velké problémy nepůsobí. Protože se neumím (v MS Windows) těchto znaků nějak efektivně a rychle zbavit, musím si buď pohlídat, abych soubor neupravoval editorem, který to dělá nebo soubor zpracovat správným překladačem, ale je to drobná nepříjemnost, protože na cizích počítačích je převod přes Notepad nejspolehlivější a nejrychlejší způsob konverze mezi osmi- a šestnáctibitovým kódováním.

Chtěl jsem se zeptat, zda někdo nevíte, jestli je to tak i v novějších verzích TeXlive, tj. že byte-order mark zruší %&-parsing.

Děkuji

Pavel Calábek

Pali Rohár

unread,
Aug 16, 2016, 4:45:37 PM8/16/16
to
On Thursday 11 August 2016 21:02:00 Calabek Pavel wrote:
> Zdravím konferenci,
>
> Používám texlive 2013 (a zatím ho měnit nehodlám). Zjistil jsem
> následující. Textový soubor kódovaný v UTF8 může na svém začátku
> obsahovat tzv. byte-order mark, tj. byty 0xEF 0xBB 0xBF (a některé
> editory (např. MS Notepad) jej tam rády přidávají jako signalizaci
> UTF8). Při zpracování TeXem je takto označený soubor bez problémů
> zpracován a tyto znaky problémy nepůsobí a vynechají se. Bohužel
> však působí problémy, pokud se používá na začátku souboru %& pro
> určení TeXového překladače (jak to umožňuje texlive). V tomto
> případě TeX nepřepne na příslušný překladač (protože soubor opravdu
> nezačíná %&). Zatím mi to velké problémy nepůsobí. Protože se neumím
> (v MS Windows) těchto znaků nějak efektivně a rychle zbavit, musím
> si buď pohlídat, abych soubor neupravoval editorem, který to dělá
> nebo soubor zpracovat správným překladačem, ale je to drobná
> nepříjemnost, protože na cizích počítačích je převod přes Notepad
> nejspolehlivější a nejrychlejší způsob konverze mezi osmi- a
> šestnáctibitovým kódováním.

Zdravím! Na začiatok by som odcitoval, čo sa píše v štandarde Unicode
(kap. 2.6): "Use of a BOM is neither required nor recommended for UTF-8"

Je pravda, že pdfTeX kontroluje prvé dva znaky na %& a UTF-8 BOM neberie
v úvahu. Dáva to ale zmysel, nakoľko pdfTeX je 8-bitový a UTF-8 vôbec
nepodporuje (csplain pre UTF-8 používa rozšírenie encTeX, to sa ale
aktivuje o dosť neskôr ako parsovanie %&).

Takže odporúčam používať textové editory, ktoré BOM pre UTF-8
automaticky nepridávajú.

> Chtěl jsem se zeptat, zda někdo nevíte, jestli je to tak i v
> novějších verzích TeXlive, tj. že byte-order mark zruší %&-parsing.

Je to stále rovnako. %&-parsing má na starosti funkcia parse_first_line,
ktorá je v súbore texmfmp.c. Odkaz na aktuálnu verziu v svn je tu:

https://foundry.supelec.fr/scm/viewvc.php/branches/stable/source/src/texk/web2c/lib/texmfmp.c?view=markup&root=pdftex

Prvý znak súboru musí byť '%' a druhý '&'. Žiadna kontrola na BOM, nič
sa teda nezmenilo.

Osobne ani neočakávam žiadnu zmenu do budúcna, nakoľko samotný štandard
Unicode nielenže nevyžaduje ale ani neodporúča používať BOM pre UTF-8 a
naviac sám pdfTeX UTF-8 nepodporuje vôbec.

--
Pali Rohár
pali....@gmail.com
signature.asc
0 new messages