#unikod — Public Fediverse posts

Serio, #emoji i ikonki w unikodzie to koszmar.

Tak, fajno, że nie trzeba już używać <img/>, tylko można sobie wstawić magiczny znaczek z Unikodu. Można wcisnąć grafikę tam, gdzie technicznie wchodzi tylko tekst (np. w tytułach zgłoszeń błędów). Nawet lepiej, można mieć kolorowe ikonki w środku terminala prawie bez wysiłku.

Tyle że z punktu widzenia dostępności, to jest koszmar. Dziś ludzie używają tych symboli do przekazywania *informacji*. Symboli, które wymagają olbrzymich fontów do wyświetlenia, bądź wielkich baz danych do opisu.

Tak, nieopisane <img/>, przekazujące graficznie informację ssie. Ale do <img/> można dodać sensowny alt-tekst, i narzędzia mogą ten tekst wykorzystać, by podać przydatny kontekst. Jak np. "poprawka błędu".

Natomiast emoji i ikony są symboliczne. W najlepszym wypadku dostaniemy opis typu "młotek i klucz [płaski?]", i możemy się domyślić, że chodzi o "poprawkę błędu". No chyba że akurat chodziło o "czynności utrzymaniowe"? Albo dostaniemy "nieznany znak 0x1F6E0". I jestem przekonany, że nic nie będzie przyjemniejsze niż próba dopasowania tego typu opisów do legendy pełnej "nieznanych znaków".

#Unikod #dostępność

Kolejny ciekawy problem z dziedziny przenośności: kodowania #UTF-16, UTF-32, UCS-2 i UCS-4 są zależne od kolejności bajtów. Oznacza to, że można je zakodować albo jako big endian, albo jako little endian. Kodując ciągi znaków, #Python używa kolejności bajtów systemu i dopisuje Byte Order Marker na początku pliku. Przy dekodowaniu, automatycznie odczytuje zapisany wcześniej BOM, by określić właściwą kolejność bajtów, dzięki czemu wszystko "po prostu działa".

Problemy zaczynają się, kiedy próbujemy porównać zakodowane dane na poziomie bajtów, np. porównując zapisany wcześniej jako UTF-16 plik z wynikiem wywołania `encode()`. Jeżeli plik był zapisany na systemie little endian (jak to zwykle bywa), a testy uruchamiane są na systemie big endian, nagle okaże się, że dostajemy dwa różne ciągi bajtów!

"Oczywistym" rozwiązaniem jest wymuszenie konkretnej kolejności bajtów, np. użyjąc kodowania `utf-16-le` zamiast `utf-16`. Tu jednak pojawia się kolejny problem — kiedy podajemy określoną kolejność bajtów, Python nie zapisuje już BOM — tak więc porównanie na poziomie bajtów wykaże różnicę w postaci brakującego BOM. Można to jednak rozwiązać prostą sztuczką — dopisując BOM (`\ufeff`) na początku kodowanego ciągu.

https://github.com/python/importlib_resources/pull/313/files

#przenośność #unikod #Gentoo