Windows jsou case sensitivní (diskuse)

[xkucf03]

Nebylo by lepší ty Windowsy vůbec nezapínat? Ušetřil bys spoustu starostí.

[frdrx]

Toto je vyčerpávající, 100% moudro.

[Bystroushaak]

Prostě u úterý a čtvrtka musí být na začátku velké písmeno (u ostatních dní ne)

Haha, tohle je geniální trolling. Představ si, jak se museli nasmát, když to tam přidávali.

[petr_p]

Tohle je výsledek strcasecmp(3). Jeho výsledek v jiném locale než POSIX totiž není definován. A chová se tak i glibc.

[pavlix]

POSIX nikdy nebyl unicode ready. Používat holý POSIX v kombinaci s lokalizací není dobrý nápad.

[Let_Me_Be]

Co maji proboha locales spolecneho s Unicode?

[pavlix]

Napsal jsem něco nesrozumitelně, či snad dokonce špatně?

[Let_Me_Be]

Ano a ano

Unicode nema nic spolecneho s lokalizaci/nebo locales. Pouzivani locales je naprosto v poradku a bezproblemove, pokud se dodrzi nekolik jednoduchych pravidel:

1. jeden znak = jeden wchar_t (Windows nedodrzuje)
2. pri praci s cimkoliv mimo 7bit ASCII se pouzivaji siroke znaky a odpovidajici funkce
3. dusledne se pouzivaji locales tak kde se maji pouzivat

To jestli nektera je nektera cast kodovana v Unicode (at uz UTF-8,UTF-16 nebo UTF-32) je uplne sumak.

[pavlix]

Unicode nema nic spolecneho s lokalizaci/nebo locales.

Nesouhlasím, že nemají nic společného.

jeden znak = jeden wchar_t (Windows nedodrzuje)

Není obecně potřeba.

pri praci s cimkoliv mimo 7bit ASCII se pouzivaji siroke znaky a odpovidajici funkce

Není obecně potřeba.

Pouzivani locales je naprosto v poradku a bezproblemove, pokud… dusledne se pouzivaji locales tak kde se maji pouzivat

Nic neříká.

To jestli nektera je nektera cast kodovana v Unicode

Až na to, že Unicode je dnes především znaková sada.

(at uz UTF-8,UTF-16 nebo UTF-32) je uplne sumak.

Nevím, na co narážíš. Všechny uvedené dokážou reprezentovat všechny code pointy Unicode. Nějak nevidím smysluplný spor, snad kromě toho, že popíráš jakoukoli souvislost mezi Unicode a locales.

[Let_Me_Be]

Není obecně potřeba.

Pokud tohle neplati, neni mozne pouzivat standardizovane API (pokud se teda bavime o C99/POSIX a ne C++11).

Nějak nevidím smysluplný spor, snad kromě toho, že popíráš jakoukoli souvislost mezi Unicode a locales.

Ano popiram, protoze ANSI C++ (C++03), C99 a POSIX jsou agnosticke vuci znakove sade/kodovani.

[pavlix]

Pokud tohle neplati, neni mozne pouzivat standardizovane API (pokud se teda bavime o C99/POSIX a ne C++11).

Non sequitur. Jako důkaz snad postačí, že se toto API pro non-ASCII řetězce používá.

[Let_Me_Be]

Pak si ale muzes tyhle dementni komentare "Používat holý POSIX v kombinaci s lokalizací není dobrý nápad." strcit nekam.

Protoze ano, kdyz znasilnujes API k necemu k cemu nebylo navrzene a ono to nahodou funguje a obcas se to rozbije, tak je to opravdu jenom tvuj problem a ne problem toho API.

[pavlix]

Sice umíš hezky nadávat, ale jinak mě moc nebavíš.

[Let_Me_Be]

Jestli necemu nerozumis tak si zalez nekam do kouta a nesir dezinformace.

[rastos]

Dopustil si sa viacerých chýb:

1. používaš Windows (to je povinné podrypnutie v tejto situácii, ale súvisí to s nasledujúcim bodom)
2. na vytvorenie task-u používaš commandline a nie Task Scheduler
3. nepoužívaš anglickú lokalizáciu
4. myslel si si, že robiť case-insensitive porovnanie na ne-anglické znaky (jednoducho) funguje

Nech je to výstrahou pre ďalšie generácie

[GeBu]

Ad 1) Není to můj počítač, ale v jedné neziskovce, kde se to kupuje od Boxed už s Windows a tak se jiný systém neřeší.

Ad 2) Jedu přes vzdálený přístup a přes commandline mi to přišlo jednodušší. Navíc když to vytvořím přes commandline, tak se to vytvoří s takovými právy, že to Task Scheduler neumí editovat a musí si to přeuložit s jinými právy. Nechtěl jsem zbytečně měnit něco, co funguje - potřebuji to vypínat, i když není uživatel přihlášený.

Ad 3) Viz Ad 1).

Ad 4) :).

Já jsem o těch průšvizích věděl - už jsem na to jednou narazil ve Windows XP. Tam byl problém s diakritikou a pořešil se editováním přes "edit" vestavěný editor. Tady ho jednak nemůžu najít a jednak byl průšvih v něčem jiném.

[regine2]

Neobviňujme POSIX a ostatní.

Problém je v Microsoft. Proč vymýšleli v MS nějaké kódové stránky pro českou diakritiku (od DOS po Windows snad 4 varianty), když od 60tých let minulého století měla česká i slovenská kódová stránka ISO - standard?

Pokusili se o to i v Německu, ale tam si dupli a museli jim ISO ihned zavést.

Stačí si s českou diakritikou pojmenovávat soubory/adresáře/složky a jejich vlastní vyhledávač je v některých případech ignoruje. Mám ověřeno vůči Copernic Desktop Search-vyhledávači. CDS to umí.

[pavlix]

Tak IS0 8859 nebo kolik to bylo je navíc v době unicode značně obsolete.

[regine2]

No ale oboje normy jsou standardy ISO International Organization for Standardization nebo novější Unicode is a computing industry standard

ISO
Unicode

A Unicode vychází z ISO-8859:

Unicode has the explicit aim of transcending the limitations of traditional character encodings, such as those defined by the ISO 8859 standard ...

[pavlix]

Reagoval jsem na ty české a slovenské kódové stránky. Nehledě na to, že druhá citace jenom podporuje to, co jsem psal, že v době unicode jsou naše národní znakové sady jaksi zbytečné.

[regine2]

Samozřejmě rozumím a souhlasím.

Problém MS vytvořil v tom, že než se rozběhlo Unicode, tak vygeneroval několik kódovacích stránek pro obrovské množství informačních databází a znalostních databank.
Ve vzniklé kódovací džungli se potom vyhledávací roboti ztrácí a dohledání informací je problematické.

[pavlix]

Co jsem tak slyšel, tak MS tím jen pokračoval v tradici IBM, která sekala národní kódování jak baťa cvičky ;).

[Franta]

Napadá tě jiné řešení než mít více znakových sad, když má platit 1 znak = 1 bajt? (tehdy zcela validní požadavek – místy validní i dnes) Národní kódování jsou přirozené a správné řešení tohoto úkolu. Problém je ve vytváření „truc-kódování“ která mají zanést nekompatibilitu, škodit, být duplicitní k jiným používaným/standardizovaným kódováním, podporovat vendor lock-in.

[pavlix]

Psal jsem, že IBM byli pokud vím proslulí tím, že sekali kódování jako baťa cvičky. Tedy vytvářeli duplicitní, nekompatibilní a obecně nepotřebná kódování. Dokonce na to byl nějaký vtip o e-mailech mezi IBM stroji.

[Let_Me_Be]

Bohuzel dokud budeme mit Windows tak 8bit kodove stranky nebudou nikdy zbytecne. Windows vs. Unicode je velmi smutny a dlouhy pribeh.

[pavlix]

Bohuzel dokud budeme mit Windows tak 8bit kodove stranky nebudou nikdy zbytecne.

To by nic neměnilo na tom, že na ně už není potřeba pohlížet jako na znakové sady a redefinují se jako neúplná kódování unicode. Ale ani tak si nemyslím, že máš pravdu. Windows nemají ani tak problém s absencí unicode, jako s provedením. Ale zdaleka v tom nejsou samy. A zdaleka to není jen vina Microsoftu.

[Let_Me_Be]

U Windows je presne opacny problem. Problem je v tom ze kazde kodovani je explicitne pritomne (narozdil od Linuxu, ktery je pomerne dusledne nezavisly na kodovani).

[pavlix]

Linux je nezávislý na kódování asi tak jako céčko. Umí ASCII a rozšířené znakové sady a víc ho nezajímá. Do toho perfektně zapadá UTF-8. Ale že by například nedefinování znakové sady API pro práci s názvy souborů byla nějaká extra výhoda, to se mi úplně nezdá.

Pořád píšeš o nějakých imaginárních problémech, ale nevšiml jsem si, že bys jeden jediný popsal.

[Let_Me_Be]

Cecko neumi ASCII.

[pc2005]

Windows vs. Unicode je velmi smutny a dlouhy pribeh.

Neměl MS už v době win3.11 něco jako unicode? Pamatuju si, že během vrtání v binárkách byly některé textové řetězce tvořené nulou a normálním znakem.

[Franta]

V té době, kdy byla otázka cp1250 vs. ISO-8859-2 aktuální se běžně používala pouze jednobajtová kódování, prostě jeden bajt = jeden znak.

[pavlix]

Mění to něco na tom, co jsem psal?

[Franta]

Tvůj předchozí komentář se zdá být mimo téma. Pro pořádek: psal jsi ho ve vztahu k současnosti, nebo ve vztahu k té době kdy MS vytvářel cp1250?

[pavlix]

Tvůj předchozí komentář se zdá být mimo téma.

Nejsem o tom přesvědčen.

Pro pořádek: psal jsi ho ve vztahu k současnosti, nebo ve vztahu k té době kdy MS vytvářel cp1250?

K současnosti, tedy časově spíše vzhledem k obsahu blogpostu než komentáře. Použité slovo navíc mělo značit, že se snažím informaci podpořit a doplnit, nikoli popřít.

[Franta]

Tvůj předřečník kritizoval MS za vytváření duplicit k ISO 8859-2 standardu a ty se tuto informaci snažíš podpořit kritikou ISO 8859-2 standardu? No nevím, to je asi jedno.

[pavlix]

Standard ISO-8859-2 jsem nikde v diskuzi nekritizoval. Nenapadá mě jediný důvod, proč bych měl označení za obsolete považovat za kritiku.

[gtz]

No jak jsem už někdy psal, s kódováním z MS je vždy nějaký problém. Stačí si jen udělat export kontaktů z outlook.com do jejich CSV souboru. A co se stane? Čeština je rozsypaný čaj a když se podívám tak to vypadá:

Non-ISO extended-ASCII text, with very long lines, with CRLF line terminators

Vypadá to jako cp1250, ale není, je to nějaký jeho paskvil. Nakonec jsem nevydržel se s tím babrat a načetl jsem to ve Wmvare do Widlí, přeuložil do UTF-8 a pohoda.

A jak píše autor, překlady funkcí stojí za dvě věci ..

[jozka]

Prekladatele, ktery se ve sve pyse pusti do prikazu bych za trest posadil pred dilo jejich myslenkoveho souputnika z uplne jine jazykove oblasti. Jako se to stalo me se spanelskym excelem nebo ceskou MicroStation, kde jakysi alternativni inteligent dokazal stvorit situaci, kde fungovalo odpojeni vsech referencnich vykresu po zadani logicky odvoditelneho prikazu "ref det vše".

[pc2005]

Ještě to mohlo být horší. Ještě to mohlo být přeložený úplně celý .