Autor Wątek: Unicode (wydzielony z: Zagadki językoznawcze)  (Przeczytany 4862 razy)

Offline Xirdus

  • Redaktor

# Czerwiec 27, 2014, 13:22:14
Nie pomyślałem o tym. Zwracam honor.

Oczywiście, TRWTF to to, że takie twory w Unicode się w ogóle znajdują. Nie wspominając o alfabecie klingońskim, dwudziestu spacjach, czy U+1F4A9. Jeśli nie wprowadza się takich dziwactw, cztery miliardy code pointów starczyłoby na każdą kombinację kropek i kresek używanych w piśmie.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline albireo

  • Użytkownik

# Czerwiec 27, 2014, 14:09:34
Klingońskiego akurat nie ma w unicode (jest tylko jakieś mapowanie na znakach prywatnego użytku), ale fakt, wrzucanie tego całego śmietnika do kodowania to spora przesada. No i ileś tam lat temu unicode ograniczyło liczbę dostępnych codepointów do nieco ponad miliona (żeby dało się zapisać jako utf-16).

Offline Xender

  • Użytkownik

  • +1
# Czerwiec 28, 2014, 00:02:19
Nie chodzi mi o znaki kontrolne, a o combining characters, czyli w skrócie o takie kody które np dodają nad/pod literkę kreseczkę, kropeczkę czy inną dupereleczkę (przy czym nie łączy to się z każdym znakiem), sporo znaków ma podwójną reprezentację, jedną jako pojedynczy kod i inną jako połączenie dwóch (lub więcej kodów), co więcej występują też takie cuda jak ligatury (np ff), czyli połączenie dwóch lub więcej znaków w jeden kod.
Oczywiście, TRWTF to to, że takie twory w Unicode się w ogóle znajdują.
To ma swoje uzasadnienie - nie wszystkie znaki można zapisać bez użycia "combining characters". Ba, w Załączniku o normalizacji są konkretne przykłady.

Nie wspominając o [...] dwudziestu spacjach, czy U+1F4A9. Jeśli nie wprowadza się takich dziwactw, cztery miliardy code pointów starczyłoby na każdą kombinację kropek i kresek używanych w piśmie.
I na razie 4 miliardy, a nawet sporo mniej, jak najbardziej wystarcza.
Problem stanowił UCS-2, nie UCS-4. Tylko, że 4 bajty na znak niepotrzebnie zajmują miejsce, a nadal niewiele dają jeśli chodzi o pojęcie "długości tekstu", bo definicja długości jest bardzo wrażliwa na kontekst (jest o tym na UTF-8 Everywhere).

Co do 20 rodzajów spacji - tak, ma to uzasadnienie. To, że nie spotkasz ich np. na stronach www nie znaczy, że nie są potrzebne np. komuś, kto pracuje przy typografii.

ale fakt, wrzucanie tego całego śmietnika do kodowania to spora przesada.
Ogólnie - to, że coś jest rzadko spotykane, nie znaczy, że jest zbędne. Więc "combining characters" i 20 spacji są uzasadnione. "Kupka kupy" nie bardzo, ale reszta...

Przypominam, że Unicode ma być uniwersalny. Gdyby nie on i jego 20 spacji, to kodowanie zawierające tylko to, co ktoś uznał za powszechne by się nie przyjęło i nadal tkwilibyśmy w epoce mojibake.

Generalnie narzekacie tak na Unicode, ale sporo tu nieporozumień i szukania problemów tam, gdzie ich nie ma. Wolelibyście 3 zamiast ł?
« Ostatnia zmiana: Czerwiec 28, 2014, 00:07:07 wysłana przez Xender »

Offline Xion

  • Redaktor
    • xion.log

  • +1
# Czerwiec 28, 2014, 00:57:37
Jeśli sam tylko Unicode jest dla was tak wielkim powodem do narzekania, to cieszcie się, że nie macie do czynienia z całą i18n przez duże 18 ;p

Offline Xirdus

  • Redaktor

