Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Kodowanie
Forum PHP.pl > Forum > Przedszkole
ziutek
20.07.2006, 13:47:11
Witam.

Bardzo wiele problemów przy pracy stwarzają polskie ogonki. Oczywiście, niektórzy z nich rezygnują, ale niestety nie wszyscy. Chciałbym zebrać garść porad odnośnie tego problemu. Może ja zacznę, jeśli pisze głupoty - proszę o poprawę.

Zwykły html i polskie znaki, wystarczy dodać w sekcji <head> odpowiedni znacznik <meta>:

[HTML] pobierz, plaintext 
  1. <meta http-equiv="content-type" content="text/html; charset=iso-8859-2" />
[HTML] pobierz, plaintext

wówczas wszystkie nasze ąćęłńóśźż wyświetlane są poprawnie. Jeśli kod to czysty HTML, problemów raczej nikomu to nie sprawia.

Ale problemy pojawiają się, gdy zaczynamy dodawać do tego php. Bardzo często zdarza się, że wówczas (np. używając szablonów Smarty, czy też podczas wysyłania maili - zarówno w formacie HTML jak i textowym) polskie znaki zamieniają się w krzaczki. Co więc należy zrobić w przypadku np. Smarty, żeby te polskie znaki pojawiały się? Sam meta tag nie wystarcza, jeśli ktoś nie wierzy, mogę pokazać przykład. To samo tyczy się wysyłania maili funkcją mail().
Istnieje oczywiście np. iconv(), ale czy to jedyne wyjście?

A jeszcze więcej problemów pojawia się, kiedy przyjdzie nam korzystać z MySQL (sam niejednokrotnie robiąc backupa bazy poprzez phpmyadmina zamiast polskich znaków, dostałem krzaczki - a problem nie pojawia się tylko przy backupie).

Z przeczytanych postów gdzieniegdzie informacji wnioskuje, że aby polskie znaki chodziły wszędzie tak, jak należy, kodowanie zarówno HTML, jak i php i MySQL powinno być takie samo.

Jak zrobić? W niektórych momentach naprawdę już człowiek nie ma siły szukać, a być może ktoś już przez te problemy przebrnął i ma jakiś skuteczny na to sposób.
strife
20.07.2006, 16:36:50
Witaj,

Zrezygnuj z ISO-8859-2 i koduj znaki w UTF-8. To po pierwsze, a po drugie to wszystkie znaki dodane do dokumentu muszą być zapisane właśnie w takim kodowaniu, aby było poprawnie wyświetlane ( edytor PsPAD ma taką opcję, ale nie tylko, zobacz temat o edytorach do php ).

Jeżeli chodzi o samo php to tutaj, jeżeli nagłowek jest poprawny czyli UTF-8 to znaki są kodowane właśnie w nim. Ewentulanie, jeżeli nadal nie masz polskich znaków, a w samym html'u masz poprawne kodowanie ustawione to możesz dodać surowy nagłowek ( header" title="Zobacz w manualu php" target="_manual ) ... Ja osobiście problemów z polskimi znakami nie miałem nigdy, oprócz konwersji baz mysql.

Jeżeli masz jakiś konkretny problem to podaj kod, to pomożemy/wyjaśnimy smile.gif

Pozdrawiam!


» Zobacz również
- Najczęstsze błędy, pkt 4
mariuszn3
20.07.2006, 16:39:57
Przede wszystkim problemem nie są żadne ogonki tylko kodowanie znaków przyjmowane przez edytor i/lub przez program w którym odbiorca ogląda dokument..
Są dwie rzeczy o których trzeba pamiętać pierwsza to upewnić się, że edytor, w którym piszemy faktycznie zapisuje dane w kodowaniu w jakim chcemy by zapisywał.. druga rzecz by odbiorca wraz z dokumentem dostał informację o tym w jakim kodowaniu jest dany dokument. To wszystko koniec kropka.
Snoopy
20.07.2006, 19:02:45
Więc jak chcesz poważnie pisać stronki to daruj sobie Notepad'a biggrin.gif

Polecam TigerII MiniPad, nie jest to kombajn ale w zupełności wystarczy, no i możesz sobie wybrać kodowanie.

Ja mam takie pytanie.

w mysql'u mam dane zapisane w UTF-8 a pliki w iso-8859-2, wszystko jest ok i dane zapisywane do bazy jak i odczytywane są poprawnie, ale czy jest to poprawne jeśli chodzi o normy i standardy ?
mariuszn3
20.07.2006, 19:08:02
Raczej nie poprawne.. domyślam się, że mysql nie wie w jakim kodowaniu mu wysyłasz dane. Problem się pojawi wtedy gdy będziesz chciał pobrać dane z bazy jakimś innym wynalazkiem pracującym w innym kodowaniu.. Dopóki będziesz działał tylko mysql <-> php nie zauważysz żadnego problemu
Snoopy
20.07.2006, 21:39:16
hmm trochę mnie to przerasta

1. Pliki .php i .html mam kodowane w iso-8859-2
2. Przy wchodzeniu w phpMyAdmin pisze:
System kodowania znaków dla MySQL: UTF-8 Unicode (utf8)
oraz
System porównań dla połączenia MySQL: utf8_unicode_ci
3. Natomiast pola w tabelach mam:
Metoda porównywania napisów: utf8_polish_ci

I teraz juz nic nie rozumiem... phpMyAdmina sam instalowałem więc mogłem coś popieprzyć, już czuję przez monitor te podśmiechujki. No ale tak juz jest biggrin.gif

Co powinienem zmienić żeby było tak jak być powinno. Przekodowywanie plików trochę zajmie, bazę mam dosyć małą więc jak by wyskoczyły tam jakieś syfy to nie było by to takim problemem.
mariuszn3
20.07.2006, 21:55:52
To, że masz bazę w innym kodowaniu i w innym pliki php nie jest żadnym problemem pod warunkiem, że serwer MySQL zdaje sobie z tego sprawę smile.gif
W php upewnij się, że pierwsza rzecz jaką wysyłasz po połaczeniu z bazą jest informacja o kodowaniu czyli w Twoim przypadku:
[SQL] pobierz, plaintext 
  1. SET NAMES 'latin2'
[SQL] pobierz, plaintext

To wszystko, teraz MySQL wie, że to co dostaje z php jest w tym kodowaniu i w takim też kodowaniu będzie Ci zwracał dane. Nie ma tu już znaczenia jakie kodowanie masz ustawione w tabelach. Jeśli jest inne sam serwer MySQL będzie konwertował dane które przyjmuje i które wysyła.. tak by się nic nie gryzło. (znaczy - nie ma znaczenia dopóki wysyłasz dane ze znakami, które kodowanie ustawione w tabeli zawiera.. jeśli jest inaczej to będzie kaszana).
Jak wyślesz tą informację o kodowaniu to wyjdzie szydło z worka.. smile.gif Jeśli dotychczas MySQL przyjmował, że przesyłasz mu dane w innym kodowaniu.. to te dane, które wtedy dodałeś MySQL teraz (na ślepo konwertując do latin2) zacznie zwracać z krzaczkami smile.gif

A odnośnie phpMyAdmin'a to myślę, że te ustawienia dotyczą tylko jego interfejsu. To znaczy - w jakim kodowaniu chcesz by phpMyAdmin pracował.. (phpMyAdmin potem wysyła informacje do mySQL, że chce otrzymywać dane w danym kodowaniu i w takim też je będzie wysyłał i sam też informuje przeglądarkę, że objawia się w tym kodowaniu).. System porównań wiadomo dotyczy tylko alfabetycznego sortowania.. czyli jesli będziesz chciał mieć rekordy poukładane alfabetycznie według jakiego pola, to to ustawienie określa według jakiego klucza będzie przyjęta kolejność (kluczem zazwyczaj są różne języki.. czyli jak wybierzesz polski.. to 'ą' będzie po 'a' a nie po 'z')
Nostress
20.07.2006, 22:43:15
To może i ja się czegoś dowiem. Wspominane tu było o wysyłaniu maila i problemie polskich znaków nim. Jak to wysyłać tak, żeby tych problemów nie było? Mam przykładową stronę, zawierającą formularz (pola temat, treść i submit) oraz strona zapisana (w PsPadzie) przy kodowaniu utf-8 oraz meta tag z utf-8.

Po kliknięciu na submit wysyła maila do dwóch adresatów: jeden ma poczte na poczta.fm, drugi na gmail.com. W obu przypadkach w temacie i treści wpisuje wszystkie polskie znaki. Co się okazuje? Że na gmail.com znaczki interpretowane są dobrze, zaś na poczta.fm wyskakują tylko i wyłącznie krzaczki. Czy można coś z tym zrobić?

Kod za to odpowiedzialny:

[PHP] pobierz, plaintext 
  1. <?php
  2.  
  3. if( $_POST['temat'] != '' )
  4. {
  5. 	$header .= "From: mail@example.comn";
  6. 	$header .= "Content-Transfer-Encoding: 8bitn";
  7. 	$header .= "MIME-Version: 1.0n";
  8. 	$header .= "Content-type: text/html; charset=utf-8n"; 
  9.  
  10. 	mail( 'mail@poczta.fm,mail@gmail.com', $_POST['temat'], $_POST['tresc'], $header );
  11. }
  12.  
  13. ?>
  14.  
  15. //tutaj kod html strony, włączając meta tag z kodowaniem utf-8
[PHP] pobierz, plaintext
mariuszn3
20.07.2006, 23:13:08
Najprawdopodobniej poczta.fm ma gdzieś kodowanie znaków i nie sprawdza kodowania w jakim wiadomość została wysłana.. po prostu binarnie przerzuca treść na ekran a że sama pracuje w kodowaniu ISO-8859-2 to mail wysłany w utf-8 pokazuje krzaczki. Rozumiem, że chodzi o to jak to wygląda na stronie poczta.fm, myślę, że jeśli odbiorca będzie odbierał wiadomość przez jakiegoś klienta poczty na komputerze, który już będzie respektował informacje o kodowaniu to nie będzie tego problemu.
Gmail nawet nie musi sprawdzać kodowania by dobrze pokazać tę wiadomość, bo sam pracuje w utf-8.
Gdzieś czytałem, że właśnie w przypadku maili lepiej pozostać przy iso, bo jeszcze w użyciu jest wiele klientów, które ignorują informacje o kodowaniu i wszystko przyjmują jako iso i to jest dobry przykład do tej tezy.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.