[PHP] mb_substr zonder length param, maar met encode param

[bindsa]

Ik zit met een probleem, ik wil mb_substr gebruiken zonder lengt param (dus de hele string), maar met een encoding parameter. Dit krijg ik niet werken, behalve met een ranzige bypass. Dit is wat ik geprobeerd heb:

PHP:

//Just to be sure, encode it in UTF-8 (test purposes only)
$string = utf8_encode("abcdefghijklmnopqrstuvwxyz");
//Trying to get mb_substr() return a string like $string, without the first 4 chars (encoded in UTF-8
$teststring[] = mb_substr($string, 4, NULL, "UTF-8"); //Returns empty string
$teststring[] = mb_substr($string, 4, 0, "UTF-8"); //Returns empty string
$teststring[] = mb_substr($string, 4, false, "UTF-8"); //Returns empty string
//$teststring[] = mb_substr($string, 4, , "UTF-8"); //This won't work at all
$teststring[] = mb_substr($string, 4, "UTF-8"); //Returns empty string
$teststring[] = mb_substr($string, 4, -1, "UTF-8"); //Returns the right string, exept that the last char is missing
$teststring[] = mb_substr($string, 4, mb_strlen($string, "UTF-8") - 4, "UTF-8"); //Works, but can't it be done more easy?

$reference = substr("abcdefghijklmnopqrstuvwxyz", 4);
$length = strlen($reference);
print "Reference: <br> The test should return a string with $length characters: $reference <br><br>";
foreach($teststring as $key => $value) {
    $length = mb_strlen($value, "UTF-8");
    print "Test $key returned a string with $length characters: $value<br>";
}

En de output:

code:

Reference: 
The test should return a string with 22 characters: efghijklmnopqrstuvwxyz 

Test 0 returned a string with 0 characters: 
Test 1 returned a string with 0 characters: 
Test 2 returned a string with 0 characters: 
Test 3 returned a string with 0 characters: 
Test 4 returned a string with 21 characters: efghijklmnopqrstuvwxy
Test 5 returned a string with 22 characters: efghijklmnopqrstuvwxyz

Ik zie vast iets heel simpels over het hoofd, maar ik weet niet wat Wie weet de oplossing?

[linksnl]

L0calh0st schreef op vrijdag 28 mei 2010 @ 11:32:
Ik zit met een probleem, ik wil mb_substr gebruiken zonder lengt param (dus de hele string), maar met een encoding parameter.

Het is misschien een idee om vooraf de 'internal' character encoding naar UTF-8 te zetten zodat die parameter niet meer aan mb_substr hoeft te worden meegegeven.

[bindsa]

linksnl schreef op vrijdag 28 mei 2010 @ 11:39:
[...]


Het is misschien een idee om vooraf de 'internal' character encoding naar UTF-8 te zetten zodat die parameter niet meer aan mb_substr hoeft te worden meegegeven.

Had ik ook al aan gedacht, alleen in dit geval moet ik tijdelijk even van encoding wisselen. En daarom is het makkelijker om dan gewoon voor 1 keer de encoding parameter mee te geven.

[Janoz]

//Works, but can't it be done more easy?

Kijkende naar de documentatie: nee. Wat is precies je probleem hiermee?

[Janoz]

L0calh0st schreef op vrijdag 28 mei 2010 @ 11:41:
[...]


Had ik ook al aan gedacht, alleen in dit geval moet ik tijdelijk even van encoding wisselen. En daarom is het makkelijker om dan gewoon voor 1 keer de encoding parameter mee te geven.

Tijdelijk van encoding wisselen? Zou je dat wat verder kunnen uitleggen? Het wisselen van encoding zou alleen moeten gebeuren bij de input en de output. Zorg dat je van elke input en output stroom de encoding weet en converteer waar nodig. Gebruik binnen je eigen stuk altijd maar 1 encoding.

[MueR]

Je weet dat de encoding parameter alleen aan de functie vertelt welke encoding er in gebruik is? Als je nu eens gewoon de documentatie een keer goed bekijkt en daarbji logisch nadenkt, zou je misschien kunnen overwegen om de interne encoding in te stellen op UTF8, dan ben je ook klaar. Maar hier een topic aanmaken is natuurlijk handiger.

[SoulWar1]

Als je voor de length parameter 999 gebruikt oid, dan krijg je toch ook het goede resultaat. Of zie ik iets over het hoofd?

[pedorus]

Gewoon PHP_INT_MAX gebruiken?

[MueR]

SoulWar1 schreef op vrijdag 28 mei 2010 @ 12:01:
Als je voor de length parameter 999 gebruikt oid, dan krijg je toch ook het goede resultaat. Of zie ik iets over het hoofd?

Behalve dat het een enorm ranzige constructie is die compleet onnodig is wanneer localhost gewoon de encoding parameter niet opgeeft omdat hij niet nodig is? Behalve dat er mogelijk meer tekens in die string zitten?

[ Voor 7% gewijzigd door MueR op 28-05-2010 12:23 ]

[SoulWar1]

MueR schreef op vrijdag 28 mei 2010 @ 12:23:
[...]
Behalve dat het een enorm ranzige constructie is die compleet onnodig is wanneer localhost gewoon de encoding parameter niet opgeeft omdat hij niet nodig is? Behalve dat er mogelijk meer tekens in die string zitten?

Het ging er mij meer om dat er gestunteld werd met de length parameter (-1, 0 of zelfs null), terwijl er gewoon een maximale lengte ingevuld moet worden. Natuurlijk wordt de string afgekapt als deze langer is dan die waarde en natuurlijk is het onnodig om deze te gebruiken, maar daar ging het mij niet om.

[bindsa]

Janoz schreef op vrijdag 28 mei 2010 @ 11:45:
[...]

Tijdelijk van encoding wisselen? Zou je dat wat verder kunnen uitleggen? Het wisselen van encoding zou alleen moeten gebeuren bij de input en de output. Zorg dat je van elke input en output stroom de encoding weet en converteer waar nodig. Gebruik binnen je eigen stuk altijd maar 1 encoding.

Het gaat hier om het genereren van externe files, denk aan bijv. xls en csv files. Die wil ik een net iets andere encoding versturen naar de client dan de gewone PHP output.

Je weet dat de encoding parameter alleen aan de functie vertelt welke encoding er in gebruik is? Als je nu eens gewoon de documentatie een keer goed bekijkt en daarbji logisch nadenkt, zou je misschien kunnen overwegen om de interne encoding in te stellen op UTF8, dan ben je ook klaar. Maar hier een topic aanmaken is natuurlijk handiger.

Doe even normaal. Ik heb zo m'n redenen om tijdelijk even van encoding te wisselen (zie eerder deze post). Door je post lijkt het of ik van tevoren niet naar de document heb gekeken, dat kan je niet weten en dat is ook niet het geval. Om maar even duidelijk te maken:
- Ik heb alle documentatie over functie parameters bekeken
- Heb gekeken wat de default value was van de length parameter (die bleek er niet te zijn)
- Tot slot heb ik zelf een aantal testcases gedaan met alle mogelijk values die PHP zou kunnen interpreteren als default (0, false, NULL enz.)
- Ik heb zelf alternatieven bedacht (mb_strlen)

Dus aan logisch nadenken ontbreekt het niet. De enige reden dat ik dit topic open, is dat ik dacht dat ik misschien iets over het hoofd zag, en dat wou ik hier even vragen, of mag dat soms niet?

[ Voor 49% gewijzigd door bindsa op 28-05-2010 17:12 ]

[Janoz]

L0calh0st schreef op vrijdag 28 mei 2010 @ 17:08:
[...]


Het gaat hier om het genereren van externe files, denk aan bijv. xls en csv files. Die wil ik een net iets andere encoding versturen naar de client dan de gewone PHP output.

Dus output.. Waarvoor heb je de substring methode dan nodig? Je hoeft dan alleen maar bij het daadwerkelijk wegschrijven de encoding goed hebben staan.

Ik moet je echter wel meegeven dat het in PHP nu eenmaal niet zo heel triviaal is, maar dat komt voornamelijk omdat de mensen achter php zelf eigenlijk geen reet begrepen hebben van het hele encoding verhaaltje.

