Portál AbcLinuxu, 10. května 2025 04:18
jeden paznak obvykle odpovida dvoum pismenumTo je UTF-8 – tam se většina českých znaků s diakritikou zapisuje jako dva bajty. Ten text byl uložen až po nějaké úpravě (přidání textu), takže je teď část v UTF-8 a část ve Windows-1250? Pak můžete zkusit např.
iconv
z UTF-8 do Windows-1250 s tím, že neznámé znaky se budou ignorovat, a pak provést opačnou konverzi. Případně můžete zkusit recode nebo enconv, třeba si s tím některý poradí.
Kwrite neinterpretovatelné znaky (což budou asi všechny mimo rozsah základního ASCII)KWrite snad není tak primitivní editor, že by zvládl jen 7bitové ASCII. Ostatně tazatel sám píše o UTF-8, takže jiné znakové sady snad KWritu nedělají problémy. Běžný český text zapsaný ve Windows-1250 je platnou sekvencí UTF-8 znaků, takže by s ním editor neměl mít problém. Pouze nebude mít pro některé znaky v písmu odpovídající tvar znaku, ale o tom by se editor snad ani neměl dozvědět. A textový editor hodný takového označení snad dnes nebude používat nějakou vlastní množinu znaků, se kterými umí pracovat, ale zvládne pracovat s celou Unicode sadou (nebo alespoň s původní 2bajtovou sadou Unicode). Jediná skupina znaků, se kterou by si editor nemusel tímto způsobem poradit, jsou řídící znaky, ty jsou ale pro Windows-1250 i UTF-8 stejné. Výsledný uložený text tedy podle mne lze pořád brát jako text ve Windows-1250, pouze se tam budou někde vyskytovat české znaky zapsané v UTF-8. Což by u většiny z nich neměl být problém, protože české znaky v UTF-8 budou při interpretaci jako Windows-1250 vypadat vždy jako dvojice znaků, přičemž první znak se v českých textech běžně nevyskytuje (měkké l, A s přehláskou atd.). Takže stačí tyto dvojice nahradit jejich ekvivalentem ve Windows-1250 a je hotovo. Otázka je, zda to zvládne některý z konverzních programů aniž by poškodil okolní text, nebo zda je lepší těch pár znaků nahradit nějak „ručně“ (tj. postupný nahrazování jednotlivých párů v nějakém editoru přes funkci vyhledej-a-nahraď, nebo
sed
em nebo něčím podobným).
To nicméně není v rozporu s tím, že (nejen) znaky s diakritikou z cp1250 jsou v utf-8 neinterpretovatelné (možná náhodně některé n-tice takovýchto znaků vytvoří platný čínský znak).Máte pravdu, UTF-8 je mnohem „děravější“, než jsem si myslel – třeba „ř“ ve Windows-1250 (
0xF8
) nemůže být na začátku žádné UTF-8 sekvence. Když dekódování sekvence vede na nějaký např. čínský znak, bylo by to vpořádku, ale neplatná UTF-8 sekvence způsobí načtení neznámého znaku.
Možná je celý zádrhel v tom, že do paměti si editor při otevírání souboru načte ty znaky, které skutečně zobrazíPokud editor umí pracovat s kódováním znaků UTF-8, pak nejspíš umí zobrazit celé Unicode (nevidím důvod, proč by tomu mělo být jinak). Pochybuji o tom, že by editor při každé změně písma znovu kontroloval, zda zvolené písmo definuje všechny potřebné znaky a znaky chybějící v písmu v paměti nahradil neznámým znakem. Ostatně na to stačí udělat jednoduchý test – změnit u českého textu písmo na nějaké bez českých znaků a pak zpět – české znaky se znovu zobrazí. Takže mezi zobrazením textu v textovém editoru a jeho interní reprezentací v paměti takhle vzájemné ovlivňování nebude. Problém tedy není v tom, že by editor nějaký znak neuměl zobrazit, ale že některé sekvence bajtů českého textu ve Windows-1250 jsou neplatné sekvence znaků v UTF-8 (standard tomu říká „ill-formed“ sekvence) – editor se s tím vypořádá tak, že danou sekvenci načte jako nějaký speciální znak.
Problém tedy není v tom, že by editor nějaký znak neuměl zobrazit, ale že některé sekvence bajtů českého textu ve Windows-1250 jsou neplatné sekvence znaků v UTF-8 … – editor se s tím vypořádá tak, že danou sekvenci načte jako nějaký speciální znak.Asi jsem se předtím špatně vyjádřil, neboť přesně takto jsem to myslel
iconv --from-code=ISO-8859-1 --to-code=UTF-8 ./oldfile.htm > ./newfile.html
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.