Waarschijnlijk is mijn probleem niet zo moeilijk. De oplossing heb ik nog niet gevonden.
Heb ik het niet gezien? is mogelijk. wijs me de weg.
Het volgende. Mijn database, bij Lycos, kan in via MySQL beheer updaten. Het veld is wat klein en ik dacht het een voudig in te lezen en weer weg te schrijven. Echter bij speciale karakters werk het niet. Ik heb in de tekst bijvoorbeeld <a href="javascript:void(0);" onmouseover=",return enzovoort, staan. Het gaat mis op de eerste dubbele apostrophe. Zet ik echter voor die apostrophe: " dan wort er een dubbele apostrophe neergezet en niet wat er echt staat: ".
Zo had ik het gedacht neer te zetten op mijn scherm.
echo "<p><b>Tekst1: </b>";
echo $row['tekst1']."<br>";
$tekst1 = $row['tekst1'];
echo '<input textarea cols="150" rows="20" name="tekst1" value="' . $tekst1 . '" />';
Aan SanThe:
Hoe het ook zij, ik krijg wel te zien wat er staat echter met de aangegeven veranderingen.
Aan stijn:
Geen idee wat ik doe maar stripslashes geeft geen verandering. Verder gebruik ik Opera. Heb IE opgestart en krijg hetzefde te zien behalve dat IE de cols en rows niet uitvoert.
De tweede aanwijzing kan ik pas uitvoeren als ik in staat ben de juiste text op te halen.
@Frank; hoe wilde jij je database dan verknallen? Query's kunnen er zelfs door in de war raken. Mysql_real_escape_string is nodig om de data in de database te zetten. Bij het uitlezen zul je dan altijd de backslashes zien. Hoe wilde je deze anders weghalen? Stripslashes is dé manier. Ik snap niet wat je nu speculeert over verknalde data, want als je juist geen backslashes toevoegt, verknal je de query.
Ja he? De functie mysql_real_escape_string() zorgt er inderdaad voor dat bepaalde tekens in de input met backslashes geëscaped worden zodat deze veilig in een query te gebruiken is. Op deze manier worden de queries zonder fouten uitgevoerd maar het zorgt er absoluut niet voor dat de input met backslashes in de database komt te staan!
Als dat wel het geval is gaat er al iets fout voordat jij de gegevens naar de database wegschrijft. Een voorbeeld daarvan zou het gebruik van mysql_real_escape_string() kunnen zijn terwijl de magic_quotes_gpc instelling aan staat. In dat geval worden alle tekens dubbel geëscaped en krijg je dus wel backslashes in je database...
Kortom, data hoort zonder backslashes in je database te staan en als gevolg daarvan zul je de functie stripslashes() ook nooit in deze toepassing nodig hebben!
@Frank; hoe wilde jij je database dan verknallen? Query's kunnen er zelfs door in de war raken. Mysql_real_escape_string is nodig om de data in de database te zetten. Bij het uitlezen zul je dan altijd de backslashes zien. Hoe wilde je deze anders weghalen? Stripslashes is dé manier. Ik snap niet wat je nu speculeert over verknalde data, want als je juist geen backslashes toevoegt, verknal je de query.
En sinds wanneer zet mysql_real_escape_string() een hardcode \ in de database?
Wanneer jij backslashes uit de data moet halen, heb je geen goede data in de database staan, deze heb je zelf willens en wetens naar de klote geholpen. Daar valt niks aan te speculeren! Data staat altijd rauw in de database, zonder enige poespas. Wie of wat daar ook mee aan de slag gaat, je hoeft nooit eerst de data op te schonen. Moet dat wel, heb jij (of 1 van je collega's) iets goed fout gedaan. Geen twijfel over mogelijk.
Ik ben er uit, het verhaal om de backslashes gaf mij een richting om nog eens verder te zoeken in de handleidingen. Met wat try en error heb ik naar ik verder verwacht de oplossing gevonden.
De eerste echo zet het op het scherm zoals het ook op de website komt te staan en de tweede echo zet het in een venster wat ik dan aan kan passen en weer terug kan schrijven, Dit alles om het onderhoud gemakkelijker te maken.
Je hebt de input-tag, bv. voor een text-veld en je hebt de tag textarea. Jij gooit hier de boel aardig door elkaar... Daarnaast kent een textarea geen value.
