Kódování textu (diskuse)

Diskuse byla administrátory uzamčena.

[Prcek]

To logo článku je nějak špatně, ne? Slovo žluťoučký má velké Z, ale ta věta přeci zní "Příliš žluťoučký kůň úpěl ďábelské ódy", aby byly obsaženy všechny písmenka s diakritikou. To jen tak mě napadlo .

[cynic_asshole]

Ta věta může být i

Žluťoučký kůň příšerně úpěl ďábelské ódy.

a taky tam jsou obsaženy všechny znaky.

[Prcek]

To sice jo, ale za prvé mi to zní blbě a za druhé to logo nemá mezi slovy "kůň" a "úpěl" žádné jiné slovo, takže moje připomínka stále platí . Ale koukal jsem do nastavení písma v KDE4 a ta věta je tam taky neúplná, takže je to asi globální nedostatek .

[cynic_asshole]

A

Žluťoučký kůň úpěl příšerné ďábelské ódy.

by ti vyhovovalo?

[Prcek]

Dobrej pokus, taky by to šlo, i když dvě přídavná jména za sebou taky nejsou nic moc . Asi toho necháme a budeme se věnovat bohulibějším činnostem .

[xurpha]

A co příšerné ⇒ příšerně?

[Ash]

Pak to zase není česká věta ale jen věta sestávající z českých slov.

[David Watzke]

Jediná věc na celym článku, se kterou nemám nic společnýho a ty tu v tom budeš rejpat

[Václav HFechs Švirga]

U iconvu je dobré si dát bacha, aby vstup a výstup nebyl stejný, jinak si to tuším zároveň přepisuje pod rukama a nedopadne to dobře (možná se pletu)...

[David Watzke]

Tenhle příkaz převede utf8 soubor na cp1250 ... dopadne to dobře

iconv -t cp1250 -f utf8 soubor -o soubor

Na co je třeba dávat pozor je tohle

iconv -f cp1250 -t utf8 soubor > soubor
# a tohle
iconv -f cp1250 -t utf8 < soubor > soubor

protože to už tak vesele nedopadne (skončí to prázdným souborem). Ovšem to už není věc iconvu, ale přesměrování shellu.

[petr_p]

Je třeba upozornit, že se jedná o rozšíření GNU. Posixová specifikace žádný přepínač -o nezná.

[Amarok]

Je zvlastni, ze man iconv neuvadi parametr -o, sam jsem na to prisel nahodou, proste jsem to zkusil a slo to.

[Ash]

Nápodobně, s tím že já jsem to jen někde zahládl.

[petr_p]

Sekce.

[pht]

Zapomněl jste na užitečné recode X..flat

[Stanislav Brabec]

Nebo iconv -f UTF-8 -t ASCII//TRANSLIT.

Pozor, jeho výsledek závisí na locale:

~> echo Müller | LANG=cs_CZ.UTF-8 iconv -f UTF-8 -t ASCII//TRANSLIT
Muller
~> echo Müller | LANG=de_DE.UTF-8 iconv -f UTF-8 -t ASCII//TRANSLIT
Mueller

[Mti.]

coz asi vysvetluje, proc nekteri slovo "Muhehehe" zapisuji chybne jako "Muehehehe"

[Radovan Garabík]

Chýba tu môj obľúbený konwert. Hlavne pri transliterácii sa mu ostatné konvertory nevyrovnajú.

[vencas]

Není zméněno, že enconv defaultně konvertuje do kódování podle aktuální locale, takže není třeba výstupní kódování explicitně zadávat. Stačí napsat enconv * a tím je celý adresář zkonvertován do utf-8 (nebo něčeho jiného, pokud to ještě někdo používá).

[Nicky726]

Dík za ten convmv.

[pht]

Ad convmv: kdysi jsem pracoval na programu, který rekursivně převede jména souborů v celých adresářových stromech do nějaké pevně zadané množiny znaků (obvykle velká/malá písmena, číslice, pomlčky, tečky), tj. transliterace a pak nahrazení nepřípustných znaků, přičemž se samozřejmě inteligentně ošetřovaly konflikty (ukázka.doc a ukazka.doc). Byla to docela fuška :)

[Stanislav Brabec]

