brugen af strlen() og æøå mv

Funktionen virker skam præcist efter hensigten, det er blot dig som giver funktionen forkert input :)

Filens kodning kan nemlig resultere i at æøå ikke opfattes korrekt, sørg for at filen er i UTF-8 formatet.

Alternativt kan du også gøre det i koden:

Brug mb_strlen() i stedet for strlen().

Jeg har skrevet noget om det her : http://scootergrisen.dk/htmlgrisen/kode_strenge.php#multibyte_funktioner

Kræver at du bar mbstring installeret. Hvis ikke du har det så kør PHP installationen igen og tilvælg mbstring.

Det fordi når du gemmer din fil som UTF-8 så fylder tegn som Æ 2 byte. Men strlen() opfatter 1 byte som 1 tegn så det går galt.

Der finder i øvrigt mange af de her erstatningsfunktioner til strenge hvor du tilføjer mb_ foran funktionsnavnet.

<ole>

Der er mange alternativer ... f.eks:


/mvh
</bole>

ole,

$str = 'Øl';
$len = count(str_split($str));

$len indeholder tallet 3 hos mig. Vil du prøve igen? :-)

@lclemens: Ja, det kan jeg da godt se! Jeg havde forestillet mig, at dokumentationen holdt vand:


Men det var nok lidt naivt. Der skulle tydeligvis have stået:

Tja, man kunne jo læse begyndelsen af dokumentationen



:-)

Nu var det dokumentationen for str_split, jeg tænkte på. Det burde ikke være nødvendigt at skulle ned i grunddokumentationen for at finde en disclaimer, som forklarer, at sproget er skrevet i et andet årtusindes paradigme - og at al dokumentation skal læses i dette lys.

I 2012 burde den slags explicit fremgå under de berørte funktioner  =)

Du begår da ikke samme fejl som fandens oldemor :-)

Substansen er, at PHP på mange områder er outdated - og at den slags væsentlige 'detaljer' naturligvis explicit bør fremgå af dokumentationen for de berørte funktioner.

Hvis man mener, det er udtryk for en dårlig undskyldning, er det måske, fordi man selv har brug for en  *o)

Man kører jo heller ikke over for rødt, selv om man ikke explicit har fået fortalt, at det må man ikke i dét kryds.

:-)

Nej, det ville da være totalt idiotisk!

Men til gengæld er der næppe nogensinde en myndighed, som vil være så tåbelig at skrive:

"Krydset kan frit passeres!"

- underforstået: "- men som færdselsloven foreskriver: Kun når der er grønt lys!"

Forskellen på 'dokumentation' og 'snik-snak' er, at dokumentationen skal være explicit  *o)

PS: og så er dit eksempel faktisk ret misvisende  =)

PHP er beregnet til pre processing af HTML. Multibyte tegnsæt er forlængst blevet de facto tegnsæt på WWW, så det burde i udgangspunktet kunne forventes, at sprog, som behandler webdokumenter, i er indrettet på dette.

Sagen er jo netop, at man ved 'din' lyskurv forventes at køre overfor rødt, mens man alle andre steder holder tilbage. Derfor burde du nok have sat et skilt op, som forklarede forskellen  *o)

Dokumentationen gør tydeligt opmærksom på, at et tegn i en php-streng altid er én byte. Du kan altså ikke sno dig uden om.

Som Rudy S. Kleutzner så sandt siger det: "Har man ikke pære, må man ævle!"

En PHP string indeholder bytes.

Derved kan en PHP string indeholder:
- tekst i single byte encoding
- tekst i multi byte encoding
- binary data

Teksten øverst i http://www.php.net/manual/en/language.types.string.php er faktisk forkert, men længere nede kommer den rigtige forklaring i http://www.php.net/manual/en/language.types.string.php#language.types.string.details så det er dokumenteret.

Visse tekst funktioner bl.a. str* virker kun med single byte encoding.

Andre tekst funktioner bl.a. mb* virker også med multi byte encoding.

Dette er dokumenteret i dokumentationen for string (se link).

str* funktioner angiver at det tager string som argument. Og flere af dem har endda hyperlink til beskrivelsen af string.

Det burde være tilstrækkeligt.

Det er ikke specielt logisk at strenge i et sprog brugt til web apps skulle være i UTF-8 encoding bare fordi output er det. Intern og ekstern brug er forskellig. UTF-8 har nogle fordele som eksternt format p.g.a. ASCII kompabiliteten. Men UTF-8 er ikke særlig god til internt brug p.g.a. den variable længde - at finde et index er O(n) fremfor O(1). ASP, ASP.NET og Java EE bruger da også UTF-16.

Var det en fejl at PHP ikke fik unicode support for 17 år siden? Ja! Men det er baseret på hvad vi ved idag. Dengang var unicode ret ny og det var langtfra åbenlyst at unicode ville slå igennem.

Kan man ændre string til at være UTF-16 idag og derved få bedre unicode support? Nej! Det ville breake alt for meget eksisterende kode.

Det var så vidt jeg ved hvad der var planlagt for PHP 6 - og kompabilitets problemerne er grunden til at PHP 6 er udskudt på ubestemt tid.