# Czerwiec 28, 2014, 01:50:32
To ma swoje uzasadnienie - nie wszystkie znaki można zapisać bez użycia "combining characters". Ba, w Załączniku o normalizacji są konkretne przykłady.
Weźmy znak ṩ (s z kropką nad i pod) - według linka (chyba że źle zrozumiałem) powinien on być zapisany jako U+0073;U+0323;U+0307 - odpowiednio s, kropka pod, i kropka nad. Ale po co, gdy mamy U+1E69, który jednym code pointem ogarnia wszystko? Naprawdę, Unicode byłby o wiele lepszy, gdyby tylko odzwierciedlał wizualny obraz znaków i nic więcej - żadnych mongolskich rozdzielaczy głosek, żadnych średnich matematycznych spacji, żadnych rzymskich liczb (tak, liczb, nie cyfr). Ja wiem, że gdy dodamy gramatykę do tekstu, łatwiej się ją parsuje dla syntezatorów mowy - ale po pierwsze przeciętny pisarz (tzn. twórca treści tekstowej) ma to głęboko gdzieś, co praktycznie unicestwia sensowność tego, a po drugie są lepsze sposoby na przypisywanie metadanych tekstowi niż wsadzanie jej bezpośrednio do treści. Niektóre 'redundantne' znaki powinny zostać dla celów poprawnego formatowania, np. niełamliwa spacja, ale po co mi na przykład em quad?

Jeśli sam tylko Unicode jest dla was tak wielkim powodem do narzekania, to cieszcie się, że nie macie do czynienia z całą i18n przez duże 18 ;p
Jestem informatykiem, myślę zero-jedynkowo - albo coś mnie nie obchodzi i siedzę cicho, albo coś mnie obchodzi i drę się na całe gardło - nie ma stanów pośrednich ;)

Offline aphity

  • Użytkownik

# Czerwiec 28, 2014, 07:36:37
Weźmy znak ṩ (s z kropką nad i pod) - według linka (chyba że źle zrozumiałem) powinien on być zapisany jako U+0073;U+0323;U+0307 - odpowiednio s, kropka pod, i kropka nad. Ale po co, gdy mamy U+1E69, który jednym code pointem ogarnia wszystko?
Pewnie dlatego że do standardu wciąż dodawane są kolejne języki, rozszerzenia i warianty odwzorowujące różne istniejące przejawy ludzkiego piśmiennictwa. Nawet gdyby zagospodarować całą teoretyczną 32 bitową przestrzeń (czego nie można zrobić, bo UTF-16 ogranicza ją do 17*65536 wartości) i przypisać wszystkim kombinacjom osobne kody, to wyobraź sobie jakiego rozmiaru nabrałyby pliki fontów lub bazy danych wspomagające przetwarzanie tekstu (baza dołączona do biblioteki ICU zajmuje już teraz kilkadzesiąt MB).

Moim zdaniem teoretycznie słuszne powinno być pójście w odwrotnym kierunku: tzn. przypisanie kodów wyłącznie formom podstawowym i zapisywanie wszystkiego w taki sposób jaki dziś nazywamy postacią zdekomponowaną (NFD). Przy czym ta teoretyczna możliwość nie ma raczej szans realizacji, biorąc pod uwagę jedno z założeń Unicode - zachowanie umiarkowanej zgodności z wcześniej stosowanymi kodowaniami. O ile dobrze rozumiem tę kwestię, chodzi o to by możliwe było mapowanie 1-1 pomiędzy znakami ze starych kodowań a tymi w Unicode.

Oczywiście, są w Unicode fragmenty których sensu trudniej dociec, niemniej w ogólności jest ten standard całkiem dobrze skonstruowany.

Offline albireo

  • Użytkownik

