Názory k článku
Textové soubory na různých operačních systémech
-
Jarek (neregistrovaný)Tak to teda brzo, pod vlivem zdejších popularizačních keců o tom, jak je linux jednoduchý jsem si nainstaloval debian a pominu-li že mi to tam neumí diakritiku, tak taková základní věc, jako přenést texťák na flashdisku z debianu do windowsu (kterej je bohužel všude jinde), prostě nešla! Jak dlouho už linux existuje, že to nemůže být vyřešeno pro bezproblémovou práci? Nakonec se to podařilo převést jakousi webovou aplikací, takže dobrý... ale prostě toho času zbytečně... a linuxáci se konečně, v roce 2008 rozhodli zabývat se rozdíly textů v různejch systémech. Dík za zprávičku.
-
miky8 (neregistrovaný)Kdyz s tim neumite tak proc rovnou Debian? Jsou mnohem schudnejsi cesty jak na linux. Neslo prenest textak z Debianu na flash? Zeby nebyla pripojena? Opet jina distribuce by to zvladla za Vas. Pouze nesmyslna volba 1. distribuce.
PS: my take dekujeme za hodnotny prispevek a uz se nevracejte, dekuji. ;) -
Lael Ophir (neregistrovaný)Windows samozřejmě umí Unicode v Notepadu i WordPadu. Problém je v tom, že většina textových souborů historicky není v Unicode. Proto se soubor otevírá v code page systému. V Unicode se otevře pouze pokud je na začátku souboru Byte Order Mark (BOM), který Unicode Consorcium doporučuje k identifikaci takového souboru (případně pokud Notepad vyhodnotí, že to Unicode musí být, což ale u UTF-8 nelze zjistit). Problém je v tom, že unixy původně žádnou podporu Unicode nemají, a UTF-8 je prakticky ne-podporou - berličkou, která má snížit na minimum počet nutných úprav systému. A protože soubory na unixech mají mnohdy pevně dané začátky souborů (například na první řádce je uveden interpret skriptu), a neupravené nástroje (třeba kdysi bash) neskousnou BOM, tak unixy zásadně neříkají, že je soubor v Unicode.
Řešením je například použít menu File/Open v Notepadu. Ale aby to bylo uživatelsky příjemné, nechcete unixy nějak naučit používat BOM? -
Rejpal (neregistrovaný)
Windows samozřejmě umí Unicode v Notepadu i WordPadu. Problém je v tom, že většina textových souborů historicky není v Unicode. Proto se soubor otevírá v code page systému.
Ano. Toho jsem si také všimnul, když jsem importoval data do Active Directory nástrojem od Microsoftu přesně podle návodu od Microsoftu a ve chvíli, kdy jsem otevřel protokol v Poznámkovém bloku, abych zkontroloval případné chyby (přesně podle návodu), viděl jsem tam česko-symbolovou hatmatilku. :o)
UTF-8 je prakticky ne-podporou - berličkou, která má snížit na minimum počet nutných úprav systému.
Ne tak docela. UTF-8 je spíš zpětně kompatibilní kódování vytvořené kvůli tomu, aby nebylo nutné zahodit všechny systémy (hardwarové i softwarové) vytvořené za posledních třicet let. To není jen čistě záležitost Unixu. To už byste mohl říct, že za to můžou všichni, kdo ještě nepřešli na UTF-16LE Windows, včetně výrobců routerů, mainframů, zařízení s embedded webovými servery a podobných blbostí.
Ale aby to bylo uživatelsky příjemné, nechcete unixy nějak naučit používat BOM?
Ale vždyť ono to je uživatelsky příjemné. Ještě se mi nestalo, abych na Linuxu otevřel soubor v UTF-8 a on se zobrazil špatně. Kate, Gedit, Vim, Emacs, Mousepad - v žádném editoru se nevyskytly sebemenší problémy. Netuším, proč navrhujete před textový soubor přidávat bazmeg, který nemá smysl - UTF-8 nezná žádný "byte order" (jedna z jeho příjemných vlastností, na rozdíl od UTF-16).
Ostatně na Internetu je zvykem, že na nějaké změny bajtového pohlaví nikdo není zvědavý (proto máme network byte order, a ne nějaké přepínače v protokolech).
-
Lael Ophir (neregistrovaný)Podpora Unicode v jiném kódování, než UTF-8, by rozhodně neznamenala nutnost zahodit všechny systémy vytvořené za posledních 30 let. Podívejte se na řešení ve Windows. Staré aplikace jedou v kódové stránce systému, úplně stejně jako na starých systémech. Nové aplikace používají jiné datové typy. Samozřejmě staré aplikace je třeba pro nové datové typy upravit, ale to by zrovna na Linuxu byl daleko menší problém, než ve Windows (kde zdrojáky aplikací obecně nejsou veřejné).
Ono to uživatelsky příjemné *není*. Většina textů není v UTF-8, ani v Unicode. Jak Kate, Gedit, Vim, Emacs, Mousepad a další rozeznají, jestli je text v 8859-cokoliv, nebo v UTF-8? Nepoznají to, a uživatel pak má problém. Přitom stačí říci, že když je na začátku textu BOM, tak je v Unicode. Podle BOM poznáte, jestli jde o UTF-8, UTF-16, a ještě zjistíte případný byte order. -
Messa (neregistrovaný)K čemu BOM v UTF-8? Že je text v UTF-8 se dá s podle mě velkou pravděpodobností zjistit automaticky. A když v UTF-8 nebude, co pak? cp1250 žádný BOM nemá :-) Nechápu tedy, o co ti jde. To, že UTF-8 dokumenty budou mít BOM mi nijak nepomůže rozeznat, v jakém kódování jsou soubory, které nejsou v UTF-8 :-)
-
Lael Ophir (neregistrovaný)Zjišťovat pomocí statistické analýzy textu, že je "s velkou pravděpodobností" v UTF-8, je poněkud nepraktické. BOM řeší problém zcela jasně, navíc je k tomu určený.
Pokud není text v Unicode, považuje se za text v code page. Stejně jako u starých systémů nelze zjistit, v jaké code page je. Předpokládá se ale primární code page systému, což je v českém locale ANSI 1250. Na Linuxu by se zřejmě předpokládala 8859-2, opět podle locale. -
"V Unicode se otevře pouze pokud je na začátku souboru Byte Order Mark (BOM)"
Pane LO, co kdybyste přestal kecat? Já vím, že na místě, kde málokdo zná Windows Vám to asi projde - ale lež lež lež. Třeba i ten jednoduchý Notepad celkem dost spolehlivě odhadne, zda je soubor Unicode, a nebo UTF-8. Mimochodem, Windows dokonce má API funkci IsTextUnicode(), která statisticky zjišťuje, zda je text Unicode, nebo ANSI. A třeba i ten Notepad jí vnitřně používá.
"případně pokud Notepad vyhodnotí, že to Unicode musí být, což ale u UTF-8 nelze zjistit"
Zvláštní, podle LO to nelze zjistit, ale Notepad na mém Windows to na 100% spolehlivě zjišťuje i u souborů, které nemají BOM na začátku. Zatím se mi nestalo, že by u mě Notepad nepoznal, že jde o UTF-8 i bez BOM znaku. Samozřejmě tam musí být aspoň jeden dva znaky s diakritikou, jinak se totiž formátem UTF-8 neliší od ANSI textu.
"UTF-8 je prakticky ne-podporou - berličkou"
UTF-8 je jediné rozumné kódování textu pro Unicode soubory. Je to 100% přenositelný formát, který nezávisí na endianu, a který dokáže spolehlivě přenést celou 32 bitovou znakovou sadu (což UTF-16, jeden z nejhorších formátů pro Unicode s četnými nevýhodami - což je ten, který Vy nazýváte ve Windows "Unicode" - nezvládne ani náhodou). V ničem jiném texty neukládám a ani ukládat nechci. UTF-8 je defaultní standard pro Unicode a řada technologií, operačních systémů, atd.. když mluví o Unicode, myslí tím, že zpracovává UTF-8.
"Ale aby to bylo uživatelsky příjemné, nechcete unixy nějak naučit používat BOM?"
Zvláštní, že mě v unix nástrojích BOM funguje. Vim ho dokonce automaticky pozná a pracuje s ním. -
Lael Ophir (neregistrovaný)Současnou verzi Notepadu jsem nezkoušel, ale ve Win2K i XP se mi UTF-8 soubory pravidelně otevíraly, jako by byly v ANSI 1250, pokud neměly BOM. Notepad je jednou z aplikací, které když textu chybí BOM ještě navíc odhadují, jestli nejde o UTF-16. Dělají to právě z toho důvodu, že ne každý editor přidá na začátek souboru BOM.
Unicode je 24-bit kódování, a i jeho rozšíření z 16 na 24 bitů se řada asiatů brání (po zkušenostech s CJK code pages). A samozřejmě UTF-16 umí přenést všech 24 bitů; nelžete nám tum, přijde se na to :)
O problémech unixů s Unicode se tu vedly dlouhé diskuze. Jako krátkou rekapitulaci si dovolím konstatovat, že unixy Unicode vlastně nepodporují, a jen přes 30 let staré API cpou UTF-8 místo znaků v code page. To vede k zábavným situacím, kdy se různě míchají data v různých code pages, například názvy souborů na disku. Ještě větší sranda je to, že některé frameworky (třeba Qt a Java) pracují v UTF-16, veškeré stringy před voláním převádějí do UTF-8, a po návratu zase do UTF-16. K tomu přičtěte pomíchaná data v různém kódování (třeba názvy souborů na FS), takže převod do UTF-16 někdy ani nelze provést... Takhle to dopadá, když se na začátku řekne "zkusíme to nějak zflikovat, hlavně ať to nestojí moc práce".
Vim možná pozná BOM, dobře tak. Jen by bylo dobré, kdyby vim, vi, ed a řada dalších psaly BOM vždy, když je text v Unicode. -
"Unicode je 24-bit kódování, ..."
Ono Unicode je v současné době 21 bit kódování. Jeho rozšíření se nabrání Asiaté, ba právě naopak - řada Asiatů se brání používat Unicode právě pro jeho malou bitovou šířku, díky čemuž dochází k zprznění asijských znaků (tzv. han unification proces).
UTF-16 neumí přenést 24 bitů, to ani náhodou. Ba dokonce ani neumí přenést celých 21 bitů, musely se dokonce některé znaky vyjmout díky UTF-16 z Unicode sady - jsou to tzv. surrogate code points. UTF-16 je suverénně nejhorší kódování Unicode, jaké můžete mít s obrovskou řadou nevýhod. Důvod proč se používá je jednoduchý - používá ho bohužel Windows a Java. Jinak by 16-ti bitové kódování nikdy nevzniklo. Zcela pravdivě se dá říci, že právě díky Microsoftu a Sunu je problém rozšířit Unicode sadu nad 21 bitovou šířku, protože je nutné udržet kompatibilitu s dinosauřími a prehistorickými věcmi, jako je UTF-16.
Dovolím si krátkou poznámku, kdyby všude lítalo buť UTF-8, nebo UTF-32, byl by ráj. Kdyby se konečně podařilo vymlátit UTF-16, znamenalo by nesmírný a obrovský pokrok ve všem, co se Unicode týká. Pro Qt není problém zbavit se UTF-16, protože jeho třída QChar (snad to píšu dobře, Qt nepoužívám) není závislá na vnitřní reprezentaci. Klidně další verze Qt může vše uvnitř mít jako UTF-32 a no problem.
Nevidím sebemenší problém v tom hnát přes API UTF-8, protože to je velmi dobré řešení. Dokonce geniální, protože nedělá problémy ani programům zpracovávajícím věci postaru 8-bitově, a ani programům potřebující pracovat s Unicode.
Zatímco bohužel s Windows a Javou se nehne. Windows je tak prožrané UTF-16, že se s tím nedá nic dělat. A ta skvělá, objektová Java, vzor to čistoty a OOP bohužel je tak špatně navržená, že znak není objekt, je to natvrdo 16-bitový unsigned int, takže Java z UTF-16 neuteče. Pro jakýkoli jiný systém a technologii není problém.
Jinak, pane LO, prosím, zkuste přestat kecat o věcech, kterým rozumíte velké kulové. -
Lael Ophir (neregistrovaný)Na první místě máte pravdu, že Unicode je 21-bitový.
Asiaté mají velmi negativní zkušenost s MBCS. Tam znaky nad 128 byly vyhrazeny pro různě dlouhé sekvence, kódující asijské znaky. Bohužel když jste v textu hledal "A", tak nebylo zjevné, jestli jde o znak "A", nebo část sekvence kódující něco úplně jiného. Potéto zkušenosti by asiaté nejraději kódování s pevnou šíří, například UCS-2 nebo UCS-4.
'...používá ho bohužel Windows a Java. Jinak by 16-ti bitové kódování nikdy nevzniklo' - LOL. Unicode byl od začátku designován jako 16-bitové kódování, což byste snad mohl vědět. Jedinou formou kódování bylo UCS-2 bez určení endianness, později byl přidán Byte Order Mark pro určení endianness. Teprve dodatečně vyvstala potřeba rozšířit Unicode nad 16 bitů, a z UCS-2 se stalo UTF-16, se surrogate pairs (kterým se někteří brání, viz výše).
16-bitový wchar pochopitelně neudrží 21 bitů, takže je nutné kombinovat dvě 16-bit wchary (surrogate pairs), abyste těch 21 bitů obsáhl. Zvláštní je, že 8-bit char vám připadá skvělý, i když v UTF-8 může mít znak cokoliv mezi 1 a 6 chary - je to prostě fajn a skvělé. Naopak 1 nebo 2 16-bitové hodnoty jsou hrozně špatně, a brzda všeho pokroku. Nemáte šupiny na očích? ;)
Qt má s UTF-16 a obecně Unicode celkem problém, protože 1) musí neustále převádět stringy mezi UTF-8 a UTF-16 (jistě oceníte takový design :) ); 2) Qt předpkládá, že API vrací UTF-8, což nemusí být pravda, a program na tom může zhavarovat (seznam souborů v adresáři dostanete jako UTF-16 stringy, jenže názvy na disku mohou obsahovat invalidní UTF-8 sekvence, protože mohou být třeba v 8859-2 - chyba převodu do UTF-16, konec). Samozřejmě také není pravda, že UTF-16 lze z Qt lehko vymlátit. Jak asi předáte z nové aplikace string knihovně kompilované se starší verzí Qt? A jak byste načítal datové struktury zapsané staršími verzemi aplikací? Jistě pouze změníte šíři QCharu, a no problem, že?
Opravdu nevidíte problém v neustálém převádění stringů mezi UTF-8 a ostatními reprezentacemi, jak je tomu v případě Qt a Javy na Linuxu? Já v tom naopak vidím celkem velký problém.
Windows používá 16-bit wchar, což je zcela OK. Asi by bylo možné používat 32-bit wchar, ale utrpěla by zpětná kompatibilita. V .NETu by to mohl být menší problém, protože s bytecode si lze lépe vyhrát.
Říkáte, abych přestal "kecat o věcech, kterým rozumím velké kulové". Přitom jste to vy, kdo tu blábolí nesmysly. Zameťte si před vlastním prahem. Když jsme u toho, konfrontační styl diskuze jste si vybral sám. -
anonymníLinuxáci se v roce 2008 nerozhodli řešit rozdíly mezi textem napříč platformami, ti o něm vědí už dávno, stejně jako ostatní :)
Je to jako výkřik po zasunutí hřebíku do zásuvky: ale ten proud kope?!
Různé platformy ukládají "čistý" text různě, s tím nic nenaděláš. Patrně jsi text netvořil ve vimu, ale v něčem pokročilejším, nebyla tam někde v menu kolonka "kódování znaků"? A nebyly tam volba Windows - CP1250 nebo UTF-8? A v tom notepadu ve windows, tam není možnost zvolit kódování znaků (ansi, unicode, big endian, utf-8?
Linux má moře chyb, windows taky, ale tohle bych jim nevytýkal, to je chyba na židličce :)
Nicméně, pokud chceš relativně bezproblémově přenášet texty, použij RTF - na linuxu ho vytvoříš skoro čímkoli, ve windows přečteš (a zapíšeš a pošleš zpět) i bez office. -
Drom (neregistrovaný)No ale linux nemuze za to, ze notepad umi jenom to, co vyprodukujete na Windows. Ja s prenosem z Windos na linux problem nemam, mozna to chce textovy editor, co neni tak hloupej a umi pracovat i s jinymi knci radku a jinym kodovanim.
To, ze Vas Debian neumi diakritiku je Vas problem, neco mate spatne / nemate nainstalovano nebo nastaveno spatne.