I já jsem kdysi za účelem konverze systému na UTF-8 podobný program napsal: utf8ize. Umí opravovat symlinky a přeskakovat soubory, jejichž názvy již v UTF-8 jsou.

[Andrej]

Kdyby tak už konečně tohle všechno zmizelo a všude zavládlo kódování UTF-8! Hned by bylo na světě o něco lépe.

Jenže to by nesměl existovat Mrkvosoft se svými Windows. To je nejhorší brzda veškerého pokroku. Těžko lze najednou prosadit UTF-8 ve všech textech, síťových protokolech, souborových systémech a lokalizacích aplikací, když drtivá většina českých uživatelů tam všude bude mít zmrzačený-latin-2 zvaný Windows-1250.

I samotná existnce „jazykových verzí“ software svědčí o zoufalé technické zaostalosti Mrkvosoftu v této oblasti. Například u KDE uživatele ani nenapadne, že by měl třeba KDE CZ nebo něco podobného! Když se k jednomu počítači připojí čtyři monitory, čtyři klávesnice a čtyři myši, může si k němu sednout Číňan, Japonec, Čech a Egypťan a všichni čtyři budou mít samozřejmě celé prostředí ve svém jazyce. K Windows zasedne stěží jeden jediný člověk a ani tehdy nic nezaručuje, zda tam bude schopen svoji lokalizaci nějak nastavit.

[pht]

Over the last year or so, as UTF-8 has finally started to gain some acceptance, I've ran into a lot of UTF-8 zealots who think that UTF-8 should be the single global one-size-fits-all standard; that it is the Final Encoding and there will be nothing after it. They seem to think that programs should assume that all input and output is, will be and should be UTF-8 or, if the program doesn't need to deal with individual characters, that it should ignore character sets and encodings altogether, assuming a single global standard – the UTF-8 monoculture.

Have they not learned that assumption is the mother of all fuck-ups?

[vencas]

To je argument z autority? (není uveden autor...) Jsem s utf-8 naprosto spokojen, řeší všechny mé problémy, které jsem kdy s kódováním měl.

[Jan Zahornadsky]

Dost Japonců, snad i Číňanů a Korejců (kteří se dostali dostatečně pod povrch) by s tebou nesouhlasilo

Já taky moc nesouhlasím, stále nějak tápu nad tím, jak to, že "c" a "с" jsou různé znaky, zatímco "..." a "…" má být jedno a totéž.

[pht]

Je to úryvek z klasiky Idiot box Linux, respektive podčlánku zabývající se UTF8.

http://www.modeemi.cs.tut.fi/~tuomov/b/2006/the_utf8_monoculturists/

[mmmmario]

Ono UTF-8 je docela vhodné pro angličtinu (kompatibilita s ASCII-7) i pro češtinu (česká písmena na 2 bajty), ale pro různé japonštiny a čínštiny (až 4 bajty na písmeno/znak) je mnohem vhodnější UCS16 nebo jak se to píše. Prostě každé písmeno pevně 2 bajty ať je z latinky nebo korejsky.

[Jan Zahornadsky]

Dva bajty už docela dlouho nestačí (znaků je o pořádný kopec víc než magických 65k). A co se týče Unicode, ty problémy bohužel ani zdaleka nejsou jenom o tom, kolik strašlivě moc prostoru to zabírá. Ono komu dnes záleží na pár bajtech, že.

[pavlix]

Jak jo... když záleží na pár bajtech, použije se daleko silnější komprese, že :). 7zip?

[David Watzke]

xz (lzma)

[pavlix]

utf-16 se to píše (ještě existuje něco jako ucs2 ale teď nevím, jestli je to úplně to samý, utf-16 znaky mají dva nebo čtyři bajty, takže proměnlivá šířka, jako u utf-8, hádám, že dneska už je ucs2 definovaný stejně, kdysi byl unicode dvoubajtový, že).

Pak na spoustu věcí je vhodnější utf-32, které má pevnou šířku znaku. Například ukládat jednoznakovou konstantu do utf-8, kde bude mít jeden až čtyři bajty (teoreticky šest).... je dost nešikovný, když to můžeš dát do utf-32, kde je to klasický integer nebo unsigned integer (unicode je dneska teoreticky až 31bitový).

