[PHP] Base 64 decoding

[Anoniem: 9905]

Ik ontvang in een PHP script een stuk tekst wat in BASE64 gecodeerd is. Via de PHP functie base64_decode() decodeer ik deze tekst. Dit gaat goed, met uitzondering van één onderdeel: de enter/carriage return. Deze wordt niet meegenomen, waardoor opgemaakte tekst verandert in een enkele (lange) regel tekst. Decodeer ik de gestuurde tekst met een willekeurige andere BASE64 decoder (heb er online ene paar geprobeerd, een JAVA en een Python versie), dan wordt de brontekst wel goed gedecodeerd. Conclusie: PHP decodeert BASE64 niet goed middels base64_decode().
Nu kan PHP opzich via imap_base64 dit decoderen. Ik weet niet of dit een oplossing zou kunnen bieden, maar voor mij is dit helaas niet toepasbaar (omdat het PHP platform waar ik op werk geen imap/c-client ondersteuning heeft en kan hebben).

Wie kan me hier helpen? Ik maak gebruik van de PHP 5.1.x. Is er wellicht iemnand die een PHP filetje voor me heeft met een andere implementatie van een BASE64 decoder?

(ja ik heb voldoende gezocht naar oplossing maar zonder resultaat)

[GlowMouse]

In dit topic worden enkele custom base64_encode functies gegeven. Op eenzelfde manier zou je ook met een eigen functie kunnen decoden.

[ Voor 4% gewijzigd door GlowMouse op 08-03-2006 17:43 ]

[MarkvE]

Het zou vreemd zijn als PHP dit niet goed doet. Als het zo is zou er ook een entry op bugs.php.net erover te vinden moeten zijn (is aannemelijk dat het dan al eens geconstateerd is). Kan het niet liggen aan de manier waarop het base64 gecodeerde gedeelte naar PHP wordt verzonden (of ontvangen wordt) door PHP?

Misschien dat http://nl2.php.net/manual/en/function.chunk-split.php je kan helpen als het gaan om restricties bij een te lange regel code (slechts een suggestie).

[Anoniem: 50683]

Probleem met BASE64 is dat er wat varianten zijn:
- wel/geen cr/lf's op einde regel
- wel/geen uitvulteken

Ben ook paar keer tegengekomen dat de ene routine de data van een ander niet kan uitpakken.

[BasieP]

Anoniem: 50683 schreef op woensdag 08 maart 2006 @ 17:52:
Probleem met BASE64 is dat er wat varianten zijn:
- wel/geen cr/lf's op einde regel
- wel/geen uitvulteken

Ben ook paar keer tegengekomen dat de ene routine de data van een ander niet kan uitpakken.

van dat eerste word de data niet anders, en voor dat tweede moet je gewoon een afspraak maken.. dat kan nl. met alle BASE dingen..

@TS:
met wat gereken (modulus) kan je zelf je eigen functie wel bouwen toch?

Is er wellicht iemnand die een PHP filetje voor me heeft met een andere implementatie van een BASE64 decoder?

dat zou een scriptrequest zijn, en daar houden we niet zo van.
we willen je wel helpen als je het zelf probeert

[ Voor 28% gewijzigd door BasieP op 08-03-2006 18:19 ]

[Anoniem: 50683]

BasieP schreef op woensdag 08 maart 2006 @ 18:14:
[...]


van dat eerste word de data niet anders

Nee de data niet, maar door het als de cr/lf wordt gezien als onderdeel v/d data, wat niet zou moeten want het is absoluut geen base64 data, gaat het toch mis.

, en voor dat tweede moet je gewoon een afspraak maken.. dat kan nl. met alle BASE dingen..

Handig geantwoord, blijkbaar kan en/of gebeurt dat niet overal/altijd.
Goed is het niet, maar wel de praktijk

[Icelus]

Met een preg_replace de cr/lf's uit de data verwijderen en daarna base64_decode aanroepen?

[CH4OS]

Van wat voor server komt het af?
Meen mij te herinneren dat op Linux bakken \n al zorgt voor een nieuwe regel...
En dat je daar op een Windows bak \n\r voor nodig hebt...

[BasieP]

GJ-tje schreef op donderdag 09 maart 2006 @ 14:24:
Van wat voor server komt het af?
Meen mij te herinneren dat op Linux bakken \n al zorgt voor een nieuwe regel...
En dat je daar op een Windows bak \n\r voor nodig hebt...

mac = \r
linux/unix = \n
windows \r\n

dus zowel \r als \n weghalen en 't is echt weg

[CH4OS]

BasieP schreef op donderdag 09 maart 2006 @ 14:26:
dus zowel \r als \n weghalen en 't is echt weg

Of de tekst als preformatted tekst behandelen, dat je het dus in de HTML tussen <pre> en </pre> zet...

[crisp]

Zit je niet gewoon naar een HTML-presentatie van je decoded data te kijken (waarbij een enter in de broncode in HTML visueel geen linebreak is, tenzij je het geheel in <pre>-tags wrapped of enters vervangt door <br>?)