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ć?
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?

do góry

> Czy warto się tym przejmować?

i tak i nie. z jednej strony, jest to część standardu. z drugiej strony,
pisma tam umieszczone są już egzotyką pośród egzotyki. z trzeciej strony,
miejsca jest dużo, więc z czasem może dodadzą tam jakiś bardzo-fajny zestaw
znaków, który będzie zyskiwał na popularności: może coś na miarę
dzisiejszych emotikonek, może jakieś kody sterujące, trudno przewidzieć.

żeby się nie odcinać od tego obszaru, warto unikać odwoływania się do znaków
poprzez konkretny, stały indeks jak str[5] -- a tylko gdy indeks pochodzi z
funkcji typu find(), pos() czy podobnej: str[i].
pojawi nam się jednak drugi problem: że nawet wyszukanego indeksu nie możemy
ot tak sobie przesuwać (np. i++). ale problemu się pozbędziemy, jeśli string
będzie albo zawsze traktowany jako całość, albo - jeśli konieczna jest jego
analiza - przez wyrażenia regularne lub podobne funkcje biblioteczne, o ile
oczywiście te będą prawidłowo obsługiwać surogaty.

ale jeśli okaże się z tym za dużo zachodu, to póki co można machnąć ręką...

> Czy używane są znaki powyżej granicy 64 Ki,

skoro zostały zdefiniowane, to na pewno fascynaci takich znaków się
znaleźli.

> jakie fonty je używają aby przetestować?

tutaj test egipskich hieroglifów, które są na pewno powyżej BMP
http://users.teilar.gr/~g1951d/

a tutaj różne czcionki, ale to już sprawdź które skrypty są w BMP a które
korzystają z surogatów:
http://www.alanwood.net/unicode/egyptian-hieroglyphs
.html


> Czy tekst złożony z dwóch surogatów podany do TextOut
> da w rezultacie wyrysowany jeden znak?

powinno. sprawdź...

> Znaki chińskie i japońskie mieszczą się w planie podstawowym od
> 0x4e00 do 0x9fff (miejsce na ponad 20 tys. ideogramów)

no nie wszystkie, powyżej jest dalsze 50 tys. znaków, tu masz rozpiskę

http://en.wikipedia.org/wiki/CJK_Unified_Ideographs#
Unicode_version_history

ale ideogramy które są powyżej BMP przeciętnego Chińczyka lub Japończyka
interesują mniej więcej tyle, co nas głagolica, albo jakieś runy. do
zastosowań w opracowaniach historycznych, językoznawczych i podobnych. w
codziennej gazecie takich znaków nie uświadczysz.

podsumowując: jeśli stringi tylko pobierasz, wczytujesz, składujesz,
wyświetlasz - zawsze w całości, to nie musisz nic robić: przetestuj tylko
czy wyświetlają się prawidłowo.
problemy się zaczynają, gdy zaczynasz te stringi parsować, szatkować i
wyżymać.


--
Azarien

do góry

> tutaj test egipskich hieroglifów, które są na pewno powyżej BMP
> http://users.teilar.gr/~g1951d/

> a tutaj różne czcionki, ale to już sprawdź które skrypty są w BMP a które
> korzystają z surogatów:
> http://www.alanwood.net/unicode/egyptian-hieroglyphs
.html



linki odwrotnie ;-)


--
Azarien

do góry

On Tue, 24 May 2011 23:03:01 +0200, Wiktor S. wrote:

> żeby się nie odcinać od tego obszaru, warto unikać odwoływania się do znaków
> poprzez konkretny, stały indeks jak str[5] -- a tylko gdy indeks pochodzi z
> funkcji typu find(), pos() czy podobnej: str[i].

Jesteś trochę niekonsekwentny. Bo albo wszystkie elementy interfejsu
działają dla danego przypadku źle, albo wszystkie dobrze. Nie może być tak,
że operator [] zwraca pół znaku, a już find zwróci pozycję na cały znak. No
chyba, że mówimy o jakiejś bardzo popsutej implementacji.

