Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: A. F. 04. 07. 2018, 19:27:19
-
Zdravím.
Předpokládejme, že mám systém, který texty načítá z nějakého souboru. Aspiruju na mezinárodní trh.
Otázka: mohu prohlásit, že obsah toho textového souboru musí být v utf8? Pokryje to všechny normální jazyky a písma na světě (tedy třeba minojština mě až tak netrápí). Nebo naopak mohu narazit třeba u Japonštiny? Čínštiny? Kde jsou hranice?
Děkuji za odpověď.
-
pro zacatek narazis u japonskych/cinskych pisem
-
Kde jsou hranice?
UTF-8 se snaží napasovat Unicode nad ASCII kódování, pro uložení textového souboru. UTF-8 se pak načte do paměti, kde se reprezentuje 4bytově little nebo big engian podle platformy. Je třeba také uvažovat o směru textu zleva doprava i obráceně.
Hranice může nastat při použítí textově orientovaných utilitek, kde se s UTF nepočítá a s knihovnami třetích stran pro zpracovaní nějakých datových struktur, kde může docházet k nějakým neplechám, kvůli potencionálně neplatným sekvencím bytů...
-
pro zacatek narazis u japonskych/cinskych pisem
Můžeš být konkrétnější?
Pro japonská a čínská písma nelze použít vůbec, nebo "jen" většinou ano, ale v některých okrajových případech ne?
Co se používá místo toho?
-
Kde jsou hranice?
UTF-8 se snaží napasovat Unicode nad ASCII kódování, pro uložení textového souboru. UTF-8 se pak načte do paměti, kde se reprezentuje 4bytově little nebo big engian podle platformy. Je třeba také uvažovat o směru textu zleva doprava i obráceně.
Hranice může nastat při použítí textově orientovaných utilitek, kde se s UTF nepočítá a s knihovnami třetích stran pro zpracovaní nějakých datových struktur, kde může docházet k nějakým neplechám, kvůli potencionálně neplatným sekvencím bytů...
Zajímá mě pouze to získávání textu. Tedy řeknu uživateli: "sem piš co chceš, ale musí to být v utf8". Já si to následně zpracuju. Přičemž už je na mě, abych měl třeba kompletně unicode fonty atd.
-
Unicode pokryje všechny normální jazyky a písma na světě – přesněji na Zemi :-) UTF-8 je jeden ze způsobů serializace Unicode. Tedy to, co potřebujete, pokryjete vstupem v UTF-8. Např. JSON je podle standardu vždy UTF-8, takže nebudete první, kdo toto kódování určí jako jedinou možnost. I zmíněné japonské nebo čínské znaky jsou pokryté Unicode, např. japonská Wikipedia používá Unicode. Akorát není v těchto zemích UTF-8 tak populární, jako v Evropě a Americe, protože japonské nebo čínské znaky kóduje neefektivně, oproti jiným kódováním. UTF-8 tedy můžete použít.
-
Utf-8 muzete s klidem pouzit a zakodujete libovolny znak. Ma akorat promenlivou delku, casto pouzivane znaky latinky azbuky a alfabety jsou 1-2 bajtove, ostatni znaky maji bajtu vice. Je to jen zpusob kodovani cele Unicode mnoziny. Co vam chteli povedet je ze jedna vec je znak zakodovat a druha vec je ho zobrazit - cili potrebujete font co je obsahuje. A treti vec je ze pozor na knihovny ci utilitky na zpracovani textu - ne vsechny umeji vicebajtovye znaky - hlavne bacha na regex.
-
pro zacatek narazis u japonskych/cinskych pisem
Můžeš být konkrétnější?
Pro japonská a čínská písma nelze použít vůbec, nebo "jen" většinou ano, ale v některých okrajových případech ne?
Co se používá místo toho?
To mě taky zajímá. UTF8 má rozsah 32 bitů a měly by tam být všechny Unicode znaky. Narazit lze leda v Javě, kde UTF8 má limit 16 bitů. To je ale vada Javy, ne UTF.
-
UTF-16 a UTF-32 nicméně všechno na co jsem narazil se vešlo do UTF-8
GB 18030 je snad čínský unicode, ale nikdy jsem to neviděl
Mám podobné řešení, pokud nevím co to je, předpokládám, že UTF-8... pravděpodobnost shody je velmi vysoká.
Je jasné, že počet bajtů je variabilní a mnoho různých nástrojů může narazit o řazení ani nemluvím.
pro zacatek narazis u japonskych/cinskych pisem
Můžeš být konkrétnější?
Pro japonská a čínská písma nelze použít vůbec, nebo "jen" většinou ano, ale v některých okrajových případech ne?
Co se používá místo toho?
To mě taky zajímá. UTF8 má rozsah 32 bitů a měly by tam být všechny Unicode znaky. Narazit lze leda v Javě, kde UTF8 má limit 16 bitů. To je ale vada Javy, ne UTF.
-
UTF8 má rozsah 32 bitů a měly by tam být všechny Unicode znaky. Narazit lze leda v Javě, kde UTF8 má limit 16 bitů. To je ale vada Javy, ne UTF.
Máte to trochu pomíchané. Unicode je 21 bitový. Pokud použiteje k zapsání unikodu UTF-8, pak jeden unicode znak je kódován pomocí jednoho až čtyř bajtů (což plně pokryje těch 21 bitů). Pokud použijete UTF-16, pak jeden unicode znak je kódován pomocí jednoho až dvou 16 bitových hodnot (což opět pokryje plně těch 21 bitů). Java používá UTF-16 a není to vada :-)
-
Akorát bych podotkl, že podpora vícejazyčnosti je širší téma než jen uložení/načtení textu. Ligatury, směr toku textu, spellchecker, řazení a porovnávání textu, různé formáty čísel, měn a datumu, odlišná časová pásma, fulltextové vyhledávání, tisk, různé jednotky (váhy, míry), různá legislativa, atd.
-
V některých jazycích je UTF-8 neefektivní co se délky týče (narozdíl od češtiny například).
A když jsme u toho to české vyhledávání je strašný paskvil i když je to dle pravidel. Každý kdo si toho není vědom je naprosto zmaten. Obzvlášť v mobilech to každý hlásí jako "ten krám vůbec nefunguje - je to rozbitý".
Akorát bych podotkl, že podpora vícejazyčnosti je širší téma než jen uložení/načtení textu. Ligatury, směr toku textu, spellchecker, řazení a porovnávání textu, různé formáty čísel, měn a datumu, odlišná časová pásma, fulltextové vyhledávání, tisk, různé jednotky (váhy, míry), různá legislativa, atd.
-
Ligatury?
-
V některých jazycích je UTF-8 neefektivní co se délky týče (narozdíl od češtiny například).
Z hlediska velikosti souboru, pro jazyky používající latinku je vhodnější UTF-8 a pro nelatinské jazyky UTF-16.
-
Utf-8 muzete s klidem pouzit a zakodujete libovolny znak.
OK, díky.
Ma akorat promenlivou delku, casto pouzivane znaky latinky azbuky a alfabety jsou 1-2 bajtove, ostatni znaky maji bajtu vice. Je to jen zpusob kodovani cele Unicode mnoziny. Co vam chteli povedet je ze jedna vec je znak zakodovat a druha vec je ho zobrazit - cili potrebujete font co je obsahuje. A treti vec je ze pozor na knihovny ci utilitky na zpracovani textu - ne vsechny umeji vicebajtovye znaky - hlavne bacha na regex.
Dobře, dobře, ale už je to mimo téma mé otázky :-)
-
Akorát bych podotkl, že podpora vícejazyčnosti je širší téma než jen uložení/načtení textu. Ligatury, směr toku textu, spellchecker, řazení a porovnávání textu, různé formáty čísel, měn a datumu, odlišná časová pásma, fulltextové vyhledávání, tisk, různé jednotky (váhy, míry), různá legislativa, atd.
Jsem si toho vědom. Mě ale zajímá pouzet text. Tudíž z toho co jste vyjmenoval pouze ligatury. Na wiki píšou, že ligatury se dávají do "Doplňková oblast pro soukromé použití". Víte jak to funguje?
Arabské slitky ( l + `aliv: لا, k + `aliv, k + l, k + l + `aliv, l + m) jsou umístěné kde, netušíte? Dévanágarí jich má mít také mnoho. Vzhledem k tomu, že slitky nejsou povinné, v arabštině l + `aliv povinné je, ostatní již ne; fi, ti v češtině záleží na druhu slova - tak si nedovedu představit, že by se to dělalo automaticky.
-
Původní specifikace UTF-8 měla na znak 1-6 bajtů. Jak to je u knihoven jestli počítají s tímto nebo už jen s novější specifikací, omezenou na 4 bajty nevím - jen pro upřesnění.
-
pro zacatek narazis u japonskych/cinskych pisem
Můžeš být konkrétnější?
Pro japonská a čínská písma nelze použít vůbec, nebo "jen" většinou ano, ale v některých okrajových případech ne?
Co se používá místo toho?
lze je pouzit, ale _nelze_ korektne pokryt vsechny znaky: cinske znaky se totiz zavedly v koreji a japonsku, v cine probehla reforma zjednoduseni pisma... atd atd, nakonec existuji ruzne sady znaku a ruzne lokalni variace, ktere unicode/utf nepokryva nebo pokryva chybne. pouziva se misto toho ucs
-
Akorát bych podotkl, že podpora vícejazyčnosti je širší téma než jen uložení/načtení textu. Ligatury, směr toku textu, spellchecker, řazení a porovnávání textu, různé formáty čísel, měn a datumu, odlišná časová pásma, fulltextové vyhledávání, tisk, různé jednotky (váhy, míry), různá legislativa, atd.
Jsem si toho vědom. Mě ale zajímá pouzet text. Tudíž z toho co jste vyjmenoval pouze ligatury. Na wiki píšou, že ligatury se dávají do "Doplňková oblast pro soukromé použití". Víte jak to funguje?
Arabské slitky ( l + `aliv: لا, k + `aliv, k + l, k + l + `aliv, l + m) jsou umístěné kde, netušíte? Dévanágarí jich má mít také mnoho. Vzhledem k tomu, že slitky nejsou povinné, v arabštině l + `aliv povinné je, ostatní již ne; fi, ti v češtině záleží na druhu slova - tak si nedovedu představit, že by se to dělalo automaticky.
Jak to funguje nevím. OpenType zná automatické kontextové použití ligatur, podrobnosti však neznám.
-
Krátká odpověď: ANO
Dlouhá odpověď: můžeš narazit na problémy u málo používaných dialektů asijských jazyků. Viz https://www.unicode.org/faq/han_cjk.html#6
-
Jakmile to má na začátku 'u', tak je to v cajku. ;D
Pak to je to nejspíš Unicode a Unicode je jen jeden. Co v něm není, není.
A Číňani jsou připraveni na to, že tam může něco chybět. Mají to tak rádi. Rozhodně se to nemůže stát u normální čínštiny.
Různé UTF jsou jen otázka přesypání dat. Nic se nemůže ztratit. To číslo v podstatě znamená po kolika bajtech se má konzumovat vstup, aby se na náhodou nepřešlo ukončení textu.
UTF8 je pro nás super, protože vypadá jako ASCII. Pokud by v tom měl být delší 'asijský text', tak to asi bude zbytečně prodlužovat.
Jenže, těch pár bajtů nikoho to nezajímá :) :) :) Nebo zajímá?
http://utf8everywhere.org/ (http://utf8everywhere.org/)
Doporučuji hlavně bod 3.
-
Původní specifikace UTF-8 měla na znak 1-6 bajtů. Jak to je u knihoven jestli počítají s tímto nebo už jen s novější specifikací, omezenou na 4 bajty nevím - jen pro upřesnění.
Myslel jsem codepoint 32bitů. Tzn. jen čistý obsah bez "úvodních" bitů. Serializované ve streamu to může mít těch 6 bajtů.
-
Krátká odpověď: ANO
Dlouhá odpověď: můžeš narazit na problémy u málo používaných dialektů asijských jazyků. Viz https://www.unicode.org/faq/han_cjk.html#6
To už není problém Utf8, ale Unicode obecně.
-
Takže pro shrnutí - UTF-8 dokáže kompletně zakódovat celé Unicode. Unicode samo o sobě dokáže reprezentovat všechny znaky snad až možná na nějaké poloprivátní obskurnosti které tě nemusí zajímat.
Dříve (v době kdy Unicode bylo nadefinováno jako až 2 miliardy (nebo 4?) znaků - tj. 4 byty) tak mělo mít UTF-8 1-6 znaků, ale moderní UTF-8 má již jen 1-4 (pro 21 bitové Unicode). To dává cca 1 milion znaků v 17 Unicode planech. První je standardní a obsahuje i hodně znaků z Čínštiny, Japonštiny a Korejštiny, ale ne všechny (tedy v prvních 64k znacích nejsou všechny asijské znaky), druhý nebo třetí jsou věnovány asijským znakům. Pak tam jsou někde i emoji.
Na Windows se používá často UTF-16, které vypadá že je fixní 2 bytové délky, ale pro reprezentaci znaků dál než 64k, používá tzv. surrogate pairs (coz znamená že některé znaky jsou ilegální bez svého párového doplňku).
Pro tvoji potřebu je jednoznačně správně použít UTF-8, a neřešit ani věci jako že možná některým asijským jazykům to zabere trochu více bytů, jak ukazuje ten odkaz na utf8everywhere tak to stejně většinou není problém (třeba pokud je to HTML tak je tam kupa kratších znaků které to vybalancují).
Jen bych doporučil použít odladěné knihovní funkce pro práci s tím a případně převod do Unicodové reprezentace v paměti (pokud to rovnou není v programovacím jazyků který stringy v paměti ukládá jako UTF-8). Existuje i sada unit testů na parser, možná by stálo za to na ně mrknout a kouknout jaké edge případy se tam řeší (např. jak se zachovat k ilegálním znakům a sekvencím bytů).
-
nakonec existuji ruzne sady znaku a ruzne lokalni variace, ktere unicode/utf nepokryva nebo pokryva chybne. pouziva se misto toho ucs
Nesmysl, UCS má stejné znaky a k nim přiřazené stejné kódy, jako Unicode. Praktický rozdíl je hlavně v tom, že UCS kódování mají pevnou délku znaku – UCS-2 má dva bajty a UCS-4 čtyři bajty. UCS-2 tedy umí vyjádřit pouze základní (původní) Unicode sadu, čímž se liší od UTF-16, které základní Unicode sadu vyjadřuje také pomocí dvou bajtů, ale pomocí náhradních párů umožňuje zapsat i znaky mimo BMP.
-
Nejlepší bude, pokud vstupní sadu vůbec nespecifikuješ. Někdo tam chce vrazit ASCII, většina asi UTF-8, jiní UTF-16 nebo UCS-2. Když uděláš interní sadu aplikace Unicode, do které se všechna kódování na vstupu automaticky konvertují, bude to ideální.