Åäö direkt i tpl.php-filerna?
Hej, ett problem som jag stött på med Drupal ett tag nu och som kan vara riktigt irriterande är saknaden av att använda ÅÄÖ direkt i tpl.php-filerna (page.tpl.php, block.tpl.php osv). Jag fattar inte varför det inte fungerar. Direkt i Drupals noder fungerar det ju såklart, men ibland om man vill ha statisk text t.ex. någon slags slogan så måste man alltid skriva ä, ö och å istället för åäö. Jag har provat lagt till en ny meta-tagg som tar fram ISO eller UTF-kodning direkt i dokumentet men det fungerar inte. Det största problemet jag har nu är att jag ska ha jQuery och jag måste ha ordet "Välj" i koden, men det blir istället ett frågetecken istället för "ä".
Jag har provat sätta "Vunescape("%C4")lj"); (%C4 är "ä" på javascript-kodning) men det fungerar inte, trots att det gjorde det på en annan hemsida jag har. Jag provade även lägga drupal_add_js direkt i blocket, men i just detta läget verkar det inte fungera, jag måste ha koden i page.tpl.php. Hur fasen ska jag göra? Enklast vore ju om det gick att ändra kodningen med någon meta-tagg eller nåt, jag kanske gjorde fel tidigare.
Just nu ser det ut såhär, och det är ju inte kul:
<script type="text/javascript" charset="UTF-8">
$(function() {
$("#edit-lan option:first").text("Valj butik");
$("#edit-lan option:first").val(0);
});
</script>
Oj, glöm alltihop! Lösningen
Oj, glöm alltihop! Lösningen var att spara dokumenten som UTF-8. Jag använder notepad++, så då går man upp till Format -> Koda i UTF-8. :)
Jag fick en flashback från
Jag fick en flashback från mitten av nittiotalet när man skrev
äoch andra tecken för hand i HTML :DJo, det var mest frustrerande
Jo, det var mest frustrerande förut när jag satt och stylade ett webbformulär direkt i en webform-mail.tpl.php. Så för varje åäö var jag tvungen att skriva i ascii... :P
Heh
Php och UTF-8... Det där problemet har jag slitit mitt hår över, särskilt när någon annan sparar över ens fil med typ Windows-1252. Skitbra det blir då.
Nån som vet varför det är som det är, dvs vad är anledningen till att php fullkomligt skiter i vad som står i php.ini och istället tittar på filformatet? Man kan ju tycka att php borde vara såpass smart att den kan konvertera från det ena till det andra utan att man ska behöva ändra encoding etc.
Hoppas jag inte får till allt
Hoppas jag inte får till allt för svåra sakfel nu... (lite trött i pallet efter att ha bråkar med IE7 hela dagen...)
Har inte med PHP att göra... det har med webbläsaren att göra.
När webbläsaren börjar tolka det den får tillbaka hittar den information om teckenkodning... i allmänhet UTF-8 (utan BOM, men det står det inte något om). Om då hela, eller delar av, sidan är lagrad i något annat teckenkodningsformat... ja vad ska webbläsaren göra då?
"Men kan inte PHP lösa det?" (OBS! Fiktiv fråga... ingen har ställt den)
Det innebär att PHP ska ta ett ansvar för att fastställa om du avsiktligt eller av misstag lagras en fil med Latin-1. Dessutom krävs det att PHP frågar webbläsaren ska du ha det som UTF-8, och det vet inte webbläsaren... för det är HTML-koden som ev. styr det.
Hypotetiskt: Vad ska PHP göra om du avsiktligt petar in Latin-1, fast du vet att webbläsaren kommer tolka det som UTF-8? Ska man sätta en flagga i filen som säger... "Jo, jag vet att det är fel format så PHP strunta i detta tack..." ;-)
Hur som haver, låt säga att du lagrar bokstaven Ä i Latin-1 och din webbläsare vill ha UTF-8. Det som skickas till webbläsaren är 0x00C4... Men det betyder bara Ä om webbläsaren tolkar det som Latin-1. Men i UTF-8 blir det knas.. (Ä i UTF-8 kodas 0xC384).
I UTF-8 har inte ens kodning mellan 0x0080-0x-00FF någon egentlig innebörd som tecken. Vilken av alla ISO-standarder skulle få populera detta kodområde? Nä, alla IS0-standarder fick finna sig i att derar högre "adressrymd" flyttades upp i 0x0100-0xFFFF.
"Men varför blir inte A-Z m.fl. knas?" (OBS! Fiktiv fråga igen...)
Jo, det beror på att man var "smarta" när man skapade UTF-8 och utgick ifrån att det var viktigt att lagra dessa tecken på samma sätt.
Så A lagras som 0x0065 i Latin-1, och det är exakt samma kod som används för att lagra det i UTF-8. Dvs. alla tecken definerade i 0x0000-0x007F är samma för IS0 och UTF-8.
//marcus - StrategIT
0x0000-0x007F - Mer info...
Som jag sa, 0x0000-0x007f är lika i både UTF-8 och ISO. Detta beror på att det har sitt ursprung i ASCII-koderna.
Dvs.
0x0000-0x001f är inte fastställda, inte heller 0x007f.
0x0020-0x007e är tilldelade, och har samma tecken i båda.
Och åter igen, ISO 0x0080-0x00FF har olika betydelse beroende på vilket ISO-format det lagras som. Därför har man inte "rakt av kopierat" dessa värden, utan låter dem husera i någon del av UTF-8 som ligger i 0x0100 och uppåt.
//marcus - StrategIT