10 svar · 1 834 visningar · startad av kluringen
$file = fopen($filnamn2, "w");
fwrite($file, $innehall);
fclose($file);
$innehall är inläst från en UTF-8 fil. Den nya filen blir ANSI. Funktionen är avsedd att hanteras av en slutanvändare, annars är det lätt att spara om den till rätt format i Notepad++. Tacksam för tips.
Förklara vad du menar med "Den nya filen blir ANSI." Visas filen korrekt när du öppnar som ANSI? Visas våra prickiga bokstäver fel, typ Ã¥, ä och ö? Hur läser du in filen? Hur öppnar slutanvändaren filen?
testa:
fwrite($file, utf8_encode($innehall));
Tack @nders, det fungerar.
Förklara vad du menar med "Den nya filen blir ANSI." Visas filen korrekt när du öppnar som ANSI? Visas våra prickiga bokstäver fel, typ Ã¥, ä och ö? Hur läser du in filen? Hur öppnar slutanvändaren filen?
Riktigt, det var de prickiga som stökade. Blir ok med @nders lösning. Jag läser texten med "fread", och slutanvändaren får filen i en "include" som öppnas i webbläsaren.
För det första bör du inte använda include för att inkludera filer som inte innehåller kod. Rent allmänt, om någon petar in PHP-kod i den inkommande filen så kommer ju den köras, vilket kan vara en säkerhetsrisk. Du bör istället använda readfile för denna typ av filer.
För det andra undrar jag om filen du läser in från början verkligen är UTF8. Om det inte finns kod som uttryckligen ändrar teckenkodning ser jag inte hur det felet skulle kunna ske.
För det första bör du inte använda include för att inkludera filer som inte innehåller kod. Rent allmänt, om någon petar in PHP-kod i den inkommande filen så kommer ju den köras, vilket kan vara en säkerhetsrisk. Du bör istället använda readfile för denna typ av filer.
För det andra undrar jag om filen du läser in från början verkligen är UTF8. Om det inte finns kod som uttryckligen ändrar teckenkodning ser jag inte hur det felet skulle kunna ske.
Ingen fara. Endat ett fåtal användare som är betrodda att hjälpa till att underhålla hemsidan kan skriva i filerna. Varför skulle dom vilja lägga in php kod? Dom som är så pass kunniga att de kan sånt lär få högre behörighet att manipulera hela hemsidan.
Ponera att någon lyckas lista ut ett sätt att spara filer utan att ha admin-rättigheter. Det finns mindre nogräknade personer som lever på att utnyttja andras sidor för att spamma och eller värre saker, så det behöver inte handla om att någon attackerar DIG specifikt. En kedja är inte starkare än sin svagaste länk. Ponera att någon faktiskt lyckas komma åt admin-interfacet utan att logga in, men stoppas av att du använder readfile istället för include, t ex.
Ponera att någon lyckas lista ut ett sätt att spara filer utan att ha admin-rättigheter. Det finns mindre nogräknade personer som lever på att utnyttja andras sidor för att spamma och eller värre saker, så det behöver inte handla om att någon attackerar DIG specifikt. En kedja är inte starkare än sin svagaste länk. Ponera att någon faktiskt lyckas komma åt admin-interfacet utan att logga in, men stoppas av att du använder readfile istället för include, t ex.
”En kedja är inte starkare än sin svagaste länk” säger du. Jag köper det. Men om någon lyckas lista ut hur man kan spara filer på vår webbplats måste väl den svagaste länken finnas hos Loopia? Jag kan inte inse att det skulle vara möjligt annars, om man inte forcerar mitt relativt säkra inloggningsskydd. Svårt även som inloggad eftersom Tinymce kommenterar bort all eventuell php kod.
Jag har inte skapat någon speciell admin-interface. Har bara tänkt igenom vilka textavsnitt som man kan behöva ändra utan dröjsmål, utan html kunskaper och utan tillgång till ett FTP program och åtkomstuppgifter mot servern.
Är tveksam till hur lång det är nödvändigt att driva säkerhetstänket på en BRF hemsida . På de allmänna sidorna kan styrelsen numera ändra korta textavsnitt på tre sidor, t ex felanmälan, uppgift om vilka som sitter i styrelsen och viss del av mäklarinformationen som kan ha blivit inaktuell. På de interna sidorna är det betydligt flera filer som kan ändras på samma sätt. Jag anropar samma kodfiler för alla. Det är dessa små html filer (17 st f.n.) som jag har klippt ut till egna filer som jag gör ”include” på jämte menyer och kod som anknyter till inloggningsskyddet.
Men du får gärna visa hur readfile koden ska se ut. Blev helt förskräckt av allt som jag måste sätta mig in i när jag kollade på "readfile" syntaxen på php.net. Till saken hör, att när jag började bry mig om föreningens hemsida visste jag knappt vad html var. Sen har lag lärt mig mer, lite i taget allt efter behov då kraven på sidan växte. Jag är bara en gammal Cobol programmera som fortfarande svär ve o fasa över all flygskitskod som måste bli rätt i PHP och det som är krångligt i CSS.
Där du skriver (i syfte att inkludera en textfil)
include $fil;
// eller
include "fil.txt";
skriv
readfile($fil);
// eller
readfile("fil.txt");
så bör det fungera rakt av.
Du har nog rätt i att det säkert inte gör någon skillnad just i detta fall. Det handlar mer om principen. Och du har rätt, det är lätt att skjuta sig i foten med PHP.
Ok nitro2k01, goda principer som bygger på erfarenhet ska man väl följa så klart. Jag förstår skillnaden nu. Testade att byta include mot readfile för "menylista .php" och då försvann menyn. Man lär så länge man lever vare sig man vill det eller ej.
Tack!
Ifråga om säkerhet har jag lagt lite krut på att kunna rätta till handhavarfel som användaren kan ställa till. Jag har byggt in ett litet backup system i anslutning ändringsfunktionen. Så här funkar det:
Varje gång användaren trycker på "Spara", sparas filen även i det skick den var innan den öppnades för ändring. Från ver-1 till ver-5 skapas en ny fil där fem är den senaste. På alla senare varv tar jag bort ettan och flyttar upp de andra filerna ett snäpp så tvåan blir etta, fyran trea och femman blir fyra, sen lägger den senaste i femman. Elegant, ingen behöver bry sig om att städa bort gamla backup filer. Användaren kan själv välja att hämta in en gammal text och lägga till eller ersätta den befintliga texten.