(PHP) Kan inte skriva ut å ä ö?

Gör aldrig så här, det är en dålig lösning på ett problem som inte finns. Använd rätt encoding på filen istället, förslagsvis utf-8 som har rekommenderats ovan.

Detta är inte heller en bra lösning. Om texten redan är utf8-kodad kommer tecknena bli dubbelenkodade och man får ett annat tecken.

PHP är inte det bästa valet om du ska arbeta med UTF8, faktum är att det är det sämsta valet du kan välja ifall du ska göra hemsidor som stödjer UTF8. Både Ruby on rails & ASP.NET är betydligt bättre val där.

I alla fall för att hjälpa dig lite på traven så kolla in dessa klasser, http://php.net/manual/en/ref.mbstring.php

de löser en del Unicode problem PHP har men inte allt.

Nu för tiden kör man oftast med utf-8 på allt. Visst tar lite mer plats, men lätt värt det.

Skickades från m.sweclockers.com

Tja, PHP är dåligt på det mesta så det skulle inte vara direkt överraskande. De flesta andra ramverk tar UTF-8 seriöst utan att skapa en massa överflödiga multibyte-funktioner för att täcka för behovet.

Ja må hända vara det dummaste du har hört men det betyder inte att det inte är sant, det finns stora allvarliga brister i PHP's hantering av UTF8, Känner du inte till dom kommer du ha ett stort rejält helvette att arbeta med UTF8 baserade hemsidor.

Det är lätt att man inte upptäcker detta om man ENBART sitter med t.ex. Engelska, eller olika sorters ASCII rymder som T.ex Svenska (latin1), men sitter du och faktiskt arbetar med UTF8 utöver engelska tecken så kommer du stöta på problemen, vissa av dom är riktigt jobbiga att hantera också.

Vist går det lösa det mesta, men i PHP's fall så måste du jobba runt problemet och det ger enormt mycket extra arbete. Ska du skriva en sida idag som faktiskt behöver UTF8 så är det ett bättre val att välja ett annat språk. PHP är inte ultimata valet för allt du gör där ute.

mb_strtolower($str, 'UTF-8');

strtolower($str);

Tja största problemet är att det kan gå fel där med ja, Är strängen du får T.ex. inte UTF8

I alla fall som standardvärden så hanteras det som UTF8 så du slipper definiera UTF8 samt det finns plugin som byter ut alla alla standard metoder med mb_ så du faktiskt slipper skriva dom. Men detta är bara ett plåster ovanför det redan misslyckade UTF hanteringen. Dock vissa sidor kommer inte detta funka så bra på och som alla vet så använder php globala inställningar och inte applikations baserade inställningar.

samt denna sida har en bra lista med UTF8 relaterade PHP problem
http://www.phpwact.org/php/i18n/utf-8

------

Men för att få lite mer värkliga problem jag har haft som inte precis är allt för lätta att lösa ( Går att lösa genom att jämföra UTF-8 adress rymder men det går in förbaskat mycket tid in här för att lösa det )

T.ex. ska du matcha strängar, så vist kan man göra en byte check eller en string check. T.ex. många språk så finns det dubbla och om inte mer uppsättningar av samma tecken i olika adressrymder beroende på beteende.

T.ex. Engelska alfabetet & Hiragana/Katakan här har vi Half-width form. Troligtvis har ni nog aldrig någonsin hört om detta men tja nu har ni.

Vill ni t.ex. göra en vettig sträng compare så kommer den misslyckas i PHP då den saknar bland anant det totalt samt då det inte är "samma" tecken mellan A och Ａ. T.e.x i C# så behöver du inte bry dig mer eller mindre alls då du kan göra en string compare som hanterar detta. Detta är bland annat ett rent helvette i PHP som många t.ex. inte känner till.

Det handlar om att textfilerna man skriver sparas med UTF8-kodning.
PHP i sig har inga svagheter med någon form av teckenkodning. Den skriver ut det som skrivs i textfilerna/databaserna.

<code>_encode -kommandona i PHP används i de få fall man behöver mata ut med en annan kodning än den som php-scriptet i sig sparades med.
T.ex utf8_encode för att skriva up UTF8-kodad text från ett dokument sparat i cp1252 t.ex. (cp1252 är Windows standard-kodning. Notepad t.ex sprarar alltid med teckenkodning cp1252 )

Tre krav för att få fullt stöd för en specifik teckenkodning:

1. Textfilerna som håller scripten/koden sparas i den aktuella teckenkodningen. Detsamma gäller databaser.

2. Utmatningen från webbservern sker i den valda teckenkodningen. De flesta webbservertjänsterna använder samma kodning som textfilerna använder sig av.

3. Webbläsaren kan tyda och se att dokumentet den läser är av den aktuella kodningen.
   Fölr HTML gäller det att lägga till meta-taggen som talar om för webbläsaren att man matar utmed en given teckenkodning. I det här fallet UTF8.

Litet tillägg. Funktionen utf8_encode() är olyckligt namngiven, den konverterar egentligen från ISO-8859-1 till UTF-8. Om inputsträngen använder sig av en annan tabell kan man få oväntade resultat, Windows-1252 innehåller t.ex. tecken som inte finns i ISO-8859-1 och dessa kommer inte konverteras rätt.