Biblioteka SDFat - polskie znaki w nazwach plików

[Zealota]

7 minut temu, ethanak napisał:

dlaczego chcesz mieszać wchar_t z UTF-8?

Bo mogę? Bo nie umiem wymyślić nic bardziej zgrabnego? A to jest zgrabne, tak uważam. Nie jestem programistą, żeby z rękawa znajdować dobre rozwiązania do problemu. Przejrzę jeszcze raz wątek skoro autor ma coś do zaproponowania.

Dodatkowo dlaczego mam coś kompilować pod Amigę 🙂 Rozumiem też przewrotny przykład poprzez skrajny, w kontekście moich problemów, przewartościowany przykład, który prawdopodobnie zwraca uwagę na problem przenośności kodu z powodu endianess. Znam ten problem oraz to pojęcie. Programując czysto amatorsko do tej pory nie musiałem nad tym się pochylać. Linux, Windows, STM32 i AVR to wszystko operuje na little endian, zatem póki co mam to w pamięci i się nie przejmuję.

[ethanak]

1 godzinę temu, Zealota napisał:

Bo nie umiem wymyślić nic bardziej zgrabnego

A po co tu coś wymyślać? Algorytm konwersji utf-8 na ucs-2 i w drugą stronę jest ogólnie znany, dobrze opisany i można go znaleźć choćby w Wikipedii. Tymczasem wymyśliłeś własny sposób przechowywania w wchar_t nie kodów znaków (do czego ten typ służy) tylko jakichś sekwencji...

1 godzinę temu, Zealota napisał:

Dodatkowo dlaczego mam coś kompilować pod Amigę

Bo można? Bo na Amidze też można odpalić Linuksa? I Twoja aplikacja będzie należała do tych nielicznych, które nie będą działać bo programista tak sobie wymyślił że nie? Dałem przykład Amigi bo M68k to pierwszy przykład procka z BE który mi przyszedł do głowy...

Poza tym akurat do wyszukiwania Twoja metoda niespecjalnie się nadaje - o ile na ośmiobitowych AVR-ach to się jeszcze sprawdzi, ale aby wyszukać znak w UTF-8 musisz zrobić porównanie typu *(uint16_t *)str == X, a to nie zawsze wychodzi na zdrowie, szczególnie jeśli adres w str jest nieparzysty...

2 godziny temu, Zealota napisał:

A to jest zgrabne, tak uważam

Pominę to znaczącym milczeniem... 🙂

2 godziny temu, Zealota napisał:

Programując czysto amatorsko do tej pory nie musiałem nad tym się pochylać

Też tak kiedyś myślałem... dopóki ktoś nie postanowił odpalić mojego wielce genialnego (tak wtedy uważałem) programu na jakimś Crayu.

[Zealota]

31 minut temu, ethanak napisał:

 

Gdy przyjdzie znowu taka potrzeba to wrócę do tematu.

Z ciekawości zarzuciłem temat "na internety" i znalazłem takie coś:

https://kmim.wm.pwr.edu.pl/myszka/wp-content/uploads/sites/2/2015/03/w11.pdf

Jest tam m.in. taki tekst:

"powinniśmy korzystać z typu wchar_t (ang. „wide character”), jednak jeśli chcemy udostępniać kod źródłowy programu do kompilacji na innych platformach, powinniśmy ustawić odpowiednie parametry dla kompilatorów, by rozmiar był identyczny niezależnie od platformy."

W sekcji "Polskie literki" robią dokładnie to samo co "sam wymyśliłem" 🙂 także jest coś na rzeczy...

[ethanak]

9 godzin temu, Zealota napisał:

W sekcji "Polskie literki" robią dokładnie to samo co "sam wymyśliłem"

Jesteś tego pewien?

U Ciebie znak 'ą' ma kod 0xC485,  a prawidłowy (czyli L'ą') jest 0x0105. Widzisz różnicę?

Tak z ciekawości - jaki kod według Twojego systemu będzie miał używany w Polsce znak '—' (dywiz aka długi myślnik)?

Edytowano Czerwiec 15, 2020 przez ethanak

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Zealota]

Do Linuksa mam inna tablicę polskich literek, cóż poradzić, że w Windows zawsze na opak.

Co do myślnika, gdy będę go potrzebował to znajdę odpowiedni kod.

 

[ethanak]

5 minut temu, Zealota napisał:

Do Linuksa mam inna tablicę polskich literek, cóż poradzić, że w Windows zawsze na opak.

 

Czyżby UTF-8 w Linuksie był inny niż w Windows?

W żadnym kodowaniu znak 'ą' to nie jest 0xC485, nieważne czy to Windows, czy Linuks.

Co do myślnika owszem, znajdziesz kod, w Twoim wykonaniu byłoby to pewnie 0xE28094, bardzo ładnie się zmieści w 16 bitach...

Wybacz, ale to co tu przedstawiasz to prawdopodobnie wynik niezrozumienia tego, jak to wszystko działa, rozumiem że się upierasz przy swoim wielce genialnym pomyśle - ale nie podsuwaj ludziom ewidentnie błędnego rozwiązania twierdzącw dodatku,  że jest (cytując) "zgrabne".

Podałeś link z którego podobno korzystałeś... może przeczytasz to, co jerst pod tym linkiem w całości, przyda Ci się na przyszłość.

[Zealota]

Proponuję zresetować, tę część wątku, bez moich domysłów tylko po uzupełnieniu wstępnym wiedzy, wygrzebałem co mam, bo wszystko wskazuje na to, że zapomniałem o co "kaman".

Zanim przejdę dalej to wymaga wyjaśnienia link, który podałem - nigdzie nie pisałem, że z tego korzystałem. Ten link to był dla mnie dowód pośredni na to, żeby "działać" z kodowaniem UTF8 (i nie tylko) to należy (można, trzeba - do wyboru) korzystać z typu "wchar_t" - jeśli się umie, ja być może nie umiem pomimo pewnych pozytywnych wyników - choćby możliwość dekodowania poprawnie polskich znaków w moich projektach, ale mniejsza na razie z tym. 

Tamte kody po prostu pomieszałem 😳, a główny problem polegał z pomieszania pojęć  "UNICODE" i "UTF8" 🙂 mea culpa, biję się w pierś... Mam w starym projekcie zdefiniowane dwie tablice jedna oznaczona jako Unicode, a druga jako UTF-8 (również też inne "latiny" czy "cp"). Wartości polskich znaków odpowiadają tym choćby tutaj:

https://pl.wikipedia.org/wiki/Kodowanie_polskich_znaków

Oprócz tego wiele wyjaśnia ten link:

https://www.utf8-chartable.de/

Ta tablica dokładnie odzwierciedla, tak myślę, zależność kodów w Unicode oraz UTF-8. 

To pewnie ta różnica, o której pisałeś czyli znaki Unicode i UTF-8 być może wymagają konwersji, a być może wystarczy obie wersje stablicować i używać w odpowiednim kontekście. Mój ten skrytykowany, niby "elegancki" sposób to właśnie skorzystanie z takich tablic. Przecież "stablicować" czy liczyć w locie to odwieczny dylemat czy poświęcić trochę miejsca w pamięci stałej czy może lepiej liczyć w locie - bez kontekstu zwykle nie można tego rozsądzić, zgadza się?

Jak pojmuję Twój tok rozumowania ten cały wchar to na grzyba, bo można sobie coś w locie konwertować i używać innych typów, bo wchar nie jest przenośny i  na amidze będę miał problem (lub gdzie indziej). Jak pisałem delikatnie obecnie mam w nosie amigę 🙂 , jednak przyjmuję ten pogląd na przyszłość o przenośności kodu, bo w sumie w moich założeniach jest, żeby te "polskie znaczki" rozpatrywać w szerszym aspekcie - być może moje projekty, a to trzeba wyjaśnić, mają działać głównie na STM32 i w przyszłości komunikować się z softem na Linuksie - a w ostateczności pod Windows. W środowisku, którym piszę opartym na gcc wchar_t jest 4-bajtowy - można to zmienić za pomocą opcji kompilatora do 2 bajtów, ale to tylko tak informacyjnie. W Windows jest 2 bajtowy tak pisałeś i faktycznie można to znaleźć choćby tu:

https://docs.microsoft.com/pl-pl/cpp/cpp/char-wchar-t-char16-t-char32-t?view=vs-2019

