Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 344 345 [346] 347 348 ... 375
5176
Server / Re:OwnCloud pro produkční nasazení
« kdy: 27. 07. 2014, 09:07:04 »
Diskutujúci sa sami presvedčili, že nechcem úložisko. Ja ako užívateľ chcem "Dropbox" a v ňom tlačítko na úpravu PDF. Alebo na konverziu JPEG do PDF.
Ne, vy nechcete Dropbox. Možná akorát nevíte, co to Dropbox vlastně je, ale doporučuju, abyste tohle přirovnání přestal používat, protože tím pouze matete všechny okolo.

Vy chcete webovou stránku, kam nahrajete soubor, server s ním provede nějaké úpravy a vy si ho zase stáhnete k sobě.

A pôvodná otázka znela, že čo použiť namiesto "Dropboxu" : Owncloud, AjaxExplorer, SeaFile etc.
Přičemž se posléze ukázalo, že žádné úložiště nechcete.

Aj keď neviem načo odznovu kódiť už raz nakodené.
Nic takového nikdo nenavrhuje. To, co byste použil z vámi uváděných aplikací, je upload souboru přes web a jeho download. Přičemž obojí je už naprogramované ve webových prohlížečích, takže byste to znovu neprogramoval. To, co potřebujete naprogramovat vy, je ten mezičlánek na serveru, který vezme uploadovaný soubor a upraví jej.

5177
Server / Re:OwnCloud pro produkční nasazení
« kdy: 26. 07. 2014, 17:52:58 »
Se mi zdá, že většina odpovědí je dost off topic. Tiskařů asi nebude milion, nebudou mít tisíce přístupů v jednom okamžiku, a na cloudu taky nezáleží...
Mimo téma není většina odpovědí, ale původní dotaz:

Citace
rovnako kvalitné úložisko ako je je Dropbox?
Teprve v průběhu diskuse vyplynulo, že tazatel nechce žádné úložiště, které by byť jen vzdáleně připomínalo Dropbox. Že vlastně nechce vůbec žádné úložiště.

5178
Hardware / Re:Spojení DVI-DVI pomocí kabelu HDMI a redukcí
« kdy: 19. 07. 2014, 08:14:52 »
Také si dejte pozor na to, zda na obou koncích je digitální DVI. Analogové DVI přes HDMI neprocpete.

5179
/dev/null / Re:Zobrazeni Google Street View
« kdy: 18. 07. 2014, 14:01:54 »
no a nebo ceska alternativa (beztak lepsi pro ceske planovani)
Lepší zejména pro plánování nočních cest…

5180
Server / Re:Nastavení localhost
« kdy: 17. 07. 2014, 15:53:25 »
Opravdu máte na těch Windows jenom tenhle řádek, není tam třeba taky následující?
Kód: [Vybrat]
127.0.0.1 localhost
A i kdyby ne, název localhost bych na jinou IP adresu nepředělával, ten název má speciální význam.

5181
/dev/null / Re:Zobrazeni Google Street View
« kdy: 17. 07. 2014, 09:13:53 »
Když něco vyhledáte, náhled StreetView se zobrazí přímo v tom panelu s výsledky vyhledávání, stačí na něj kliknout. Žlutý panáček je vpravo dole.

5182
Software / Re:Samba a opravnenia
« kdy: 15. 07. 2014, 19:02:20 »
Dostanete se do toho adresáře a vypíšete jeho obsah pod příslušným uživatelem normálně z linuxové příkazové řádky?

5183
Vývoj / Re:Kódování souboru v Javě
« kdy: 15. 07. 2014, 15:00:24 »
Because the contents of the encoding declaration are restricted to characters from the ASCII repertoire (however encoded), a processor can reliably read the entire encoding declaration as soon as it has detected which family of encodings is in use.
Nepletete vy si znaky a bajty?
Mám kódování, kde se znak < (hodnota 60) zapisuje jako dvojice oktetů 3C 3F, znak ? (hodnota 63) jako dvojice oktetů 78 6D, znak x (hodnota 120) jako dvojice oktetů 6C 20 atd. Standard je splněn, znaky <, ? i x jsou znaky z ASCII, i celá deklarace kódování jsou jen znaky z ASCII, protože pevné části deklarace jsou znaky z ASCII a název kódování jsou také znaky z ASCII.
Akorát je tu pořád ten problém, že existují kódování, která znaky ASCII (ani z její dolní poloviny) nekódují do oktetů stejně, jako kódování ASCII. Příkladem takových kódování jsou UTF-16 nebo UCS-4.

Ne, žádné další kódování nebude hádat, proč by to dělal? Hlavička je úspěšně načtena a je v ní uvedeno kódování BLABLA.
A jak se to podařilo tu hlavičku načíst, když k jejímu správnému přečtení je potřeba vědět, že je v kódování BLABLA? A když to nevíte a pokusíte se to přečíst jako ASCII, dostanete jiný text?

Zajímavé je, že nikdo z autorů XML parserů s tímto neměl nikdy problém
Ano, protože parsery řeší pár vybraných kódování. Ale standard, který připouští libovolné kódování, pokud je černé, je trochu divný.

Není potřeba, už jsi to zkopíroval a vložil.
Já jsem vkládal pouze části, které se týkají zpracování znaků. V souborech jsou ovšem bajty (oktety), které je potřeba na znaky převést. Jak se mají převést, to určuje právě kódování. Jenže abych se dozvěděl kódování, musím nejprve přečíst text – ve správném kódování. Dnešní parsery to dělají tak, že zkusí tipnout varianty UCS-2 a UCS-4, pokud to nevychází, mohou tipnout ještě EBCDIC, a pokud ani to nevyjde, předpokládají, že jde o kódování, které znaky 0–127 kóduje stejně, jako ASCII. Takže když narazí na kódování, které tyhle znaky kóduje jinak, nedopadne to dobře – v lepším případě parser skončí chybou kvůli neočekávaným znakům, v horším případě ty oktety budou dávat smysl i pokud budou čtené jako ASCII, a parser načte něco úplně jiného, než v souboru je ve skutečnosti.

5184
Vývoj / Re:Kódování souboru v Javě
« kdy: 15. 07. 2014, 13:41:57 »
No dobře, uznávám že standard jasně říká že pokud je k dispozici externí informace o kódování (tj. ona metadata), tak se může udělat fakt opravdu libovolné.
Nebylo by jednodušší, než si to vymýšlet, přečíst si příslušnou část standardu, kterou jsem v předchozím komentáři citoval? Tam je jasně napsáno, že pokud externí informace k dispozici není a není použito kódování UTF-8 nebo UTF-16, musí být kódování vždy uvedeno v hlavičce.

Žádnou. Pokud všechny znaky v této sekvenci mají stejné kódování jako v ASCII, tak je všechno v pořádku, metadata jsou korektně zakódována přímo uvnitř souboru a není potřeba mít žádná out-of-band data.
A pokud znaky v této sekvenci nemají stejné kódování, jako v ASCII, je podle standardu také všechno v pořádku, akorát parser musí zkusit uhodnout další kódování. A když bude to moje kódování vhodně vytvořené, tak ho nedokáže odlišit od kódování třeba UTF-8.

Dokazes pochopit len tu jednu jedinu vec, kde sa pise o hlavicke?
Ano. Chápu jí, dokonce jsem jí tu citoval, aby to ostatní nemuseli hledat, a pak jsem popsal příklad, který neodporuje ničemu ze standardu, přesto parser nedokáže kódování určit, i když to kódování bude umět.

Citace
V té hlavičce smí být jen znaky s ordinální hodnotou 0-127
To je ten standart.
Vím, že se budu opakovat, ale kde to v tom standardu je uvedené? Standard není něco, co vy jen tak prohlásíte. XML je definováno tímto standardem, takže odpověď na otázku „kde to ve standardu je“ by měla označit nějakou část tohoto dokumentu, nebo dokumentu z něj odkazovaného. Případně tu část můžete zkopírovat a vložit sem.

5185
Vývoj / Re:Kódování souboru v Javě
« kdy: 15. 07. 2014, 12:08:15 »
Velmi jednoduchá a jasná odpověď: specifikace / standard.
XML standard striktně definuje a omezuje jaká kódování se smí použít. Pokud dodržíš standard, tak autodetekce bude fungovat.
Kde to ten standard definuje?

Although an XML processor is required to read only entities in the UTF-8 and UTF-16 encodings, it is recognized that other encodings are used around the world, and it may be desired for XML processors to read entities that use them. In the absence of external character encoding information (such as MIME headers), parsed entities which are stored in an encoding other than UTF-8 or UTF-16 must begin with a text declaration (see 4.3.1 The Text Declaration) containing an encoding declaration:

In an encoding declaration, the values " UTF-8 ", " UTF-16 ", " ISO-10646-UCS-2 ", and " ISO-10646-UCS-4 " should be used for the various encodings and transformations of Unicode / ISO/IEC 10646, the values " ISO-8859-1 ", " ISO-8859-2 ", ... " ISO-8859- n " (where n is the part number) should be used for the parts of ISO 8859, and the values " ISO-2022-JP ", " Shift_JIS ", and " EUC-JP " should be used for the various encoded forms of JIS X-0208-1997. It is recommended that character encodings registered (as charsets) with the Internet Assigned Numbers Authority [IANA-CHARSETS], other than those just listed, be referred to using their registered names; other encodings should use names starting with an "x-" prefix. XML processors should match character encoding names in a case-insensitive way and should either interpret an IANA-registered name as the encoding registered at IANA for that name or treat it as unknown (processors are, of course, not required to support all IANA-registered encodings).

Když si nadefinuju vlastní kódování „BLABLA“ a budu mít soubor, který bude mít na začátku hlavičku s následující sekvencí znaků (zapsanou samozřejmě v „BLABLA“ kódování), kterou část standardu ten soubor porušuje?
<?xml encoding='x-BLABLA'?>

Co mi brání vymyslet si 3- nebo 6bajtové?

Brání tomu konvence, normy a specifikace, u XML jednoduše akceptujeme asi sedm možností, ostatní se buď přizpůsobí nebo zemřou.
Ono to v praxi funguje, protože se reálně těch kódování moc nepoužívá, ale univerzální postup použitelný pro jakoukoli sadu kódování neexistuje.

5186
Vývoj / Re:Kódování souboru v Javě
« kdy: 15. 07. 2014, 10:31:25 »
Které kódování tímto postupem neprojde?
Třeba libovolné vícebajtové kódování jiné než UTF*/UCS*, nebo libovolné bajtové kódování, kde spodní polovina není shodná s ASCII. A dá se vymyslet i takové kódování, které bude procesor podle tohoto postupu považovat třeba za UTF-16, ale ve skutečnosti půjde o jiné kódování.

Taky jsem mohl poslat odkaz bez kotvy, aby sis to mohl přečíst celé.
Není potřeba, já jsem to celé četl už dávno a od té doby mnohokrát.

Jestliže si nedokážeš představit natož realizovat algoritmus na detekci zda je počáteční <?xml 1-2-4 byte a little-big endian, pak s tebou diskuze na toto téma opravdu nemá smysl.
Kde je definováno, že libovolné kódování musí být 1-, 2- nebo 4bajtové? Co mi brání vymyslet si 3- nebo 6bajtové? Co mi brání vymyslet si třeba dvoubajtové kódování, ve kterém se posloupnost tří znaků <?x zapíše jako 3C 3F 78 6D 6C 20?

5187
Vývoj / Re:Kódování souboru v Javě
« kdy: 15. 07. 2014, 09:16:56 »
http://www.w3.org/TR/xml/#sec-guessing-no-ext-info
Ano, to je ten postup ono to v praxi funguje, protože se reálně těch kódování moc nepoužívá, ale univerzální postup použitelný pro jakoukoli sadu kódování neexistuje. Já vím, ono je to napsané až ve třetím odstavci odkazovaného textu, kdo by tak daleko dočetl, že… Takže stále platí, že opravdu univerzální řešení je jenom uvádět typ souboru a jeho kódování v metadatech mimo samotný obsah souboru.

5188
Vývoj / Re:Kódování souboru v Javě
« kdy: 15. 07. 2014, 08:14:08 »
V té hlavičce smí být jen znaky s ordinální hodnotou 0-127.
Podle kterého standardu?

5189
Vývoj / Re:Kódování souboru v Javě
« kdy: 15. 07. 2014, 06:49:52 »
Dokumenty XML, které jsou v jiném kódování, mají povinnost toto kódování uvést v hlavičce.
No právě. Jenže pro správné přečtení hlavičky je nutné znát to kódování.

5190
Vývoj / Re:Kódování souboru v Javě
« kdy: 14. 07. 2014, 21:22:53 »
Však jsem popsal deterministický postup. Musím zde uvádět kompletní algoritmus, abys to pochopil?
"Pokusí se uhodnout" nezní zrovna jako deterministický postup. A "jiná kódování se nezkoušejí" nevypadá jako dobrý postup, jak přečíst ten dokument v jiném kódování. Ono to v praxi funguje, protože se reálně těch kódování moc nepoužívá, ale univerzální postup použitelný pro jakoukoli sadu kódování neexistuje. Když si vymyslím čtyřbajtové kódování, kde menšítko bude kódováno jako 3C 00 3F 00 atd., bude se to těžko odlišovat od UTF-16.

Stran: 1 ... 344 345 [346] 347 348 ... 375