|  | 		    
					
        
         
          
         
	
          | |  | Language i php.ini? Fra : Kurt Hansen
 | 
 Dato :  13-10-11 11:38
 | 
 |  | Jeg har installeret MAMP på min Mac for at kunne arbejde med en webshop
 offline, teste og eksperimentere.
 
 Jeg har kopieret det hele fra udbyderens server og installeret en backup
 af databasen.
 
 Det hele funker, men de danske tegn vises ikke korrekt. Jeg er blevet
 hvisket i øret, at det vistnok er i php.ini jeg skal rette et-eller-andet.
 
 Jeg har fundet følgende sekvens:
 
 ; As of 4.0b4, PHP always outputs a character encoding by default in
 ; the Content-type: header.  To disable sending of the charset, simply
 ; set it to be empty.
 ;
 ; PHP's built-in default is text/html
 default_mimetype = "text/html"
 ;default_charset = "iso-8859-1"
 
 Mimetype er den eneste aktive linje.
 
 Nu /kunne/ jeg selvfølgelig prøve at fjerne semikolonnet foran charset,
 men min erfaring er, at det med tegnsæt er så indviklet og upålideligt,
 at man skal være forsigtig. Hvis jeg redigerer online og kopierer det
 over online, kan jeg risikere at smadre de danske tegn. Og så er der
 vist noget med, at Mac (som jeg bruger) har det med /ikke/ at skrive ren
 tekst, men i eet eller andet Mac-format?
 
 Hva' så, gutter. Er det her jeg skal rette noget?
 --
 Venlig hilsen
 Kurt Hansen
 
 
 |  |  | 
  scootergrisen (13-10-2011) 
 
	
          | |  | Kommentar Fra : scootergrisen
 | 
 Dato :  13-10-11 15:15
 | 
 |  | Stemmer din html fils charset med den encoding du har gemt filerne i ?
 
 Prøv og check at din browser er sat til at vise siden med automatisk
 encoding og ikke med en bestemt encoding.
 
 Umiddelbart tænker jeg at det må være din database som er sat med en
 anden encoding så prøv og check at dit webhotel og din lokale computer
 bruger samme encoding i databasen.
 
 Det kan man vist check med phpmyadmin hvis der er det på dit webhotel.
 
 Prøv eventuelt og brug dem her øverst i dine php filer og se om det gør
 nogen forskel :
 
 ini_set('default_charset', 'UTF-8');
 
 ini_set("iconv.input_encoding", "UTF-8");
 ini_set("iconv.internal_encoding", "UTF-8");
 ini_set("iconv.output_encoding", "UTF-8");
 
 mb_detect_order("UTF-8, ISO-8859-1"); // kræver multibyte modul i php
 mb_internal_encoding('UTF-8'); // kræver multibyte modul i php
 mb_http_output("UTF-8"); // kræver multibyte modul i php
 
 Du skal selvfølgelig rette UTF-8 til den encoding du bruger.
 
 
 |  |  | 
  Jonathan Stein (13-10-2011) 
 
	
          | |  | Kommentar Fra : Jonathan Stein
 | 
 Dato :  13-10-11 21:29
 | 
 |  | Den 13-10-2011 12:38, Kurt Hansen skrev:
 
 > Nu /kunne/ jeg selvfølgelig prøve at fjerne semikolonnet foran charset,
 > men min erfaring er, at det med tegnsæt er så indviklet og upålideligt,
 > at man skal være forsigtig.
 
 Det kedelige svar er, at du skal vælge det tegnsæt, som du gemmer dine
 filer i.
 
 - Du får aldrig et pålideligt resultat, hvis du ikke har styr på hvilket
 tegnsæt, din editor gemmer i.
 
 Jeg kører selv altid utf-8, med mindre der er en specifik grund til andet.
 
 Noget kunne tyde på, at din editor også bruger utf-8, hvis du har
 problemer med æøå, for browseren vil typisk gætte på iso-8859-1, hvis
 andet ikke er angivet.
 
 M.v.h.
 
 Jonathan
 
 
 |  |  | 
  Stig Johansen (14-10-2011) 
 
	
          | |  | Kommentar Fra : Stig Johansen
 | 
 Dato :  14-10-11 08:42
 | 
 |  | 
 
            Jonathan Stein wrote:
 > Noget kunne tyde på, at din editor også bruger utf-8, hvis du har
 > problemer med æøå, for browseren vil typisk gætte på iso-8859-1, hvis
 > andet ikke er angivet.
 1) Læg mærke til han kører på Mac:
http://en.wikipedia.org/wiki/Mac_OS_Roman 2) Der er ikke tale om at 'gætte', da det er standard hvis ikke charset er
 angivet.
 Der er *mange* ting involveret her, bla. om der er konvertering ved flytning
 af databaser osv.
 Jeg har selv arbejdet meget med HP-grej (HP Roman8), og her var der tale om
 konvertering af tegnsæt (FTP/Ascii), men ikke binary.
 Jeg kender ikke Mac, så jeg kan ikke gå dybere ind i problemet.
 -- 
 Med venlig hilsen
 Stig Johansen
            
             |  |  | 
   Jonathan Stein (14-10-2011) 
 
	
          | |  | Kommentar Fra : Jonathan Stein
 | 
 Dato :  14-10-11 12:04
 | 
 |  | 
 
            Den 14-10-2011 09:41, Stig Johansen skrev:
 >> Noget kunne tyde på, at din editor også bruger utf-8, hvis du har
 >> problemer med æøå, for browseren vil typisk gætte på iso-8859-1, hvis
 >> andet ikke er angivet.
 >
 > 2) Der er ikke tale om at 'gætte', da det er standard hvis ikke charset er
 > angivet.
 ISO-8859-1 er godt nok standard jf. HTTP-protokollen, men W3C synes 
 alligevel ikke det er godt nok til HTML:
www.w3.org/TR/html4/charset.html#h-5.2.2 Resultatet er det samme, men hvis browseren følger W3C's anbefalinger, 
 så vælger den ISO-8859-1 på baggrund af et kvalificeret gæt eller fordi 
 det er brugerens standard-indstilling.
    M.v.h.
      Jonathan
            
             |  |  | 
    Karl Erik Christense~ (14-10-2011) 
 
	
          | |  | Kommentar Fra : Karl Erik Christense~
 | 
 Dato :  14-10-11 15:39
 | 
 |  | 
 
            On 14-10-2011 13:03, Jonathan Stein wrote:
 > Den 14-10-2011 09:41, Stig Johansen skrev:
 >
 >>> Noget kunne tyde på, at din editor også bruger utf-8, hvis du har
 >>> problemer med æøå, for browseren vil typisk gætte på iso-8859-1, hvis
 >>> andet ikke er angivet.
 >>
 >> 2) Der er ikke tale om at 'gætte', da det er standard hvis ikke
 >> charset er
 >> angivet.
 >
 > ISO-8859-1 er godt nok standard jf. HTTP-protokollen, men W3C synes
 > alligevel ikke det er godt nok til HTML:
 > www.w3.org/TR/html4/charset.html#h-5.2.2 >
 > Resultatet er det samme, men hvis browseren følger W3C's anbefalinger,
 > så vælger den ISO-8859-1 på baggrund af et kvalificeret gæt eller fordi
 > det er brugerens standard-indstilling.
 >
 > M.v.h.
 >
 > Jonathan
 Det er da vist en sandhed med modifikationer.
 Jeg besøgte for nyligt en dansk side, hvor æ, ø og å ikke fungerede.
 Der var ikke angivet noget tegnsæt for siden (meta).
 Ejeren sagde "Det har vi da aldrig haft vrøvl med".
 Nej, for de fleste virksomheder bruger Windows til udvikling, og IE til 
 at vise deres side. Så når siden er gemt med windows-1252 tegnsæt, er IE 
 så "dum", at den viser korrekte tegn.
 Det gjorde min FireFox bare ikke, for standart indstillingen hos mig er 
 utf-8.
 Når man ikke oplyser browseren om hvilket tegnsæt siden bruger, så er 
 det næsten dømt til at gå galt.
 Karl Erik.
 -- 
http://dmwebdesign.dk  - DM i Webdesign
http://produceret-i.dk/  - Køb danske produkter
http://webdesign.ranunkelvej.com  - Artikler om webdesign
            
             |  |  | 
     Jonathan Stein (19-10-2011) 
 
	
          | |  | Kommentar Fra : Jonathan Stein
 | 
 Dato :  19-10-11 19:57
 | 
 |  | Den 14-10-2011 16:38, Karl Erik Christensen skrev:
 
 > Det er da vist en sandhed med modifikationer.
 
 Øh - hvilken sandhed og hvilke modifikationer?
 
 > Det gjorde min FireFox bare ikke, for standart indstillingen hos mig er
 > utf-8.
 
 Så er det også korrekt i henhold til W3C at Firefox bruger din
 standard-indstilling (UTF-8) i stedet for at defaulte til ISO-8859-1.
 
 M.v.h.
 
 Jonathan
 
 
 |  |  | 
    Stig Johansen (17-10-2011) 
 
	
          | |  | Kommentar Fra : Stig Johansen
 | 
 Dato :  17-10-11 09:07
 | 
 |  | 
 
            Jonathan Stein wrote:
 > ISO-8859-1 er godt nok standard jf. HTTP-protokollen, men W3C synes
 > alligevel ikke det er godt nok til HTML:
 > www.w3.org/TR/html4/charset.html#h-5.2.2 Ja, men nu er det IETF, der står for RFC'erne, og ikke W3C.
 > Resultatet er det samme, men hvis browseren følger W3C's anbefalinger,
 > så vælger den ISO-8859-1 på baggrund af et kvalificeret gæt eller fordi
 > det er brugerens standard-indstilling.
 Fra RFC'en:
 <quote>
 3.4.1 Missing Charset
    Some HTTP/1.0 software has interpreted a Content-Type header without
    charset parameter incorrectly to mean "recipient should guess."
    Senders wishing to defeat this behavior MAY include a charset
    parameter even when the charset is ISO-8859-1 and SHOULD do so when
    it is known that it will not confuse the recipient.
    Unfortunately, some older HTTP/1.0 clients did not deal properly with
    an explicit charset parameter. HTTP/1.1 recipients MUST respect the
    charset label provided by the sender; and those user agents that have
    a provision to "guess" a charset MUST use the charset from the
    content-type field if they support that charset, rather than the
    recipient's preference, when initially displaying a document. See
    section 3.7.1.
 </quote>
 Så hvem har 'skylden' ?
 W3C mener det er serveren, og IETF mener der er user agenten.
 (Bemærk user agent <> browser).
 Bortset fra det synes jeg argumenteerne er baseret på 'oldtiden' -
 HTTP/1.0 , ikke konfigurerbare servere....
 Eksisterer nogle af disse useragents/servere i 'dagens danmark'?
 -- 
 Med venlig hilsen
 Stig Johansen
            
             |  |  | 
     Jonathan Stein (19-10-2011) 
 
	
          | |  | Kommentar Fra : Jonathan Stein
 | 
 Dato :  19-10-11 20:05
 | 
 |  | 
 
            Den 17-10-2011 10:07, Stig Johansen skrev:
 >> ISO-8859-1 er godt nok standard jf. HTTP-protokollen, men W3C synes
 >> alligevel ikke det er godt nok til HTML:
 >> www.w3.org/TR/html4/charset.html#h-5.2.2 >
 > Ja, men nu er det IETF, der står for RFC'erne, og ikke W3C.
 Jo, men W3C står for HTML-standarden, og det var jo et HTML-dokument, 
 det handlede om.
 HTML-standarden gælder for så vidt uanset hvilken protokol, dokumentet 
 bliver transporteret over.
 Det havde været smukkere, hvis standarderne ikke havde blandet sig i 
 hinandens områder, men når HTML-standarden foreskriver noget, må det gå 
 forud for hvad en evt. underliggende standard siger. - Specielt når 
 HTML-standarden specifikt siger, at man IKKE skal følge HTTP's default.
    M.v.h.
      Jonathan
            
             |  |  | 
      Stig Johansen (20-10-2011) 
 
	
          | |  | Kommentar Fra : Stig Johansen
 | 
 Dato :  20-10-11 08:10
 | 
 |  | Jonathan Stein wrote:
 
 > Den 17-10-2011 10:07, Stig Johansen skrev:
 >
 > Jo, men W3C står for HTML-standarden, og det var jo et HTML-dokument,
 > det handlede om.
 >
 > HTML-standarden gælder for så vidt uanset hvilken protokol, dokumentet
 > bliver transporteret over.
 
 Ja.
 
 > Det havde været smukkere, hvis standarderne ikke havde blandet sig i
 > hinandens områder,
 
 Muligvis, men ting hænger sammen ;)
 
 > men når HTML-standarden foreskriver noget, må det gå
 > forud for hvad en evt. underliggende standard siger.
 
 Der er vi nok ikke enige, for den underliggende standard er fælles for en
 masse 'ting' derfor skelnen mellem browser (HTML) og useragent (generel).
 
 Du opfatter muligvis HTML som det eneste over HTTP..?
 
 > - Specielt når
 > HTML-standarden specifikt siger, at man IKKE skal følge HTTP's default.
 
 Det er så W3C's valg, men HTTP bliver brugt til meget andet, bla SOAP/HTTP,
 REST, XML-RPC osv. osv.
 
 Vil du mene det er på sin plads at alle andre 'useragenter' skal undlade at
 følge standarderne ?
 
 --
 Med venlig hilsen
 Stig Johansen
 
 
 |  |  | 
       Jonathan Stein (20-10-2011) 
 
	
          | |  | Kommentar Fra : Jonathan Stein
 | 
 Dato :  20-10-11 21:14
 | 
 |  | Den 20-10-2011 09:09, Stig Johansen skrev:
 
 >> men når HTML-standarden foreskriver noget, må det gå
 >> forud for hvad en evt. underliggende standard siger.
 >
 > Der er vi nok ikke enige, for den underliggende standard er fælles for en
 > masse 'ting' derfor skelnen mellem browser (HTML) og useragent (generel).
 
 Jeg kan ikke se hvilken forskel det gør, at HTTP også bruges til
 transport af andet end HTML-dokumenter.
 
 Hvis man vil følge HTML-standarden, må man acceptere, at den
 tilsidesætter et specifikt punkt i en transport-protokol.
 
 M.v.h.
 
 Jonathan
 
 
 |  |  | 
 |  |