Názor k článku
Linus přidal tabulátory do Kconfig od RDa - Jestli je soubor v US-ASCII, tak zadny nejvyssi...

Jestli je soubor v US-ASCII, tak zadny nejvyssi bit v bajtu nastaven nebude.
Je to 7-bitove kodovani a do sedmi bitu ulozite hodnotu 0-127, nic jineho.

Vas pozadavek nastavovani osmeho bitu kdyz jich existuje sedum, je jako chtit po integer bajtu aby enkodoval 0..255 s nejakou desetinnou presnosti (0,1 ^ n; n>=1)

UTF-8 koduje cisla 0..0x10FFFF - nezavisle na verzi Unicode, do 1 az 4 bajtu.

Vse co neni definovany znak je obligatni ctverecek, ale neznamena to, ze takove znaky se napr pri copy/paste zahodi v compliant sw. A taky to neznamena, ze dokument ulozeny v novsi verzi unicode by nesel otevrit nebo snad shazoval starsi sw.

Zda je neco platna, neplatna nebo nevhodna sekvence, urcuje samotna definice UTF-8. A neplatne sekvence (ktere vubec nesouvisi s tim, ze do unicode se pridavaji dalsi znaky) se mapuji na error placeholdery podle doporuceni ve standardu.. ne dle libovule tvurce parseru.

Pokud se vam neco rozbilo, tak to byva treba spatnym prepokladem podobneho amatera jako jste vy, co bral ze relevantni Unicode pro ne ma pouze 64K znaku a dekodoval pouze 1-3 byte UTF-8 sekvence na unsigned short (16bit). Ale 4-byte kodovani na >64K tam bylo od pocatku. Na tohle trpi treba uzivatele mysql, co zvolili utf8mb3.