Parse error: syntax error, unexpected end of file in cr versus lf
Ik had hier iets raar voor.
Onder wamp alles ok. opladen naar productie, bovenstaande foutmelding. Op nas ook ok.
Na lang zoeken zie ik via codes weergeven in np++ dat sommige lijnen eindigen met CR (±10) en de andere 280 met LF
Eens alle cr veranderd naar lf, is alles ok ook op prod.
Hoe kan zoiets. lf of cr of lf+cr zou toch allemaal op dezelfde manier moeten werken.
Versies zijn overal 7.3 echter versie 7.2 en 7.1 gaf ook de melding.
volgens controle via site https://phpcodechecker.com/ was ook alles ok.
Jan
Twee programma's die mogelijk met regeleinden klooien zijn je editor (Notepad++ zoals je al zelf aangaf, bij opslaan) maar mogelijk ook je FTP-programma. FileZilla voert bijvoorbeeld vertalingen uit op bestanden waarbij (op grond van extentie) is aangegeven dat die als ASCII behandeld dienen te worden. Wanneer je een versioningsysteem hebt dan komt dit heel snel boven water, het lijkt dan namelijk of bestanden die je van de server terughaalt helemaal zijn aangepast terwijl er inhoudelijk eigenlijk niets veranderd is. Dit is dan dus een discrepantie tussen hoe je editor dingen opslaat (en die je vervolgens op die manier een versioningsysteem ingooit) en hoe je FTP-programma omgaat met ASCII-bestanden. De makkelijkste manier om dit laatste te voorkomen is door gewoon alles binair te verzenden.
Frank Nietbelangrijk op 01/09/2019 19:43:07:
Klinkt als een karakter-codering probleem.
Lijkt mij in dit geval onwaarschijnlijk omdat de codepoints van CR (13) en LF (10) altijd hetzelfde zijn tussen karakter encoderingen. En een mix van verschillende encoderingen in een bestand lijkt mij nog moeilijker realiseerbaar. Bij wegschrijven wordt deze eenmalig vastgelegd lijkt mij, dus over CR en LF zal niet zoveel verwarring kunnen ontstaan. Mogelijk gaat de rest dan wel door de vleesmolen ;).
Gewijzigd op 01/09/2019 23:00:12 door Thomas van den Heuvel
Frank Nietbelangrijk op 01/09/2019 19:43:07:
Klinkt als een karakter-codering probleem. Misschien een bestand gedownload en daarna bewerkt? Dan was het wellicht uit een compleet ander deel van de wereld en zeker geen UTF-8 of iets dergelijks?
Sinds mijn eerste keer probleem met BOM nu al enkele jaren geleden werk ik nog uitsluitend met UTF-8 zonder BOM
Toevoeging op 02/09/2019 07:40:53:
@TvdH: Ik zal FileZila eens controleren.
Jan
Select encoding:
UTF-8
UTF-8 without BOM
UTF-16
UTF-32
Die 2e versie kies jij zeker altijd :-)
Gewijzigd op 02/09/2019 13:34:56 door Ozzie PHP
Edit > Settings.
En dan onder Transfers > FTP: File Types.
Zet het Default transfer type op Binary.
Als deze namelijk op Auto staat worden alle bestanden in de lijst eronder als ASCII behandeld.
Het effect van het gebruiken van Binary is volgens mij enkel dat bestanden worden overgezet zoals ze zijn ("as is"), en dat is wat je wilt lijkt mij.
EDIT: en mogelijk maak je nu gebruik van SFTP of is er iets op de server zelf veranderd?
Gewijzigd op 02/09/2019 15:33:50 door Thomas van den Heuvel
Ozzie PHP op 02/09/2019 13:33:05:
>> Sinds mijn eerste keer probleem met BOM nu al enkele jaren geleden werk ik nog uitsluitend met UTF-8 zonder BOM
Select encoding:
UTF-8
UTF-8 without BOM
UTF-16
UTF-32
Die 2e versie kies jij zeker altijd :-)
Select encoding:
UTF-8
UTF-8 without BOM
UTF-16
UTF-32
Die 2e versie kies jij zeker altijd :-)
inderdaad. Niet goed?
Toevoeging op 02/09/2019 18:10:46:
FileZila aangepast. Nu afwachten en hopen dat ik dat niet meer tegenkom
Mwa ... behalve dat die setting niet bestaat :) Het was een grapje.
np++