On Wed, 25 May 2011 01:13:02 +0200, Wiktor S. wrote:

> 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.

Ok, może być słowo. W każdym razie, jeżeli [] działa w danym api źle
(operuje na słowach, a nie na codepoint), to i pos i find też będzie
działało źle. Przynajmniej o ile api jest spójne. I o to mi chodzi z tą
niespójnością.

--
Pozdrawiam
Zbyszek Malec

do góry

>> 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"

zapewne w dosłownym znaczeniu, np. U+131A7 EGYPTIAN HIEROGLYPH L004

> 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.

i kto tu mówił o spójności...

jak więc proponujesz by POWINNA wyglądać obsługa znaków o 17- i więcej
bitowych codepointach?

--
Azarien

do góry

On Thu, 26 May 2011 07:26:45 +0200, Wiktor S. wrote:

> zapewne w dosłownym znaczeniu, np. U+131A7 EGYPTIAN HIEROGLYPH L004

Ok, najciemniej pod latarnią :]

>> 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.
>
> i kto tu mówił o spójności...

Spójność tu jest taka, że w String jest api do operowania na znakach i one
zawsze daje wyniki w znakach oraz jest api do operowania na code point i
ono zawsze daje wyniki w codepoint. Mamy tu do czynienia z dwoma api i one
wewnętrznie są spójne (w sensie albo zawsze char albo zawsze codepoint).

> jak więc proponujesz by POWINNA wyglądać obsługa znaków o 17- i więcej
> bitowych codepointach?

Ale w ogólności, czy jak to jest zrobione w javie?

--
Pozdrawiam
Zbyszek Malec

do góry