[Javascript] PHP5 en Base64

[Verwijderd]

Hallo,

Ik gebruik al sinds een tijdje het onderstaande script.
http://www.webtoolkit.info/javascript-base64.html
om gevens via javascript base64 te coderen

Nu is het zo dat in PHP5 bij de codering van Base64 een spatie wordt aangezien als een +
In mijn Javascript file is dit echter niet het geval.
Nu los ik dit tijdelijk in de PHP code op door base64_decode(str_replace(" ","+",$base64_string))

Zou iemand mijn in de goeie richting kunnen wijzen hoe ik dat in het javascript bestand zou kunnen aanpassen.

Ik heb het al op de volgende manier geprobeerd
output.replace(/ +/g,"+") maar dit hielp niet.

Alvast bedankt.

[GlowMouse]

Verwijderd schreef op dinsdag 31 juli 2007 @ 21:45:
Nu is het zo dat in PHP5 bij de codering van Base64 een spatie wordt aangezien als een +
In mijn Javascript file is dit echter niet het geval.

>php -r "echo base64_encode(' ');"
IA==
> php -v
PHP 5.2.3 (cli) (built: May 31 2007 09:37:22)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

IA== is echt een spatie, geen plus. Waarom denk je dat hij er een + van maakt?

[Verwijderd]

Omdat dat in de documentatie staat =)
en omdat ik het dus ook getest heb =P

[GlowMouse]

Verwijderd schreef op dinsdag 31 juli 2007 @ 21:52:
Omdat dat in de documentatie staat =)
en omdat ik het dus ook getest heb =P

Ik zie het niet staan, het klinkt mij onbekend in de oren, en uit mijn test blijkt dat er gewoon een spatie in plaats van een + komt. Misschien kun je wat vertellen over je testmethode, want daar gaat waarschijnlijk iets fout.

[Verwijderd]

Bijvoorbeeld als ik met javasscript de volgende string post Base64.encode('<>///()--+_\;;') dan word de javascript base64 code PD4vLy8oKS0tK187Ow==
en als ik het met php doe met base64_encode krijg ik PD4vLy8oKS0tK19cOzs=

Door nu in php dit te doen
base64_decode(str_replace(" ","+",$base64_string))
krijg ik weer de originele string terug

Toen ik nog php4 had werkt alles wel gewoon goed

[ Voor 9% gewijzigd door Verwijderd op 31-07-2007 22:29 ]

[Verwijderd]

Verwijderd schreef op dinsdag 31 juli 2007 @ 22:28:
Toen ik nog php4 had werkt alles wel gewoon goed

Ik kwam dit eens tegen:

Please note that, as of this writing, mb_convert_encoding( $string, "UTF-8", "BASE64" ) still behaves as base64_decode( $string ) did in php <= 5.0.5 regardless of the version of php you are running.

http://nl3.php.net/manual...n.base64-decode.php#69747

[GlowMouse]

Verwijderd schreef op dinsdag 31 juli 2007 @ 22:28:
Bijvoorbeeld als ik met javasscript de volgende string post Base64.encode('<>///()--+_\;;') dan word de javascript base64 code PD4vLy8oKS0tK187Ow==
en als ik het met php doe met base64_encode krijg ik PD4vLy8oKS0tK19cOzs=

Door nu in php dit te doen
base64_decode(str_replace(" ","+",$base64_string))
krijg ik weer de originele string terug

Ook zonder die str_replace gaat dat goed. Dat is ook logisch: de str_replace voer je nu uit op je base64_string, en laten daar nu net geen spaties in kunnen zitten. Base64 encoded strings kunnen namelijk slechts een beperkt aantal verschillende karakters bevatten: "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/". Je probleem zit dus niet in de codering, maar in hoe die spatie er ooit in sluipt. Waarschijnlijk encode je de string niet netjes voordat je hem in een URL doorgeeft. Een + verandert namelijk in een spatie wanneer je dat vergeet.

>php -r "echo base64_decode('PD4vLy8oKS0tK19cOzs=
');"
<>///()--+_\;;

[funkwurm]

Javascript heeft daar escape() voor, die codeert de tekens waarvoor dat nodig is naar hun %xx code.

[Niemand_Anders]

Hij verstuurt vanuit zijn browser (javascript) die base64 encoded string via de url (querystring). Browsers maken automatisch van alle spaties in de url automatisch een + (omdat volgende de RFC 2617 spaties niet zijn toegestaan in een url. Een + dient geencode te worden door %4b.

PHP maakt om die reden dus automatisch van die plus 'weer' een spatie. Probleem hier is dat base64 zelf geen spaties bevat.

Als hij zoals funkwurm aangeeft eerst escape() uitvoert over zijn base64 string, dan wordt die plus automatisch ge-url-encode.

[Verwijderd]

Nee dit is niet het probleem het is echter nog veel vreemder zeg ik dus bijv.
document.write(Base64.encode("<>///()--+_\;;"));
dan krijg ik PD4vLy8oKS0tK187Ow==

Copy past ik nu de code <>///()--+_\;; in een textarea en en vervolgens doe ik dit

document.getelementbyid('tekstarea').value dan krijg ik
PD4vLy8oKS0tK19cOzs=
zoals het hoort te zijn

[Verwijderd]

En als je een charset meegeeft aan je <script>-element?

In je script wordt namelijk alles als binaire data gezien, maar in je textarea als een string in de door jou gebruikte charset op je pagina. Daar zit een verschil in dus.

edit
In de manual staat tr ook dat je een unicode string moet meegeven:

Converts data between ByteArray (safearray of bytes) and Base64. Works as a Base64 encoder and decoder from binary (bytearray) or from Unicode String.

[ Voor 95% gewijzigd door Verwijderd op 01-08-2007 09:43 ]

[Icelus]

Verwijderd schreef op woensdag 01 augustus 2007 @ 09:19:
Nee dit is niet het probleem het is echter nog veel vreemder zeg ik dus bijv.
document.write(Base64.encode("<>///()--+_\;;"));
dan krijg ik PD4vLy8oKS0tK187Ow==

Copy past ik nu de code <>///()--+_\;; in een textarea en en vervolgens doe ik dit

document.getelementbyid('tekstarea').value dan krijg ik
PD4vLy8oKS0tK19cOzs=
zoals het hoort te zijn

Komt dit niet door de ‘\’?
Dit is een escapekarakter en wordt in dit geval genegeerd; de string is dus gelijk aan
document.write(Base64.encode("<>///()--+_;;"));

Vanuit een text area wordt de tekst wel exact overgenomen.

[Verwijderd]

Icelus schreef op woensdag 01 augustus 2007 @ 09:56:
[...]
Komt dit niet door de ‘\’?
Dit is een escapekarakter en wordt in dit geval genegeerd; de string is dus gelijk aan
document.write(Base64.encode("<>///()--+_;;"));

Vanuit een text area wordt de tekst wel exact overgenomen.

Dat is het idd lol

[Verwijderd]

Hoe kan ik dat probleem omzeilen dan ??

[Snake]

Door de escape() functie toe te passen

[Verwijderd]

die werkt niet goed samen met php =)

[Icelus]

Zie ook: Using Special Characters in Strings.

[Verwijderd]

Verwijderd schreef op woensdag 01 augustus 2007 @ 12:12:
die werkt niet goed samen met php =)

In PHP kun je addslashes gebruiken, als je dat bedoelt?

[Verwijderd]

de site gebruikt utf8 en ajax en daarom gebruik ik dus base64 om de utf8 data via ajax te versturen base64 gecodeerd. dan gaat escape niet werken.

[Verwijderd]

iemand op php.net heeft precies hetzelfde probleem

I've come across an interesting issue with an external program that submits a gzcompressed base64_encoded string to PHP via POST. The external program encodes the string using the occasional " " (space) character, however if I encode the same original string within PHP (using base64_encode), it uses a "+" (plus) character wherever the external program would use a space. On my deployed machine, running PHP 4.3.9, base64_decode is fine with the " " (space) characters, but my test server running 5.1.4 is not. It took me a while to figure out that was the issue, but I ended up fixing it with a simple:

<?php

$post_data = str_replace(" ","+",$_POST['string'])

?>

Maar ik snap nog niet echt hoe dit nou kan.

[GlowMouse]

Verwijderd schreef op woensdag 01 augustus 2007 @ 12:59:
[...]
In PHP kun je addslashes gebruiken, als je dat bedoelt?

Addslashes is een vrij nutteloze functie die dit probleem niet verhelpt.

The external program encodes the string using the occasional " " (space) character

Daar ligt de fout dus aan het externe programma die niet de standaardcharacterset gebruikt voor base64. Hier niet aan de orde.

Maar ik snap nog niet echt hoe dit nou kan.

Zie de reacties van Icelus, hij reikt je zelfs de oplossing aan.

[Verwijderd]

Ik gebruik de code van deze site
http://www.webtoolkit.info/javascript-base64.html
en daar staat de keystring hierop
_keyStr : "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=",

dat moet toch goed zijn lijkt me ??

[Erkens]

Verwijderd schreef op woensdag 01 augustus 2007 @ 13:12:
de site gebruikt utf8 en ajax en daarom gebruik ik dus base64 om de utf8 data via ajax te versturen base64 gecodeerd. dan gaat escape niet werken.

Waarom zou je geen utf8 data kunnen versturen met "ajax"? Kwestie van de juiste headers zetten. Heb ik nog nooit problemen mee gehad iig

[Verwijderd]

GlowMouse schreef op woensdag 01 augustus 2007 @ 13:30:
[...]

Addslashes is een vrij nutteloze functie die dit probleem niet verhelpt.

[...]

Het probleem is toch de slash die hier als escape-char wordt gezien? Addslashes zal deze slash escapen waardoor de slash een 'echte' slash wordt. Waarom verhelpt dat het probleem dan niet?

[GlowMouse]

Verwijderd schreef op woensdag 01 augustus 2007 @ 13:55:
[...]
Het probleem is toch de slash die hier als escape-char wordt gezien? Addslashes zal deze slash escapen waardoor de slash een 'echte' slash wordt. Waarom verhelpt dat het probleem dan niet?

Addslashes accepteert een string, en in die string is \ en het karakter daarna al omgezet. Je zit bent dus al te laat met addslashes en daarmee kun je het probleem niet meer terugdraaien (met addslashes("\r\n") krijg je ook niet letterlijk \r\n meer terug, dat is en blijft een CRLF). Daarnaast is addslashes een PHP-functie, en het probleem, althans zoals beschreven in deze post, speelt in JavaScript.

[ Voor 13% gewijzigd door GlowMouse op 01-08-2007 14:03 ]

[.oisyn]

Verwijderd schreef op woensdag 01 augustus 2007 @ 13:55:
[...]

Het probleem is toch de slash die hier als escape-char wordt gezien?

Klopt, maar het probleem is dat die string waar de slash in staat geen user-input is, maar een string literal in de taal waarin je werkt. Het is de interpreter die de slash als escape-sequence interpreteert - daar addslashes() omheen zetten zorgt er niet voor dat de interpreter ineens die escape-sequence gaat negeren.

[ Voor 7% gewijzigd door .oisyn op 01-08-2007 14:04 ]

[Verwijderd]

Maar je vermelde dat het met PHP4 nog wel goed werkte, en dus na de update niet meer. Dan is het probleem en de oplossing daar toch te vinden? Zie m'n vorige reactie.

[GlowMouse]

Verwijderd schreef op woensdag 01 augustus 2007 @ 14:20:
Maar je vermelde dat het met PHP4 nog wel goed werkte, en dus na de update niet meer. Dan is het probleem en de oplossing daar toch te vinden? Zie m'n vorige reactie.

In de thread lopen twee problemen door elkaar
1. Problemen door een \ in de string
2. Een spatie in plaats van een + in de geëncode string
Voor het eerste probleem heeft Icelus een oplossing gepost. Het tweede probleem wordt inderdaad omzeild met de methode in jouw post, maar door url-escaping treedt het probleem sowieso niet op.

[Verwijderd]

GlowMouse schreef op woensdag 01 augustus 2007 @ 14:43:
[...]

In de thread lopen twee problemen door elkaar
1. Problemen door een \ in de string
2. Een spatie in plaats van een + in de geëncode string
Voor het eerste probleem heeft Icelus een oplossing gepost. Het tweede probleem wordt inderdaad omzeild met de methode in jouw post, maar door url-escaping treedt het probleem sowieso niet op.

Escape is geen optie omdat ik geen rommel met code in me database wil hebben maar pure UTF8 code.

de enige manier hoe het werkt is in php $post_data = str_replace(" ","+",$_POST['string'])
te doen

mb_convert_encoding( $string, "UTF-8", "BASE64" ) werkt ook niet nm

Er is dus gewoon iets veranderd maar ik zou echt niet weten wat. heel vreemd allemaal het is ook nergens te vinden.

en ik snap ook niet waarom die het wel doet als ik str_replace(" ","+",$_POST['string'])
doe want in een base64 string kunnen toch geen spaties voorkomen heel vreemd allemaal iig

[GlowMouse]

Verwijderd schreef op woensdag 01 augustus 2007 @ 15:28:
[...]
Escape is geen optie omdat ik geen rommel met code in me database wil hebben maar pure UTF8 code.

