Unicode, soft i znaki poza BMP

Witam. Mam takie pytanie do tych, ktorzy programuja na platformach, ktore wewnetrznie uzywaja UTF-16 do reprezentacji stringow (Java, widze rowniez ze .NET - http://msdn.microsoft.com/en-us/library/system.string.aspx, Obj-C, ...):
Czy martwicie sie o sytuacje, gdzie jakis znak Unicode wymaga wiecej niz 1 char? Jak robicie operacje typu: substring? Dla przykladu, ten kod w Javie:

String s = "\uD83D\uDE04"; // U+1F604, see http://punchdrunker.github.io/iOSEmoji/table_html/
System.out.println(s);
System.out.println(s.length());
System.out.println(s.substring(0, 1));

produkuje to:

Ale wiem ze maja znaki poza BMP to: chinski, koreanski, arabski

Nie.
Poza BMP znajdują się najwyżej jakieś znaki historyczne, które nie są ci potrzebne chyba że wiesz, że będą potrzebne.
Każdy cywilizowany język mieści się w całości w BMP.

Poza tym, czy tak często potrzebujesz robić substring i to w taki sposób, że przeszkodzi to w obsłudze znaków spoza BMP?

Tekst przyjęty do jakiegoś inputa, przechowany i wyświetlony w całości nie ulegnie przecież samoistnemu uszkodzeniu - i będzie poprawnie wyświetlony (o ile font w systemie jest...)

Skoro wiesz jak pobrać pierwszy znak z zachowaniem znaków >FFFF, to czemu nie - ale jest bardzo mało prawdopodobne, by ktoś umieszczał egipskie hieroglify w tytule piosenki...

Czy jednak lepiej napisac kod tak, zeby dzialal i juz, bez wzgledu na znak jaki jest uzywany?
To zależy ile nakładu pracy to wymaga. Jeżeli dodania offsetByCodePoints w kilku miejscach w kodzie to tak - jeżeli przepisywania wszystkiego od nowa to nie.

W najgorszym wypadku przy braku obsługi znaków spoza BMP wyświetli się ? albo inny śmieć. Ale absolutnie program nie powinien się od tego wywalić.

No wiec, zmiana kodu jest w jednym miejscu (te overlaye dla listy mamy ladnie wyodrebnione od reszty logiki), i jesto to malo kodu dla Javy (jak pokazalem powyzej) i 1 linijka kodu wiecej dla Obj-C, wiec wysilek zaden, trzeba to jedynie wiedziec i rozumiec dlaczego.

Substring ten jest robiony czesto - listy plikow moga byc dlugie, a scrollowanie za pomoca gestow jest szybkie i bardzo szybko sie moga znaki w overlayu zmieniac. Jest to pewiem problem jesli chodzi o performance, ale bardzo niewielki i stwierdzilismy ze mozemy zaniedbac (prawde mowiac jest niezauwazalny...).

Co do znakow - np. klucz wiolonowy czy jakiestam nuty, czy np. emoji sa poza BMP. emoji moze nie, ale np. nuty w nazwie pliku kogos, kto jest muzykeim potrafie sobie wyobrazic. Aplikacje sie nie wywalaja ale nie jest to cos co jest oczywiste - skad wiesz co robi Android czy iOS z niepoprawnymi stringami, a takimi sa takie ktore posiadaja tylko 1 char z pary surogatow? np. widzialem parsery ktore sie wywalaja na takim czyms. Pokazanie ? jest raczej nie do przyjecia skoro mozemy zrobic cos lepszego.

Kod zmienilismy, przetestowalismy i dziala ladnie, pokazuje emoji i nuty w overlayu. Dzieki za zainteresowanie. Teraz musze tylko zrobic prezentacje dla zespolu poniewaz wszyscy chca zrozumiec co ten kod robi...

Azarien napisał(a):

Ale wiem ze maja znaki poza BMP to: chinski, koreanski, arabski

Nie.

Mam w zespole kolege Chinczyka ktory pokazal mi znaki, ktore nie mieszcza sie w BMP a on i jego znajomi uzywaja w czatach itp. Wiec nie jest to absolutne 'nie', ale ja sie na takich jezykach nie znam. Sa tez jakies CJK (chinese, japanese, korean) extensions ktore maja dziwne znaki w srodku. Sa jakies znaki 'han' czy cos, itp. itd. Poza tym uwazam ze w 21. wieku kod powinien byc bez zadnego 'ale' unicode-ready i juz. Moze to paranoja, juz bylem o to posadzany np. jesli chodzi o programowanie wielowatkowe i wyszukiwanie race conditions ;d

IMO, zakładanie w dzisiejszych czasach, że mieścimy się zawsze w BMP, jest równie radosne, jak zakładanie kiedyś, że mieścimy się w ASCII. Nawet motywacja stojąca za tym założeniem jest identyczna jak kiedyś: olejmy po cichu to, co jest naszym zdaniem rzadkie, bo będzie nam "łatwiej" pracować na stałej szerokości znaków.

Te inne znaki po prostu są ;) Nieświadome ich olanie to błąd, a świadome olanie to lenistwo ;) W sumie za to lubię UTF8 - bez przerwy jest zmienna długość, więc nie da się myśleć w ten sposób ;)