Teď jsem si všiml, že píšeš o tom, že každé písmeno má pevně dva bajty, to už dávno neplatí. Dneska bys musel použít čtyři.

[xurpha]

Právěže UCS-2 není definovaný stejně jako UTF-16: USC-2 zvládne kódování jen pro BMP (basic multilingual plan), kdežto UTF-16 cokoliv. Ani UCS-4 a UTF-32 není jedno a to samé, ovšem vzhledem k tomu, že se nepočítá, že by nějaký unicodový znak překročil 15 "plánů", tak je to jedno. Pro interní reprezentaci je skutečně UCS-4 mnohdy lepší, než UTF-8; UTF-16 je k ničemu...

[mmmmario]

To jsem chtěl přesně napsat, UTF-8 je blbý v tom, že máš např. 10B textu a kolik to je písmen? Někdy 10, ale může to být i méně. Chtěl jsem napsat, že daleko vhodnější je kódování s pevnou šířkou 1 znak = x Bajtů.

[pavlix]

No to píšeš špatně :D.

Tak jak to píšeš to vyznívá, že ucs4/utf-32 (v tuhle chvíli beru jako stejný) je obecně lepší než utf-8 a to je nesmysl.

utf-8 má spoustu výhod i nevýhod a mě osobně přijde, že v praxi pro víceznakové řetězce dokonce převažují ty výhody.

utf-8 má v zásobě takové unikátní vlastnosti jako ascii-kompatibilitu, velmi dobrou možnost detekce (teď myslím čisté utf-8 bez jakýchkoli detekčních značek)... schválně si zkuste najít smysluplný text, který by mohl být špatně interpretován jako korektní utf-8.

Zpětná kompatibilita s aplikacemi, relativně dobrá komprese na to, že je to prakticky přímé kódování. Já považuju utf-8 za geniální vynález.

Samozřejmě jde použít vhodným i nevhodným způsobem.

[pht]

Já považuju utf-8 za geniální vynález.

Asi tak geniální jako RLE nebo huffman. To jen někteří, co se narodili včera, jsou z toho odvázaní až na půdu.

v praxi pro víceznakové řetězce dokonce převažují ty výhody.

Výhody převažují právě pro nevíceznakové.

[pavlix]

Já považuju utf-8 za geniální vynález.

Asi tak geniální jako RLE nebo huffman. To jen někteří, co se narodili včera, jsou z toho odvázaní až na půdu.

Urážky si nech na doma, tady na ně neni nikdo zvědavej :). I když doma asi taky, ne, viď :). S tímhle přístupem ze sebe akorát uděláš blbce.

v praxi pro víceznakové řetězce dokonce převažují ty výhody.

Výhody převažují právě pro nevíceznakové.

To je podle mě nesmysl. Ukládání jednoho znaku mi přijde daleko lepší do "integeru" než do bajtového řetězce proměnlivé délky.

[xurpha]

To je jednoduchý, spočítej všechny znaky se 7bitem = 0 (tj. <= 127) a máš to...

[pavlix]

To ti nevyjde, takhle spočítáš jen ascii znaky (pokud beru tu závorku, teda, ta je asi nejpřesnější).

[trekker.dk]

Jenže pokud se předtím někde v tom Japonsku používala angličtina, pak se 2 byty na písmeno ztrácíš zpětnou kompatibilitu

[pavlix]

A hlavně lidi pro utf-16 o to víc píšou software, co předpokládá dvoubajtové znaky.

Pro utf-8 jsem sice viděl pár kousků, co předpokládaly jednobajtové (ascii), ale daleko rychleji se to poladí, když se na to přijde už někde blízko za hranicema británie než když se to týká jen obskurních jazyků mimo BMP.

Tohle... a byte order, jsou dva důvody, proč si myslím, že v době utf-8 (pro řetězce) a utf-32/integer (pro znaky) je utf-16 úplně k ničemu a naopak dělá problémy.

[Amarok]

Vsechny problemy s kodovanim by byly vyreseny jedine, kdyby vsude fungovalo UTF-16.

[pht]

Všechny problémy s kódováním budou vyřešeny jedině až na kódování nebude záležet.

[Jendа]

Jak vypadá svět, kde na kódování nezáleží?

[petr_p]

Třeba svět XML nebo svět ASN.1. Prostě všude tam, kde data mají svá metadata z definice formátu.

[Nicky726]

XML používá Unicode, čili UTF8/UTF16, případně lze nastavit jiné. Mám ale takový pocit, že to bez kódování nepůjde.

[Amarok]

XML prece zadne kodovani "nepouziva". Pouze si tam sami napiseme, ve kterem kodovani ten XML soubor ukladame, a je uplne jedno, jestli se pouzije iso nebo utf nebo jine.

[Nicky726]

Mám za to, že Unicode je default.

[pavlix]

To neni tak úplně pravda.

Přesněji řečeno, to, co píšeš platí pro tvoje interní formáty, ne pro XML jako formát pro výměnu dokumentů.

Povinná implementace je tuším jen utf-8 a utf-16. Takže pokud použiješ iso nebo windows, nebo nějaké jiné úplně nestandardní, tak to nemusí přečíst aplikace na druhé straně.

[Jan Zahornadsky]

To by mě taky zajímalo. Striktně vzato, i binární soustava je jen způsob kódování informace o číslu. Stejně jako česká abeceda (její grafická podoba, ani nemusím mluvit o reprezentaci pomoci bajtů) je kódování mluvené řeči.

[pavlix]

Pokud jde o mluvenou řeč, tak je to velmi ztrátové kódování... takové, které většinu informace ztratí a jen zlomek nechá :).

[pavlix]

Nesmysl, utf-16 nemá kromě zabraného místa ve východních jazycích jedinou výhodu oproti utf-8.

[Jendа]

To mi přijde jako dostatečně silná výhoda .

[xurpha]

No, nevím, kvůli pár debilním národům, které si za ta tisíceletí nedokázala vytvořit použitelnou abecedu? Všechny normální písma (latinka, azbuka, arabština, hebrejština) díky tomu, že používají jen málo pár znaků se vlezou do BMP a tím pádem i jejich kódování v UTF-8 nikdy nezabere víc, než by zabralo 2, nebo vícebytové kódování...

[Jan Zahornadsky]

Oni mají jednotlivé komponenty (radikály) toho písma dobře definované. Debilní národy jsou jinde, pokud neumí implementovat chytřejší algoritmus na jejich skládání než "obšlehni to na obrazovku a posuň se, opakuj".

Mimochodem, ten chytřejší algoritmus fyzicky existuje, viděl jsem ho v nějakém čínském balíčku pro TeX. Nebo na starých Macích se používalo CangJie.

[xurpha]

Oni mají jednotlivé komponenty (radikály) toho písma dobře definované.

A co jako? System zapisu zustava debilni a zaostaly...

[Jan Zahornadsky]

Proč? Protože není stejný jako český?

Neříkám, že je nejlepší možný, ale zatím to tu zní jen jako předsudek z neznalosti.

[pavlix]

Od člověka se zájmem maximálně o evropské jazyky, něco takového nemůžeš chtít. Na druhou stranu utf-8 mi přijde jako výborný kompromis, až na to, že se někdo může cítit uražen tím, že ty jeho znaky zabírají víc místa.

To je pomalu jak nadávat u češtiny, že máš nějaký cca 20% nárůst velikosti souborů oproti klasickým 8bit kódování. Dokud to neni několikanásobek, tak bych se tím vůbec netrápil :).

[Jan Zahornadsky]

Narážím na kolegu xurpha, který se už minimálně dvakrát nechal slyšet, že systém psaní (pravděpodobně) dalekého východu je debilní a zaostalý, přitom zatím neuvedl jediný důvod.

A co se velikosti týče... Stejně je většina zpracovávaných dat netextová (různé cache, obrazy, zvuky, číselné údaje atd.), tak si myslím, že není nějaký výrazný rozdíl v tom, jestli se bude znak uchovávat pomocí jediného bajtu nebo rovnou dvaceti.

[pavlix]

IMO záleží hodně na kontextu. Pokud jde o aplikaci pro zpracování textu, tak tenhle argument při jejím návrhu neobstojí.

[Jan Zahornadsky]

