Topnet - Internet provider
Komplexní internetové služby

Chyba se znaky áíčíářáé nebo áíčíářáéářčáář

Používáte při své práci schránku? Trápí vás, že když kopírujete něco například z Internet Exploreru do ICQ, Wordpadu nebo Outlooku, vloží se vám před to nesmyslné znaky áíčíářáéářčáář? Nebo obdobné?

Tak v tom případě máme pro vás dobrou zprávu. Stačí si stáhnout opravný soubor z našeho webu, uložit ho do daného adresáře na diksu a spustit!

Oprava č. 1 ...vyberte jednu z těchto čtyř podle toho, jakou máte verzi českých Office (pokud Office nemáte, stáhněte čtvrtou)
Pokud máte: Stáhněte opravu do této složky: A spusťte.
Office 2003 SP2 C:\Program Files\Common Files\Microsoft Shared\TextConv stáhnout
Office 2003 SP1 C:\Program Files\Common Files\Microsoft Shared\TextConv stáhnout
Office XP (KB832671) C:\Program Files\Common Files\Microsoft Shared\TextConv stáhnout
ostatní (KB823559) C:\Program Files\Common Files\Microsoft Shared\TextConv stáhnout

Oprava č. 2 ...tuto budete taky potřebovat, pokud máte některý z těchto systémů
Pokud máte: Stáhněte opravu do této složky: A spusťte.
Windows XP SP2 C:\WINDOWS\system32 stáhnout
Windows Server 2003 SP1 C:\WINDOWS\system32 stáhnout

Poznámka pokud tápete, co je pro vás: většina lidí má systém Windows XP SP2. Takže stáhnete čtvrtou Opravu č. 1 a první Opravu č. 2. Pokud máte Windows XP SP2 a k tomu navíc Office XP, stáhnete třetí Opravu č. 1 a první Opravu č. 2. Kapišto??

Zdroj opravných souborů: Diskuzní příspěvek od Petra Součka na Živě.cz



Technické pozadí (pouze pro experty!)
Technické vysvětlení této chyby je daleko složitější, než si myslíte. Pokusím se to nastínit v bodech. Hlavní lidskou příčinou této chyby je však příííšerně mizerná kvalita Microsoftí specifikace RTF formátu (dále jen RTF specifikace), jak uvidíme dále.