Zoals Erkens zegt, hoef je helemaal geen base64 encoding toe te passen om UTF-8 via ajax te versturen. Base64 zorgt voor 33% overhead bij het versturen van de gegevens.
Door de base64 code te escapen voordat je het als POST-data meestuurt, verandert er helemaal niets in je database. Ik snap niet hoe je daarbij komt.
Ik krijg het idee dat alles omtrent je probleem al vermeld is, en je eens rustig de reacties door moet lezen en goed begrijpen. Verdere reacties herhalen slechts wat eerder al gezegd is.

[crisp]

funkwurm schreef op dinsdag 31 juli 2007 @ 23:52:
Javascript heeft daar escape() voor, die codeert de tekens waarvoor dat nodig is naar hun %xx code.

escape() is niet RFC1738-compliant, gebruik liever encodeURIComponent()

[Verwijderd]

en hoe krijg je encodeURIComponent weer 100% terug dan in PHP ?

[crisp]

Verwijderd schreef op donderdag 02 augustus 2007 @ 14:22:
en hoe krijg je encodeURIComponent weer 100% terug dan in PHP ?

gewoon de betreffende GET of POST var uitvragen.

Als je dan nog charset issues hebt dan zit er iets anders fout en ben je nu enkel met symptoombestrijding bezig

[funkwurm]

Ik zit me echt op te vreten terwijl ik deze thread doorlees (en ik hou van die spanning, geen verwijt ofzo ). Addslashes() server-side en encodeURIComponent() client-side gaan jou problemen oplossen of mijn naam is geen funkwurm.

JavaScript:

document.write(Base64.encode("<>///()--+_\;;"));

Deze regel is uitgepoept door je server, mee eens? De slash staat er in, dus waar in het proces verdwijnt hij? Volgens een aantal mensen hier al op de server, ik niet mee eens niet.

De slash verdwijnt omdat javascript zelf ook escaping heeft (niet te verwarren met de door mij eerder opgemerkte escape() functie). Javascript interpreteert "\;" als een enkele puntkomma, zoals hij ook "\"" als een enkel aanhalingsteken zou interpreteren. Als je nou server-side escapet dan krijgt javascript dit voor z'n kiezen:

JavaScript:

document.write(Base64.encode("<>///()--+_\\;;"));

En zoals "\;" een enkele puntkomma wordt en "\"" een enkel aanhalingsteken, zo wordt "\\" een enkele slash, en verhip, dat is wat je wou.

Als je vervolgens naar crisp luistert en het Base64-string encodeURIComponent()'t voordat je hem meegeeft achter de ? van je ajax-request, overleeft hij de limitaties van een URI ook nog. Zoals crisp ook aangeeft, deze functie zorgt er niet voor dat de string ook ver-procenttekent op de server-side arriveert, omdat php wel zo slim is om de string weer te ont-procenttekenen voordat hij hem aan je script terug geeft.

Anders gezegd, als je niet ver-procenttekent gaat het ont-procenttekenen nog steeds wel door, en daarbij worden plusjes als spaties gezien, hence your issue.

[GlowMouse]

funkwurm schreef op donderdag 02 augustus 2007 @ 23:51:
Addslashes() server-side en encodeURIComponent() client-side gaan jou problemen oplossen of mijn naam is geen funkwurm.
[..]
Als je nou server-side escapet dan krijgt javascript dit voor z'n kiezen:

JavaScript:

document.write(Base64.encode("<>///()--+_\\;;"));

Addslashes zou ook " escapen. Als je deze regel wilt echo'en, moet je er gewoon rekening mee houden dat je vier \ neerzet in de oorspronkelijke string om het in JS ook goed te laten gaan.
_psst

[funkwurm]

GlowMouse schreef op vrijdag 03 augustus 2007 @ 00:07:
[...]

Addslashes zou ook " escapen. Als je deze regel wilt echo'en, moet je er gewoon rekening mee houden dat je vier \ neerzet in de oorspronkelijke string om het in JS ook goed te laten gaan.
_psst

Ja lieverd ( 'je terug), je hebt helemaal gelijk, maar doelde op zoiets:

PHP:

echo('document.write(Base64.encode("'.addslashes($sWaardeUitDatabase).'"));');

[GlowMouse]

Dan worden single quotes ook onnodig geescaped.

[crisp]

funkwurm schreef op vrijdag 03 augustus 2007 @ 00:18:
[...]

Ja lieverd ( 'je terug), je hebt helemaal gelijk, maar doelde op zoiets:

PHP:

echo('document.write(Base64.encode("'.addslashes($sWaardeUitDatabase).'"));');

Doe dan liever zo:

PHP:

echo('document.write(Base64.encode(\''.addcslashes($sWaardeUitDatabase, "\0\n\r\t\\'/").'\'));');