Doe even normaal. Ik heb zo m'n redenen om tijdelijk even van encoding te wisselen (zie eerder deze post). Door je post lijkt het of ik van tevoren niet naar de document heb gekeken, dat kan je niet weten en dat is ook niet het geval. Om maar even duidelijk te maken:
- Ik heb alle documentatie over functie parameters bekeken
- Heb gekeken wat de default value was van de length parameter (die bleek er niet te zijn)
- Tot slot heb ik zelf een aantal testcases gedaan met alle mogelijk values die PHP zou kunnen interpreteren als default (0, false, NULL enz.)
- Ik heb zelf alternatieven bedacht (mb_strlen)

Dus aan logisch nadenken ontbreekt het niet. De enige reden dat ik dit topic open, is dat ik dacht dat ik misschien iets over het hoofd zag, en dat wou ik hier even vragen, of mag dat soms niet?

Toch zit er een punt in hetgeen je op reageert. Je moet goed beseffen dat je niet een string hebt die je omzet in een encoding. Je hebt een set bytes in de ene encoding die je omzet naar de andere encoding. Het tussentijds bewerkingen gaan doen en daarbij maar een beetje de encoding parameters lopen toevoegen is eerder een garantie voor volledige fuckups dan voor een werkend geheel.

Het is al vaak langs gekomen, maar ik wil je toch aanraden om het stuk van Joel eens te lezen.

[bindsa]

Janoz schreef op vrijdag 28 mei 2010 @ 17:19:
[...]


Dus output.. Waarvoor heb je de substring methode dan nodig? Je hoeft dan alleen maar bij het daadwerkelijk wegschrijven de encoding goed hebben staan.

Ik moet je echter wel meegeven dat het in PHP nu eenmaal niet zo heel triviaal is, maar dat komt voornamelijk omdat de mensen achter php zelf eigenlijk geen reet begrepen hebben van het hele encoding verhaaltje.

[...]


Toch zit er een punt in hetgeen je op reageert. Je moet goed beseffen dat je niet een string hebt die je omzet in een encoding. Je hebt een set bytes in de ene encoding die je omzet naar de andere encoding. Het tussentijds bewerkingen gaan doen en daarbij maar een beetje de encoding parameters lopen toevoegen is eerder een garantie voor volledige fuckups dan voor een werkend geheel.

Het is al vaak langs gekomen, maar ik wil je toch aanraden om het stuk van Joel eens te lezen.

Het zit als volgt:
- De output van de app zelf is ISO-8859-15 encoded
- Dus internal encoding staat op ISO-8859-15
- In de applicatie gebeurt het volgende:
- Ik lees CSV uploads van users in (UTF8-encoded)
- Die parse ik string voor string, en bewerk ik dan
- Omdat de encoding UTF8 is, heb ik de mbstring extensie nodig
- Het bewerkte bestand bied ik vervolgens weer als download aan de user aan

[Gomez12]

L0calh0st schreef op vrijdag 28 mei 2010 @ 21:45:
[...]


Het zit als volgt:
- De output van de app zelf is ISO-8859-15 encoded
- Dus internal encoding staat op ISO-8859-15
- In de applicatie gebeurt het volgende:
- Ik lees CSV uploads van users in (UTF8-encoded)
- Die parse ik string voor string, en bewerk ik dan
- Omdat de encoding UTF8 is, heb ik de mbstring extensie nodig
- Het bewerkte bestand bied ik vervolgens weer als download aan de user aan

Maak nu eens een scheiding app / script ( of app / classes )

Zoals ik het nu lees is :
- Of het inlezen / bewerkingen doen / output genereren een apart stuk wat niets met de rest van je app te maken heeft, dus kan dat script best een andere coding pakken
- Of je zit in je bewerkingen al te klootviolen met encodings en dan zou ik zeggen : bij input encoding converteren naar je interne encoding, en bij het outputten je interne encoding converteren naar de uiteindelijke encoding

[MueR]

En dan werkt dit niet?

PHP:

mb_internal_encoding('UTF-8');
doMyStuff();
mb_internal_encoding('ISO-8859-15');

[Gomez12]

@MueR : Het zal vast wel werken, maar persoonlijk zou ik de scheiding toch ietwat duidelijker maken ( Totaal ander script oid )...