Pokud ta aplikace potřebuje rychle zjistit délku textu, tak by neobstálo ani UTF-8 (nebo jakékoli jiné kódování s variabilní šířkou znaku), přesto se běžně používá. Je to jen multiplikativní konstanta.

Pokud někomu záleží na velikosti, použije kompresi. Text se komprimuje velmi dobře, v tomto případě ani ne kvůli kódování, ale díky samotným vlastnostem lidského jazyka.

[pavlix]

To už se pouštíme do prázdných spekulací, že :). Někdy se hodí formát s pevnou šířkou, jindy relativně efektivní utf-8, jindy nějaká šikovná komprese na jedné z uvedených variant. Těžko najdem obecně nejlepší variantu. Snad jen utf-16 u mě prohrává ve všech případech :).

[Jan Zahornadsky]

Na tom se shodneme

[pavlix]

+1

[Nicky726]

Písma, kde znak představuje slovo, mají výhodu v tom, že se může na jeden znak namapovat několikerá "nářeční" výslovnost. Takhle se pomocí písma dorozumí například celá Čína, i když by si v mluvené řeči kvůli "nářečním" problémům vůbec nerozuměli.

V evropském prostředí s písmy, která reprezentují spíše zvukovou podobu, než vlastní význam, je sice výrazně menší množina znaků, které musí člověk umět, ale zato Němec nerozumí zápisu, který udělá Angličan, i když jsou po stránce příbuznosti na tom asi podobně jako některé národy v Číně.

[Jan Zahornadsky]

Celá Čína se jedním písmem domluví díky tomu, že existuje prakticky jediná psaná forma jazyka. Něco jako celá Evropa by se "dopsala" mezi sebou, pokud by se jako jediná psaná forma učila třeba jenom němčina (tj. Češi by na papír psali "Ich möchte" když chtějí napsat "chci").

[Andrej]

Zrovna tenhle text není moc dobrý argument pro obhajobu současného zmatku kolem kódování. A z téhož článku cituji:

Almost everyone in their right mind will use an UTF-8 locale for now (unless some obsolete but important piece of software has other requirements), but nobody should be forced to do so, neither now, nor in the future. For, if something better or more suited to some environment comes along, it will then be easier to switch to it.

Autor na jedné straně tvrdí, že kdo nepoužívá UTF-8 locale, ten na tom možná není úplně dobře, pokud jde o rozum. Na druhé straně ostře vybízí k bezbřehé toleranci hraničící s otevřenou podporou totálního chaosu. Poněkud rozporuplný přístup k věci.

V době vzniku toho blogpostu jsem už sice měl UTF-8 locale, ale o pár měsíců dřív jsem ještě používal ISO-8859-2, protože kvůli některým programům (a rozhodně nebyly obsolete) to bylo nezbytné. A potíže s hlavou jsem neměl.

Refusing minimal locale support and encoding conversions, where possible and useful, and assuming instead everyone who wishes to partake in an exchange, to use the same locale and encoding, should not be an option, not if diversity has any value to you. And if that is not the case, I don't want to have anything to do with you or your programs.

Ve světě, kde žiju já, je situace taková: Drtivá většina uživatelů o takových věcech vůbec nerozhoduje a ani nedovede kvalifikovaně rozhodnout! 99% uživatelů netuší, jakým způsobem se ukládají jejich data a jak s tím souvisí texty. Chtějí pouze kompatibilitu. Problém tedy není v tom, že by někdo nutil uživatele, aby byli ve všem stejní. Někdy vidíme pravý opak. Microsoft je toho příkladem. Jeho kódování Windows-1250 andeb zmrzačené-latin-2 na dlouhou dobu zmrazilo pokrok v oblasti ukládání a sdílení textů ve všech jazycích kromě angličtiny.

Zatímco ASCII-assumption je zjevně něco zcela špatného, protože jde v podstatě o předpoklad existence jen dvou jazyků — latiny a angličtiny —, UTF-8-assumption mi přijde jako rozumný předpoklad všude tam, kde není možné kódování explicitně oznámit v metadatech nebo jiným vhodným způsobem. Jednoduše proto, že v dnešním světě neexistuje jazyk, kterému by UTF-8 působil problémy. Nebo snad existuje?

