OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Nějak mi občas nefunguje načítání doplňkových souborů k uloženým html stránkám, tak jsem se snažil zjistit, čím to je a udělal jsem pokus:
Vyrobil jsem si dva html dokumenty (dal jsem je tady do přílohy, ať na ně vidíte). Jsou v něm odkazy - jeden dokument odkazuje na druhý dokument a naopak, takže kliknutím na odkaz se dostanete z jednoho dokumentu na druhý. Odkazy jsou dělané pomoci relativní cesty, v tomto případě cesta obsahuje jenom název souboru. Názvy těchto souborů neobsahují mezery, háčky, čárky nad písmenem, ani podobné nevhodné znaky. Aby tyto odkazy fungovaly, oba html soubory musí být umístěné společně v jedné složce. Dokumenty jsem vyrobil ve znakové sadě UTF-8. Odkazy fungují, jak mají. Dokonce i když název složky, ve které jsou umístěné, nebo název kteréhokoliv nadřazeného adresáře, obsahuje háčky, čárky, mezery a pod, nevadí, nemá to na funkci vliv.
Potom jsem zkusil oba html dokumenty převést do jiné znakové sady, například na ISO 8859-2 a samozřejmě jsem nezapoměl ani opravit tag meta, aby v něm zapsaná znaková sada odpovídala te použité. Tyto dokumenty jsem zkusil otevřít v prohlížeči, zobrazují se opět čitelně a fungují i odkazy, ale odkazy fungovaly jenom do te doby, než jsem některý z nadřazených adresářů pojmenoval názvem, obsahujícím háčky, čárky nad písmeny, mezery a podobně. Potom mi přestalo fungovat klikání na odkazy v těch dokumentech a hlásilo se něco podobného, jako: Chyba při načítání /home/david/Nov??slo?ka/clanky/clanek2. Soubor /home/david/Nov??slo?ka/clanky/clanek2 neexistuje. Když jsem v prohlížeči ručně nastavil znakovou sadu UTF-8, samozřejmě se texty zobrazovaly nečitelně (což je v pořádku), ale klikání na odkazy fungovalo.
Čím to je, že to tak blbne? A zjistil jsem, že podobné problémy jsou nejen s klikacími odkazy typu a href=, ale i img src= a možná i dalších. Později jsem zjistil další věc: Pokud nastala ta situace, kdy ty odkazy nefungují (například výše popisovaný pokus), tak nefungují, jen když ty dokumenty prohlížím v Konqueroru; když jsem je otevřel v Mozille Firefoxu, tak to funguje normálně. Není to nakonec chyba Konqueroru? Verzi Konqueroru se mi nepovedlo zjistit, ale jestli to pomůže, mám KDE verze 3.5.7.
Všechny ne-ASCII znaky by v URL měly být zaescapované, potom nebudete mít problém nikde.
Jak se znaky zaescapovávají?
Jinak - v těch mých html dokumentech v URL žádné ne-ASCI znaky nemám, takže nemám co zaescapovávat a cesty v URL tam používám zásadně relativní. Ty ne-ASCI znaky mám jenom v nadřazených adresářích (které už nemám ani nemusím mít uvedené v cestách těch URL) a přesto mají někdy blbé účinky, jak jsem popisoval. Bude muset být chyba v moje verzi Konqueroru. Vám všem to v Konqueroru taky dělá v popisovaných případech ty samé problémy, jak mi?
Jak poznám, jestli můj lokální souborový systém je v UTF-8? (ikdyž nejspíš bude) A platí obecně pravidlo, že bych měl do počítače ukládat html dokumenty jenom ve stejné znakové sadě, jak můj lokální souborový systém? Pokud toto pravidlo platí, není to dobré, protože co když budu například chtít své html dokumenty vypálit a půjčit někomu, kdo má v počítači souborový systém v jiné znakové sadě? Potom se mu můžou blbě načítat doplňující soubory k těm mým html souborům a podobně, pokud by v tom počítači byl některý z nadřazených adresářů pojmenovaný názvem obsahujícím ne-ASCI znaky. Hrozí ten problém?
Jak poznám, jestli můj lokální souborový systém je v UTF-8?V linuxu bohužel názvy souborů neobsahují znaky, ale bajty. Takže neexistuje nic jako systémové nastavení kódování názvů souborů – každá aplikace si názvy souborů interpretuje sama. Normálně k tomu ale aplikace používají kódování nastavené v locale. Takže když si z příkazového řádku spustíte příkaz
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
locale a ve výpise budete mít u jednotlivých parametrů „UTF-8“, bude drtivá většina programů používat pro kódování názvů souborů UTF-8.
A platí obecně pravidlo, že bych měl do počítače ukládat html dokumenty jenom ve stejné znakové sadě, jak můj lokální souborový systém?Žádné takové pravidlo neplatí, byl by to nesmysl. To vámi popsané chování je jednoznačně chyba Konqueroru – používá pro ten samý text jinou kódovací tabulku pro dekódování a jinou pro kódování.
Jak se znaky zaescapovávají?Jednoduše podle tabulek UTF-8, resp. jiného kódování, které máte (pro UTF-8 lze vyhledat kódy např. v KCharSelect). Místo každého kódovaného bajtu se uvede %XX, které vyjadřuje hexadecimální hodnotu onoho bajtu. V UTF-8 má např. „ř“ hodnotu dvou bajtů 0xC5 0x99 a zaescapované je „%C5%99“.
Jinak - v těch mých html dokumentech v URL žádné ne-ASCI znaky nemám, takže nemám co zaescapovávat a cesty v URL tam používám zásadně relativní.V tom případě je chyba v prohlížeči. Qt (KDE) a GNOME aplikace mají obecně problémy pracovat s adresáři, jejichž názvy jsou v jiném kódování, než které uvádí locales, protože interně používají UCS-2 a při převodu tak jméno rozbijí.
Vám všem to v Konqueroru taky dělá v popisovaných případech ty samé problémy, jak mi?Ano, mám přes NFS připojený oddíl, kam nahrávají přes FTP lidé z Windows soubory a adresáře v kódové stránce CP-1250, takže můj Konqueror je potom nedokáže otevřít, protože já používám UTF-8.
A platí obecně pravidlo, že bych měl do počítače ukládat html dokumenty jenom ve stejné znakové sadě, jak můj lokální souborový systém?Pokud budete používat ne-ASCII znaky v relativních URL, tak ano, neexistuje způsob, jak je tam zapsat tak, aby správně fungovaly. URL nadřazených adresářů dodá souborový systém, takže o ně se starat nemusíte.
A platí obecně pravidlo, že bych měl do počítače ukládat html dokumenty jenom ve stejné znakové sadě, jak můj lokální souborový systém?
Pokud budete používat ne-ASCII znaky v relativních URL, tak ano, neexistuje způsob, jak je tam zapsat tak, aby správně fungovaly. URL nadřazených adresářů dodá souborový systém, takže o ně se starat nemusíte.
Žádné ne-ASCII znaky v URL nepoužívám, přesto Konqueror načítání těch URL neumí, pokud ten soubor HTML má kódování jiné, než UTF-8, a pokud přitom někde v nadřazeném adresáři někde nad tím HTML dokumentem (a to ikdyž jde o adresář, který v těch URL neuvádím, ani nepotřebuji uvádět, protože URL mám relativní) je nějaký ne-ASCII znak. Proto kvůli chybě v Konqueroru jsem nucený se stareat i o znaky názvů všech nadřazených adresářů, nebo jsem nucený používat to nesmyslné omezující pravidlo, co jsem teď znovu opsal v první větě citace.
Podle příkazů locale aplikace používají znakovou sadu UTF-8.
Tiskni
Sdílej:
