baza mi je enkodirana u utf8 i svi znakovi se prikazuju dobro i nove linije se uredno zapišu u polja. No kada kroz phpMyAdmin krenem urediti neko polje… dok se polje pretvori u edit mode i dalje uredno prikazuje nove linije, ali nakon spremanja ih proguta i ostavi sav tekst u jednoj liniji. (Koji se također kasnije takav učitava prema webu.)
Ako za vrijeme uređivanja lupim dodatni enter, to se također neće spremiti kao nova linija.
Ako ručno probam unesti \n …to se također ne uhvati.
Isto se dešava neovisno za tipove polja varchar ili text.
Neće.
Ali recimo i da se može…problem bi i dalje postojao zato jer ako ja kliknem na neko polje da ga editiram …dopišem recimo jedno slovo i zatvorim. Sam taj čin otvaranja-zatvaranja će mi progutati sve prelaske u nove linije unutar toga teksta (koji je već postojao u tom polju.)
Znači jedina mi je opcija izađi iz editiranja sa ESC da izbjegnem spremanje…a to povlači da ne mogu ništa dopisati …ili ako bi znao kako se dodaju nove linije, morao bi “obraditi” cijeli tekst da bi ga mogao spremiti…
Na ovo drugo sam mislio (da nije ckeditor, tinymce etc u pitanju[ mada ne bi trebalo da se desava uopste]).
Sto se prvog tice, Sublime default-no cuva fajlove kao UTF-8 without BOM, ali provjeri da li su se fajlovi tako i sacuvali.
Ovo je tapkanje po mraku jer je nemoguce znati sto se to desava.
Vec je negdje pominjano na temama, ali evo rjesenja za kad baza nece da isporucuje domaca slova sa kvacicama i sl:
-sacuvaj fajl kao utf-8
-enkoding baze utf8
-meta tag stavis u stranicu
tu bi vec trebalo da radi, ako nece stavi da prvi query bude “SET NAMES utf8”
onda mora da radi.
Moze li primjer teksta ispravnog/neispravnog iz baze?
Hmm…meni je sumnjivo da ikako problem može biti vezan sa enkodingom file-ova text ditora ili sa vrstom frontend text editora…kad je problem isključivo povezan sa bazom podataka.
Ajde da se na podacima koji stignu iz editora kasnije progutaju nove linije…a na onim unesenim kroz phpmyadmin ne progutaju…onda bi neštu tu bilo. Ovako je, kako se čini, problem isključivo vezan uz phpMyAdmin i eventualno uz način kako se te tablice kreiraju ili nešto…
Očekivao sam da je možda neka setup postavka u pitanju ili tako…ali je nosense kako se god okrene
Načuo sam nešto da phpmyadmin ima takav bug …ali prije nisam imao taj problem. Možda mi je uletila neka verzija…
Tekst prije…selektiran u polju:
tekst koji ima nove linije
ovo je nova linija
Tekst selektiran nakon što se klikne dblclick na polje:
tekst koji ima nove linijeovo je nova linija
Tekst nakon izmjene:
tekst koji ima nove linijeovo je nova linija
Kad malo bolje razmotrim, problem je doslovice do tog njihovog edit input polja koje ne podržava novu liniju. Jednostavno ju proguta čim se otvori to edit-input polje…isto tako ako u to edit-input polje probam kopirat neki tekst izvana…odmah nakon copy-paste nema novih linija.
Ako probam editirati željenu vrijednost u tablici pomoću SQL naredbe isto putem phpmyadmina …onda se uhvati sve.
1.otvorim phpmyadmin (PMA)
2. napravim novu bazu podataka putem sučelja PMA (odaberem collation utf8_bin)
3. putem sučelja PMA napravim novu tablicu s poljima ID (primary), TEXT (text)
4. pomoću SQL naredbe putem PMA sučelja unesem redak u tu tablicu
5. vidim da je redak tamo
6. double click na vrijednost text polja da probam editirati to polje (opet putem PMA)
7. PMA mi ne dopušta da napišem pokoju novu liniju i da ju spremim
ZAKLJUČAK: nema ovaj problem veze sa nikakvim JS-codom, PHP-codom, develop vrsti editora i enkodingu istoga …frontend web editora.
Ako nije vezano uz same PMA postavke kod kreiranja baze…onda bi jedino problem mogao biti do operativnog sustava, gdje imam win 8.1.
Prije toga, ne bi bilo lose probati iz konzole da se odrade sve akcije sa bazom (kreiranje tabele unos podataka, izmjena i sl). Tako bi se znalo da li je kompromitovan samo PHPMyAdmin ili MySQL. Ili instalisati HeidiSQL recimo i prbati iz njega prije bilo kakve reinstalacije.