# Czerwiec 28, 2014, 12:01:14
Moim zdaniem teoretycznie słuszne powinno być pójście w odwrotnym kierunku: tzn. przypisanie kodów wyłącznie formom podstawowym i zapisywanie wszystkiego w taki sposób jaki dziś nazywamy postacią zdekomponowaną (NFD). Przy czym ta teoretyczna możliwość nie ma raczej szans realizacji, biorąc pod uwagę jedno z założeń Unicode - zachowanie umiarkowanej zgodności z wcześniej stosowanymi kodowaniami. O ile dobrze rozumiem tę kwestię, chodzi o to by możliwe było mapowanie 1-1 pomiędzy znakami ze starych kodowań a tymi w Unicode.
Jako umiarkowana zgodność w zupełności by mi wystarczyło jakby tekst przekodowany do unicode a później z powrotem do źródłowego kodowania dawał dokładnie to co było na wejściu, a do tego coś w stylu NFD powinno wystarczyć (chyba, że gdzieś się plącze jakieś kodowanie które ma możliwość zapisania jednego znaku na więcej niż jeden sposób).

Oczywiście, są w Unicode fragmenty których sensu trudniej dociec, niemniej w ogólności jest ten standard całkiem dobrze skonstruowany.
Jak dla mnie, żeby uznać kodowanie za dobrze skonstruowane, to musiałby mieć jednoznaczną reprezentację każdego znaku i można by było, mając specyfikację w wersji 1, móc zaimplementować (tak by działały dla każdej przyszłej wersji) następujące algorytmy: podział tekstu na znaki, rozpoznanie klasy znaku (litera, cyfra, znak kontrolny, interpunkcja, itp), podział na glyphy, upper/lower/title case. Przy czym przy takim kodowaniu szedłbym raczej w jakieś multibyte (nie byłoby problemu z endianami).
« Ostatnia zmiana: Czerwiec 28, 2014, 12:06:15 wysłana przez albireo »

Offline Xender

  • Użytkownik

# Czerwiec 28, 2014, 12:27:48
Jak dla mnie, żeby uznać kodowanie za dobrze skonstruowane, to musiałby mieć jednoznaczną reprezentację każdego znaku i można by było, mając specyfikację w wersji 1, móc zaimplementować (tak by działały dla każdej przyszłej wersji) następujące algorytmy: podział tekstu na znaki, rozpoznanie klasy znaku (litera, cyfra, znak kontrolny, interpunkcja, itp), podział na glyphy, upper/lower/title case. Przy czym przy takim kodowaniu szedłbym raczej w jakieś multibyte (nie byłoby problemu z endianami).
Dla mnie to brzmi jak UTF-8 znormalizowany do jednej (arbitralnie wybranej) z postaci skomponowanych/zdekomponowanych.

W sumie to ciężko tu mówić o algorytmach, to po prostu kwestia dostarczenia przez standard metadanych do każdego znaku w postaci czytalnej maszynowo. AFAIK Unicode to robi.

Offline albireo

  • Użytkownik

# Czerwiec 28, 2014, 12:39:21
Dla mnie to brzmi jak UTF-8 znormalizowany do jednej (arbitralnie wybranej) z postaci skomponowanych/zdekomponowanych.

W sumie to ciężko tu mówić o algorytmach, to po prostu kwestia dostarczenia przez standard metadanych do każdego znaku w postaci czytalnej maszynowo. AFAIK Unicode to robi.
Ale mi chodzi o to, żeby do tych algorytmów wystarczyły metadane z 1 wersji standardu. Poza tym unicode nie dostarcza (a przynajmniej nie udało mi się znaleźć) metadanych dotyczących glyphów (i ligatur), w szczególności które combining characters można z czym łączyć, czy ligatur z dewanagari (i podobnych alfabetów).

W sumie to jakiś moderator mógłby wydzielić część dotyczącą unicode do osobnego wątku.

Offline Xender

  • Użytkownik