Diakritické znaky áíčíářáé resp. áíčíářáéářčáář se zobrazí na začátku pole, protože se obsah pole vloží z RTF dokumentu s chybnou syntaxí.
Obsah pole se vloží z RTF dokumentu, protože pole je tvořeno prvkem RichEdit Control, který si při vkládání ze schránky vybere RTF formát dat.
Pole je tvořeno prvkem RichEdit Control (dále jen RichEdit) - k tomuto účelu ho využívají různé známé programy (ICQ 5, MSN Messenger, Wordpad, Outlook v režimu bez Wordu, atd.)
RichEdit je součást všech možných verzí Windows a je reprezentován soubory RICHED32.DLL (verze 1.0), RICHED20.DLL (verze 2.0 a 3.0) resp. MSFTEDIT.DLL (verze 4.0 a výše).
Ve schránce je RTF formát dat, protože při vložení HTML kódu (např. části dokumentu v Internet Exploreru) do schránky se do ní uloží nejen HTML kód, ale i obyčejný textový formát a také právě RTF formát.
Konverzi HTML->RTF při uložení HTML kódu do schránky zajišťuje systémová součást zvaná Microsoft HTML Converter (dále jen HTMLConv)
HTMLConv je reprezentován soubory %ProgramFiles%\Common Files\Microsoft Shared\TextConv\HTML32.CNV (Windows i Office různých verzí), případně navíc také %SystemRoot%\system32\HTML.IEC (Windows XP SP2, Windows Server 2003 SP1).
RTF dokument má chybnou syntaxi, protože HTMLConv do jeho hlavičky (konkrétně do tabulky stylů) chybně ukládá názvy jednotlivých stylů.
Názvy stylů jsou v dokumentu chybně, protože obsahují RTF control word (dále jen token) \u<unicode-znak>.
Token je řídící prvek v RTF. Je to něco jako tag v HTML a začíná vždy zpětným lomítkem a pokračuje jedním či více písmeny.
Token \u reprezentuje znak Unicode. Je to jediný způsob, jak zapsat Unicode znak bez závislostí na kódovou stránku dokumentu.
Názvy stylů nesmějí obsahovat token \u, protože RTF specifikace zakazuje používání tokenů v názvech stylů (a také dalších názvech).
Názvy stylů v dokumentu obsahují token \u, protože ho do něj vkládá HTMLConv v rozporu s RTF specifikací.
HTMLConv do názvů stylů vkládá token \u, protože styly pojmenovává českými názvy (s českými znaky).
Tyto české názvy stylů jsou mimo jiné: Normální (Normal), Definiční pojem (Definition Term - DT), Bloková citace (Blockquote), Předem naformátované (Preformatted - PRE), z-Konec formuláře (z-Bottom of Form - /FORM), z-Začátek formuláře (z-Top of Form - FORM). Všimněte si tučně vyznačených písmenek a srovnejte je s nadpisem :-)
Většina lidí přikládá chybu překladatelům Windows, že přeložili i názvy stylů. To je ovšem chybná interpretace, protože české názvy stylů v RTF jsou povoleny! Skutečná chyba je jen a jen kvůli tokenu \u.
HTMLConv by neměl do názvů stylů vkládat \u, ale nanejvýš control symboly \'<hex-znak>.
Control symboly nejsou tokeny (za zpětným lomítkem nepokračuje písmeno, ale symbol), proto jsou v souladu s RTF specifikací.
Control symbol \' reprezentuje znak s příslušnou pozicí v kódové stránce dokumentu. Jeho nevýhodou je, že pomocí něj nelze zapsat znak, který není obsažen v kódové stránce dokumentu.
RichEdit si s takovýmto chybným RTF dokumentem neumí poradit (RTF specifikace neříká, co se má v tomto případě stát), a proto znaky reprezentované těmito \u tokeny nepovažuje za část názvů stylů, ale přímo za součást dokumentu. Proto je nesprávně zobrazí. Což je oprávněné chování RichEditu - chyba není na jeho straně. Control symboly interpretuje správně.
Pokud se však obsah schránky vkládá nikoli do RichEditu, ale do Microsoft Office Wordu 2003 (nižší verze nevím), tento problém tu nenastane.
Je to tak, protože Word tokeny \u (a možná i další) v názvech stylů toleruje.
A pokud RTF dokument chceme přenést z Wordu do RichEditu, vše proběhne také správně.
Word totiž pro uložení nepoužije tokeny \u, ale control symboly \'.
A pokud se v názvu nějakého stylu vyskytne znak, který není obsažen v kódové stránce dokumentu, použije Word workaround s využitím tokenu \upr. Tento workaround je nedokumentovaný a v rozporu se specifikací RTF, přesto však funkční.
Token \upr byl zaveden v jedné novější RTF specifikaci z důvodu zpětné kompatibility pro non-Unicode programy. Jeho syntaxe je: \upr{<část pro non-Unicode programy>\*\ud{<část pro nové (Unicode) programy>}}. Staré programy (ty, které neznají token \upr a pravděpodobně také neumí Unicode) vezmou v úvahu část pro staré programy a tu pro nové přeskočí. Naopak nové programy, které token \upr znají, vezmou v úvahu pouze část pro nové programy (tu, která je uvedena tokenem \ud). Tu pro staré ignorují.
Starší programy takhle fungují, protože už v dřívější specifikaci bylo uvedeno, že neznámé tokeny se mají ignorovat, ale jejich tělo (ve složených závorkách) se má vzít v úvahu. Ovšem s výjimkou, že pokud je před tokenem dvojice znaků \*, má se token ignorovat včetně jeho těla.
Tento workaround spočívá v tom, že pro tabulku stylů Word použije token \upr. Zapíše tedy dvě tabulky stylů. V té první používá pouze control symboly (\') a symboly, které takto zapsat nejdou, nahradí znakem otazník. V té druhé (uvozené tokenem \ud) používá pro jinak nezapsatelné symboly token \u (což je v rozporu s RTF specifikací).
Přesto je tento workaround funkční, protože RichEdit nezná token \upr a Word s tím zřejmě počítá. RichEdit tedy části, kde se v názvech stylů vyskytuje token \u, prostě přeskočí, tím pádem se dokument v RichEditu zobrazí správně. Kdežto Word při načítání vezme v úvahu část uvozenou tokenem \ud, a proto načte názvy stylů správně včetně speciálních znaků (reprezentovaných tokeny \u).
Mimochodem, skutečnost, že RichEdit nezná \upr ani \ud, ale zná \u, je velice zvláštní. Už jen proto, protože tyto tokeny se v nové verzi RTF specifikace objevily všechny zároveň a všechny byly zavedeny kvůli jedné problematice (podpora Unicode).

Klientská část