W CubeIDE_1.3.0 (chyba kompilator to załatwia) konwersja następuje prawdopodobnie w "locie", bo pomimo wybrania strony kodowej UTF-8, w pamięci lądują znaki z tablicy UNICODE ('ą' = 261). Ten mechanizm jest mi obcy, nie znam standardu, który to opisuje, więc to oczywiście domniemania, może źle patrzę...

Co do Twojego "dywiz" na cóż mi on, w kontekście moich wymagań "co do projektów". Rozumiem, że "wywiz" to taki przykład podobny to tej amigi - czyli przerysowanie celem nakreślenia problemu.

Nie zamierzam sięgać dalej niż 2 bajty, a w Unicode to nawet nie jest dalej niż 1 bajt? Czy zakres zmiennej 2-bajtowy w Windows nie wystarczy, żeby te kilka polskich znaków dobrze obsłużyć w Linuksie i Windows? Czy opcje kompilatora gcc, które pozwalają sterować wielkością wchar_t, nie wystarczą to kilkusystemowej przenośności kodu? Ostatecznie czemu ten "wchar_t" to zły pomysł, bo niestety nie łapię tej negacji? Czy wchar to nie jest "następca" char, który wymyślono, żeby znaki kilkubajtowe "trzymać" w czymś? A może po prostu sam nie korzystasz z wchar_t tylko z przyzwyczajenia "liczysz wszystko w locie, tak od lat"?

Dobrze byłoby chyba te moje wypociny przenieść do nowe wątku...

 

[ethanak]

6 godzin temu, Zealota napisał:

Jak pojmuję Twój tok rozumowania ten cały wchar to na grzyba

Nigdzie czego takiego nie napisałem. Próbowałem wyjaśnić Ci, że wchar_t służy jak sama nazwa wskazuje do przechowywania szerokich znaków (wide characters), a nie hgw czego.

6 godzin temu, Zealota napisał:

Ostatecznie czemu ten "wchar_t" to zły pomysł,

Nie przeinaczaj moich słów. Patrz wyżej.

 

6 godzin temu, Zealota napisał:

obecnie mam w nosie amigę

Odpinkol się od tej Amigi albo zrób sobie s/Amiga/m68k/ - doskonale wiesz o co mi chodziło, a to że masz w nosie procesory BE to Twój problem - mogą Ci nos zapchać i dostaniesz kataru.

6 godzin temu, Zealota napisał:

Co do Twojego "dywiz" na cóż mi on, w kontekście moich wymagań "co do projektów"

Nigdy się z nim nie spotkałeś? Spróbuj kiedyś wziąć do ręki książkę (możę być ebook), ale nie taką mądrą o informatýce tylko taką głupią co w niej różne postaci występują, jak dojdziesz do miejsca w którym ludzie gadają ze sobą to zobaczysz dywiza. A jak nie masz książki pod ręką (fakt, współczesnej młodzieży mogą wydać się niepotrzebnym reliktem w epoce video) to naciśnij kombinację minus-shift-altgr (przynajmniej w Linuksie).

Nie znam Twoich projektów, ale jeśli nie pozwalają na zapisanie polskiej interpunkcji to domyślasz się, co o tym mogę sądzić. W każdym razie gwarantuję, że webmasterem to Ty nie zostaniesz.

 

6 godzin temu, Zealota napisał:

Czy zakres zmiennej 2-bajtowy w Windows nie wystarczy, żeby te kilka polskich znaków dobrze obsłużyć w Linuksie i Windows

Odróżnij szerokość znaku (dwa bajty) wystarczającą do większości zastosowań, od jego reprezentacji w UTF-8 (która to reprezentacja jest zmiennej długości i może liczyć w przypadku 16-bitowych znaków od 1 do 3 bajtów).

6 godzin temu, Zealota napisał:

A może po prostu sam nie korzystasz z wchar_t tylko z przyzwyczajenia "liczysz wszystko w locie, tak od lat"?

Nie, korzystam z wchar_t wtedy, kiedy trzeba. Pisząc pod ncurses korzystam z wchar_t. Pisząc pod GTK+ używam utf-8. Tyle  że nie wpycham do zmiennych wchar_t jakichś swoich wynalazków a kody znaków.

A co do różnych kodowań... jeśli (jak twierdzisz) pracujesz na Linuksie, zrób sobie:

zless /usr/share/i18n/charmaps/UTF-8.gz