Kunne man tilføje en ny widestring data type med tilhørende wcs( funktioner og L"..." literals? Ja! Det har andre sprog gjort (C/C++).

Vil man gøre det? Aner det ikke!

Nej, det er efter min mening ikke tilstrækkeligt. Hvis der var tale om konsistens ville jeg måske være enig, men det er der ikke.

Lad os tage tilfældet med denne tråd: Jeg læser spørgsmålet og tænker: "Det må da være fordi, PHP ser strengen som bytes og tæller derefter".

Så får jeg tanken: "Der er da vist en streng-splitter-funktion, så man kunne tælle elementer i det resulterende array. Gad vide, om den er 'byte-safe'?".

Jeg hopper op til strengfunktionerne på php.net og finder str_split. Her finder jeg ingen 'disclaimers', men teksten i #5. Derfor tjekker jeg funktionen strlen, som spørgsmålet drejer sig om. Her finder jeg følgende, tydelige notice:


Her ligger tanken jo snublende nær, at str_split på dette punkt adskiller sig - men det ville selvfølgelig forudsætte en passende konsistens, som ikke synes tilstede.

En eller anden i Zend synes at være af den opfattelse, at det er et stykke info, som fortjente at blive nævnt under den ene funktion. Enten har andre opdateret de øvrige strengfunktioner, eller også finder personen det - af for mig uransagelige årsager - ikke fundet det passende at bringe samme info dér.

"str* funktioner angiver at det tager string som argument. Og flere af dem har endda hyperlink til beskrivelsen af string."

Ja, jeg kan umiddelbart se to(!) med link til String: strlen og strtr. Den første har, som allerede nævnt, en 'disclaimer', og ved den sidste står tydeligt anført:


Hvis disse to deldokumentationer var udtryk for en konsistent holdning fra Zend, ville jeg også mene, at "Det burde være tilstrækkeligt". Men det er det ikke, og det er såmænd blot det, jeg efterlyser.

Jeg er helt med på de historiske årsager til, at PHP ikke i udgangspunktet fik Unicode support - og at det altid er svært, grænsende til umuligt, at ændre den slags, når et sprog først er blevet udbredt. Jeg er også opmærksom på, at utf-8 ikke er 'det perfekte' tegnsæt, og at det i andre sammenhænge giver andre problemer.

Min pointe er blot, at PHP's dokumentation på dette punkt ikke er tilstrækkelig konsistent. Enten bør man vælge at være eksplicit - eller også bør man lade være. Det er uhensigtsmæssigt at være det ved nogle funktioner, men ikke ved andre.

Er det tvingende nødvendigt? Det er der jo ikke meget, der er.

Vil det være mindre forvirrende for folk, der ønsker at lære PHP - og for folk, der har brug for et hurtigt opslag? Det ved jeg ikke objektivt, men jeg mener, der er god grund til at tro det.

Konsistens har aldrig vaeret PHP's staerke side.

PHP er klart bazaar og ikke cathedral.

Bare den kendsgerning at string funktionerne hedder xxxxxx, strxxx og str_xxx er inkonsistent.

Men saadan er det altsaa.

Folk der vil laere PHP boer klart laese om string om andre typer, saa de faar det basale paa plads.

Og jeg vil formode at folk der arbejder med PHP dagligt kan den slags.

Kan det vaere tricky for folk som kun arbejder med PHP en gang imellem og maaske har glemt lidt siden sidst? Ja da.

Men jeg synes ikke at det er specielt for PHP at man ikke repetere string koncepter under string funktioner. Java, .NET, standard C, standard C++ goer ikke. De eneste jeg kender som goer det er faktisk MS C (men det er ogsaa rigtigt grumset med str, wcs, mbs of tcs).

Jeg arbejder dagligt med PHP, men har ikke brugt str_split i meget lang tid. Jeg tvivlede selv på, at den ville virke og slog den derfor op.

Jeg så ikke en 'disclaimer' og checkede strlen. Da jeg er vandt til PHP's håndtering af strenge, er lige den slags info ikke noget, jeg normalt kikker efter, når jeg bruger dokumentationen. Derfor gik jeg lidt naivt udfra, at når det stod ved den ene funktion, måtte den, det ikke stod ved, være 'utf-8-safe'.

Det mener jeg sådan set ikke - heller ikke ved efterrationalisering - er spor underligt. Sådan burde en dokumentation forventes at kunne bruges ... i min verden, that is  =)

"Men jeg synes ikke at det er specielt for PHP at man ikke repetere string koncepter under string funktioner. Java, .NET, standard C, standard C++ goer ikke. De eneste jeg kender som goer det er faktisk MS C (men det er ogsaa rigtigt grumset med str, wcs, mbs of tcs)."

Nej, det er ikke specielt, men én eller anden hos Zend har jo i hvertfald ment, det var hensigtsmæssigt at skrive ved to af String funktionerne.

Er det relevant for de to, må det også være det for resten. Er det ikke relevant for resten, burde det heller ikke være relevant for de to.

Det er lidt ligesom med bankrådgivere. De kan give råd - eller de kan give råd (som i 'gode råd' henholdsvis 'råddenskab'). Dokumentation bør give råd (læs: vejledning/overblik) ... ikke råd (læs: vildledning/forvirring)  *o)

Jeg ved godt, at en radikal forklaring lyder, at "Sådan er det jo". Ja, det er det jo - men mit argument er såmænd også bare, at det er ikke hensigtsmæssigt  =)

Tillader mig at lukke spørgsmålet