Textové soubory na různých operačních systémech

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. ;)

Debian je pro nadšence, kteří tomu rozumí. Lidem, kteří nechtějí celé dny editovat konfigurační soubory, psát do konzole a kompilovat se doporučuje *buntu nebo opensuse. Když si někdo nainstaluje debian, nemůže si stěžovat, že mu to a to nešlo hned.

"Lidem, kteří nechtějí celé dny editovat konfigurační soubory, psát do konzole a kompilovat"
Rofl! Chlape,vy jste mě teda pobavil.
Nejspíš používáte jiný Debian,než já... ;-)

Problem s prevodom textakov nema GNU/Linux ale Windows! V Unixe neexistuje rozdiel medzi binarnym a textovym suborom.

Vas prispevok je vykrik do tmy uboheho loosera. Problem nie je v Linuxe ale na stolicke. :)

A může snad GNU/Linux za to,že Windows neumí (v defaultním editoru) Unicode?

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).

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 :-)

Co to je "code page"? Jaké ANSI 1250? Nic takového neexistuje! Nemáte na mysli "Windows-1250"

(Nedomáčkl jsem otazník...)

Ano, z té stránky je jasné, že Windows-1250 nemá s ANSI prakticky nic společného. Tak proč tomu říkáte "ANSI 1250", když nic takového neexistuje? To už bych (s mnohem větší mírou pravdivosti) mohl říct, že používám ISO Linux (dle ISO/IEC 23360-1:200).

Říkám tomu ANSI 1250, protože jde o ustálenou terminologii. Windows podporují OEM a ANSI code pages.

Pokud jde o nevyslovenou nabídku na flame o ANSI, code pages a standardech, tak s díky odmítám. Myslím, že by to byla ztráta času pro mě, pro vás, i pro ostatní.

"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.

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.

jak malej Jarda .)

někde je chyba a v debianu to nebude :) ja diakritiku mám a přenos Lin vs. Win problémy nedělá...

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.