Albo ogólnie:

ls /usr/share/i18n/charmaps

nie będziesz musiał szukać po Internecie tego, co masz pod nosem.

[Zealota]

3 godziny temu, ethanak napisał:

Spróbuj kiedyś wziąć do ręki książkę (możę być ebook), ale nie taką mądrą o informatýce tylko taką głupią co w niej różne postaci występują, jak dojdziesz do miejsca w którym ludzie gadają ze sobą to zobaczysz dywiza. A jak nie masz książki pod ręką (fakt, współczesnej młodzieży mogą wydać się niepotrzebnym reliktem w epoce video)

Daruj sobie wycieczki osobiste w ocenie jakie książki w życiu przeczytałem oraz w tym ile mam lat. Gadajmy o mikrokontrolerach, bo o tym jest wątek. Dla przypomnienia temat wyjściowy to operacje we/wy na kartę, a właściwie problem (niech będzie mój) z polskimi literami kodowanymi w UTF-8.

 

3 godziny temu, ethanak napisał:

Nie przeinaczaj moich słów. Patrz wyżej.

Nic nie przeinaczam, skrytykowałeś użycie wchar_t do zapisania napisu kodowanego w UTF-8 w pamięci flash, który podałem. Nadal nie wiem dlaczego jest nieelegancki. Gdy zaczęliśmy drążyć to okazało się, że przenośność kodu, endianess, amigi itd. to w ogóle jakieś błędne koło, które ma marginalne znacznie w tej całej dyskusji. Jakie ma znaczenie rozmiar typu wchar 2 czy 4 bajty, jeśli zakres znaków jaki chce używać spokojnie mieści się w 2 bajtach (polskie litery), a gcc jest elastyczne i pozwala regulować taki parametr (-fshort-wchar), a również pomoże gdyby ktoś chciał zaoszczędzić pamięci, itd....

2 godziny temu, ethanak napisał:

Próbowałem wyjaśnić Ci, że wchar_t służy jak sama nazwa wskazuje do przechowywania szerokich znaków (wide characters), a nie hgw czego.

 Przecież polski znak w UTF-8 to już jest szeroki, więc co jest nie tak z wchar_t?

Próbuję przekazać, że w moim rozumieniu "char" to jest za mało by trzymać w pamięci mikrokontrolera napisy kodowane w UTF-8, szczególnie w kontekście korzystania z polskich liter, które zajmują 2 bajty - zatem należy użyć wchar_t. Gdybym miał inne założenia to bym sobie wziął CP852 i nie miałbym tego problemu i czym to jest hgw w tym kontekście? Skrót oczywiście znam, tak dla uprzedzenia...

 

2 godziny temu, ethanak napisał:

Pisząc pod GTK+ używam utf-8. Tyle  że nie wpycham do zmiennych wchar_t jakichś swoich wynalazków a kody znaków.

A zapis:

const wchar_t napis[] = L"gżegżółka";

to niby co to jest, jak nie "wepchanie" kodów znaków do tablicy wchar_t? Gdzie tu są "wynalazki"? 

Być może nadal czegoś nie rozumiem, ZAPROPONUJ jak inaczej zapisać do pamięci mikrokontrolera napis kodowany w UTF-8 i uzasadnij krótko dlaczego właśnie tak. Zwykłe znaki trzymać w char, a polskie w wchar, bo UTF-8 ma zmienną ilość bajtów - przecież to bez sensu. Jeden przykład na pewno powie więcej niż 5 akapitów pisaniny.

 

3 godziny temu, ethanak napisał:

A co do różnych kodowań... jeśli (jak twierdzisz) pracujesz na Linuksie, zrób sobie:

Co do programowania, nie zamierzam być webmasterem, linuksa czy windowsa używam głównie jako platformy do programowania mikrokontrolerów w c, a nie stricte do programowania - obecnie. Jeśli będzie potrzeba to być może się to zmieni, ale na pewno nie w szerokim zakresie. To, że jakieś pliki dla deweloperów gdzieś są w czeluściach "/" to super, na pewno skorzystam, jeśli poznam - no cóż nie od razu Rzym zbudowano... Ścieżki oczywiście pomocne, nie trzeba szukać po internetach jak napisałeś.

[ethanak]

Wiesz co - darujmy sobie.
 

