mboost-dp1
Danske bogstaver i RSS
Hej :)
På min hjemmeside har jeg en RSS-funktion som indtil for nylig har fungeret fint. Nu har jeg dog det problem at Firefox ikke længere kan indlæse det, og kører jeg RSS'en igennem validator.w3.org får jeg da også fejl.
Det ser ud til at være en fejl med et å, men jeg kan ikke forstå hvorfor det pludselig er et problem, for der er andre å'er som den ikke melder fejl ved og som har virket fint tidligere.
Den melder også en fejl om at RSS'ens URL ikke er den samme som den der står i selve RSS'en, men det kan jeg ikke helt få til at passe, for jeg synes nu ellers der står det samme.
Fejlene kan ses ved at følge linket.
Er der en der kan gennemskue problemet?
På forhånd tak :)
Mark
På min hjemmeside har jeg en RSS-funktion som indtil for nylig har fungeret fint. Nu har jeg dog det problem at Firefox ikke længere kan indlæse det, og kører jeg RSS'en igennem validator.w3.org får jeg da også fejl.
Det ser ud til at være en fejl med et å, men jeg kan ikke forstå hvorfor det pludselig er et problem, for der er andre å'er som den ikke melder fejl ved og som har virket fint tidligere.
Den melder også en fejl om at RSS'ens URL ikke er den samme som den der står i selve RSS'en, men det kan jeg ikke helt få til at passe, for jeg synes nu ellers der står det samme.
Fejlene kan ses ved at følge linket.
Er der en der kan gennemskue problemet?
På forhånd tak :)
Mark
Argh, den har fjernet mit link. Nå, her er det igen:
http://validator.w3.org/feed/check.cgi?url=http%3A...
Prøver lige med link-tag igen: link
Hvorfor virker det ikke? :S
Nå, http://validator.w3.org/
og
http://smilinger.dk/image_rss.php
http://validator.w3.org/feed/check.cgi?url=http%3A...
Prøver lige med link-tag igen: link
Hvorfor virker det ikke? :S
Nå, http://validator.w3.org/
og
http://smilinger.dk/image_rss.php
Dine "snyde" ÆØÅ-koder fejler med start linie 21.
Skriv alt indhold i feedet med normale karakterer, intet behov for at konvertere dem.
Sender du headers?
header("Content-Type: application/xml; charset=utf-8");
header("Content-Encoding: gzip"); **
header("Content-Length: " . strlen($contents));
** Hvis du bruger komprimering, som man vel altid gør :)?
Skriv alt indhold i feedet med normale karakterer, intet behov for at konvertere dem.
Sender du headers?
header("Content-Type: application/xml; charset=utf-8");
header("Content-Encoding: gzip"); **
header("Content-Length: " . strlen($contents));
** Hvis du bruger komprimering, som man vel altid gør :)?
#4 Mener ellers bare jeg havde problemer da jeg lavede det med normale karakterer (det er ved at være ret lang tid siden - hvorfor har det virket indtil nu?)
Mht. karakterer er det højst sandsynligt pga. manglende headers. Indtil jeg fik sendt de rigtige havde jeg samme problemer. Man kan sige du modsiger dig selv, forstået på den måde at UTF-8 tegnsættet indeholder alle de karakterer du overhoved har brug for, men alligevel konverterer du dem om.
Afhængig af hvor lang tid siden du har roddet med det sidst, kan det være at både w3s samt Firefoxes indbyggede validator er blevet opdateret og nu kan spotte dine "slemme tricks" :)
Afhængig af hvor lang tid siden du har roddet med det sidst, kan det være at både w3s samt Firefoxes indbyggede validator er blevet opdateret og nu kan spotte dine "slemme tricks" :)
#6 Men jeg har jo andre å'er i samme dokument (også i lowercase). Jeg prøver at kigge på det i morgen. Er lidt for træt lige nu
#7
Det skulle man tro jo, men PHP sender pr. default som text/html og det kan derfor forstyre feedet. Måske virker det i en browser, men kan fucke med dedikerede RSS Readers. Derfor, før det virker over hele linien, skal der sendes headers.
Char. Encoding er det samme, hvis PHP defaulter noget andet end ventet der fucker med feedet.
Det er op til den enkelte browser/reader hvor sart den er.
Det skulle man tro jo, men PHP sender pr. default som text/html og det kan derfor forstyre feedet. Måske virker det i en browser, men kan fucke med dedikerede RSS Readers. Derfor, før det virker over hele linien, skal der sendes headers.
Char. Encoding er det samme, hvis PHP defaulter noget andet end ventet der fucker med feedet.
Det er op til den enkelte browser/reader hvor sart den er.
#10
Jeg for følgende fejl fra Visual Studio:
Fra følgende kode:
Så jeg synes du skal læse og lære om entities: http://www.xml.com/pub/a/2001/01/31/qanda.html
Og generelt bruge CDATA til alt tekst!
Jeg for følgende fejl fra Visual Studio:
Entity 'eacute' not defined.
Fra følgende kode:
<title>På café</title>
Så jeg synes du skal læse og lære om entities: http://www.xml.com/pub/a/2001/01/31/qanda.html
Og generelt bruge CDATA til alt tekst!
Åbenbart kan den ikke finde ud af entities med navne, men når jeg erstatter dem med talværdierne, så kan den godt finde ud af det. Det var det jeg havde gjort med æøå, men det gav så et problem med eacute (som jeg ikke havde sat den til at erstatte før nu).
I min database er de specielle bogstaver gemt som å, ø osv. Ved I om der er en php-funktion der kan erstatte disse med entities med talværdier? Lige nu gør jeg det med str_replace, men det ville da være dejligt ikke at skulle holde øje med det hele tiden (selvom der sjældent kommer nye ting og meget sjældent mere eksotiske bogstaver end dem jeg har nu).
I min database er de specielle bogstaver gemt som å, ø osv. Ved I om der er en php-funktion der kan erstatte disse med entities med talværdier? Lige nu gør jeg det med str_replace, men det ville da være dejligt ikke at skulle holde øje med det hele tiden (selvom der sjældent kommer nye ting og meget sjældent mere eksotiske bogstaver end dem jeg har nu).
Jeg gav dit et link som forklarede det.... Som også forklarer hvordan du kunne supportere dem.markjensen (16) skrev:Åbenbart kan den ikke finde ud af entities med navne, men når jeg erstatter dem med talværdierne, så kan den godt finde ud af det
Læs linket?
Hvorfor er de det?markjensen (16) skrev:I min database er de specielle bogstaver gemt som å, ø osv.
Hvorfor bruger du ikke bare UTF8 ligesom alle andre, og stopper med at konvertere alting til unødvendige entities?
Windcape (18) skrev:Jeg gav dit et link som forklarede det.... Som også forklarer hvordan du kunne supportere dem.
Jeg har læst linket, men det lyder som om at der er nogle som parseren altid forstår:
"You're not restricted to just the five named character entities covered above."
Men det er måske ikke det de mener? Jeg har taget udgangspunkt i newz' RSS, som ikke indeholder nogle erklæringer om eksterne/ekstra entities.
Windcape (18) skrev:Hvorfor er de det?
Fordi jeg gik ud fra at htmlentities som standard konverterede til det som alle andre bruger, men jeg kan godt se at det åbenbart ikke er UTF8.
Medmindre at UTF8 er meget bedre end ISO-8859-1, så kan jeg vel lige så godt holde alt i ISO-8859-1 nu når databasen gemmes med disse entities.
#19
Det lyder som om du roder en del rundt i det.
1) Databasen skal ikke indeholde HTML-entities, medmindre det faktisk er HTML du har i databasen.
2) Hvis databasen er i latin1 (iso-8859-1), så er det nemmest hvis dit RSS-feed også er det.
3) Hvis din database og dit RSS-feed ikke har samme tegnsæt, må du sørge for at konvertere.
Så: Vælg format og tegnsæt til både database og RSS-feed, og overhold dem.
(Og hvis din kilde (databasen) alligevel er i latin1, kan jeg ikke se nogen fordel ved utf8.)
Det lyder som om du roder en del rundt i det.
1) Databasen skal ikke indeholde HTML-entities, medmindre det faktisk er HTML du har i databasen.
2) Hvis databasen er i latin1 (iso-8859-1), så er det nemmest hvis dit RSS-feed også er det.
3) Hvis din database og dit RSS-feed ikke har samme tegnsæt, må du sørge for at konvertere.
Så: Vælg format og tegnsæt til både database og RSS-feed, og overhold dem.
(Og hvis din kilde (databasen) alligevel er i latin1, kan jeg ikke se nogen fordel ved utf8.)
myplacedk (20) skrev:1) Databasen skal ikke indeholde HTML-entities, medmindre det faktisk er HTML du har i databasen.
Det var nu egentlig bare for at holde databasen uden specielle karakterer, fordi jeg tænkte at hvis dne indeholder entities, så kan disse altid pege på forskellige tegn, alt efter hvilket tegnsæt man ønsker at bruge.
myplacedk (20) skrev:2) Hvis databasen er i latin1 (iso-8859-1), så er det nemmest hvis dit RSS-feed også er det.
Ja, det var også det jeg kom frem til.
Er der noget i vejen med ikke at udskrive specielle karakterer som entities, så længe jeg angiver det brugte tegnsæt? Det virker fint, men er det en dårlig idé?
markjensen (21) skrev:Det var nu egentlig bare for at holde databasen uden specielle karakterer, fordi jeg tænkte at hvis dne indeholder entities, så kan disse altid pege på forskellige tegn, alt efter hvilket tegnsæt man ønsker at bruge.
Men jeg kan godt se at dette ikke giver specielt meget mening når databasen jo i sig selv er indkodet i noget.
Modsat så er det en bedre ide altid at have ALTING i unicode.myplacedk (20) skrev:Og hvis din kilde (databasen) alligevel er i latin1, kan jeg ikke se nogen fordel ved utf8.
Du har stadigvæk ikke forstået character encodings i deres grundliggende forstand.markjensen (21) skrev:Det var nu egentlig bare for at holde databasen uden specielle karakterer, fordi jeg tænkte at hvis dne indeholder entities, så kan disse altid pege på forskellige tegn, alt efter hvilket tegnsæt man ønsker at bruge.
Der er altså noget at læse op på her.
#23 Se min næste post.
Er der overlap mellem de mest udbredte bogstaver?
Er der overlap mellem de mest udbredte bogstaver?
#25 Nu var det mere utf8 og latin1 jeg tænkte på :). Men jeg spørger lige igen. Er der nogen fordel i at bruge entities i forhold til bare at bruge tegnene?
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund