Forum PHP.pl

Witam

mam mały problem jestem zmuszony do wykorzystywania na jednej stronie znaków diakrytycznych wielu języków, problem w tym że w php mam z tym mały problem w poniższym kodzie

[PHP] pobierz, plaintext 
<?php session_start(); ?>
<meta name="test - blabla" http-equiv="content-type" content="text/html; charset=utf-8"/>
 
<?php
 
 
$a="gęś";
print "$a<br>"; // tutaj drukuje ok
for ( $i = 0 ; $i < strlen ($a) ; $i++ )
{
	print "{$a[$i]}<br>"; // a tutaj w miejsach znaków diakrytycznych wstawia dziwne znaczki
}
?>
[PHP] pobierz, plaintext 

a wynik jest taki:
gęś
g
�
�
�
�

od razu pwoiem ze strona kdoowa dla pliku jest ok i przeglądarka też dobrą rozpoznaje.

z góry dzięki za jakieś podpowiedzi co z tym zrobić

A z jakim kodowaniem zapisales plik php Powinienes w edytorze zapisac z plik z kodowaniem UTF-8

Ten post edytował NuLL 13.07.2006, 21:55:16

No cóż, jak widać, php ma problem z unicode i to wiadomo nie od dzisiaj. W taki sposób pobierasz po 8 bitów, a polskie znaki diakrytyczne są kodowane 16, co widać na przykładzie. Nic z tym w ten sposób nie zrobisz. Pokombinuj z iconv, które pozwala na wycinanie pojedynczych znaków z tekstu kodowanego na różne sposoby.

miałem na myśli że strona kdoowa dla pliku jest utf-8



to mie teraz zmartwiłeś na mojej stronce dość sporo razy pobieram dane z i do bazy i generalnie przeróbka z użyciem iconv będzie mie troche kosztowała czasu

Ten post edytował szymek116 13.07.2006, 22:01:39

To teraz Cię zmartwię jeszcze bardziej, bo z tego co mi wiadomo, wsparcie Unicode jest planowane w PHP6... Gdybyś kodował UTF-16, to by nie było problemu, bo każdy znak jest zapisywany zawsze w postaci dwóch bajtów. Mógłbyś pobierać to mniej więcej tak:

[PHP] pobierz, plaintext 
<?php
for ( $i = 0 ; $i < strlen ($a) / 2 ; $i++ ) {
	print substr($a, $i*2, 2) . "<br>"; // a tutaj w miejsach znaków diakrytycznych wstawia dziwne znaczki
}
?>
[PHP] pobierz, plaintext 

no dobra wstawiłem twój kod ale po przekonwertowaniu pliku na utf-16 wygląda na to że przęglądarka (firefox 1.5.0.3) tak jak by nie widziała treści strony tzn w źródle nic nie ma, co z tym może być ?

a i jeszcze trzy pytania:
1. utf-16 to jest 8 plus rozszerzenie o znaki chińskie ?
2. kiedy jest planowane php 6 ?
3. czy mysql obsługuje utf-16 ?

[PHP] pobierz, plaintext 
<?php
 
mb_internal_encoding("UTF-8");
 
$a="gęś";
 
for ( $i = 0 ; $i < mb_strlen ($a) ; $i++ )
{
   $char = mb_substr($a, $i, 1) 
   print "{$char}<br>"; 
}
 
?>
[PHP] pobierz, plaintext 

Powinno zadziałać. IMHO nie używaj iconv'a - iconv nie radzi sobie ze znakami (np. Wordowymi cudzysłowami) i przy konwersji z UTF na ISO obcina tekst w miejscu gdzie taki niestandardowy znak występuje... Lepiej już użyć SET NAMES latin2 przed wyciagnieciem czegokolwiek z bazy - MySQL przynajmniej w takim przypadku wstawia znak zapytania ale caly tekst sie pokazuje (nie jest obcinany).

Ogólna rada, żebyś lepiej takie czynności jak przycinanie tekstu itp. wykonywał za pomoca SQLa i pobierał juz z niego gotowe dane - tak jest proscie a MySQL np. bardzo dobrze sobie radzi z UTFem.

Nie używaj UTF-16! W tej chwili wsparcie dla tego kodowania jest slabe!

Ten post edytował dooshek 13.07.2006, 22:28:48

wiesz co jak cie kiedyś spotkam masz u mie browara WIELKIE DZIĘKI

Ad 1. UTF-16 działa zupełnie inaczej. Koduje znaki zawsze przy pomocy 2 bajtów. UTF-8 używa zmiennej ilości, chyba od 1-6 bajtów, więc ma większy zakres znaków. Znaków chińskich chyba nie obsługuje. Ostatecznie jest UTF-32, które zwiększa rozmiar czterokrotnie... Mimo wszystko bym się skłaniał ku iconv. Konwersji za dużo nie będzie, za to niektóre operacje na stringach wykonujesz przy pomocy innych funkcji i tyle.
Ad 2. Nie orientuję się. Jedyne co mogę powiedzieć, to że poczekamy jeszcze trochę zanim wypuszczą stabilną wersję. Oczywiście od razu na serwerach się nie pojawi...
Ad 3. Nie piszą o UTF-16, ale wspomnieli o UCS-2, który jest podobny. Nie wiem czy identyczny.

Co do firefoxa, to nie mam pojęcia...

U mnie zasadniczo UTF-8 sprawuję się doskonale, nie mam problemu. Być może problem leży po stronei edytora?

Może od razu UTF-64. Zanim zaczniesz dalej szerzyć swoje mądrości zastanów się, poczytaj i jeszcze raz napisz ten post. UTF8 jest używane szeroko w świecie, UTF16 spotyka się w takich krajach jak Chiny czy Japonia, z UTF32 jeszcze się nie spotkałem.

UTF-16 to standard bo jest najwygodniejszym kodowaniem Unicode dla BMP (w palecie tej jest kodowaniem o stałej długości w przeciwieństwie do UTF-8) i to ono jest właśnie szeroko stosowane w świecie. UTF-8 to głównie strony WWW (w sumie to nie wiem czemu właśnie ono, a nie 16-bitowa wersja). UTF-32 jest jedynym kodowaniem o stałej długości znaku dla całej palety Unicode, a gdzie jest stosowane? Na Wiki pewnie będzie.

UTF8 jest wstecznie zgodne z ASCII, UTF16 i powyższe już raczej nie. Myślę że właśnie dlatego jest stosowane dla WWW. Co do tego UTF16 to rzeczywiście - aż mnie to zdziwiło że XPek już to stosuje - ale racja po twojej stronie

W każdym kodowaniu Unikode (czyli m.in. UTF-8) da się zapisać każdy znak Unikodu, a Unikod sam w sobie zawiera właściwie wszystkie znaki używane do komunikacji na Ziemii. Tak więc jakieś głupoty wypisujesz @InnoDB (pomijając fakt, że ledwo da się Ciebie zrozumieć).

Proponuję się najpierw douczyć: http://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings

@InnoDB
Z tego co pamiętam to tobie chodziło o sposób składowania jakiś wielojęzycznych wierszy (może mi się miesza, dużo tego przewija się na forum). W takim wypadku najsensowniej byłoby składować po stronie bazy jako UTF-16 a serwować przeglądarce jako UTF-8. Wszystko rozbija się o zajętość. W bazie i tak będziesz składował wszystkie wersje a można założyć że większość użytkowników będzie się posługiwać alfabetem łacińskim lub pochodnymi - więc zaoszczędzisz trochę na łączu.