To samo dotyczy inkrementacji zmiennej indeksującej - operator indeksowania
w typie napisowym powinien działać tak, że zwraca n-ty znak. Raczej nie
znajdziesz takiej implementacji, w której zamiast tego zwracany jest n-ty
bajt napisu (o ile akurat bajt nie jest tożsamy ze znakiem).

--
Pozdrawiam
Zbyszek Malec

do góry

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

do góry

W dniu 2011-05-24 23:05, Wiktor S. pisze:
>> http://users.teilar.gr/~g1951d/

Fonty mają rozszerzenie .otf, jak się je instaluje?

do góry

> Fonty mają rozszerzenie .otf, jak się je instaluje?

tak samo jak .ttf - zależnie od posiadanego systemu ;-)


--
Azarien

do góry

>> żeby się nie odcinać od tego obszaru, warto unikać odwoływania się
>> do znaków poprzez konkretny, stały indeks jak str[5] -- a tylko gdy
>> indeks pochodzi z funkcji typu find(), pos() czy podobnej: str[i].
>
> Jesteś trochę niekonsekwentny. Bo albo wszystkie elementy interfejsu
> działają dla danego przypadku źle, albo wszystkie dobrze. Nie może
> być tak, że operator [] zwraca pół znaku, a już find zwróci pozycję
> na cały znak. No chyba, że mówimy o jakiejś bardzo popsutej
> implementacji.

find zwróci na cały - o ile szukamy znaku "małego".

> To samo dotyczy inkrementacji zmiennej indeksującej - operator
> indeksowania w typie napisowym powinien działać tak, że zwraca n-ty
> znak. Raczej nie znajdziesz takiej implementacji, w której zamiast
> tego zwracany jest n-ty bajt napisu (o ile akurat bajt nie jest
> tożsamy ze znakiem).

nie n-ty bajt, tylko n-te słowo. czyli pół znaku czasami. i tak działa chyba
większość implementacji stringów o 16-bitowych znakach.

--
Azarien

do góry

W dniu 2011-05-25 00:18, Zbigniew Malec pisze:
> 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.

Chciałbym poznać Javę od strony tworzenia własnych komponentów, zrobić
komponent wypisujący znaki z danego zakresu Unicode (tabelka). Potrzebny
do testów jest font mający znaki o wyższych kodach.
Ale nie jestem pewien jak działa funkcja String.codePointAt
czy jeśli mam _dwa_słowa_na_hieroglif, litera A
to dla zera zwróci hieroglif natomiast A zwróci dla trójki zamiast dla
dwójki?
Mam w openJDK:
Class String:
public int codePointAt(int index) {
if ((index < 0) || (index >= count)) {
throw new StringIndexOutOfBoundsException(index);
}
return Character.codePointAtImpl(value, offset + index, offset
+ count);
}

Class Character:
// throws ArrayIndexOutofBoundsException if index out of bounds
static int codePointAtImpl(char[] a, int index, int limit) {
char c1 = a[index++];
if (isHighSurrogate(c1)) {
if (index < limit) {
char c2 = a[index];
if (isLowSurrogate(c2)) {
return toCodePoint(c1, c2);
}
}
}
return c1;
}

do góry

On Wed, 25 May 2011 01:13:52 +0200, Borneq wrote:

> Ale nie jestem pewien jak działa funkcja String.codePointAt
> czy jeśli mam _dwa_słowa_na_hieroglif, litera A
> to dla zera zwróci hieroglif natomiast A zwróci dla trójki zamiast dla
> dwójki?

Nie bardzo rozumiem słowo "hieroglif". Code point to jest numerek znaczka w
unicode. Jeżeli twój napis składa się z dwóch charów, bazy i surogatu, to
przeczytasz dwa chary, ale jeden codepoint.

--
Pozdrawiam
Zbyszek Malec

do góry