const char napis[]="gżegżółka"; // tak się wpisuje w utf8

const wchar_t napis_w[]=L"gżegżółka"; // a tak w utf-16 czy co tam.

Natomiast to co Ty wstawiasz do wchar_t nie jest żadnym szerokim znakiem (bo ciąg bajtów 0xc4 0x85 interpretowany jako UTF-8 nie jest tym samym, co 0xc485 interpretowane jako szeroki znak, bo to koreańska sylaba 'ssweoni' a nie żadne 'ą'). W dalszym ciągu mylisz podstawowe pojęcia i - co gorsza - upierasz się że tak jest dobrze...

Poza tym "szeroki znak" to nie to samo co "wielobajtowa sekwencja UTF-8". Przyjmij to wreszcie do wiadomości i przestań się dalej kompromitować.

 

[Zealota]

const char napis1[]="gżegżółka";
const wchar_t napis2[]=L"gżegżółka";

char znak1 = napis1[1];
wchar_t znak2 = napis2[1];

Jeśli tak zadeklaruję napisy to jakie wartości przyjmą zmienne znak1 i znak2 i czemu tylko znak2 daje mi to co chcę, wartość którą ma zainicjowaną w tablicy polskich znaków?

Co będzie gdy zrobię tak:

char znak = 'ą';

Czemu ten zapis jest do kitu, bo przecież jest, gdy ustawię stronę kodową edytora na UTF8?

 

[ethanak]

2 godziny temu, Zealota napisał:

Czemu ten zapis jest do kitu, bo przecież jest, gdy ustawię stronę kodową edytora na UTF8?

Bo nie rozumiesz podstaw. Gdybyś chociaż spróbował to byś wiedział dlaczego.

Mogę Ci to wszystko wytłumaczyć jeśli chcesz, ale zdaje mi się że wolisz się upierać przy swoim i co bym nie pisał i tak to olejesz... szkoda mi czasu, za mało mi go zostało żebym musiał go tracić na zbędne dyskusje.

Chyba że rzeczywiście chcesz? To na początek popatrz sobie, jak jest to rozwiązane w glib.

Edytowano Czerwiec 16, 2020 przez ethanak

[Zealota]

Oczywiście, że chcą, ale pozwól, że jeszcze coś dopiszę, to może naświetli brak wiedzy lub moje błądzenie.

Zanim zaczniemy powrócę ostatniego wpisu i tablic napis1 oraz napis2. Opiszę moje przypuszczenia - podkreślam przypuszczenia, w formie pytającej, aczkolwiek podglądam co widzę w debugerze, bo niestety często jest to źródłem mojej wiedzy. Środowisko to CubeIDE_1.3.0.

Po deklaracji napis1 zrobi "sieczkę" w pamięci. Dostanę 14 znaków, w tym "0" i nie będę wstanie "rozkodować" tego napisu, bo kompilator rozłożył "po bajcie" zgodnie ze stroną kodową edytora - zwykłe litery po 1 bajcie, polskie po 2, dokładnie jak to jest z tablicą znaków w UTF-8 i chyba nie będę wiedział jak to poskładać.  Natomiast napis2 jest dla mnie uporządkowany, bo kompilator "zamienił" UTF-8 na UNICODE. Mam dokładnie tyle bajtów ile liter x 2 + 2 = 20 (tyle zajmuje koniec znaku, jeśli dobrze patrzę), bo akurat skorzystałem z opcji kompilatora, o której pisałem i wchar_t zajmuje 2 bajty. 

Gdy chcę dopasować litery polskie i np. wyświetlać je w postaci bitmap na LCD, to moje dekodowanie wydaje się banalne, jak ten przykład z tablicą. Mogę indeksować tablicę i sprawdzać warunki, porównywać itd. Co zrobię, gdy dostanę bufor z napisem po polsku? Tego jeszcze nie wiem, nie próbowałem dekodować w tę stronę. Jeśli to będzie Unicode, to nie widzę problemu na tę chwilę.

A no i deklaracja znak='ą' jak pokazałem wyżej daje ostrzeżenia:

large integer implicitly truncated to unsigned type [-Woverflow]
multi-character character constant [-Wmultichar]
Wydają mi się to jasne, bo zgodnie ze stroną kodową do danej jednobajtowej próbuję upchać "z edytora" 2 bajty.

 