Jsou konvence, jejichž nedodržení vede k potížím. To pochopitelně neznamená, že by se z konvence měl stát zákon. Vznikla by totalita. (V tomto směru s autorem blogpostu souhlasím.) Neodpustím si ovšem jeden protipříklad pro ilustraci:

Kdybych měl dost prostředků, nic mi nebrání zkonstruovat auto, které se řídí gamepadem připojeným do USB portu na palubní desce. Když si ale půjčím pro mě dosud neznámé auto v půjčovně, můžu směle předpokládat, že bude mít volant a pedály. Autor odkazovaného blogpostu ovšem tvrdí, že to předpokládat nesmím a že musím být kdykoliv připraven začít se v přeplněných ulicích velkoměsta učit ovádat auto gamepadem. A to je nesmysl.

[Andrej]

Drobná oprava: Poznámka o Windows se měla týkat všech znakových sad Windows-xxxx, ne pouze té středoevropské.

[pht]

Zjevně jste nepochopil pointu článku.

UTF8 možná je v současné době použitelné, ale není to konečná. Vy, jako programátor, nikoliv jako uživatel, byste neměl předpokládat, že všechny texty v minulosti, současnosti a budoucnosti budou v UTF8, ale měl byste předpokládat, že budou v čemkoliv, a použít nějakou abstrakční vrstvu, která se vypořádá nejen se současně používanými kódy, ale bude i v budoucnu rozšiřitelná.

Navíc mám dojem, že si pletete Unicode a UTF8.

[Jan Zahornadsky]

Jednoduše proto, že v dnešním světě neexistuje jazyk, kterému by UTF-8 působil problémy. Nebo snad existuje?

Existuje A nejsou to žádné jazyky na vymření, třeba čínština a japonština. To si jednou nějaká chytrá hlava kdysi řekla, že "vždyť to vypadá málem stejně" a jednoduše se sjednotily některé varianty znaků. Takže je v Unicode jeden kód pro dva (graficky a foneticky, někdy i významově) různé znaky.

Převedeme-li to, co se stalo s kódováním těmto asiatům do našich zeměpisných šířek, tak je to jako kdyby byl v Unicode jediný kód pro znaky "ů" a "ô" (a klidně i pro další páry, co třeba "m" a "n", taky téměř stejné). Volbou vhodného fontu (slovenský font, český font, font s m, ...) by se rozlišovalo, který z těchto znaků se zobrazí. Kdo by proboha mohl mít tu drzost takový systém nazývat konečným řešením!?

A to jsem ještě nezačal uvádět druhou vlnu zjednodušování čínských znaků (která co jsem se naposledy koukal chybí téměř celá), ten korejský nesmysl co je zaveden, ty chyby co tam zavlekla nepozornost, systematických duplicit atd. atd.

[xurpha]

a) naprosto nesmyslně směšujete UTF-8 s unicodem. UTF-8 význam žádných znaků nedefinuje, je to čistě transportní kódování,

b) od toho se unicode vyvíjí a má pravidla, jak řešit podobné problémy, aby v případě potřeby bylo možné v další verzi unicode sjednat nápravu (jak se už mnohokrát stalo)...

[michal00]

Klingončina nebola zahrnutá do unicode, takže v budúcnosti snáď vznikne niečo širšie...

[Tomas]

Prosim, priste si aspon jednou v zivote ty windowsy pustte, aby jste vedel o cem pisete. Protoze to co pisete v tretim odstavci, je nesmysl. Od zacatku do konce..

- jediny rozdil ms X linux je v tom, ze zatimco s linuxem (resp. v distribucich) dostavate vsechny jazykove balicky naraz. ve svete windows defaulnte dostavate jednu vybranou (to je ta verze, kterou koupite). dalsi jazykove balicky si muzete dostahovat z win update na jeden, dva kliknuti. binarky programu jsou stejne, jedine co balicky obsahuji a do systemu dokopiruji, jsou prislusne jazykove resourcy (texty atd) - cili princip stejny jako v linuxu

- pokud mate v systemu prislusne jazykove balicky, tak muze soucasne pracovat samozrejme X uzivatelu (i soucasne) a kazdy muze mit jine prostredi (jeden cinstinu, jeden japonstinu, dalsi anglictinu a dalsi cestinu). to se SAMOZREJME tyka jak klavesnice a narodnich zvyklosti (datum, cas , format cisla apod), tak veskerych textu, napoved apod.

[Jan Zahornadsky]

Hehe, souhlas, navíc je ten překlad aspoň kompletní a za něco stojí.

Akorát si myslím, že aby to co tu Tomas napsal platilo, je potřeba mít multiple language version nebo jak se tomu nadává. Některé levnější distribuce Windows to totiž tuším nepovolují.

[Tomas]

ano, samozrejme. u klientskych edici windows se to tyka "vyssich" edici (nicmene nizsi verze jsou identicke, jen je prislusne GUI pro nastaveni jazykove verze skryto, ale da se to tam (proti licenci) dostat i u nich). u serverovych edici windows je to soucast vsech edici.

ve vetsi mire se jazykove balicky a multilanguage prostredi objevuji a pouzivaji u win vista, win 7, win server 2008 a win server 2008. nicmene existuji i multijazykove verze starsich systemu (i kdyz tam to bylo mnohem mene obvykle).

ostatne, i u "prehistorickych" windows xp existuje multijazykova verze - pouzivala ji edice windows media center. taktez u win 2000 byla udajne multijazykova verze (ale s tou jsem se nikdy nesetkal). u starsich systemu (win 95, win 98 atd) byly jazykove resourcy opravdu "natvrdo" v binarkach.

[Andrej]

Inu dobrá, takže Microsoft se s desetiletým zpožděním dohrabal k podpoře pro lokalizaci, která byla v linuxových distribucích už dávno. Well done.

Nicméně tato lokalizace je (předpokládám) k dispozici jenom za příplatek a jenom u některých verzí. Ostatní verze mají antifeature. Což je skoro totéž, jako by tam nebyla.

Mimochodem, znamená to, že když spustím jeden počítač s Windows a bude s ním přes RDP pracovat 10 uživatelů paralelně, bude mít každý z nich svoji lokalizaci? Mám takové tušení, že v tom zase bude háček...

[Tomas]

Za kazdou cenu budete prudit?

K dispozici jsou samozrejme VSECHNY jazykove balicky, a to ZDARMA. U serverovych windows funguji na jakekoli edici, u "klientskych" na vyssich edicich (u nizsich se daji pouzit neoficialne).

A co se terminal serveru a RDP tyce, tak SAMOZREJME kazdy muze mit svuj vlastni jazyk.

[pavlix]

Proc tak agresivni ton?

A... ZDARMA? SAMOZREJME? VSECHNY?.... a co mi jeste nabidnete, ze muzu vyhrat auto?

Prijde mi, ze ted opravdu jen prudite.

[pavlix]

A tedka prozmenu k veci... lokalizace neni pouze jazyk, ale treba i casova zona. Lze alespon nekterou verzi a variantu windows pouzivat vzdalene s ruznymi casovymi zonami?

[Tomas]

a jeste doplnim - duvod, proc jsou jazykove balicky samostatne, a nejsou soucasti systemu, je jednoduchy - proc mit na instalacnim DVD o giga vic obsazeneho mista (a nasledne na PC o vic nez dve giga obsazeneho mista), kdyz 99% lidi za cely zivot pouzije jeden jediny jazyk (a to svuj)...

[Andrej]

Rád věřím, že na nějakých Windows Ultra-Hyper-Server-Stojím-Sto-Litrů to asi půjde, ale nějaká Vista, což jsou zatím poslední Windows, které jsem viděl, se ke změně locale moc neměla. Asi to nebyla edice Hyper-Kdesicosi, nevím...

To je podobné, jako když se se mnou tuhle někdo hádal, že 64-bitová verze Windows podporuje víc než 8 GB RAM. Skutečně? Vista Home Basic rozhodně ne.

[hajma]

Po tomhle mi už nezbývá, než doporučit odstranit diakritiku z názvů úplně.

Ja bych naopak doporucil se s tim naucit zit. Protoze se ti jinak stane, ze musis neco udelat na stroji, kde jsou nazvy obsahujici pomalu i konce radek, a kdyz nevis co s tim, tak koncis.

[Martin Fiala]

Pro převod znakových sad existuje online nástroj na adrese http://retezce.jednoduse.cz/