Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Byla vydána (𝕏) nová verze 2025.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Dánské ministerstvo pro digitální záležitosti má v plánu přejít na Linux a LibreOffice [It's FOSS News].
V úterý Google vydal Android 16. Zdrojové kódy jsou k dispozici na AOSP (Android Open Source Project). Chybí (zatím?) ale zdrojové kódy specifické pro telefony Pixel od Googlu. Projekty jako CalyxOS a GrapheneOS řeší, jak tyto telefony nadále podporovat. Nejistá je podpora budoucích Pixelů. Souvisí to s hrozícím rozdělením Googlu (Google, Chrome, Android)?
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.101 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.101 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
V Brně na FIT VUT probíhá třídenní open source komunitní konference DevConf.CZ 2025. Vstup je zdarma, nutná je ale registrace. Na programu je celá řada zajímavých přednášek, lightning talků, meetupů a workshopů. Přednášky lze sledovat i online na YouTube kanálu konference. Aktuální dění lze sledovat na Matrixu, 𝕏 nebo Mastodonu.
Vyloučení technologií, které by mohly představovat bezpečnostní riziko pro stát, má umožnit zákon o kybernetické bezpečnosti, který včera Senát schválil spolu s novelami navazujících právních předpisů. Norma, kterou nyní dostane k podpisu prezident, počítá rovněž s prověřováním dodavatelů technologií pro stát. Normy mají nabýt účinnosti od třetího měsíce po jejich vyhlášení ve Sbírce zákonů.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.6.
Po Red Hat Enterprise Linuxu a AlmaLinuxu byl v nové stabilní verzi 10.0 vydán také Rocky Linux. Přehled novinek v poznámkách k vydání.
Bylo vydáno Eclipse IDE 2025-06 aneb Eclipse 4.36. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Jsem zakladatelem tohoto portálu. Linux jsem používal spousty let, nějaký čas jsem se aktivně podílel na jeho propagaci v Česku (CZLUG, časopisy ComputerWorld, Network Magazine atd). Se současným Abíčkem už nemám nic společného.
(English summary at the end of the article) Uvažoval jsem, že upgradnu jetty, na kterém běží abíčko, z historické verze 4.1.20 na aktuální. Dlouho jsem se k tomu neměl, nejdříve kvůli chybě jsem měl opatchovanou verzi a nebyl jsem si jist, zda můj patch byl začleněn a pak u řady 5 chyběly startovací skripty. A vůbec, kdo by šťoural do něčeho, co funguje, že? Teď jsem se k tomu dostal, ale po odeslání formuláře jetty 6.0.2 byly znaky s diakritikou zničeny.
Chvíli jsem si s tím tedy hrál v debuggeru a skutečně metoda request.getParameter()
vracela deformovaná data, se kterými překódování pomocí new String(param.getBytes("ISO-8859-1"))
už nic nesvedlo. Zeptal jsem se v konferenci a dostal jsem pár tipů, například request.setEncoding("ISO-8859-2")
nebo System.setProperty("org.mortbay.util.URI.charset","ISO-8859-2")
. Nicméně tyto rady neměly žádný efekt.
Nakonec jsem si napsal testovací webovou aplikaci se servletem, který se dá konfigurovat, jaké kódování má requestu nastavit a dva jsp soubory s dvěma formuláři, které odesílají vstup (žížala) jednou přes POST podruhé přes GET. Jedno jsp bylo v ISO-8859-2 kódování, druhé v UTF-8. A jal jsem se testovat všechny možné kombinace, v jetty řady 4.1 i 6.0 a 6.1. Přitom jsem snifferem zjistil, že Firefox odesílá vstup jinak v závislosti na kódování HTML souboru (jak překvapivé, Watsone). Závěr je, že jetty 4 se chová jinak než jetty 6 a že pod jetty 6 spolehlivě fungují formuláře, pokud jsou ve stránce kódované pomocí UTF8, zato v ISO-8859-2 nefungují spolehlivě nikdy. Detaily najdete v příloze.
When I upgraded jetty from version 4.1.20 to 6.0.2 I found that it damages request parameters. The characters with caron from ISO-8859-2 encoding where replaced by ? character or disappeared at all. The trick with recoding new String(param.getBytes("ISO-8859-1"))
using did not work. I asked in jetty conference and tested few tips without luck: request.setEncoding("ISO-8859-2")
, System.setProperty("org.mortbay.util.URI.charset","ISO-8859-2")
. So I decided to test this topic thouroughly and wrote simple webapp consisting of two same jsp files and servlet dumping the request parameter. The jsp files contained two identical forms sending word 'žížala' either by GET or POST method to the servlet. One jsp file was encoded in UTF-8, the second in ISO-8859-2 encoding. I tested all combinations with both jetty versions and found difference between them. Jetty 6 can reliably accept accented characters if and only if the form was sent from HTML page encoded to UTF-8. When the page was encoded to ISO-8859-2 (latin2), then it is not possible to find setting suitable for both GET and POST methods. Test web application including complete results.
Tiskni
Sdílej:
QueryEncoding
(je to rozčíření Jetty), RequestCharacterEncoding
se u GETu vůbec nebere v úvahu. S následujícíém nastavením mi funguje testLatin2:
import org.mortbay.jetty.Request; ... protected void service(HttpServletRequest request, HttpServletResponse response) throws IOException { if (requestEncoding != null) request.setCharacterEncoding(requestEncoding); (Request)request).setQueryEncoding("iso-8859-2"); String tmp = request.getParameter("note"); String tmp1 = new String(tmp.getBytes("ISO-8859-1")); // this is correct for request locale cs String tmp2 = new String(tmp.getBytes("ISO-8859-2")); String tmp3 = new String(tmp.getBytes("UTF-8")); response.setContentType("text/html; charset=ISO-8859-2"); Writer w = response.getWriter(); ...
decodeQueryTo
třídy org.mortbay.jetty.HttpURI
, musí tam být
public void decodeQueryTo(MultiMap parameters, String encoding) throws UnsupportedEncodingException { if (_query==_fragment) return; if (encoding==null) encoding=URIUtil.__CHARSET; if (StringUtil.isUTF8(encoding)) UrlEncoded.decodeUtf8To(_raw,_query+1,_fragment-_query-1,parameters); else UrlEncoded.decodeTo(StringUtil.toString(_raw,_query+1,_fragment-_query-1,encoding),parameters,encoding); }