No to tyle z mojego riserczu. Zamieniam się w słuch.

[ethanak]

Od razu informuję: nie chcę tu pisać całej książki, zajrzyj choćby do Wikipedii, masz tam większość ładnie opisaną (artykuł w polskiej wersji jest bardzo uproszczony).

Przede wszystkim: ponieważ UTF-8 to po prostu ciąg bajtów, gdzie każdy znak może zajmować więcej niż jeden bajt a ich ilość może wynosić od jednego do czterech (technicznie do sześciu, ale Unikod ograniczony jest do 21 bitów). W przypadku wielobajtowych znaków każdy bajt ma ustawiony najstarszy bit, pierwszy zawiera informację o długości całego znaku oraz początkowe bity, następne po 6 bitów. Pierwszy bajt ma zawsze ustawiony przedostatni bit, następne mają ten bit wyzerowany, co pozwala na łatwą identyfikacją znaczenia bajtu (konieczne przy "wstrzeleniu się" w przypadkowe miejsce w stringu).

Tak więc zapis typu:

char a = '<unicode character>'

nie ma sensu - możesz dla lepszego zrozumienia potraktować ten znak jako tablicę, co pozwoli łatwiej zrozumieć dlaczego tak nie można:

int x=[1,2,3]; // też niedozwolone, prawda?

I tu ponieważ część bitów to informacja potrzebna tylko do dekodowania, nie wystarczy tu proste przepisanie n bajtów. Na szczęście dekodowanie jest proste:

Jeśli pierwszy bajt zaczyna się od 110, znak zajmuje dwa bajty; starsze 5 bitów jest zawarte w kolejnym bajcie (najstarsze bity 10 oznaczają kontynuację). Tak więc znak L'ą' o kodzie szesnastkowym 105 (czyli binarnym 1 00000111) możemy podzielić tak:

100 000111

Pierwszy bajt będzie więc miał wartość 11000100, (czyli  0xC4) drugi 10000111 (czyli 0x85).

Znaki o kodach powyżej 0x7ff zapisywane są w trzech bajtach: 1110 xxxx 10xxxxxx 10xxxxxx

I tak dalej.

W drugą stronę jest tak samo prosto: musimy odrzucić niepotrzebne bity i połączyć pozostałe. Tak więc mając bajty 0xC4 0x85:

ponieważ pierwszy bajt zaczyna się od 110, mamy tu pięć bitów znaku, kolejny jeden bajt musi zaczynać się od 10 i zawiera 6 bitów. Tak więc:

11000100 -> pozostawiamy pięć bitów, czyli 00100

10000111 -> pozostawiamy sześć bitów, czyli 000111

Po połączeniu daje to 00100 000111, czyli bardziej czytelnie: 001 0000 0111, czyli  szesnastkowo 0x105 - czyli mamy nasze L'ą'!

Brzmi to na początku nieco zawile, ale w rzeczywistości jest to trywialnie proste. W dodatku istnieją biblioteki, które zawierają wszystkie funkcje konieczne do pracy z UTF-8, a kody enkoderów/dekoderów UTF-8 szwendają się po całym Internecie jak nie przymierzając panienki po poboczu 🙂

34 minuty temu, Zealota napisał:

i chyba nie będę wiedział jak to poskładać

No to już wiesz 🙂

35 minut temu, Zealota napisał:

Co zrobię, gdy dostanę bufor z napisem po polsku?

Zdekodujesz go jak wyżej.

Co więcej: nieważne czy będzie po polsku, rosyjsku czy chińsku: możesz w łatwy sposób zdekodować go np. do wchar_t* bez obawy, że coś tam się nie zmieści (co najwyżej czterobajtowe znaki pozamieniasz na jakieś znaki zapytania).

Wystarczy na początek?

 

 

 

[Zealota]

Dnia 16.06.2020 o 22:22, ethanak napisał:

Przede wszystkim: ponieważ UTF-8 to po prostu ciąg bajtów, gdzie każdy znak może zajmować więcej niż jeden bajt a ich ilość może wynosić od jednego do czterech (technicznie do sześciu, ale Unikod ograniczony jest do 21 bitów).

Dzięki za tak szczegółowy opis. Póki co zostawiam temat, ale na pewno wróci do mnie gdy przyjdzie pora.