Visa ett inlägg
Oläst 2011-03-27, 23:39 #2
Conny Westh Conny Westh är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: Aug 2005
Inlägg: 5 166
Conny Westh Conny Westh är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: Aug 2005
Inlägg: 5 166
Detta är ett typiskt fel man får när man kommunicerar mellan ett Windows- och ett Unix/Linux-baserad operativsystem.

Det kan bero på att när du skapar en textfil i Windows så avslutas alltid varje textrad med tecknen <CR>+<LF> (dvs CarrigeReturn, char(13) och LineFeed, Char(10)).

Medan de unix/linux-baserade system alltid avslutar en rad med enbart <CR> dvs char(13).

Om ett unix/linux-system trots allt hittar ett extra <LF> tecken så tolkas det som en extra rad eftersom det betyder RadMatning. Konsekvenser blir att du ser det som en extra tom rad mellan dina ursprungliga rader.

Lösningen brukar finnas i att man specifierar att det är en PC-fil man skickar upp och att man måste ange att den ska konverteras till unix/linux-format vid uppladdning och vid nedladdning så ska den omvandlas till Windows-formatet igen. Detta gäller ENDAST textfiler, binärfiler ska ALDRIG konverteras på detta sätt.

Om du gör tvärtom, dvs hämtar ner en unix/linux-fil till Windows så får du rader som skriver över varandra och det blir en total mess av allting. De flesta bra editorer som exempelvis TextPad kan hantera detta automatiskt, då det är enkelt för editorn att känna av om det är ett CRLF eller bara CR för radsluten.

Senast redigerad av Conny Westh den 2011-03-27 klockan 23:45
Conny Westh är inte uppkopplad   Svara med citatSvara med citat