Dit soort geintjes gewoon midden in een script zetten lijkt mij een disaster waiting too happen, ooit gaat er iemand even over die beginregel heenlezen en een verkeerde functie / verkeerde data pakken en dan heb je de poppen aan het dansen.

Scheid dan liever gewoon de scripts die dit soort dingen moeten doen af in aparte directory...

[Voutloos]

WTF probeer je met mb_substr() te doen.

Er is gewoon een functie voor het converteren van de encoding van een string. 1x op de logische plek mb_convert_encoding() gebruiken en klaar ben je. Of je bekijkt eerst de andere gerelateerde functies voordat je op de gok een substring functie gaat verbouwen in de hoop dat het een encoding probleem oplost.

[bindsa]

MueR schreef op vrijdag 28 mei 2010 @ 22:22:
En dan werkt dit niet?

PHP:

mb_internal_encoding('UTF-8');
doMyStuff();
mb_internal_encoding('ISO-8859-15');

Dat werkt wel Vroeg me alleen af of er niet in PHP een manier was om een parameter gewoon te skippen ofzo.

[Cartman!]

Tja, PHP kan natuurlijk niet ruiken wat voor encoding jij wilt bij een wijziging

[bindsa]

Cartman! schreef op zondag 30 mei 2010 @ 09:49:
Tja, PHP kan natuurlijk niet ruiken wat voor encoding jij wilt bij een wijziging

Ik bedoel dat ik de length parameter skip en wel een encoding invul, maar dat schijnt dus niet te kunnen

[steffex]

voor het encoden van de hele string hebben ze een functie gemaakt, namelijk: mb_convert_encoding(klikbaar).

substr gebruiken om de gehele string terug te geven is dan ook wel beetje omslachtig...
Volgende keer iets beter de manual doorlezen...

[ Voor 8% gewijzigd door steffex op 31-05-2010 08:44 ]

[Voutloos]

Dat zei ik dus ook al. Ik snap echt niet wat je van een substring functie verwacht zonder een lengte parameter, en hoe je er in *&@%%naam op komt dat het voor het converteren van encodings is.

[Janoz]

Substring heeft naast de length ook nog een offset parameter, dus er is genoeg dat je kunt doen met een substring functie zonder length.

Ook krijg ik niet de indruk dat de topicstarter daadwerkelijk de conversie met de substring methode wilde doen, maar gewoon een set bewerkingen uit wilde voeren op data die in een specifieke encoding zat.

Wat de topicstarter zich voornamelijk afvroeg was of er ook een manier was om zelf te kiezen voor welke parameters je de default waarde wilde gebruiken, maar hij moet nu tot de conclusie komen dat dat niet mogelijk is en dat je alleen de laatsten weg kunt laten.

[pedorus]

Bij UTF-8 worden de eerste 128 tekens niet gebruikt in de multi-byte characters. Je kunt dus prima csv parsen zonder je iets van mb-characters aan te trekken. De utf8_encode op de tweede regel van je TS zal dus ook niets doen.

Verder is iconv standaard en mbstring niet. En daarnaast wordt utf-8 standaard in php6, waarom gebruik je nu ISO-8859-15? Dan heb je bijvoorbeeld opeens $double_encode=false nodig. Tweakers gebruikt ook deze encoding, maar dat is alleen maar vanwege historische redenen, terwijl ik het vermoeden heb dat het om een relatief nieuwe applicatie gaat.. .

[bindsa]

Janoz schreef op maandag 31 mei 2010 @ 10:01:
Substring heeft naast de length ook nog een offset parameter, dus er is genoeg dat je kunt doen met een substring functie zonder length.

Ook krijg ik niet de indruk dat de topicstarter daadwerkelijk de conversie met de substring methode wilde doen, maar gewoon een set bewerkingen uit wilde voeren op data die in een specifieke encoding zat.

Wat de topicstarter zich voornamelijk afvroeg was of er ook een manier was om zelf te kiezen voor welke parameters je de default waarde wilde gebruiken, maar hij moet nu tot de conclusie komen dat dat niet mogelijk is en dat je alleen de laatsten weg kunt laten.

Klopt helemaal. Dat was wat ik moest weten, bedankt