Inputfelt til MySql db med kyriliske og andre tegn
Kort sagt drejer det sig om at når man skriver i et inputfelt og submitter, bliver hvert tegn holdt op mod en db jeg laver med kyriliske, græske og andre tegn.
Siden er lavet i UTF-8, det samme bruger jeg i db'en. Det virker ikke, ellers ville jeg selvfølgelig ikke skrive her. For at checke hvad php/MySql tolker teksten som, sætter jeg den samtidig også ind i en tabel. Jeg har prøvet forskellige metoder, de fleste konverterer blot tegnene til et D med en streg igennem, og et ekstra tegn efter.
Det er ikke visningen det er galt med, men sammenligningen mellem tegnene. Når jeg submitter, loades siden igen og teksten sættes ind i en database (som forsøg på at finde ud af hvordan PHP og MyAql opfatter tegnene). Der går det galt, da teksten ikke indsættes som tegnene er, men med de mærkelige D tegn.
Du mener at PhpMyAdmin kører i iso-8859-1 visning? tegnene bliver jo stadig ikke fundet, så jeg tror ikke det er det eneste der skulle være galt. i øvrigt viser sammenligningstabellen de russiske tegn korrekt.
Det kan godt være det jeg mener ;) Så hvad med at lave en simpel side det trækker et par rækker ud, og serverer dem som utf-8. Husk at du bør sætte tegnsæt 2 steder: i HTTP-headeren (hvis serveren ikke allerede sætter det), og i meta-tag.
Og for lige at få det helt præcist: din mysql opbevarer blot bytes, og for de russiske tegn to bytes, startende med et sjovt D. At tabellens tegnsæt er utf-8 betyder blot at den sorterer efter utf-8. Det vil derfor sige at hvis du skriver: партия (parti), så står der ikke 6 bytes, men 12. Den mysql-sætning der trækker de 12 bytes ud ved ikke selv noget om at det er 6 utf-8 tegn i 12 bytes. Derfor skal man der hvor de 6 utf-8 tegn bruges specificere at det er utf-8.
Og for nu at fortsætte min monolog: du er klar over at hvis du erklærer et felt som varchar(6), så kan du godt skrive "abekat" i feltet. Men ikke ordet parti på russisk, fordi det jo fylder 12 bytes.
"Husk at du bør sætte tegnsæt 2 steder: i HTTP-headeren (hvis serveren ikke allerede sætter det), og i meta-tag." - Det har jeg, og jeg har alligevel været nødt til i en .htaccess fil at angive at filen er UTF-8 - ellers vil W3 ikke validere siden.
"Og for lige at få det helt præcist: din mysql opbevarer blot bytes, og for de russiske tegn to bytes, startende med et sjovt D." - De tegn jeg allerede har oprettet, har jeg skrevet direkte ind via phpMyAdmin. der har jeg blot skrevet de russiske tegn ved at skifte til russisk tegnsæt. Det gik da fint nok!
"19/09-2008 13:13:37" - Så jeg forstår på det hele at jeg skal indskrive alle tegnene v.h.a en SQL indsættelse og leve med at tegnene så bliver konverteret til 2 tegn?
... men jeg kan stadig gemme kyriliske tegn direkte i databasen...? Lyder ikke logisk. ved indsættelse via en mysql query fylder de to tegn. Ved direkte indskrivning i en tabel fylder de et..
" ...så de vises rigtig og ikke med to tegn." - ja, de vises som et tegn, men fylder 2 bytes, hvis et tegn fra det kyrilliske alfabet vises i utf-8. Jeg kan ikke længere se hvor dit problem er. Du kan sammenligne utf-8 strenge med == i PHP, men kan også kigge på http://php.net/mbstring
Mit problem er som beskrevet... jeg får indsat to tegn som intet har med det oprindelige tegn at gøre, når jeg indsætter via php. Indsætter jeg tegnet direkte i tabellen, ser det rigtig ud.
Altså.. scriptet kører jo før doc declaration, men selve dokumentet er UTF-8 i doc dec. Derudover en "AddDefaultCharset UTF-8" i en .htaccess i folderen. Ellers validerer W3 ikke.
Filen er gemt i UTF-8 (without bom). Notepad++ siger ANSI as UTF-8, det skulle være det rigtige format.
Beklager, men der mangler oplysninger til at løse problemet, ud over de retninger, der er peget i allerede.
Det er intet problem at gemme kyrilliske bogstaver i databaser, og vise dem igen, men hvis der et sted bruges iso-8859-1 (eller tilsvarende) går det jo galt.
Men det er jo egentlig ikke det der er problemet. Siden viser tegnene rigtig. Hvis jeg kalder db'en fra en anden side og henter tabellen fra new-2.jpg, vises de rigtigt og w3 validerer. Problemet ligger i starten a filen hvor jeg indsætter/sammenligner tegnene. Der går det åbenbart galt.
"Og for nu at fortsætte min monolog: du er klar over at hvis du erklærer et felt som varchar(6), så kan du godt skrive "abekat" i feltet. Men ikke ordet parti på russisk, fordi det jo fylder 12 bytes." - Det kan jeg nu altså godt. Lige afprøvet.
CREATE TABLE IF NOT EXISTS `XXX` ( `ID` int(5) NOT NULL auto_increment, `Tekst` varchar(30) character set utf8 collate utf8_unicode_ci NOT NULL, `Tekst2` varchar(30) character set koi8u NOT NULL, PRIMARY KEY (`ID`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=18 ;
Jeg indsætter altså kyriliske tegn i første hug, og får de forkerte tegn indsat. Der er næsten inge html kode på siden, blot et par klikbare ikoner, lidt javascript, en input boks m.m.
Det du beskriver, er hvad jeg har i et eksempel. Jeg putter РУССКИЙ ind, og får РУССКИЙ ud (man skal lige forestille sig bogstaverne, hehe). UTF-8 hele vejen.
Jeg har lige lavet en test med koden 19/09-2008 22:20:39 Blot sætter jeg yderligere input boksens værdi til $text så jeg får smidt input teksten tilbage. Her er alt ok, html koden viser russiske tegn.
Uden DB? Jeg har ikke lige et russisk tastatur, men ved at klistre РУССКИЙ ind fra et andet sted, skriver den det ud igen. Godt nok.
Du skriver du har gjort det samme uden problemer. Det originale problem er hostet hos gigahost, og testsiden jeg prøvede hos en anden host er host dreamhost. Det er jo 2 vidt forskellige udbydere.
Jeg har et forum kørende på http://smf.e-debatten.dk. Der prøvede jeg i nat at skrive russiske tegn i et indlæg. Det blev også til russiske tegn i db'en. De bruger også utf8_unicode_ci. Så det virker på en eller anden måde. Jeg kan dog ikke lige se hvordan de behandler teksten inden de putter den i db'en.
Man kan ikke skrive: "Det blev også til russiske tegn i db'en" ... spørgsmålet er hvilket tegnsæt disse tegn er lavet i, og dermed hvordan de skal vises.
Kan jeg se på det link du gav 20/09-2008 00:15:36 hvordan teksten ser ud hentet fra databasen?
Russiske tegn kan også skrive i iso-8859-5 og en af koi8-varianterne. Derfor er der flere måder, og derfor er det afgørende at vide med sikkerhed hvilket tegnsæt, der er anvendt. Det er den eneste måde korrekt at fortolke de bytes, der er i teksten.
Den plejer også at være korrekt. Men det kan ikke passe at den både kan sige ASCII (iso-8850-1) og russisk på tekst, der kommer samme sted fra. Æ, ø og å i utf-8 fylder også 2 bytes, og er karakteristiske nok til at den skal sige utf-8. Så hvad mener du med "dansk tegnsæt" og "russisk"?
Ok, så passer det. Den kan ikke på "abc" se andet end "ASCII". Så får du utf-8 tilbage fra databasen. Det kan du så skrive ud på en side, hvor tegnsæt er angivet til utf-8.
Hvis du ser teksten "abcÆØÃ..." som iso-8859-1, så er det korrekt indsatte ÆØÅ-er som utf-8. De skal selvfølgelig vises som utf-8 for at se det igen.
Nej, det har intet med visningen at gøre. Som jeg nævnte i starten...indsættes tegnene manuelt i phpMyAdmin, vises de rigtigt nok. Indsættes de via php, kommer de ind som dobbelt tegn.
"...indsættes tegnene manuelt i phpMyAdmin, vises de rigtigt nok" - med fare for at gentage mig selv: det afhænger af tegnsæt, og der er ikke noget der hedder "rigtigt nok". I denne sammenhæng.
Det du siger til mig er at reelt kan ingen vide hvad det er de sidder og kigger på, de kan reelt aldrig vide hvad de har i deres tabel eller på deres html side.
Næppe. For så ville det jo bare virke - det er hvad utf-8 er beregnet til. Og hvad andre sagtens kan klare. Der er et eller andet sted "kæden falder af". Jeg ved ikke hvor, og jeg kan ikke se af det skriver, eller viser, hvor det er.
Ja, og så er det tegnsættet på siden, der indtastes på, eller siden, der vises. Der er ingen magi i dette.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
