Problem z kodowaniem w MySQL, szystkie polskie znaki zamiejają sie w ? Opcje

[Coolmax]

...
P.P.S. jeszcze jedno... krzaki po eksporcie pojawiają się tylko jeśli dane w bazie != ustawieniu charset dla komórek/bazy, jeśli już poradzimy sobie z przekonwertowaniem bazy np. z latin1 na latin2, to po eksporcie dane będą poprawne, tyle, że w przypadku nowego phpmyadmina znaki będą zawsze w utf8 (ale mogę się mylić), przy mysqldumpie chyba można wybrać kodowanie...

No właśnie - nie ma gdzieś w konfigu phpmyadmina, aby zmienić te kodowanie na iso-8859-2? Jeśli nie, to w ramach nauki napisze sobie skrypt konwertujący z utf na iso, a co będę ściągał jakiegoś gotowca

[WereWolf]

No właśnie - nie ma gdzieś w konfigu phpmyadmina, aby zmienić te kodowanie na iso-8859-2? Jeśli nie, to w ramach nauki napisze sobie skrypt konwertujący z utf na iso, a co będę ściągał jakiegoś gotowca

przyznam szczerze, że ja testując to co pisałem, używałem praktycznie tylko phpmyadmina zainstalowanego domyślnie na serwerze (serwery wirtualne), a co za tym idzie nie miałem dostępu do konfiga... raz zrobiłem wyjątek, przy testowaniu starszej wersji...

w każdym razie, jeśli chodzi o konfig, to faktycznie jakieś ustawienia są (default collation, default charset), ale trzeba by potestować metodą prób i błędów jakie ustawienie by zadziałało (podejrzewam, że zależy to też od ustawienia default character setu dla serwera itp.), bo mam dziwne przeczucie, że jeśli dane w bazie nie odpowiadają ustawieniu charsetu dla bazy, to znowu przy eksporcie pojawią się znaki zapytania... chyba metoda konwersji pliku po eksporcie jest pewniejsza

[koskitos]

Mi się udało to załatwić bez problemu.
Wszystko jest na utf8_polish_ci
I raz dałem zapytanie: SET NAMES latin2
Eksportuje i imprortuje bez problemów. Zawsze z UTF-8. Tylko jeżeli mam baze zimportowaną ze starszego phpmyadmina to podczas importu zmieniam na latin1.

Jedyne co jest nie tak to, że w phpMyAdminie nie mam polskich znaków, a krzaki....

Udało sie komuś załatwić to, aby wszystko chodziło bez problemów łącznie z phpmyadminem?

Ten post edytował koskitos 8.11.2006, 22:54:18

[Nevermore]

U mnie w tej chwili na swiezo zalozonej bazie tez jest utf8_polish_ci i wszystko ladnie sie wyswietla takze w tym badziewiu, ktorego nazwy nie przytocze, zeby sie nie denerwowac. Ale to tak ladnie pieknie jest pewnie tylko dlatego, ze jeszcze nie musialam tej bazy uploadowac z backupu.

[WereWolf]

Jedyne co jest nie tak to, że w phpMyAdminie nie mam polskich znaków, a krzaki....

Udało sie komuś załatwić to, aby wszystko chodziło bez problemów łącznie z phpmyadminem?

jeśli w phpmyadminie masz krzaki, to znaczy, że masz ustawione złe kodowanie... tzn. przykłądowo, ustawienie collation i charset na latin1, a faktycznie przetrzymujesz w bazie dane kodowane pod latin2...

żeby w phpmyadminie widzieć znaki poprawnie, ustawienie kodowania dla bazy i dane zawarte w komórkach muszą się zgadzać...

[koskitos]

WereWolf, wszędzie mam utf8_polish_ci, baza, tabele, komórki, wszystko.

Czyli jak powienienm to ustawić?

[WereWolf]

WereWolf, wszędzie mam utf8_polish_ci, baza, tabele, komórki, wszystko.

Czyli jak powienienm to ustawić?

a jakie dane trzymasz w bazie? tzn. w jakim kodowaniu?

[koskitos]

Jakie dane? Hmmm... Dane są wprowadzane z formularzy ze strony. Wszystko jest ustawione na utf8_polish_ci, wiec to chyba ten typ...

[WereWolf]

Jakie dane? Hmmm... Dane są wprowadzane z formularzy ze strony. Wszystko jest ustawione na utf8_polish_ci, wiec to chyba ten typ...

no właśnie niekoniecznie...

kodowanie danych wprowadzanych z formularzy na stronie zależy od ustawień kodowania przeglądarki (i/lub charsetu ustawionego w meta-danych na stronie)

przykładowo jeśli na stronie używasz kodowania iso-8859-2, to w takim właśnie kodowaniu dane są przesyłane do bazy... wtedy nic dziwnego, że w phpmyadminie widzisz krzaczki, bo kodowanie danych nie zgadza się z ustawieniami w bazie...

a jeśli na stronie faktycznie używasz kodowania w utfie, to nie mam innego pomysłu...

[koskitos]

Czyli w takiej sytuacji mam zmienić kodowanie strony na utf? Ale wtedy trzba coś kombinować przy wpisywaniu znaków?

Czy zmienić kodowanie bazy na jakieś inne, a jeżeli inne to jakie?

[WereWolf]

Czyli w takiej sytuacji mam zmienić kodowanie strony na utf? Ale wtedy trzba coś kombinować przy wpisywaniu znaków?

Czy zmienić kodowanie bazy na jakieś inne, a jeżeli inne to jakie?

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

[GhOsT9]

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:

Kod

ini_set('default_charset', 'UTF-8');

i po polaczeniu z baza:

Kod

mysql_query('SET CHARACTER SET utf8');

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.

Kod

    pl                varchar(150)                   NOT NULL,
    en                varchar(150)                   NOT NULL,
    de                varchar(150)                   NOT NULL,

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?

[WereWolf]

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

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

Jaka odmiana kodowania UTF8 dla bazy (utf8_unicode_ci czy utf8_general_ci)

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

[GhOsT9]

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.

Ten post edytował GhOsT9 11.12.2006, 12:34:19

[WereWolf]

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?

[woodzu]

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



Ten post edytował woodzu 14.12.2006, 17:03:43

[WereWolf]

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ż " ó ".

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

[woodzu]

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

[hhg]

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

[WereWolf]

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 

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

Ten post edytował WereWolf 15.12.2006, 07:16:16