jeśli wszystko na stronie działa normalnie, to nie musisz nic kombinować, jedynym błędem będą właśnie krzaki w phpmyadminie, dane wprowadzane przez phpmyadmina też mogą być później źle wyświetlane na stronie...

w praktyce, żeby wszystko działało jak należy, na stronie powinno być dokładnie takie samo kodowanie, jakie są ustawienia dla bazy, czyli jeśli na stronie masz iso-8895-2, to dla bazy powinno być ustawione kodowanie latin2... z tym, że to też nie takie proste zmienić po prostu kodowanie, bo wtedy pojawią się znaki zapytania w zapisach bazy, musisz to zrobić po kolei, np. tak jak opisywałem w poprzednich postach

Rowniez mam problem z krzakami, wiec sie dolacze...

Zalozylem sobie ambitny plan - zrobienie strony w 3 jezykach w 95% na bazie MySQL i w UTF8. Wszystkie podstrony i caly panel administracyjny maja charset=UTF-8. Baza danych jest ustawiona na utf8_unicode_ci (moge przestawic na utf8_general_ci ale tak i tak jest lipa).

Strona i baza stoja na hostingu - linux i MySQL 4.1.x

Po dodaniu tekstu z polskimi znakami, na stronie wyswietlaja mi sie krzaki w czesci liter ogoniastych. Tak samo w panelu przy edycji. Probowalem deklarowac kodowanie przy zakladaniu tabel w bazie: TYPE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;

Dodalem do skryptow dwie rzeczy:
na poczatku:



i po polaczeniu z baza:



Wciaz nie smiga a ja jestem w lesie. Strona ma wersje jezykowe PL, EN, DE, wszystkie jezyki sa zapisywane obok siebie w komorkach tabeli, np.



Formularze zrobilem na takiej zasadzie, ze przed dodaniem do bazy wpisuje sie wszystkie wersje jezykowe w jednym formularzu, analogicznie jak w sklepach opartych na oscommerce.

Po wielu eksperymentach, wciąż mam krzaki w części znaków.

Ma ktos patent jak to ustawic zeby smigalo bezproblemowo z trzema jezykami i bez krzakow?
Jaka odmiana kodowania UTF8 dla bazy (utf8_unicode_ci czy utf8_general_ci), jaki system porownan dla tabel i co dodac do skryptow php przed odczytem, dodaniem czy zmiana danych w bazie?

to chyba oczywiste, ale na wszelki wypadek zapytam...

oczywiście na stronie masz w meta ustawionych charset utf8?



to tylko systemy porównań (z tego co się orientuję), kodowanie i tak jest utf8, więc to raczej bez znaczenia


jeśli chodzi o zapytanie wysyłane po połączeniu z bazą to raczej powinno być:

[PHP] pobierz, plaintext 
<?php
mysql_query("set names 'utf8'");
?>
[PHP] pobierz, plaintext 

chyba to powinno wystarczyć... jeśli nie, to albo nie wszystkie kolumny mają ustawione kodowanie utf8, ustawienie ogólne dla bazy nie jest utf8, albo coś na samej stronie jest nie tak... nic więcej mi do głowy nie przychodzi

WereWolf:

dzięki za info. set names też przerabiałem, oczywiście, strona ma w meta utf-8.

założę bazę od nowa i pokatuję ponownie "set names".

edit:
cóż, nie do końca pomogło. mam set names, set character set. strona i baza w UTF8, tabela testowa w UTF8...
wszystkie ogoniaste poza "ń" są OK. duże Ń też jest ok... fajnie.

a gdzie konkretnie masz ten problem?

1. wyświetlanie "statycznych" tekstów na stronie
2. wyświetlanie tekstów z bazy:
- wyświetlanie pobranych tekstów z bazy na stronie
- wyświetlanie tekstu z bazy przez phpmyadmina?

Ja swój problem rozwiązałem wszędzie deklarując iso-8859-2 / latin2-general-ci

1. phpMyAdmin - 2.9.1.1

phpMyAdmin/index.php (linijka 98)

[PHP] pobierz, plaintext 
<?php
lang_iso_code = 'pl-iso-8859-2';
?>
[PHP] pobierz, plaintext 

phpMyAdmin/librares/config.default.php

[PHP] pobierz, plaintext 
<?php
// linijka 392
	  $cfg['DefaultLang'] = 'pl-iso-8859-2';
 
// linijka 395
	  $cfg['DefaultConnectionCollation'] = 'latin2_general_ci';
 
// linijka 400
	  $cfg['Lang']	 = 'pl-iso-8859-2';
 
// linijka 404
	  $cfg['FilterLanguages'] = '';
 
// linijka 409
	  $cfg['DefaultCharset'] = 'iso-8859-2';
?>
[PHP] pobierz, plaintext 

2. MySQL 5.0.22 (my.ini):

Kod

[client]
  default-character-set=latin2
[mysql]
  default-character-set=latin2
[mysqld]
  default-character-set=latin2

3. Apache/2.0.59 (Win32) (httpd.conf)

Kod

AddDefaultCharset ISO-8859-2

4. na stronie (index.php) oczywiście :

Kod

mysql_query ("SET NAMES latin2");
mysql_query (" SET collation_connection = latin2_general_ci ");

// oraz

[HTML] pobierz, plaintext 
<html xml:lang="pl" lang="pl" xmlns="http://www.w3.org/1999/xhtml">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" />
[HTML] pobierz, plaintext 

Z takiej konfiguracji eksportowałem już na serwer przez phpMyAdmin 2.7.0-pl2 ( MySQL 4.1 ) z ustawieniem "System porównań dla połączenia MySQL: latin2_general_ci" i jakiś inny serwer z utf8. Bezproblemowo się importowało i później eksportowało z tych serwerów.

Wszystko działa pięknie i wspaniale. Przy imporcie trzeba tylko zaznaczyć "Zestaw znaków dla pliku latin2", coby nie stracić ogonków. W strukturze bazy każdą kolumnę typu char/text mam z metodą porównywania latin2_genere_ci.


Stronę miałem wcześniej w ISO-8859-2. Kiedy podzieliłem ją na podstrony wstawiane przez funkcje reqiue_once () index.php został w tym kodowaniu, natomiast podstrony zapisywały się w WINDOWS-1250. To rozwiązał program Gżegżółka XP w kilka sekund. Więc strony miałem już czyste.

W PMA nie wyświetlają się żadne zbędne krzaki, można spokojnie dodawać i edytować rekordy.
Jedyny problem na jaki się napotkałem to PMA zmieniał literkę " ó " na "& oacute;". Tzn. w takiej formie zapisywał do bazy, ale na stronie było już " ó ". Tymczasowo rozwiązałem to przy odczycie z bazy funkcją ...

[PHP] pobierz, plaintext 
<?php
$zmienna = str_replace ( "& oacute;" , "ó" ,  $zmienna );
?>
[PHP] pobierz, plaintext 

... ale kombinuje dalej czemu wstawia się tak a nie tak jak być powinno. Macie może pomysły?

P.S.
Aha tak w sumie to witam wszystkich bo to mój pierwszy post na tym forum :]
Mam nadzieję że komuś się może przydać mój conig.

Pozdrawiam

hmm... a to ciekawe, z tym się nie spotkałem

a zamieniane jest to tylko przy wprowadzaniu danych przez PMA, czy przez formularze na stronie też?
jeśli tylko przez PMA, to pewnie wina samego engine'u PMA... ale w niego się nie zagłębiałem, więc nie wiem ogólnie używam go tylko do przeglądania danych od czasu do czasu (raczej rzadko), ewentualnie do poprawienia czegoś na szybko, albo wyszukania jakichś danych... wolę konsolę, ale nie zawsze jest do niej dostęp

przez formularze też zamienia, zapomniałem tego dodać, gdyby zamieniał tylko przy wprowadzaniu danych z PMA to bym się tym tak nie przejmował, jak narazie to mój jedyny mankament

wnioskuje że to coś związane z kodowaniem samego MySQLa

mysle ze powinno sie skorzystac z tego:
http://dev.mysql.com/doc/refman/5.0/en/charset-convert.html

tyle ze mam maly problem z zastosowaniem:

[SQL] pobierz, plaintext 
SELECT CONVERT(_latin1'Müller' USING utf8);
INSERT INTO utf8table (utf8column)
    SELECT CONVERT(latin1field USING utf8) FROM latin1table;
[SQL] pobierz, plaintext 

nie rozumiem co wstawic za _latin1'Muller'

wogole co oznacza co w tym zapytaniu??

z tego co rozumiem:
CONVERT - nazwa funkcji
_latin1 - użyj kodowania _latin1 (traktuje tekst jako kodowany w latin1, nie zważając na domyślne ustawienia, albo ustawienia typu "set names")
'Muller' - tekst, ktory ma zmienic
USING - wiadomo
utf8 - kodowanie wyjściowe

w drugim wstawia do kolumny utf8column (jak przypuszczam ustawionej na utf8), konwertując w locie komórkę latin1field przy użyciu utf8 z tabeli latin1table...

nawet jeśli to działa tak jak ma działać, to jakoś nie jestem do tej metody przekonany
powinno być raczej wszystko poustawiane tak jak miało być, czyli wszędzie jedno kodowanie - strona, ustawienia tabeli i w razie konieczności (jeśli serwer ma ustawione inne domyślnie używane kodowanie) - dodane po połączeniu z bazą zapytanie "set names 'kodowanie'", zwłaszcza, że zapytania typu _latin1'tekst' raczej nie są stworzone do takich zastosowań, a raczej do pojedynczych przypadków

druga sprawa... przy takiej metodzie, przy każdym zapytaniu do bazy następuje jakaś tam konwersja znaków - a to zawsze trochę trwa, przy niewielkiej stronie pewnie można by to pominąć, ale przy większej ilości zapytań już wzrasta obciążenie serwera

dokładnie ! taka metoda odpada

a ja już częściowo rozwiązałem problem,
- eksportowałem całą bazę,
- podmieniłem wszystkie wystąpienia "& oacute;" na normalne "ó" w pajączku,
- przeinstalowałem, MySQLa i phpmyadmin, wszystkie konfigi tak jak powyżej podałem,
- tylko w phpMyAdmin/librares/config.default.php zakomentowałem linijke $cfg['Lang'] = 'pl-iso-8859-2';
- import
teraz już normalnie, zarówno pma wstawia/edytuje "ó" jak i zwykły formularz text/textarea również,
problem pozostał tylko w formularzach wysiwyg (konkretnie to TinyMCE) , ale to już temat na inną bajkę i chyba wiem gdzie się to zmieniało

Witam

Jest to mój pierwszy post na tym forum więc witam gorąco,
niestety mam podobny problem, próbowałem rozwiązać go
powyższymi sposobami, ale niestety zonk, a do plików Apache,
mySQL itp. nie mam dostępu.

Po pierwsze, mam dwie wersje bazy danych w postaci (fragment)
a) normalne polskie znaki

[SQL] pobierz, plaintext 
INSERT INTO `kategoria` VALUES (1, 'Aktualności', 1, 1);
[SQL] pobierz, plaintext 

kodowane znaki czyli ¶, ±, ľ itp.

[SQL] pobierz, plaintext 
INSERT INTO `kategoria` VALUES (1, 'Aktualności', 1, 1);
[SQL] pobierz, plaintext 

Z którym plikiem bazy danych mam się "bawić"?

Mój cel to kodowanie iso, metodę porównywania znaków mam ustawione
na latin2_general_ci, w projekcie tabeli:

[SQL] pobierz, plaintext 
DEFAULT CHARSET=latin2
[SQL] pobierz, plaintext 

No i mam znaki ? ? ? po imporcie na serwerze :/
Jakieś pomysły, po zmianie na binary wszystko cyka,
ale jak wrócę na np. varchar znów to samo.

Mam podobny problem jak opisane powyżej z tą różnicą, że jak wchodze do myphpadmin i przeglądam dane z bazy to wszystko jest OK
Ale jak strona próbuje pobrać te same dane z bazy to większość poskich znaków zamienia się na znaki zapytania

"...Zespó? powsta? w Sopocie na prze?omie 1993/94 roku. Przez ten czas, wspó?pracowa? z ró?nymi muzykami zbieraj?c nowe do?wiadczenia. ..."

kod strony wygląda następująco

plik ./inc/common.php'

<?php
function db_connect()
{
@$link_id= mysql_connect("localhost","user","pass");
if(!$link_id)
{
return false;
}
if(!mysql_select_db("nazwa_bazy"))
{
return false;
}
return $link_id;
}
?>

plik index.php

<?php include('./inc/common.php');
$link_id=db_connect();
if(!$link_id) return "brak poł&plusmn;czneia z baz&plusmn;";
$sql = 'SELECT * FROM `program` WHERE ( `data` = \'2005-01-28\' )';
$wynik_pobierz=mysql_query($sql);
while($dane_pobierz=mysql_fetch_array($wynik_pobierz)){
$data_program=$dane_pobierz["data"];
$data_program=strtotime($data_program); //zamienia na formayt uniksowy
$data_program=date("d-m-Y",$data_program); // konweruje w formacjie d-m-r
$tytul_program=$dane_pobierz["tytul"];
$tytul_program=stripslashes($tytul_program);
$opis_program=$dane_pobierz["caly"];

echo "<table>";
echo"<tr><td><B>$data_program</b></td></tr>";
echo "<tr><td>$tytul_program</td></tr>";
echo "<tr><td>$opis_program</td></tr>";
}
?>

to wszystko jest odpalone na debianie , co mogę zrobić, żeby normalnie odczytywać znaki polskie na stronie??

dwa pytania:
1. czy masz na samej stronie w htmlu ustawione informacje o kodowaniu znaków? (meta)
2. w jakim kodowaniu masz dane w bazie? jeśli w phpmyadminie wszystko wyświetla się poprawnie, to podejrzewam, że wystarczy dodać zapytanie przy łączeniu się z bazą danych - o tym było już wcześniej... np. jeśli dane są w iso-8895-2, to po mysql_connect dodaj: mysql_query("set names latin2")

Witam!

A ja mam problem taki że nie wiem jak wstawiać polskie znaki do bazy przez stronę www. Wszsystkie ustawienia mam na latin2 i iso-8859-2. Ustawienia Apache 2.0.59, PHP 5.1.6, phpMyAdmin-2.9.2, i MySQL 5.x mam takie jak podał kolega @woodzu.

W index.php mam następujący przykładowy kod:

[PHP] pobierz, plaintext 
...
<html xml:lang="pl" lang="pl" xmlns="http://www.w3.org/1999/xhtml">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" />
...
 
<?php
$db = new mysqli('localhost', 'root', '***', 'ZSRDB');
db -> query('SET CHARACTER SET latin2');
db -> query('SET collation_connection = latin2_general_ci');
$db -> query("insert into ogloszenia (TYTUL, TRESC, AUTOR, TYP) values ('tytul', 'żźćąęół', 'autor', 1)");
$zapytanie = "select * from Ogloszenia";
$wynik = $db -> query($zapytanie);
$wiersz = $wynik -> fetch_assoc();
echo $wiersz['TRESC'];
?>
[PHP] pobierz, plaintext 

Kiedy wstawiam dane do bazy przy użyciu poniższej instrukcji z poziomu index.php

[PHP] pobierz, plaintext 
<?php
$db -> query("insert into ogloszenia (TYTUL, TRESC, AUTOR, TYP) values ('tytul', 'żźćąęół', 'autor', 1)");
?>
[PHP] pobierz, plaintext 

po ich wyświetleniu w tym samym skrypcie zamiast kogonków są krzaki.

Kiedy wstawię te same dane przy użyciu phpMyAdmin-2.9.2 po ich wyświetleniu w index.php tekst jest normalny, czyli ogonki są.

Proszę o pomoc w odpowiedzi na pytanie jak wstawiać do bazy dane przy użyciu formularza www, ewentualnie bezpośrednio ze skryptu php aby po ich wyświetleniu nie zgubiły się ogonki.

daj takie cos przed dodaniem i przed wyciaganiem danych z bazy

[PHP] pobierz, plaintext 
<?php
$db->query("set names 'iso-8859-2");
?>
[PHP] pobierz, plaintext 

powinno pomóc, mi zawsze działa z tym ze nie stosuje iso od dawno. Polecam utf-8 mniej klopotów

widze, ze połączenie masz na clasach, wię ja bym do classy łączącej się z bazą dał takie coś

[PHP] pobierz, plaintext 
<?php
mysql_query('SET character_set_connection=latin2', $this->connection_id);
mysql_query('SET character_set_client=latin2', $this->connection_id);
mysql_query('SET character_set_results=latin2', $this->connection_id);
mysql_query('set names latin2;');
?>
[PHP] pobierz, plaintext 

zaraz po nawiązaniu połączenia z bazą,wtedy od razu odpada ci wszelkie dodatkowe zapytania, pamiętanie o nich itp

Aby nie tworzyć nowego tematu, dołączę pytanie tutaj.

Zaktualizowałem pakiet WebServ - więc PHP z 5.1.5 nad 5.2.3 i MySQL z 4 na 5. Teraz w przeglądarce nie wyświetlają się polskie znaki w pobranych danych z bazy. Aktualizacja rekordów z poziomu PHP też nic nie daje. MySQL 5 dodatkowo jeszcze posiada mechanizm porównywania znaków.

Fragment my.ini:

Zmienne MySQL:
Pozostałe zmienne - collation_* i character_set_* (opr. _filesystem = binary) mają wartość LATIN2.

Tabele również mają kodowanie latin2, lecz nie mogą zapamiętać porównania znaków (ustawiam latin2_general_ci, nie ma polish_ci), chyba że MySQL-Front po prostu ich nie odczytuje.

Pomaga dopiero poniższe zapytanie wywołane po rozpoczęciu połączenia:
Tylko dla nowo wprowadzonych danych.

Czym to jest spowodowane? Nieprawidłową konwersją bazy danych? Czy da się ten problem ominąć bez dodatkowego zapytania, czy w skryptach dla MySQL 5 to raczej standard? A może lepiej postawić na UTF?

Niedawno odkryłem cudowne rozwiązanie na wszelkie problemy związane z kodowaniem. Czasami zdarza się, że mimo wpisania wszystkich ustawień w plikach konfiguracyjnych nadal mamy krzaczki, ew. musimy przed każdym zapytaniem ustawiać CHARACTER SET. Ten wpis w my.ini załatwia większość problemów:

Witam,

Odgrzewam temat bo mam spory problem, otóż,
<span style="font-weight: bold;"><a href="http://pl.php.net/baza mysql z której eksportuje ma:character set client utf8character set connection utf8character set database utf8character set filesystem binarycharacter set results utf8character set server utf8character set system utf8character sets dir C:\Dev\MySQL\share\charsets\collation connection utf8_general_cicollation database utf8_general_cicollation server utf8_general_ci" title="Zobacz w manualu PHP" target="_manual">baza mysql z której eksportuje ma:
character set client utf8
character set connection utf8
character set database utf8
character set filesystem binary
character set results utf8
character set server utf8
character set system utf8
character sets dir C:\Dev\MySQL\share\charsets\
collation connection utf8_general_ci
collation database utf8_general_ci
collation server utf8_general_ci</a></span>
niby wszystko ok, tabele mają:

[SQL] pobierz, plaintext 
CREATE TABLE `classes_fields` (
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
[SQL] pobierz, plaintext 

i nie zależnie od tego, z czego robie dump'a (mysqdump, phpmyadmin, mysql administrator) wali takimi o to krzakami:Aktualność , Treść, NagĹ‚Ăłwek.
Jak otworze plik dump.sql poprzez notatnik to widzę kodowanie pliku ładnie UTF-8.

Dodam, że serwer http (po drodze żadnej konwersji nie ma) na localhoście wyświetla pięknie utf-8 bez krzaków. Tylko w dumpie są.

Może jakieś koncepcje?

pozdrawiam,
patS

P.S. Dodatkowa zagadka, poprawnie już mi się udało go wyeksportować, za pomocą komendy: C:\Dev\MySQL\bin>mysqldump.exe -u root -p --default-character-set=latin1 kig > c:\Dump.sql - plik otwieram w notepadzie - wskazuje utf-8 i nie ma żadnych krzaków 9poza &oacute.

ha!

sam sobie odpowiem, dla potomnych jakby ktoś kiedyś miał problem:

1. mysqldump.exe -u root -p --default-character-set=latin1 kig > c:\Dump.sql
2. w notatniku zamieniamy kodowanie z utf8 z sygnaturą na utf8 i dopisujemy set names 'latin2'
3. importujemy z phpmyadmina i wybieramy jako kodowanie pliku utf8



pzdr, patS