Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Český telekomunikační úřad vydal zprávy o vývoji cen a trhu elektronických komunikací se zaměřením na rok 2024. Jaká jsou hlavní zjištění? V roce 2024 bylo v ČR v rámci služeb přístupu k internetu v pevném místě přeneseno v průměru téměř 366 GB dat na jednu aktivní přípojku měsíčně – celkově jich tak uživateli bylo přeneseno přes 18 EB (Exabyte). Nejvyužívanějším způsobem přístupu k internetu v pevném místě zůstal v roce 2024 bezdrátový
… více »Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-10-01. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Jedná o první verzi postavenou na Debianu 13 Trixie.
Byla vydána nová verze 4.6 svobodného notačního programu MuseScore Studio (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Společnost DuckDuckGo stojící za stejnojmenným vyhledávačem věnovala 1,1 milionu dolarů (stejně jako loni) na podporu digitálních práv, online soukromí a lepšího internetového ekosystému. Rozdělila je mezi 29 organizací a projektů. Za 15 let rozdala 8 050 000 dolarů.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.17. Díky 278 přispěvatelům.
Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.
Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.
… více »Radicle byl vydán ve verzi 1.5.0 s kódovým jménem Hibiscus. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
Společnost OpenAI představila text-to-video AI model Sora 2 pro generování realistických videí z textového popisu. Přesnější, realističtější a lépe ovladatelný než předchozí modely. Nabízí také synchronizované dialogy a zvukové efekty.
Zatímco nastavení správného kódování souborů odesílaných webovým serverem do prohlížeče je už celkem zvládnutá věc, příjem textů z formulářů na webovém serveru může záludnostmi souvisejícími s kódováním ještě potrápit. Protože jsem při hledání jedné chyby na Abíčku zabrousil do hlubin zdrojových kódu Servlet API a servlet kontejneru Jetty, a nechci to za půl roku zkoumat znovu, popíšu (si) závěry výzkumu sem.
Ani s vynálezem Unicode není problémům s různými kódováními znaků konec. Většinou už se s nimi nesetkávají běžní uživatelé, ale programátoři si jich stále ještě užijí dost a dost. Jedním z klasických problémů je komunikace přes HTTP.
Každý slušný webový server, pokud posílá nějaký text, přidá do HTTP hlaviček informaci o jaký typ dat se jedná (např. HTML, čistý text) a také v jakém jsou kódování:
HTTP/1.x 200 OK Date: Wed, 17 May 2006 18:24:59 GMT Server: Jetty/4.2.17 Content-Type: text/html; charset=UTF-8
Při odesílání dat z webového formuláře na server je ale situace horší. application/x-www-form-urlencoded
nebo multipart/form-data
, o použitém kódování ani čárka. Nějak mezi prohlížeči není zvykem tam informaci o kódování přidávat. Ona by nejspíš také spoustu serverů zmátla, a zbytek by s ní neuměl pracovat. A servery se tuto informaci zase nepokoušejí číst, protože ji prohlížeče neposílají. Začarovaný kruh.
Naštěstí je mezi prohlížeči dobrým zvykem odesílat data zpět v kódování, v jakém ho přijala (resp. v kódování, které má na dané stránce uživatel zrovna nastavené, takže změní-li si uživatel z nějakého důvodu kódování stránky, pošlou se data v jiném kódování, než čekáte). Vynechám teď speciální případy, kdy mám v jednom projektu stránky v různých kódováních, nebo kdy bych chtěl odesílat data do formuláře, který nemám pod kontrolou (na cizí web) a musel bych se kódováním své stránky trefit do kódování cílového webu. I v jednoduchém případě, že odesílám formulář na svůj vlatní web, který má konzistení kódování znaků, pořád je tu problém: já jako autor aplikace vím, v jakém kódování mám stránky, a tedy v jakém kódování očekávat odpověď. Ale ta aplikace to neví.
Konkrétně ve specifikaci Servlet API k tomu, aby se to aplikace dozvěděla, slouží metoda ServletRequest.setCharacterEncoding(String)
, doplněná do API od verze 2.3. Tím sdělíte Servlet API, v jakém kódování bude odpověď. (Jak jsem popsal výše, Servlet API nemá žádný způsob, jak kódování zjistit z HTTP požadavku. Spoléhá tedy na programátora, že dopředu ví, jaké to kódování bude. Ještě stále dokážou programátoři z pohledu počítačů magické věci – zde třeba věštit budoucnost.) Dobrým zvykem tedy je na začátku servletu (ještě před jakýmkoliv čtením z HTTP požadavku) zavolat tuto metodu se správným kódováním – a o zbytek už se není potřeba starat, Servlet API se postará o správné rozkódování parametrů dotazu a programátor v dalším kódu už jen může vrnět blahem nad tím, jak Java pěkně pracuje s řetězci, že String je prostě řetězec Unicode znaků a o nějaké kódování se nemusím starat, dockud nechci řetězec poslat zase někam ven.
Pokud tuhle metodu programátor na začátku nezavolá, předpokládá servlet kontejner nějaké defaultní kódování – např. Jetty ve verzi 4.2.x předpokládalo kódování iso-8859-1, verze 5 a výš předpokládají UTF-8. Poměrně častý způsob zacházení s kódováním požadavku (a před přidáním metody ServletRequest.setCharacterEncoding(String)
jediný možný) tedy bylo:
Až dosud by to byla docela známá věc, a nebylo by potřeba nic zkoumat. Kdyby mi při testování nevracelo Servlet API tvrdošíjně řetězce překódované podle iso-8859-1 nezávisle na tom, jaké kódování jsem nastavil. (V situaci, kdy Jetty je spuštěné pod Windows a tedy kódovou stránkou windows-1250, konzole ve Windows zobrazuje v CP852, HTML stránky a tedy parametry jsou v iso-8859-2 a Servlet API si o tom myslí, že je to iso-8859-1, taky chvíli trvalo, než jsem zjistil, kde se to vlastně špatně překóduje…)
Kamenem úrazu se zde stalo ono před jakýmkoli čtením požadavku. Debugování naustále ukazovalo, že parametry požadavku už někdo četl… Pochvíli byl jasný i pachatel: Filtr jakarta_compression
(nejspíš součást Tomcatu), který komprimuje odpovědi gzipem, aby se po síti přenášelo míň dat. Tento filtřík s 60 řádky copyrightu a 200 řádky kódu se zcela nevinně dotazoval na parametr gzip. Sloužil mu k tomu, aby v případě, že je nastaven na false, data nekomprimoval. Taková drobná fíčurka usnadňující ladění… Tím pádem už někdo četl parametry, tedy četl požadavek, a tedy jakékoli snahy o změnu kódování vyšly naprázdno.
Jak z toho ven? Napadají mne dvě možnosti: za prvé – pokaždé, když Servlet API získá informaci o změně kódování, zahodit nakešované parametry a načíst je znovu, tentokrát ve správném kódování (fuj). Taky by to zřejmě znamenalo pamatovat si celý požadavek po celou dobu zpracováníní… Druhá možnost: všem filtrům a veškerému zpracování požadavku předřadit ještě jeden filtr, který nastaví předpokládané kódování (dvakrát fuj). Všechny filtry mezi tím prvním nastavovacím a mým servletem budou už pracovat s nějakým kódováním, a nebudou o tom vědět. Navíc nastavení kódování parametrů, které potřebuji v Servletu, musím udělat úplně někde jinde, v nesouvisející části, a ještě nesmím zapomenout to všude přidat. Asi jako kdyby se už u zápisu do 1. třídy ptali, z jakých předmětů chci maturovat…
Bohužel, nezbyde než použít metodu dvakrát fuj, protože jak mě upozornil Greg Wilkins, autor Jetty, specifikace k metodě ServletRequest.setCharacterEncoding(String)
říká:
Overrides the name of the character encoding used in the body of this request. This method must be called prior to reading request parameters or reading input using getReader(). Otherwise, it has no effect.Tedy volně řečeno: dokud požadavek nikdo nečetl, lze měnit kódování libovolně, jakmile se někdo byť jen na písmenko podíval, je se změnami kódování utrum.
A závěr? Příště už si nebudu myslet, že volání setCharacterEncoding
na prvním řádku servletu je dostatečně brzo. Bez Filter
u nastavujícího správné kódování už v Servlet webaplikacích ani ránu. Aneb
public class EncodingFilter implements Filter{ public void init(FilterConfig filterConfig) { this.encoding = filterConfig.getInitParameter("encoding"); } public void doFilter ( ServletRequest request, ServletResponse response, FilterChain chain ) throws IOException, ServletException { request.setCharacterEncoding(this.encoding); chain.doFilter(request, response); } }do každé rodiny. A příležitostně pošťouchnout Mozillí Bugzillu, jestli by třeba nechtěl Firefox s formulářovými daty posílat i jejich kódování, pozeptat se ve fóru Servlet API, Apache a dalších, jestli by z takových údajů nechtěli informace o kódování získávat, a tak. A nebo doplnit křišťálovou kouli jako standardní výbavu webserverů…
PS: A mimochodem – ta chyba na Abíčku nakonec byla úplně v něčem jiném. Věřili byste, že je možné přes chránku vložit do textového pole formuláře ve Firefoxu znaky jako Escape (kód 27)? A zřejmě občas někdo považoval za dobrý nápad takovéhle znaky vložit třeba do diskuze… Ale exkurze po zdrojácích Jetty z toho byla rozhodně zajímavá, vyzkoušet si vzdálené ladění Jetty s pomocí eclipse se také hodilo, a zase jsem o něco chytřejší…
Tiskni
Sdílej: