Problem med substr och ÅÄÖ
 

Hur kringgår man detta problem? Att åäö verkar räknas som två tecken var.

Har inte för mig att det varit såhär tidigare... Aldrig haft problemet innan...
Dokumentet är sparat som UTF-8 (utan BOM), samt att jag lagt till header('Content-type: text/html; charset=utf-8');

Använd mb_substr istället.

tack... men varför är det så här dumt gjort?

Enkelt förklarat, UTF8 sparar icke-ASCII i två bitar (två tecken). Jmfr. "two bit characters"

Kan väl tillägga att du inte är ensam om att få problemet och även om man har vetat om det förut så hinner man glömma det till nästa gång och då sitter man och kliar sig i skallen och undrar varför... :)

Har du en bättre lösning? :) Det finns en hel del tecken som ryms inom utf-8.

:) njä, men syftade väll snarare till varför substr + andra funktioner inte automatiskt åtgärdade detta. Kan inte komma på en vettig situation då man faktiskt vill att det skall fungera som det gör nu, istället har man skapat en annan liknande funktion :P onödigt :)

Det är hål i huvudet att inte bygga funktioner som klarar av UTF från början. Ett tråkigt utslag av amerikansk etnocentricitet.

Då har du förstås aldrig jobbat med binärdata heller? Det finns gånger då man vill veta hur många byte det är utan att funktionen gör automatiska antagningar om teckenkodningen.

Dessutom står det ju klart och tydligt i manualen vilken teckenkodning funktionen använder (ISO-8859-1 som resten av PHP). Det är du som vill köra en annan teckenkodning än funktionen är byggd för. Fast visst vore det smidigt om substr hade samma funktion som mb_substr har idag, med en tredje parameter för teckenkodningen.

Det står var och en fritt att laga PHP. Dess rötter är i ett fulhack från långt tillbaka, så det är klart att inte allt bytt till det senaste på tapeten. UTF-8 var bara ett par år gammalt när första versionen av PHP skapades. Användningen av ISO-8859-1 var däremot utbredd.

Vad Israel har med "amerikansk etnocentricitet" att göra vet jag dock inte; PHP är som bekant en israelisk produkt.

Suck. Den typen av argument (är du inte nöjd med opensource så skriv om det själv då) trodde jag vi hade lagt bakom oss på ett sånt här forum.
Visst kan jag skriva om hela PHP, blir säkert klar i eftermiddag, eller kanske till lunch om jag jobbar på, men det är strategiska beslut i bakom sådant som vilka teckenkodningar man ska stödja och det är generellt sett påfallande ofta amerikanska utvecklare som utgår från att världen inte behöver något annat än latin1 och att man kan bortse från resten av världens bokstäver.
Rasmus Ledorf som är den ursprunglige skaparen av PHP är inte israel, utan snarare född grönländare, delvis uppvuxen i och numera bosatt i Kanada. Om Gutmans eller Suraski ägnade teckenfrågan en tanke vet jag inte. Jag är tillräckligt gammal för att ha varit med på den tiden man använde 7-bitars teckenkod och vet att det inte var lätt att tänka mångfald om tecken då, men ett dåligt beslut är ett dåligt beslut även om man inte visste bättre då.
Nu har PHP vänt strategi och ska hantera UTF fullt ut vilket gör att jag sliper skriva om hela kodbasen själv som du föreslår. Men gamla funktioner finns tyvärr fortfarande kvar och används antagligen slentrianmässigt även i nyskrivna projekt. I manualen noteras inte att substr() inte hanterar UTF korrekt utan det får man reda på först när man läser användarnas kommentarer. En uppdatering där borde man unna sig.

Nja, det är väl inte helt sant. UTF var inte särskilt utbrett tidigare och flera av Sveriges största sajter använder det ännu inte. Det finns ingen större anledning att byta till UTF om man inte kör det från första början vilket givetvis är att föredra.

Det känns ändå mer logiskt att behålla de gamla funktionerna som de är och införa nya för mb-uppsättningar precis som man gjort. Att köra mb-funktioner är dessutom betydligt långsammare i många fall, särskilt vad gäller strtoupper och strtolower.

Det finns ingen större poäng med att skriva kommentarer på varje sträng-funktion utan där ska endast viktig och EJ överflödig information finnas med för att manualen ska vara just snabb, smidig och översiktlig. Övrigt hör hemma just i användarkommentarerna. Det framgår med all önskvärd tydlighet redan i de inledande styckena i manualen hur tecken och strängar i PHP är uppbyggda:

http://www.php.net/manual/en/language.types.string.php

Hur variabler och typning fungerar är väl ändå bland det första man lär sig när man tar sig an ett nytt programmeringsspråk?

Jag kör UTF-8 på alla webbplatser jag utvecklar.
För att kunna hantera den här typen av problem så använder jag en samling funktioner som finns att ladda ner här:
http://sourceforge.net/projects/phputf8/

Om du inkluderar detta bibliotek som standard i din kod så har du tillgång till alternativ till alla funktioner som hanterar strängar och teckenlängder.
T.ex:
substr -> utf8_substr
strpos -> utf8_strpos
strlen -> utf8_strlen
etc.

Helt ovärderligt för mig i alla fall!

Tack för alla bra svar.

Lite synd att diskussioner måste bli så hetsiga och penislängden måste mätas om och om igen här på WN ibland. :P

Men men, antar att någon snart svarar mig att jag kan skapa mitt egna J*VLA forum om jag inte är nöjd ;)

Ha det!