24. januar 2012 - 10:44Der er
43 kommentarer og 1 løsning
AJAX returnering af danske tegn
Jeg sidder og roder med noget AJAX for første gang. Jeg har en PHP-side som henter data fra en database, ud fra variabler defineret i sidens link. Selve 'brugerfladen' som henter data fra denne side, kan dog ikke tolke Æ, Ø og Å rigtigt. Jeg her prøvet at definere language i <html> tagget som man skal i XHTML, jeg har smidt nogle requestHeaders ind imellem post() og send(), men jeg kan simpelthen ikke hive de rette tegn ud.
Nogen der lige kan komme med et par hints?
Jeg kan godt lige smide noget kode ind, en gang når jeg lige har muligheden.
Keysersoze: Når jeg kører UTF-8 på min front-end, eller hvad man skal kalde det, laver den samme nummer som min back-end gør. Jeg har også lidt svært ved at forstå hvorfor min front end gør det ved UTF-8, da min DB også kører UTF-8, men jeg prøver lige at leje med det ved lejlighed.
Det virker stadig ikke helt. Sørgeligt nok, har encodingen af selve dokumentet aldrig faldet mig ind. Den var ANSI-encoded da php-filen var oprettet i notepad. Jeg har så brugt Notepad++ til at ændre den til UTF-8. Jeg har været inde i min DB og ændre fra UTF-8-danish_ci til UTF-8_unicode_ci.
Der står i guiden at man kan ændre selve outputtet fra DB'en også, gennem .htaccess, men jeg kan ikke finde denne, jeg ved at den burde ligge i roden på mit webhotel, men jeg kan ikke finde den.
Efter jeg ændrede selve selve php-filerne fra ANSI til UTF, reagerer de ens, men det er stadig med firkanter i stedet for Æ, Ø og Å, så jeg tror lige jeg skal have fundet ud af hvordan jeg ændrer selve kommunikationen.
Så fandt jeg .htaccess, og fik tilføjet AddDefaultCharset utf-8 desværre med samme resultat på den side jeg arbejder med - og så har det jo også lige en ret tydelig effekt på alt indholdet af min gamle side ;P men den er nemlig det, gammel, og skal alligevel skrives om fra bunden, så man kan lige så godt få lavet alt i UTF-8 fremover.
Men jeg mener at have ændret alt i den guide du foreslog i #1, men den laver stadig firkanter.
DB: UTF8_unicode_ci .htacces: AddDefaultCharset utf-8 front-end-fil: UTF8 front-end-meta: UTF8 back-end-fil: UTF8 requestheader for backend i front-end-fil: UTF8
Jeg har ikke skrevet noget html-tag eller head->meta-tag i back-end-filen, da jeg går ud fra at indholdet hentes til front-end-filen og encodes der, og ellers burde default charset fra .htaccess klare resten - ikke?
.htaccess var åbenbart ikke nok, og af en eller anden grund, kunne serveren ikke lige at jeg forsøgt at definere det for al php, men ovenstående fixede lige resten af mine problemer :)
Da data, du har indsat med det gamle dokument, vil altid være ANSI - uanset, om du er overgåret til utf-8 eller ej. mysql_set_charset('utf8',$db); burde være unødvendig, hvis du i øvrigt har styr på tegnsættet
Jeg bedte Notepad++ om at konvertere dokumentet fra ANSI til UTF8, og når det efterflg. vises som ANSI, ser det hele da lidt mærkeligt ud, så jeg har en formodning om at selve dokumentet og indhold faktisk er UTF8 nu.
Om jeg har styr på tegnesættet er jeg ikke sikker på, som jeg sagde før, har jeg forsøgt at holde UTF8 over hele linien, men alt hvad der spyttes ud af databasen kommer Æ, Ø og Å ud som firkanter, medmindre jeg definerer mysql_set_charset('utf8',$db); Tabellerne, og de enkelte celler i databasen, er alle sat op til UTF8_unicode_ci
Hvis der på back-enden sendes et "Ø" uden noget til at definere charset, kommer den også over som "Ø" nu, men alt der hentes fra DB'en skal bruge mysql_set_charset('utf8',$db); for at vises korrekt.
Okay, så har jeg åbenbart forklaret mig utydeligt. Jeg prøver lige igen =)
Hvis du har indsat data i en database med et ANSI-dokument, er disse data ANSI-kodet - uanset, hvad databasen står til - og uanset, om du senere bruger et utf-8 dokument til at hente og fremvise med.
"... men alt der hentes fra DB'en skal bruge mysql_set_charset('utf8',$db); for at vises korrekt." >> Nej, ikke hvis data er kodet korrekt, og de involverede dokumenter er utf-8 filer
Jeg har brugt phpMyAdmin til at fylde data i mine tabeller indtil videre. På forsiden står der at den er sat op til UTF8 også. Jeg har efter al min roden omkring prøvet at skrive noget nyt ind i tabellerne, gennem phpMyAdmin, som det andet, men med samme resultat. Nu er det store spørgsmål så om browserens opsætning har noget at sige ifm indtastning af data, og om der er noget andet som stadig mangler opsætning i phpMyAdmin.
Det ser også rigtigt ud. Men jeg er til gengæld lige kommet til at kikke på din kollationer utf8_unicode_ci. Prøv lige at ændre dem til utf8_danish_ci. Så er jeg ret sikker på, danske tegn vil funke for dig *o)
Der er ingen forskel :/ Jeg har prøvet, for god ordens skyld, at skrive noget ind i tabellerne efter ændringen, men de siger alle det samme, hvilket de vel også bør, når sidens meta er utf8.
Altså - bare lige for at vi ikke snakker forbi hinanden: Oprette en utf-8 encoded PHP-side, gennem f.eks. Notepad++, med en mysql INSERT, til de eksterende tabeller?
Eller lave samme, men oprette tabel først, som man så inserter data i?
Jeg fandt i øvrigt endnu et sted hvor mysql var sat op til en ISO, det var selve databasen (ikke communication coallation og alle de andre), men hvor der vises tabellen, som viser alle de oprettede tabeller, var der endnu et sted. Jeg syntes det er lidt vildt at der er intet mindre end 4-5 steder i mysql alene hvor man kan sætte encoding. Det giver i mine øjne, fint mening at man kan sætte det op for kommunikation og cellerne i tabellernem og jeg har en formodning om at alle de andre steder er 'defaults' for deres 'child'/'children', men jeg ved ikke om det passer for mig.
Prøv at lave et helt simpelt PHP-dokument, som du objektivt ved er utf-8 kodet. Prøv at indsætte og hente med dette dokument - og prøv også at vise de hentede data i dokumentet.
Husk dog, at du ikke kan vise noget i et rent PHP-dokument - uden valid HTML-kode med Content-Type meta og det hele. Og visningen skal foregå i BODY elementet - ikke før DTD'en. Overholder du ikke dette, kan alt ske =)
Dælme jo! Det fungerede som en drøm! Jeg klaskede en UTF 8 encoded fil sammen, som smider noget i databasen og læser det ud bagefter. Alt der er skrevet ind gennem phpMyAdmin, kommer danske tegn ud som firkanter. Det som er sat ind fra siden som også henter resultaterne, kommer ud præcist som de skal... Det overasker mig godt nok lidt, men så ved man det til næste gang!
Jeg sidder så og kigger lidt på kildekoden for INSERT-siden i phpMyAdmin igen, og som jeg har konstateret éen gang, er meta-tagget defineret til "utf-8", men det viser sig så, nu hvor jeg har kilden åben i Notepad++, at dokumentet er "ANSI as UTF8", så jeg vil tro at det er der fejlen ligger, hvis "<input>"-delene på siden arver ANSI-encodingen fra selve dokumentet.
Tak for hjælpen :)
Og Ole du tager vel stadig ikke imod point? Skal du have nogle/dem Keysersoze?
Selvtak. Det anede mig! Nå, men løber jeg tør for toiletpapir, er det jo skønt at vide, jeg bare kan printe et par A4-sider med phpMyAdmins koder!
Anyway, så pegede min søn, som også er udvikler, mig engang i retning af et Delphi program, som hed MySQL-Front. Det skal zq nok være 10 år siden efterhånden. Jeg skiftede øjeblikkeligt, og brugte det i en hel del år, selvom udviklingen af det desværre var stoppet.
For små 6 år siden blev programmet skrevet om med det langt nyere ZeosLib databaselag og lagt på SourceForge under navnet HeidiSQL. To år senere blev det skrevet om endnu engang og flyttet til GoogleCodes.
I dag kan programmet downloades fra dette site. Jeg må erkende, at jeg aldrig nogensinde kunne finde på at bruge phpMyAdmin igen. Jeg vil på det varmeste anbefale det til alle, der bruger MySQL - og det håndterer for den sags skyld også msSQL.
Du har ret, jeg samler ikke point, men tak for tilbudet =)
Jeg vil lige kigge på programmet når jeg sidder ved min stationære. Men jeg gad egentligt godt at vide om det er et problem der er browser specifikt eller om det er server-side. Det jeg har siddet og rodet med, var igennem IE9, yeah yeah... I know - bruger også alt andet på mine andre computere :P Men hvis nu at det er IE9 som er kodet så den genbruger encodingen fra dokumentet i stedet for fra meta-tagget. Så kunne det jo godt være at FF eller Chrome kunne finde ud af at gøre det rigtigt. Nu ved jeg ikke ret meget om opbygningen af deciderede programmer, så jeg ved ikke om det er muligt at gå fra et charset, til et andet i programmet, men det bør det vel næsten være, hvis det er muligt i en browser.
Anyways... hvis man helt kan undgå den type problemer ved at bruge det program du linkede til, så kan det også være ligemeget - det er bare lidt ærgeligt at fordømme den ene producent for noget, som i virkeligheden er en fejl fra en anden producent.
Du skal såmænd ikke flove dig over, du bruger nettets næstmest sikre browser* - fra et firma, der har været en af de væsentligste drivkræfter bag nettets udvikling. Husk på - her er du i professionelle hænder, og det er primært i WWW's amatør community, man driver sekteriske 'koranskoler' *o)
Og nej, det har intet med browserforskelle at gøre. Filen indeholder en utf-8 meta, men er gemt med et andet tegnsæt. Det er en klar fejl, som ingen browserfabrikant kan stilles til regnskab for.
*) Symantec's sammenlignende opgørelse over browserhuller for 2011 udkommer først om et par måneder, men her er den for 2010. Det bliver spændende at se den nye =)
Så i bund og grund, kan man lave alle de opsætninger man vil i phpMyAdmin, men det vil ikke gøre nogen forskeld, medmindre serveren selv, konverterer dokumentet fra ANSI til det charset man har valgt at bruge - great :P
Så den eneste måde man kunne få den side til at fungere korrekt på, ville vel være fra phpMyAdmins side at tilføje mysql_set_charset($userselectedcharset,$db); før alle deres queries, så dokument charsettet ikke roder med det der sættes ind og det der læses ud.
Nå nok om det - jeg har dælme også fået nok af phpMyAdmin Martin->GoogleCodes!
Meh... Så fik jeg hentet programmet, men jeg kan ikke få banket hul igennem til databasen, søger fibrilsk info hos one.com som kan udfyle evt. huller, men ikke nok held endnu :/
Hvis jeg ikke husker helt forkert connecter man til mysql med localhost hos one.com og det betyder at du ikke har adgang til at connecte udefra. Det igen betyder at det fremragende(?) phpMyAdmin er din eneste adgang.
Jeps... Du har helt ret, jeg tror faktisk jeg sad og chattede med support mens du skrev her, men der er simpelthen lukket udefra 'af sikkerhedsmæssige grunde'.
Jeg skrev også til hende om det bøvl der er med at det ikke passer sammen, og hvor irriterende det er hvis det er ens eneste løsning, så foreslog hun at jeg sendte en mail til deres support, det er hermed gjort, men det er nok begrændset hvor meget de vil rode i det, bare fordi et enkelt brok-hoved pipper lidt... Så jeg får nok et standard brev en gang i næste uge om at de ikke roder i koden for phpMyAdmin, så det må jeg bare leve med. Men - så kan man jo altid kode sit eget database-værktøj (det er nemlig ganske sikkert slet ikke nogen særlig omstændig opgave :P)xD Ej, jeg skal under alle omstændigheder, kunne fylde data i db'en fra siden, så phpMyAdmin, brugte jeg kun da jeg regnede med at man kunne stole lidt mere på dens INSERTS, så det var nemmere lige at få tilpasset/stylet outputtet, men der kan man se hvor meget fejl man kan tage :/
Men keyser, det var en rigtig god guide til lige at få styr på de steder man bør være opmærksom og Ole vil ikke have nogen point, så hvis du vil ha' dem, så smid et svar :)
'Sikkerhed' bruges ofte som undskyldning for manglende kompetencer blandt de billigste hoteller. Og så koster det jo at have folk til at tage sig af sikkerheden. Fylder man ikke benzin på bilerne, kan man jo bortspare store dele af færdselspolitiet *o)
Jeg fik svar i nat, men de skulle lige vide mit domæne så de kunne undersøge alt til bunds.Jeg ved ikke om de har tænkt sig at konvertere filerne, eller hvad planen er, men i så fald er det jo kun en halv løsning, hvis man nu skulle bruge andre charsets.
Hvilke webhoteller buger i selv (hvis i da ikke bare hoster det selv)?
Hmm... Jeg var meget grundig i at forklare problemet, men ikke at jeg gerne specifikt ville have UTF-8 så her var deres løsning på problemet:
Hello,
The issue is now fixed and the characters should now display correctly. This was fixed by changing the default charset in .htaccess to ISO-8859-1 which is a more standard charset for Western alphabetic languages.
Using UTF-8 should not pose any issues as it supports vastly more characters than any other charsets. However, ISO-8859-1 is more compact choice for Danish characters so we would recommend that you use it on your documents. This is as well to ensure that regardless of browser used, visitors of your site will not have issues with the character display.
Jeg havde jo netop specificeret utf8 i .htaccess, for at den ikke defaultede til ISO8859-1 :P
Altså, som jeg beskrev det, var det bare at der var et problem med at taste data ind i phpMyAdmin når man brugte UTF-8 og alle detaljer omkring hvad der var prøvet, og hvilke konklusioner vi var kommet til herinde, men jeg glemte at sige at jeg jo netop forsøgte at komme væk fra ISO-8859-1.
Svarede også til deres løsning at jeg syntes at det var mindre end en halv løsning, da jeg næppe er den eneste der har været i den situation.
Forskellen er bare at andre sikkert lader sig 'nøjes' med ISO-8859-1, mens dem som ikke gør, sikkert kender problemet, eller ved nok om det til hurtigt at kunne identificere problemet.
Men som en stædig/perfektionistisk 'begynder', er det altså ikke lige phpMyAdmin-filens encoding man kigger først på når man fejlsøger :P
Jeg bruger som sagt ikke selv phpMyAdmin og har ikke brugt den i mange år. Jeg ved det udelukkende p.gr.a. de mange tråde, jeg har deltaget i her på E.
Det er helt korrekt, at utf-8 data fylder dobbelt så meget som iso-8859-1 - men WWW kender ikke grænser. Skal/vil man kommunikere på tværs af sprog, er utf-8 vejen frem. At et andet Unicode format måske så overtager med tiden, kan godt være, men forløbig er det utf-8, der er den =)
Havde jeg været lidt bedre til at formulere mig tydeligt, uden at blive afsporet, tror jeg at jeg ville skrive en grundig guide, som dækker alt fra phpMyAdmins og egne filers encoding, til valg og opsætning af charsets i php, (evt. phpHeader), meta tags, og helt ned på element niveau, hvad der er vigtigt hvornår og hvorfor.
Jeg har selv ledt, men jeg syntes altid det er om en specifik del af en hel side, i stedet for slavisk gennemgang af opsætning af DB og tabeller og helt fra INSERT fra siden og hele vejen tilbage til SELECT på (en/"") side(""/n).
Der er meget, meget få emner indenfor webudvikling, der ikke trænger til en kompetent gennemgang!
En yderst uhensigtsmæssig sideeffekt ved WWW er, at det er blevet så let at publicere. Det har lokket alle mulige uvidende og inkompetente klaphatte på banen, som tydeligvis har en uimodståelig trang til at fylde nettet med deres fejl, misforståelser og mangel på forståelse (jeg nævner i flæng: w3schools.com, hjemmesideskolen.dk o.m.fl.).
Et af de ganske få steder, som virkelig fungerer, er Wikipedia. Det skyldes udelukkende en benhård censur, udøvet af wiki-nørd grupper, spredt over hele verden. Skriver du noget vrøvl, er det som oftest rettet i løbet af 15 minutter.
Så meget for WWW som demokratisk jubelåbenbaring! *o)
Der kan man bare se, jeg har i lang tid brugt w3schools som min bibel, i mangel af bedre. Jeg havde faktisk en idé om at w3 konsortiet (eller hvad det nu hedder) havde en finger med i spillet der, men så må man vel bare i gang med at læse dokumentation i stedet og håbe at browserne overholder det de nu skal ift. standarderne. Jeg går dog ikke ud fra at det er det helt store issue post IE6 (medmindre man snakker ikke færdigt udviklede/godkendte standarder), som vel mere eller mindre kørte sit helt eget sprog - altså så længe man holder til korrekt HTML, jeg er nemlig udmærket klar over at dårlig HTML tolkes lige så forskelligt som vinden blæser.
W3C modtager oceaner af klagemails fra folk, som tror, w3schools.com har tilknytning til W3C. Derfor har de flere gange forsøgt at få ham (en tilfældig nordmand) til at tage webkode seriøst - eller i det mindste gøre det tydeligt, at han ikke har nogen somhelst tilknytning til W3C. Det har han indtil nu ikke ønsket.
Hvis du løser hans quizzer helt korrekt, får du ikke '100% korrekt besvaret', fordi han ikke selv kender de korrekte svar!
Nu tilbyder han dæleme også 'certifikater', som er helt uden værdi i branchen - og som han ingen på noget tidspunkt har godkendt. Du er med andre ord så heldig, at du for 500 kr. kan få tilsendt et totalt værdiløst PDF-dokument, som du kun bliver til almindelig nar og grin med, hvis du udprinter og fremviser til en ansættelsessamtale. Til gengæld får du sikkerhed for ikke at blive ansat *o)
Der var såmænd ikke de store problemer før i tiden, hvor browserne godtog den mest utrolige tag-soup. Nu om stunder er det langt vigtigere at skrive god og valid kode - og dermed at holde sig langt væk fra sites som w3schools.com
@keysersoze: Præcis! Jeg er ikke del af gruppen, men har det sidste stykke tid kraftig overvejet at lave en dansk version =)
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.
