4-bajtowy Unicode
Borneq
cztery bjaty na znak; funkcje Windows używaja 2-bajtowego - jak użyć
4-bajtowego? chciaż z drugiej strony jesli się można jeszcze zgodzić żeby
każdy na znak używąc 2 bajtów to 4 bajty to za dużo. Jakie sa ograniczenia
2-bajtowego Unicodu? Czy dla każdego znaku istnieje jednoznacznie wskazanu
znak przy zamianie na duże lub małe litery? Jakie są ograniczenia
2-bajtowego w stosunku do 4-bajtowego - czy na 2-bajtowym nie można
przestawiać takich alfabetów jak chinski?
Czy w UTF-8 można przedstawić każdy znak z kodowania 4-bajtowego czy tylko
2-bajtowe?
AMX
Jestem tu przelotem więc coś napiszę, chociaż wypadałoby zajrzeć do
wikipedii.
> Na dwóch bajtach nie można przedstawić wszystkich znaków, czasem stosuje się
> cztery bjaty na znak; funkcje Windows używaja 2-bajtowego - jak użyć
> 4-bajtowego? chciaż z drugiej strony jesli się można jeszcze zgodzić żeby
> każdy na znak używąc 2 bajtów to 4 bajty to za dużo.
UTF-16 czyli dwubajtowe kodowanie znaków zawsze zajmuje 2 bajty i jak łatwo
policzyć daje możliwość przedstawienia 2^16-1 znaków. Jest to przesunięcie
ograniczeń 8bitowych znaków na 16bitów. Do tego paskudzi null bajta, który
od zarania dziejów (=:-)) był ogranicznikiem ciągu znaków.
UTF-8 jest kodowanie o _zmiennej_ długości od 1 do 4 bajtów. Daje tak dużo
możliwych znaków, że nie tylko wszystkie istniejące znaki się zmieszczą ale
również trochę nieistniejących (klingoński).
> Czy dla każdego znaku istnieje jednoznacznie wskazanu
> znak przy zamianie na duże lub małe litery?
Rozumiem, że pytasz czy różnią się o stałą.
Tak naprawdę nie wiem ale: w zakresie podstawowego ASCII (7bitów) utf-8
pokrywa się z ASCII ze wszelkimi końsekwencjami, duże małe litery i porządek
sortowania. Co jest dalej to śmiem wątpić czy tak to jest z przyczyn innej
natury. Greckie duże alfa to po prostu A. Porządek sortowania zaś tych
samych znaków w niemieckim i szwedzkim jest zupełnie inny.
Pozdrawiam wszytkich i przepraszam jeśli uchybiłem jakimś zwyczajom. (To się
więcej nie powtórzy.)
amx
\0
Marcin ‘Qrczak’ Kowalczyk
> Na dwóch bajtach nie można przedstawić wszystkich znaków, czasem stosuje się
> cztery bjaty na znak; funkcje Windows używaja 2-bajtowego - jak użyć
> 4-bajtowego?
Poczytaj o UTF-16. Znaki powyżej U+FFFF są w UTF-16 kodowane parą
znaków z zakresu U+D800...U+DFFF.
> Czy dla każdego znaku istnieje jednoznacznie wskazanu
> znak przy zamianie na duże lub małe litery?
Poprawna zamiana na duże albo małe litery w rzadkich sytuacjach jest
kontekstowa, czyli zależy od tego, jakie znaki sąsiadują (np. grecka Σ
jako mała litera ma postać ς na końcu wyrazu i σ w pozostałych
sytuacjach — te dwie postaci są kodowane osobno). W Unikodzie znaki
mają podstawowe odpowiedniki duża / mała / początkowa duża, a obok są
opisane dodatkowe reguły zależne od kontekstu albo w rzadkich
sytuacjach od języka (turecki, azerski i litewski dla kilku liter mają
inne reguły) albo kiedy odpowiednikiem jednego znaku jest ciąg kilku
znaków (po niemiecku zamiana ß na duże litery zwykle produkuje SS).
> Czy w UTF-8 można przedstawić każdy znak z kodowania 4-bajtowego czy tylko
> 2-bajtowe?
Każdy znak 4-bajtowego, czyli każdy do U+10FFFF (na tym Unikod się
kończy).
Arkadium
Użytkownik "AMX" <r-...@b2.cy> napisał w wiadomości
news:slrnga4agk...@amber.within.nat...
> On Wed, 13 Aug 2008 00:20:56 +0200, Borneq <bor...@antyspam.hidden.pl>
> wrote:
> UTF-16 czyli dwubajtowe kodowanie znaków zawsze zajmuje 2 bajty i jak
> łatwo
> policzyć daje możliwość przedstawienia 2^16-1 znaków. Jest to
> przesunięcie
> ograniczeń 8bitowych znaków na 16bitów. Do tego paskudzi null bajta,
> który
> od zarania dziejów (=:-)) był ogranicznikiem ciągu znaków.
>
pzdr. Arkadium
Borneq
> od zarania dziejów (=:-)) był ogranicznikiem ciągu znaków.
W ajki sposób poskudzi null?
Adam Kłobukowski
> UTF-8 jest kodowanie o _zmiennej_ długości od 1 do 4 bajtów. Daje tak dużo
> możliwych znaków, że nie tylko wszystkie istniejące znaki się zmieszczą ale
> również trochę nieistniejących (klingoński).
To że klingoński jest językiem sztucznie wymyślonym nie oznacza że nie
istnieje :P
Adam Klobukowski
grg12
"AMX" <r-...@b2.cy> schrieb im Newsbeitrag
news:slrnga4agk...@amber.within.nat...
> On Wed, 13 Aug 2008 00:20:56 +0200, Borneq <bor...@antyspam.hidden.pl>
> wrote:
>
>
>
> UTF-8 jest kodowanie o _zmiennej_ długości od 1 do 4 bajtów. Daje tak dużo
> możliwych znaków, że nie tylko wszystkie istniejące znaki się zmieszczą
> ale
> również trochę nieistniejących (klingoński).
>
Ja tak tylko w ramach ostrzezenia - bralem udzial w przenoszeniu starego
oprogramowania dzialajacego na zwyklych jednobajtowych znakach. Czysty C,
stringi w tablich char o statycznie deklarowanej dlugosci, zero zabezpieczen
przed zbyt dlugimi tekstami itp. potwornosci na unicode. UTF-8 zostal
wybrany bo "poprawny string UTF-8 jest tez poprawnym char-stringiem i nie
bedziemy musieli nic zmieniac w kodzie"... oj, dzialo sie... Programy
wyprawiajace cuda bo tekst z duza iloscia znakow diakrytycznych jest w UTF8
znacznie dluzszy od zwyklego i jakos tak nadpisywal stos, rozwalajace sie
formatowanie (strlen w UTF8 zwraca ilosc bajtow a nie znakow, a strlenUTF8 -
liter ale nie bajtow :) ) i wiele innych radosci. UTF32 wymagalby poczatkowo
znacznie wiekszych zmian w kodzie zeby sie go wogole dalo skompilowac - ale
przynajmniej potem by wszystko dzialalo... IMHO - jako wewnetrzna
reprezentacja tekstu w pamieci tylko kodowanie o stalej dlugosci znaku, UTF8
tylko do przesylu lub, ewentualnie, zapisu na dysku - no chyba ze tekstu
jest baaaardzo duzo a pamieci malo.
Pozdrawiam
GRG
Borneq
news:8576f$48a33748$506cdd75$19...@news.chello.at...
> przynajmniej potem by wszystko dzialalo... IMHO - jako wewnetrzna
> reprezentacja tekstu w pamieci tylko kodowanie o stalej dlugosci znaku,
> UTF8 tylko do przesylu lub, ewentualnie, zapisu na dysku - no chyba ze
> tekstu jest baaaardzo duzo a pamieci malo.
Kiedyś dwa bajty na znak było dla mnie rozrzutnością nie do pojęcia, teraz
zgodziłbym się na to korzystając z funkcji WIndows jak MultiByteToWideChar
(funckje te używają UTF-16 czy UCS-2 ?), ale 4 bajty na znak do już dla mnie
za dużo - jakich znaków nie potrafi obsłużyć UCS-2 ?
Pozdrawiam
Paweł Kierski
[...]
> Kiedyś dwa bajty na znak było dla mnie rozrzutnością nie do pojęcia, teraz
> zgodziłbym się na to korzystając z funkcji WIndows jak MultiByteToWideChar
> (funckje te używają UTF-16 czy UCS-2 ?), ale 4 bajty na znak do już dla mnie
> za dużo - jakich znaków nie potrafi obsłużyć UCS-2 ?
http://en.wikipedia.org/wiki/Basic_Multilingual_Plane#Supplementary_Multilingual_Plane
i poniżej
W sumie nigdy nie wiadomo, czy w twoim systemie ktoś nie będzie
chciał zapisać melodii "Góralu, czy ci nie żal" w starożytnym greckim
zapisie nutowym... 8-)
--
Paweł Kierski
ne...@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
Marcin ‘Qrczak’ Kowalczyk
> Kiedyś dwa bajty na znak było dla mnie rozrzutnością nie do pojęcia, teraz
> zgodziłbym się na to korzystając z funkcji WIndows jak MultiByteToWideChar
> (funckje te używają UTF-16 czy UCS-2 ?), ale 4 bajty na znak do już dla mnie
> za dużo
Ile tekstu naraz trzymasz w pamięci? Nie przejmuj się, tekst zwykle
stanowi mały ułamek danych.
Bronek Kozicki
> Na dwóch bajtach nie można przedstawić wszystkich znaków, czasem stosuje się
> cztery bjaty na znak; funkcje Windows używaja 2-bajtowego - jak użyć
> 4-bajtowego?
jeżeli potrzebujesz wykonać konwersję z UTF16 (kodowanie natywne systemu
operacyjnego Windows) na UTF32 (albo w drugą stronę), skorzystaj z
WideCharToMultiByte (albo MultiByteToWideChar) z identifikatorem strony
kodowej Unicode UCS-4 (12000 albo 12001, zależnie od "indianina"). Taka
konwersja ma sens tylko w operacjach wejścia/wyjścia.
B.
--
Remove -trap- when replying. Usun -trap- gdy odpisujesz.
Bronek Kozicki
http://www-128.ibm.com/developerworks/java/library/j-u-encode.html
Borneq
news:00651db1$0$32214$c3e...@news.astraweb.com...
> acha, znalazłem taką stronę na ten temat
> http://www-128.ibm.com/developerworks/java/library/j-u-encode.html
Dzięki za link, strona dobrze tłumaczy o kodowaniu ponad Basic Multilingual
Plane, jednak chyba Widnows tego nie obsługuje - nie udało mi sie
przekonwertować ro UCS-4 dając CodePage=12000.
Pozdrawiam
Borneq
news:g86ddg$kmn$1...@news.onet.pl...
> Dzięki za link, strona dobrze tłumaczy o kodowaniu ponad Basic
> Multilingual Plane, jednak chyba Widnows tego nie obsługuje - nie udało mi
> sie przekonwertować ro UCS-4 dając CodePage=12000.
Jednak może to zalezy od od instalacji Windowsa, na przykład Chińczycy mogą
korzystać ze znaków powyżej Basic Multilingual, przypominam sobie nawet że
przy instalacji Windows pytał czy obsługiwać języki w rodzaju chińskiego,
jednak do sprawdzenia tego potrzebna była by reinstalacja Widows, ciekawe
czy wtedy WideString oznaczałby łańcuch znaków róznej długości
Borneq
news:g86ddg$kmn$1...@news.onet.pl...
Niektóre rozszeroznego ponad BMP Uniocodu mogą zawierać pozycje prywatne:
"The UCS includes 137,468 code points for private use. This means these code
points can be assigned characters with specific properties by individuals,
organizations and software vendors outside the ISO and Unicode Consortium. A
Private Use Area (PUA) is one of several ranges which are reserved for
private use. For this range, the Unicode standard does not specify any
characters."
http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters#Private_use_characters
To niepokojące, bo znowu nie mamy jednoznaczności, powtarza się sytuacja ze
stronami kodowymi gdzie bajty z zakresu 128-255 miały różne znaczenie czy
mieliśmy stronę kodowa Latin2 czy też cyrylicę.
Piotr Wyderski
> Ile tekstu naraz trzymasz w pamięci?
Niestety u mnie są to setki megabajtów i więcej. Dlatego gdybym
musiał implementować unikodowego stringa, to wybrałbym właśnie
albo UTF8 albo reprezentację UCS-n o stałej szerokości z n
wyznaczanym osobno dla każdego stringa i zależnym od jego
zawartości. Skomplikowałoby to dość znacznie implementację,
ale by się opłacało: stosunkowo mało stringów zawiera znaki
narodowe (a już szczególnie mało z zestawu powyżej 2^16),
więc uzyskałbym dużą oszczędność pamięci i duże przyspieszenie
na SSE (dla ASCII teoretycznie 16-krotne, dla UCS-2 8-krotne
i 4-krotne dla UCS-4) oraz 2x powyższe na AVX.
> Nie przejmuj się, tekst zwykle stanowi mały ułamek danych.
Nie zawsze, niestety.
Pozdrawiam
Piotr Wyderski
Borneq
> jednak do sprawdzenia tego potrzebna była by reinstalacja Widows, ciekawe
> czy wtedy WideString oznaczałby łańcuch znaków róznej długości
Nadal konwersja o stronie kodowej 12000 nie działa.
Paweł Kierski
> Marcin 'Qrczak' Kowalczyk wrote:
>
> > Ile tekstu naraz trzymasz w pamięci?
>
> Niestety u mnie są to setki megabajtów i więcej. Dlatego gdybym
> musiał implementować unikodowego stringa, to wybrałbym właśnie
> albo UTF8 albo reprezentację UCS-n o stałej szerokości z n
> wyznaczanym osobno dla każdego stringa i zależnym od jego
> zawartości. Skomplikowałoby to dość znacznie implementację,
> ale by się opłacało: stosunkowo mało stringów zawiera znaki
> narodowe (a już szczególnie mało z zestawu powyżej 2^16),
> więc uzyskałbym dużą oszczędność pamięci i duże przyspieszenie
> na SSE (dla ASCII teoretycznie 16-krotne, dla UCS-2 8-krotne
> i 4-krotne dla UCS-4) oraz 2x powyższe na AVX.
Na unicode.org są referencyjne implementacje iteracji
dwukierunkowej. To powinno zaoszczędzić trochę roboty.
BobyX
> jeżeli potrzebujesz wykonać konwersję z UTF16 (kodowanie natywne systemu
> operacyjnego Windows) na UTF32 (albo w drugą stronę), skorzystaj z
Czy windows rzeczywiście obsługuje natywnie UTF-16, czy może tylko UCS-16?
Pozdrawiam,
BX
BobyX
> jeżeli potrzebujesz wykonać konwersję z UTF16 (kodowanie natywne systemu
> operacyjnego Windows) na UTF32 (albo w drugą stronę), skorzystaj z
Czy windows rzeczywiście obsługuje natywnie UTF-16, czy może tylko UCS-2?
Pozdrawiam,
BX