# Czerwiec 30, 2014, 21:41:12
Ale mi chodzi o to, żeby do tych algorytmów wystarczyły metadane z 1 wersji standardu.
I jak sobie wyobrażasz implementację tego, która miałaby ręce i nogi?
Jedyne, co mi przychodzi do głowy, to układać code pointy tak, by użyć górnych/środkowych/dolnych bitów (lub innych reguł podzielności) do identyfikacji rodzaju znaku. I widzę szereg problemów z tym związanych (użycie większych liczb, przeplatanie się znaków różnych rodzajów, lub rozsmarowanie jednego języka na kilka plane'ów).

Poza tym unicode nie dostarcza (a przynajmniej nie udało mi się znaleźć) metadanych dotyczących glifów (i ligatur), w szczególności które combining characters można z czym łączyć, czy ligatur z dewanagari (i podobnych alfabetów).
http://www.unicode.org/faq/ligature_digraph.html - W skrócie - ligatury są w Unicode tylko dla kompatybilności z innymi kodowaniami i odradza się ich używanie.
Unicode spycha odpowiedzialność za ligatury na system renderowania czcionek - IMHO to ma sens, bo pozwala np. na niekomplikowanie implementacji szukania w tekście, syntezy mowy ipt. ponad potrzebę.

Combining można łączyć wszystkie ze wszystkimi - wtedy powstają takie kwiatki jak Zalgo Text. :P

A na serio - trochę nie sposób tego przewidzieć. Np. w japońskiej kanie dakuten i handakuten to modyfikatory, których używa się tylko do niektórych rzędów kany. Wydaje się być to bardzo dobrze zdefiniowane....
...Tylko, że istnieją w różnym stopniu standardowe transkrypcje innych języków na kanę, które wymagają użycia tych znaków w sposób, który nie występuje w japońskim - a to dlatego, że w japońskim nie występują też dźwięki, które te zapisy mają przedstawiać.
Przykładem może być transkrypcja języka Ainu lub zapis sylab l_ jako r_ z handakutenem.

Offline albireo

  • Użytkownik

# Lipiec 01, 2014, 09:50:27
I jak sobie wyobrażasz implementację tego, która miałaby ręce i nogi?
Jedyne, co mi przychodzi do głowy, to układać code pointy tak, by użyć górnych/środkowych/dolnych bitów (lub innych reguł podzielności) do identyfikacji rodzaju znaku. I widzę szereg problemów z tym związanych (użycie większych liczb, przeplatanie się znaków różnych rodzajów, lub rozsmarowanie jednego języka na kilka plane'ów).
Jeśli zakładać by znaki o stałej długości, to rzeczywiście byłby problem, ale jeśli byłoby to multibyte (w niektórych sytuacjach o dość dużej długości), to można by to w miarę łatwo zrobić, najpierw dzielimy bajty na dwie klasy, codepoint start i codepoint continuation (dzięki temu można mieć praktycznie nieograniczoną liczbę codepointów), klasę znaku definiuje tylko codepoint start, żeby działało upper/lower case wydzielamy trzy klasy niepodlega, małe i duże (małe i duże zawsze występują w parach, więc zmiana case oznacza dla każdego codepointu tylko zmianę start). Zostają jeszcze glify/ligatury, dla nich rezerwujemy sobie jeden codepoint start, i definiujemy możliwość podania jej długości i ewentualnie jakichś dodatkowych informacji (za pomocą continuation), a do renderowania, jeśli czcionka nie zawiera odpowiedniej ligatury, renderuje się każdy znak osobno. Pozostaje tylko odpowiednie zmapowanie znaków aby się to trzymało kupy. Przy zachowaniu zgodności z ascii można by zrobić tak, że wszystkie znaki ascii to codepoint start, ostatnie 64 wartości bajtu to continuation, dodatkowo dodajemy jeszcze kilka continuation które są wspólne dla wszystkich znaków, można w to wcisnąć takie rzeczy jak dolny/górny indeks, full/half width, jakieś kółeczka/kwadraciki wokół znaków (circled/squared forms), itp, reszta to start. Przydałby się jeszcze jakiś codepoint na RTL (i podobne), bo to też upierdliwe przy renderowaniu.

http://www.unicode.org/faq/ligature_digraph.html - W skrócie - ligatury są w Unicode tylko dla kompatybilności z innymi kodowaniami i odradza się ich używanie.
Unicode spycha odpowiedzialność za ligatury na system renderowania czcionek - IMHO to ma sens, bo pozwala np. na niekomplikowanie implementacji szukania w tekście, syntezy mowy ipt. ponad potrzebę.
Tyle to, że ligatury istnieją w samym unicode jako coś zupełnie oderwanego od znaków z których się składa i tak komplikuje to szukanie, natomiast brak brak informacji o nich powoduje problemy z renderowaniem, jeśli chce się np samemu dzielić tekst na linie (i z jakiegoś powodu konieczne jest dzielenie w środku wyrazu).

Combining można łączyć wszystkie ze wszystkimi - wtedy powstają takie kwiatki jak Zalgo Text. :P
Które renderowanie się sypie, a połączenie arabskich combining z alfabetem łacińskim jakoś nie dawało sensownych wyników, zresztą arabskie combining nawet z arabskimi znakami przy większej liczbie combining też się dobrze nie łączyło (inna sprawa, że może to zależeć od czcionki).

Offline Xender

  • Użytkownik

# Lipiec 10, 2014, 00:38:53
Jeśli zakładać by znaki o stałej długości, to rzeczywiście byłby problem, ale jeśli byłoby to multibyte (w niektórych sytuacjach o dość dużej długości), to można by to w miarę łatwo zrobić, najpierw dzielimy bajty na dwie klasy, codepoint start i codepoint continuation (dzięki temu można mieć praktycznie nieograniczoną liczbę codepointów), klasę znaku definiuje tylko codepoint start, żeby działało upper/lower case wydzielamy trzy klasy niepodlega, małe i duże (małe i duże zawsze występują w parach, więc zmiana case oznacza dla każdego codepointu tylko zmianę start). Zostają jeszcze glify/ligatury, dla nich rezerwujemy sobie jeden codepoint start, i definiujemy możliwość podania jej długości i ewentualnie jakichś dodatkowych informacji (za pomocą continuation), a do renderowania, jeśli czcionka nie zawiera odpowiedniej ligatury, renderuje się każdy znak osobno. Pozostaje tylko odpowiednie zmapowanie znaków aby się to trzymało kupy. Przy zachowaniu zgodności z ascii można by zrobić tak, że wszystkie znaki ascii to codepoint start, ostatnie 64 wartości bajtu to continuation, dodatkowo dodajemy jeszcze kilka continuation które są wspólne dla wszystkich znaków, można w to wcisnąć takie rzeczy jak dolny/górny indeks, full/half width, jakieś kółeczka/kwadraciki wokół znaków (circled/squared forms), itp, reszta to start. Przydałby się jeszcze jakiś codepoint na RTL (i podobne), bo to też upierdliwe przy renderowaniu.
W ten sposób mocno ograniczasz sobie możliwość reprezentacji jakichkolwiek znaków w 1 bajcie. Nie wiem też, czy dałoby się zachować zgodność z ASCII, chociaż może...

Problem jest taki, że w ten sposób zaszywasz w samym kodowaniu mnóstwo danych, które nie zawsze mogą być potrzebne. A jeśli potem okaże się, że na etapie projektowania o czymś zapomniałeś, to wracasz do trzymania tych zapomnianych metadanych w osobnych tabelach.

Tyle to, że ligatury istnieją w samym unicode jako coś zupełnie oderwanego od znaków z których się składa i tak komplikuje to szukanie, natomiast brak brak informacji o nich powoduje problemy z renderowaniem, jeśli chce się np samemu dzielić tekst na linie (i z jakiegoś powodu konieczne jest dzielenie w środku wyrazu).
http://www.unicode.org/charts/PDF/UFB00.pdf
Jak w oderwaniu, skoro masz w samej nazwie znaku napisane, co to za ligatura? Do tego masz odniesienia do znaków składowych.

Zdaje się, że machine-readable tabele, o których mówię, to po prostu libka ICU (International Components for Unicode).
Jak potrzebujesz, to zrób z niej użytek, zamiast snuć marzenia o majstrowaniu w bitach samego kodowania.
Bo nowego "lepszego" kodowania na świecie nie wprowadzisz, a dane z tabel masz kilka kliknięć i lookupów stąd.

Które renderowanie się sypie, a połączenie arabskich combining z alfabetem łacińskim jakoś nie dawało sensownych wyników, zresztą arabskie combining nawet z arabskimi znakami przy większej liczbie combining też się dobrze nie łączyło (inna sprawa, że może to zależeć od czcionki).
I co z tego, że się sypie? To, że coś jest dozwolone przez kodowanie nie znaczy, że ma sens.
Jaki byłby sens whitelistowania dozwolonych przypadków użycia Combining Characters?
Zalgo Text nie będzie już więcej działać - łal, tyle zyskałeś.
Jak zrobisz to źle, to nie będzie się dało już zapisywać Ajnuskiego i ktoś się może wściec.

W hipotetycznej sytuacji mieszania arabskich combiningów z łaciśnkimi znakami renderowanie się sypie - i co z tego? Czemu uważasz, że trzeba cokolwiek z tym robić?

Przez analogię: "Hej, mój kot przebiegł po klawiaturze i to, co wpisał nie jest słowem w żadnym języku świata. Pomocy, trzeba coś z tymi komputerami zrobić, żeby dało się wpisywać tylko dozwolone kombinacje...
Oh, wait, właśnie to zrobiłem i ubiłem sobie wpisywanie słów kluczowych w językach programowania."

Offline albireo

  • Użytkownik

# Lipiec 11, 2014, 16:03:16
W ten sposób mocno ograniczasz sobie możliwość reprezentacji jakichkolwiek znaków w 1 bajcie. Nie wiem też, czy dałoby się zachować zgodność z ASCII, chociaż może...
Przy założeniu zgodności z ASCII będzie co najmniej tak jak z utf-8, czyli wszystko z ASCII będzie na jednym bajcie (może coś więcej nawet).

Problem jest taki, że w ten sposób zaszywasz w samym kodowaniu mnóstwo danych, które nie zawsze mogą być potrzebne. A jeśli potem okaże się, że na etapie projektowania o czymś zapomniałeś, to wracasz do trzymania tych zapomnianych metadanych w osobnych tabelach.
Kwestia tego jakie metadane chce się zaszyć w samym kodzie znaku, bo wielu po prostu się nie da, np o sortowaniu które jest zależne od języka (a często nawet w obrębie jednego język może być wiele sensownych porządków).

http://www.unicode.org/charts/PDF/UFB00.pdf
Jak w oderwaniu, skoro masz w samej nazwie znaku napisane, co to za ligatura? Do tego masz odniesienia do znaków składowych.
"w oderwaniu" chodziło mi o to, że bez dodatkowych tablic nie wiem co dana ligatura reprezentuje.

Zdaje się, że machine-readable tabele, o których mówię, to po prostu libka ICU (International Components for Unicode).
Jak potrzebujesz, to zrób z niej użytek, zamiast snuć marzenia o majstrowaniu w bitach samego kodowania.
Może, nie chce mi się sprawdzać czy ma wszystko co byłoby przydatne.

Bo nowego "lepszego" kodowania na świecie nie wprowadzisz, a dane z tabel masz kilka kliknięć i lookupów stąd.
Ano, niestety, 20 lat temu, mogłoby się udać, a jeśli nie byłoby oparte o ASCII, to i 40 lat temu mogłoby być za późno.

I co z tego, że się sypie? To, że coś jest dozwolone przez kodowanie nie znaczy, że ma sens.
Jaki byłby sens whitelistowania dozwolonych przypadków użycia Combining Characters?
Zalgo Text nie będzie już więcej działać - łal, tyle zyskałeś.
Zyskałem też wiedzę, co znaczy przesunięcie się o jeden znak/glif w prawo/lewo (nawet jakby działało Zalgo Text), a jeśli miałbym tą informację bezpośrednio w kodowaniu, to by było idealnie.

Jak zrobisz to źle, to nie będzie się dało już zapisywać Ajnuskiego i ktoś się może wściec.
Wystarczy zrobić to dobrze :D

W hipotetycznej sytuacji mieszania arabskich combiningów z łaciśnkimi znakami renderowanie się sypie - i co z tego? Czemu uważasz, że trzeba cokolwiek z tym robić?
Jakby z samego kodowania wynikała niemożliwość takiego mieszania, to problem sypania sam by się rozwiązał.

Przez analogię: "Hej, mój kot przebiegł po klawiaturze i to, co wpisał nie jest słowem w żadnym języku świata. Pomocy, trzeba coś z tymi komputerami zrobić, żeby dało się wpisywać tylko dozwolone kombinacje...
Oh, wait, właśnie to zrobiłem i ubiłem sobie wpisywanie słów kluczowych w językach programowania."
Akurat słowa kluczowe w językach programowania mają przeważnie jakiś sens (zwykle po angielsku). Ale aż taka kontrola to przesada :)
« Ostatnia zmiana: Lipiec 11, 2014, 16:10:21 wysłana przez albireo »

Offline Xender

  • Użytkownik

# Lipiec 12, 2014, 00:53:52
Zyskałem też wiedzę, co znaczy przesunięcie się o jeden znak/glif w prawo/lewo (nawet jakby działało Zalgo Text), a jeśli miałbym tą informację bezpośrednio w kodowaniu, to by było idealnie.
Przypominam, że nawet to jest nietrywialne: http://www.utf8everywhere.org/#faq.glossary
Zwróć uwagę na różnicę pomiędzy "User-perceived character" a "Grapheme cluster".
Do tego http://www.utf8everywhere.org/#myth.strlen.
Kwestia, jak traktować https://en.wikipedia.org/wiki/Hangul#Letters też jest nietrywialna.

Jeśli chodzi o przesuwanie kursora, nie widzę problemu z realizacją go na UTF-8 + danymi z tabel na temat "grapheme clusters". (czyli pewnie tego, które codepointy kodują "normalne" znaki, które to combiningi, z które służą do sklejania kilka znaków wizualnie w jeden (nie, to nie służy i nie powinno być używane do ligatur, bo ligatury to tylko eyecandy. To służy do komponowania z kluczy tych znaków CJK, które nie mają reprezentacji jako codepointy (co może zmieniać zarówno wygląd (w znaczącym stopniu, nie tak jak ligatury), znaczenie jak i wymowę znaku)).

Wystarczy zrobić to dobrze :D
Co jest nietrywialne i patrz niżej.

Jakby z samego kodowania wynikała niemożliwość takiego mieszania, to problem sypania sam by się rozwiązał.
Ale czemu uważasz sypanie się za problem? Nie oczekiwałbym, że przypadkowa kombinacja chociażby tych liter łacińskich i arabskich combiningów wyrenderuje się w jakiś sensowny sposób. Krzakowe wejście, krzakowe wyjście, nic się nie stało.
Co by Ci dało formalne ustanowienie dozwolonych/niedozwolonych połączeń combiningów? Bo zdefiniowane ich to jakiś wysiłek i fajnie by było, gdyby był czymś uzasadniony.

Offline albireo

  • Użytkownik

# Lipiec 12, 2014, 16:26:01
Oczywiście wiem, że to wszystko jest nietrywialne, ale jestem pewien, że można by to zrobić lepiej niż w unicode.

Co by Ci dało formalne ustanowienie dozwolonych/niedozwolonych połączeń combiningów? Bo zdefiniowane ich to jakiś wysiłek i fajnie by było, gdyby był czymś uzasadniony.
Sęk w tym, że są one już zdefiniowane, ale nie kojarzę, żeby to było zrobione w pełni gdzieś w standardzie unicode, ale są np w fontach  (przy czym oczywiście obejmują tylko tą część znaków która jest w foncie).
Poza tym, mniej więcej czymś takim będzie to co podałeś:
Jeśli chodzi o przesuwanie kursora, nie widzę problemu z realizacją go na UTF-8 + danymi z tabel na temat "grapheme clusters".