Parse error: syntax error, unexpected end of file in cr versus lf

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

.NET Developer / Innovatieve software / Virtual Re

Functieomschrijving Als .Net developer werken aan innovatieve software waar onder andere gebruik gemaakt wordt van Virtual Reality? Bijdragen aan een organisatie waar je uitgedaagd wordt om continu verbeteringen en ontwikkelpunten te ontdekken en door te voeren? Werken in de omgeving Putten? Reageer dan nu voor meer informatie! Het pro-actief aandragen van verbeteringen voor de bestaande applicatie; Ontwikkelen van nieuwe functionaliteiten; Doorvoeren van aanpassingen en wijzigingen; Verantwoordelijk voor koppelingen met andere systemen; Op de hoogte blijven van technische ontwikkelingen. Functie-eisen Hbo werk- en denkniveau; Een afgeronde IT gerelateerde opleiding; Minimaal 1 jaar professionele ervaring als developer; Aantoonbare kennis van C#; Initiatiefrijke

Bekijk vacature »

Jan R

Jan R

01/09/2019 19:09:47
Quote Anchor link
Hi,

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
 
PHP hulp

PHP hulp

15/09/2019 17:06:47
 
Frank Nietbelangrijk

Frank Nietbelangrijk

01/09/2019 19:43:07
Quote Anchor link
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?
 
Thomas van den Heuvel

Thomas van den Heuvel

01/09/2019 22:55:17
Quote Anchor link
Zolang je één variant aanhoudt zou dit moeten werken. Lijkt mij in ieder geval wel verstandig om dit bij één variant te houden. Je weet namelijk niet hoe PHP hier intern mee omgaat. Misschien kijkt deze naar het eerste regeleinde en switch 'ie dan naar een CRLF of LF modus ofzo. Geen wonder dat 'ie dan in de war raakt als je verschillende vormen door elkaar gaat gebruiken.

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
 
Jan R

Jan R

02/09/2019 07:39:16
Quote Anchor link
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
 
Ozzie PHP

Ozzie PHP

02/09/2019 13:33:05
Quote Anchor link
>> 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 :-)
Gewijzigd op 02/09/2019 13:34:56 door Ozzie PHP
 
Thomas van den Heuvel

Thomas van den Heuvel

02/09/2019 15:31:03
Quote Anchor link
Voor wie FileZilla gebruikt:

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
 
Jan R

Jan R

02/09/2019 18:07:56
Quote Anchor link
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 :-)


inderdaad. Niet goed?

Toevoeging op 02/09/2019 18:10:46:

FileZila aangepast. Nu afwachten en hopen dat ik dat niet meer tegenkom
 
Ozzie PHP

Ozzie PHP

02/09/2019 20:40:01
Quote Anchor link
>> inderdaad. Niet goed?

Mwa ... behalve dat die setting niet bestaat :) Het was een grapje.
 
Jan R

Jan R

03/09/2019 00:40:19
Quote Anchor link
Hoezo niet bestaan?
http://users.telenet.be/janr/utf8.png
 
Ozzie PHP

Ozzie PHP

03/09/2019 03:23:23
Quote Anchor link
Huh ... heb je die gePhotoshopt? :-/
 
Jan R

Jan R

03/09/2019 04:42:58
Quote Anchor link
nee werk al jaren met deze instelling
 
Ozzie PHP

Ozzie PHP

03/09/2019 12:05:18
Quote Anchor link
Ooooh .. haha, lol .. welk programma is dat dan?
 
Jan R

Jan R

03/09/2019 12:27:11
Quote Anchor link
Stond in de start van het topic :)
np++
 
Ozzie PHP

Ozzie PHP

03/09/2019 17:51:24
Quote Anchor link
Ah oke, niet gezien. Wel komisch.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.