On Tue, 24 May 2011 19:55:45 +0200, Borneq wrote:

> W takich językach jak Java czy C# znak jest dwubajtowy. Jednak nie możemy
> przyjąć że każdy kod odpowiada jednemu znakowi i że str[5] jest piątym
> licząc od zera znakiem. Chodzi mi o specjalne znaki o kodach powyżej 65535,
> składane z dwóch połówek ("surogatów")
> http://en.wikipedia.org/wiki/Plane_%28Unicode%29
> Czy warto się tym przejmować?

A jaką aplikację piszesz? Jeżeli jest tam szansa na pojawienie się znaków
powyżej 16bit, to tak, trzeba się przejmować. Jak nie, to nie trzeba.
Jeżeli chodzi o Javę, to zgadza się, znak jest tam dwubajtowy, jednak cały
czas masz możliwość równoległego operowania na code point (chociażby
String.codePointAt), więc tutaj nie ma problemów.
Generalnie z szerokimi znaczkami (szerszymi niż 7bitów) jest zawsze problem
i to nie tylko po stronie danego języka i jego wewnętrznych mechanizmów
implementacji typów napisowych, ale właściwie na każdym kroku, m.in:
- warstwa IO - w jakim kodowaniu jest plik? Jak warstwa IO radzi sobie z
konwersją między danym kodowaniem a innym?
- bazy danych - co z tego, że twój program działa doskonale dla wszystkich
możliwych kodowań, jeżeli okazuje się, że twoja baza danych przechowuje
dane w kodowaniu iso-8859-2?
- gui - zestaw kontrolek do wyświetlania szerokich znaków
- interakcja z innymi systemami
itd.

> Znaki chińskie i japońskie mieszczą się w planie podstawowym od 0x4e00 do
> 0x9fff (miejsce na ponad 20 tys. ideogramów)
> Czy używane są znaki powyżej granicy 64 Ki, jakie fonty je używają aby
> przetestować? Czy tekst złożony z dwóch surogatów podany do TextOut da w
> rezultacie wyrysowany jeden znak?

W Javie jest to łatwe do sprawdzenia (C# tak dobrze nie znam, możliwe, że
też):

int[] highCodePoint = { 0xFFFFF };
String highCodePointString = new String(highCodePoint, 0, 1 };
JOptionPane.showInputDialog(null, highCodePointString.
highCodePointString);

albo coś takiego.



--
Pozdrawiam
Zbyszek Malec