/ Forside / Teknologi / Udvikling / PHP / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
PHP
#NavnPoint
rfh 3959
natmaden 3372
poul_from 3310
funbreak 2700
stone47 2230
Jin2k 1960
Angband 1743
Bjerner 1249
refi 1185
10  Interkril.. 1146
Linjeskift mangler
Fra : Erik Hansen


Dato : 25-03-08 19:16

Hejsa.

Jeg har et underligt problem som jeg ikke helt kan finde ud af hvad
skyldes.

Jeg har en Apache/PHP/MySQL installation på en lokal Windows XP
computer hvor det er PHP version 4.3.11, og så har jeg en anden server
stående i Tyskland med Apache/PHP/MySQL hvor det er PHP version
4.3.10, men denne er på en Linux platform.

Mit problem er at når jeg sender en mail med mail(), så når jeg gør
det på min lokale WinXP så er der linjeskift, men hvis jeg sender det
på Linux serveren så er der IKKE nogen linjeskift.
Det er samme PHP fil jeg bruger på begge maskiner, så jeg undre mig
hvorfor.

Jeg tænker om der måske er en global instilling som kan være
forskellig på henholdvis WinXP og Linux maskinen.


--
....::Hilsen Erik

 
 
Martin (25-03-2008)
Kommentar
Fra : Martin


Dato : 25-03-08 19:56

Erik Hansen wrote:
> Hejsa.
>
> Jeg har et underligt problem som jeg ikke helt kan finde ud af hvad
> skyldes.
>
> Jeg har en Apache/PHP/MySQL installation på en lokal Windows XP
> computer hvor det er PHP version 4.3.11, og så har jeg en anden server
> stående i Tyskland med Apache/PHP/MySQL hvor det er PHP version
> 4.3.10, men denne er på en Linux platform.
>
> Mit problem er at når jeg sender en mail med mail(), så når jeg gør
> det på min lokale WinXP så er der linjeskift, men hvis jeg sender det
> på Linux serveren så er der IKKE nogen linjeskift.
> Det er samme PHP fil jeg bruger på begge maskiner, så jeg undre mig
> hvorfor.
>
> Jeg tænker om der måske er en global instilling som kan være
> forskellig på henholdvis WinXP og Linux maskinen.

Hvad bruger du af linjeskift?
Jeg plejer at bruge \r\n - der virker det både på mac linux og windows,
og både engelske og danske versioner.

Dog har jeg fundet ud af at hotmail laver nogle mærkelige tegn... men
ikke altid, og det er nu mest det der undre mig.

\r er linux' måde at lave linjeskift mens \n er windows måde. (ellers er
det omvendt)

Erik Hansen (25-03-2008)
Kommentar
Fra : Erik Hansen


Dato : 25-03-08 21:25

On Tue, 25 Mar 2008 19:55:38 +0100, Martin <martin@aarhof.invalid>
wrote:

>Erik Hansen wrote:
>
>Hvad bruger du af linjeskift?
>Jeg plejer at bruge \r\n - der virker det både på mac linux og windows,
>og både engelske og danske versioner.

Jeg angiver ikke noget da inputtet kommet fra en FORM. Der har jeg et
<TEXTAREA> hvor bruger selv laver linje skrift. Så om det er \r
eller\n eller begge ved jeg faktisk ikke.

Men hvis jeg bruger funktionen nl2br() så bliver linjeskift i begge
tilfælde erstattet af </br>.

Jeg vil helst ikke lave HTML mail, når det er små info mail, så
derfor vil jeg helst bibeholde det format jeg hele tiden har brugt.

Det skal dog siges at jeg læser de mail jeg modtager med Outlook.

--
....::Hilsen Erik

Bertel Lund Hansen (26-03-2008)
Kommentar
Fra : Bertel Lund Hansen


Dato : 26-03-08 11:48

Erik Hansen skrev:

> Jeg angiver ikke noget da inputtet kommet fra en FORM. Der har jeg et
> <TEXTAREA> hvor bruger selv laver linje skrift. Så om det er \r
> eller\n eller begge ved jeg faktisk ikke.

Løsningen består så i at lave en funktion der sikrer at
linjeskift er "\r\n".

$usertext="Et eller andet eksempel\rmed [retur] som linjeskift";
if (strpos($usertext,"\r\n")===false) {
   if (strpos($usertext,"\r")!==false) {
      $usertext=str_replace("\r","\r\n",$usertext);
   else
      $usertext=str_replace("\n","\r\n",$usertext);
}

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

Stig Johansen (26-03-2008)
Kommentar
Fra : Stig Johansen


Dato : 26-03-08 14:12

Bertel Lund Hansen wrote:

> Erik Hansen skrev:
>
>> Jeg angiver ikke noget da inputtet kommet fra en FORM. Der har jeg et
>> <TEXTAREA> hvor bruger selv laver linje skrift. Så om det er \r
>> eller\n eller begge ved jeg faktisk ikke.
>
> Løsningen består så i at lave en funktion der sikrer at
> linjeskift er "\r\n".

Jeg kan så lige bidrage med, at når der bliver sendt fra <textarea>
FF (Windows) + Konqueror sender #10 (\n)
IE sender #13#13 (\r\n) eller vbCrLf.
I noget ASP, som jeg ikke lige har ved hånden gør jeg ca. pseudokode:
if not pos(input,#13#10) then replace(input,#10,#13#10)
på den måde ved jeg at alle data i _databasen_ er konsistente med #13#10.

--
Med venlig hilsen
Stig Johansen

Bertel Lund Hansen (26-03-2008)
Kommentar
Fra : Bertel Lund Hansen


Dato : 26-03-08 14:21

Stig Johansen skrev:

> I noget ASP, som jeg ikke lige har ved hånden gør jeg ca. pseudokode:
> if not pos(input,#13#10) then replace(input,#10,#13#10)
> på den måde ved jeg at alle data i _databasen_ er konsistente med #13#10.

Du har sikkert kodet det rigtigt, men din pseudokode klarer det
ikke hvis der er brugt #13 som linjeskift. Jeg ved dog ikke om
det forekommer i dag.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

Stig Johansen (27-03-2008)
Kommentar
Fra : Stig Johansen


Dato : 27-03-08 01:26

Bertel Lund Hansen wrote:

> Du har sikkert kodet det rigtigt, men din pseudokode klarer det
> ikke hvis der er brugt #13 som linjeskift. Jeg ved dog ikke om
> det forekommer i dag.

Nu er det muligvis OT, men af nysgerrighed har du set det forekomme
nogensinde?
'Før i tiden' var en cr en cr og en lf en lf.
Dvs hvis man sendte en cr til en terminal eller printer, så gik
curseren/printpositionen til begyndelsen af samme linie.
På samme måde med lf - en lf lavede linieskift, men bibeholdt samme cursor
positionen.

Det kunne godt medføre noget _sjov_ hvis man havde glemt en af dem i større
rapportudskrifter ;)

Eller foder til makulatoren.

--
Med venlig hilsen
Stig Johansen

Peter Brodersen (27-03-2008)
Kommentar
Fra : Peter Brodersen


Dato : 27-03-08 21:44

On Wed, 26 Mar 2008 14:11:37 +0100, Stig Johansen <wopr.dk@gmaill.com>
wrote:

>FF (Windows) + Konqueror sender #10 (\n)
>IE sender #13#13 (\r\n) eller vbCrLf.

Firefox sender nu \r\n (#13 #10), dog urlencoded som %0D%0A. Det samme gør
Safari og IE6.

Det burde også gælde samtlige øvrige browsere ved en default-formular, som
submittes som "application/x-www-form-urlencoded":
http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4

==
Non-alphanumeric characters are replaced by `%HH', a percent sign and two
hexadecimal digits representing the ASCII code of the character. Line
breaks are represented as "CR LF" pairs (i.e., `%0D%0A').
==

Med andre ord: Det er ikke afhængigt af klientens browser eller
operativsystem.

--
- Peter Brodersen
Kendt fra Internet

Martin (27-03-2008)
Kommentar
Fra : Martin


Dato : 27-03-08 22:57

Peter Brodersen wrote:
> On Wed, 26 Mar 2008 14:11:37 +0100, Stig Johansen <wopr.dk@gmaill.com>
> wrote:
>
>> FF (Windows) + Konqueror sender #10 (\n)
>> IE sender #13#13 (\r\n) eller vbCrLf.
>
> Firefox sender nu \r\n (#13 #10), dog urlencoded som %0D%0A. Det samme gør
> Safari og IE6.
>
> Det burde også gælde samtlige øvrige browsere ved en default-formular, som
> submittes som "application/x-www-form-urlencoded":
> http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4

Hvordan mon så med den til data (den der skal bruges ved fil inputs) ?

>
> ==
> Non-alphanumeric characters are replaced by `%HH', a percent sign and two
> hexadecimal digits representing the ASCII code of the character. Line
> breaks are represented as "CR LF" pairs (i.e., `%0D%0A').
> ==
>
> Med andre ord: Det er ikke afhængigt af klientens browser eller
> operativsystem.

Det er så hvad standarden siger, men hvor mange browsere overholder
standarden... jeg kan ihvertfald nævne et par stykker som ikke
overholder den - eller ihvertfald store dele af den :)

Peter Brodersen (28-03-2008)
Kommentar
Fra : Peter Brodersen


Dato : 28-03-08 09:35

On Thu, 27 Mar 2008 22:56:36 +0100, Martin <martin@aarhof.invalid> wrote:

>> Det burde også gælde samtlige øvrige browsere ved en default-formular, som
>> submittes som "application/x-www-form-urlencoded":
>> http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4
>Hvordan mon så med den til data (den der skal bruges ved fil inputs) ?

Hvis det er en fil, bliver den uploadet, som den er. Her er der ikke noget
interface-issue.

>> ==
>> Non-alphanumeric characters are replaced by `%HH', a percent sign and two
>> hexadecimal digits representing the ASCII code of the character. Line
>> breaks are represented as "CR LF" pairs (i.e., `%0D%0A').
>> ==
>>
>> Med andre ord: Det er ikke afhængigt af klientens browser eller
>> operativsystem.
>
>Det er så hvad standarden siger, men hvor mange browsere overholder
>standarden... jeg kan ihvertfald nævne et par stykker som ikke
>overholder den - eller ihvertfald store dele af den :)

Denne del af standarden kan jeg nu ikke huske, at udbredte browsere har
fraveget.

--
- Peter Brodersen
Kendt fra Internet

Stig Johansen (27-03-2008)
Kommentar
Fra : Stig Johansen


Dato : 27-03-08 23:16

Peter Brodersen wrote:

> On Wed, 26 Mar 2008 14:11:37 +0100, Stig Johansen <wopr.dk@gmaill.com>
> wrote:
>
>>FF (Windows) + Konqueror sender #10 (\n)
>>IE sender #13#13 (\r\n) eller vbCrLf.
>
> Firefox sender nu \r\n (#13 #10), dog urlencoded som %0D%0A. Det samme gør
> Safari og IE6.

Jeg har lige tjekket min FF 2.0.0.13, og den sender stadig kun \n eller %0A.
IE6 derimod sender #13#10.

> Med andre ord: Det er ikke afhængigt af klientens browser eller
> operativsystem.

Jo.

--
Med venlig hilsen
Stig Johansen

Peter Brodersen (28-03-2008)
Kommentar
Fra : Peter Brodersen


Dato : 28-03-08 09:33

On Thu, 27 Mar 2008 23:15:39 +0100, Stig Johansen <wopr.dk@gmaill.com>
wrote:

>> Firefox sender nu \r\n (#13 #10), dog urlencoded som %0D%0A. Det samme gør
>> Safari og IE6.
>Jeg har lige tjekket min FF 2.0.0.13, og den sender stadig kun \n eller %0A.
>IE6 derimod sender #13#10.

Hvilket operativsystem bruger du, og hvordan har du tjekket?

Det kan testes meget enkelt med en GET-form. Min Firefox (samme version,
WinXP) sender følgende:

...../test.php?text=%0D%0A

Et udpluk fra LiveHTTPHeaders viser også at Firefox sender
text=%0D%0A
ved POST.

Opera og Safari gør det samme.

For en god ordens skyld har jeg også testet nogle text-mode-browsere under
linux. w3m, links og lynx gør det samme (omend lynx sender %0d%0a, men
applikationer opfordres så vidt jeg husker til at være fleksible til også
at modtage encoding i lowercase).

Nogle browsere kan dog have tendens til at sende et ekstra linjeskift i
slutningen. Safari gør det nogle gange, og det samme med lynx.

--
- Peter Brodersen
Kendt fra Internet

Stig Johansen (29-03-2008)
Kommentar
Fra : Stig Johansen


Dato : 29-03-08 05:36

Peter Brodersen wrote:

> On Thu, 27 Mar 2008 23:15:39 +0100, Stig Johansen <wopr.dk@gmaill.com>
> wrote:
>
>>> Firefox sender nu \r\n (#13 #10), dog urlencoded som %0D%0A. Det samme

Jeg havde lige opdateret FF til 2.0.0.13, så jeg troede du mente 'nu', as in
'det gør den nu'.

>>Jeg har lige tjekket min FF 2.0.0.13, og den sender stadig kun \n eller
>>%0A. IE6 derimod sender #13#10.
>
> Hvilket operativsystem bruger du, og hvordan har du tjekket?

Windows 2000, vistnok SP4, engelsk version.

Jeg har en proxytrace, jeg har brugt de sidste 6-7 år i forbindelse med SOAP
osv.
Det ser ud som om det stadig kan hentes her:
<http://www.pocketsoap.com/tcptrace/>
Kig efter proxytrace nede af siden.

> Det kan testes meget enkelt med en GET-form. Min Firefox (samme version,
> WinXP) sender følgende:
>
> ..../test.php?text=%0D%0A

Nu bruger jeg så POST, og det er data fra <textarea>'erne jeg kigger på

>
> Et udpluk fra LiveHTTPHeaders viser også at Firefox sender
> text=%0D%0A
> ved POST.

Jeg er ikke med på hvad 'LiveHTTPHeders' er, men proxutrace viser
_wiredata_, og ikke hvad browsere viser.

> For en god ordens skyld har jeg også testet nogle text-mode-browsere under
> linux. w3m, links og lynx gør det samme (omend lynx sender %0d%0a, men
> applikationer opfordres så vidt jeg husker til at være fleksible til også
> at modtage encoding i lowercase).

Nu er jeg af den gamle skole, og mener at hex er med stort A..F, men hvad
faen, man må jo også skrive råstbøf nu om dage ;)

> Nogle browsere kan dog have tendens til at sende et ekstra linjeskift i
> slutningen. Safari gør det nogle gange, og det samme med lynx.

Jeg er ikke 100% sikker på om du mener ekstra linier i <textarea>'et eller i
HTTP'et.

Det sidste kan meget vel være tilfældet, da jeg har nogle tomme entries i
noget logger uniddelbart efter GET request'et.
Altså at de afslutter med 3xCrLf og ikke som angivrt 2xCrLf

Det er ikke noget der bekymrer mig, jeg har løst det.
Dog gik der en del tid med 'virker' 'virker ikke' med replace af hhv Lf og
CrLf til <br/>.

Selvfølgelig virker det (måske) ved kun at replace Lf, men personligt hader
jeg at sende 'Cr<br/>' til browseren.
Specielt da jeg kører med white-space: pre;

Jeg er nok rimelig sikker på det har noget med Win2K at gøre, men jeg synes
bare jeg blev nødt til at reagere på din provokation:

Det er ikke afhængigt af klientens browser eller _operativsystem_. ;)

--
Med venlig hilsen
Stig Johansen

Peter Brodersen (30-03-2008)
Kommentar
Fra : Peter Brodersen


Dato : 30-03-08 00:04

On Sat, 29 Mar 2008 05:36:24 +0100, Stig Johansen <wopr.dk@gmaill.com>
wrote:

>>>Jeg har lige tjekket min FF 2.0.0.13, og den sender stadig kun \n eller
>>>%0A. IE6 derimod sender #13#10.
>> Hvilket operativsystem bruger du, og hvordan har du tjekket?
>Windows 2000, vistnok SP4, engelsk version.

Gider du prøve at lave en GET-form og se, hvad browseren sender i
adresselinjen? Det skulle være temmeligt let at teste.

>> Det kan testes meget enkelt med en GET-form. Min Firefox (samme version,
>> WinXP) sender følgende:
>> ..../test.php?text=%0D%0A
>Nu bruger jeg så POST, og det er data fra <textarea>'erne jeg kigger på

Prøv med en GET. Men som sagt, jeg oplever det samme med POST.

>> Et udpluk fra LiveHTTPHeaders viser også at Firefox sender
>> text=%0D%0A
>> ved POST.
>Jeg er ikke med på hvad 'LiveHTTPHeders' er, men proxutrace viser
>_wiredata_, og ikke hvad browsere viser.

Et rart browser-plugin, som viser, hvad browseren sender:
http://livehttpheaders.mozdev.org/

>> For en god ordens skyld har jeg også testet nogle text-mode-browsere under
>> linux. w3m, links og lynx gør det samme (omend lynx sender %0d%0a, men
>> applikationer opfordres så vidt jeg husker til at være fleksible til også
>> at modtage encoding i lowercase).

Jeg må lige tilføje, at jeg også her tjekker serverloggen for at se, hvad
der bliver sendt.

Hvis du vil have det, kan jeg også varme op under en pakkesniffer.

>Nu er jeg af den gamle skole, og mener at hex er med stort A..F, men hvad
>faen, man må jo også skrive råstbøf nu om dage ;)

RFC1738 nævner:
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
escape = "%" hex hex

Jeg mindes blot, at jeg i en anden RFC angående browser-issues så, at det
skulle være i uppercase, idet PHPs urldecode i gamle dage vist ikke kunne
parse lowercase, men det blev fixet lige før jeg fik skruet en patch
sammen

Nå, det er et sidespor - den må jeg finde en anden dag.

>> Nogle browsere kan dog have tendens til at sende et ekstra linjeskift i
>> slutningen. Safari gør det nogle gange, og det samme med lynx.
>Jeg er ikke 100% sikker på om du mener ekstra linier i <textarea>'et eller i
>HTTP'et.

Altså, i textarea'et. Hvis brugeren tilføjer ét linjeskift, mener
Safari+Lynx, at der også skal være et trailing linjeskift.

>Jeg er nok rimelig sikker på det har noget med Win2K at gøre, men jeg synes
>bare jeg blev nødt til at reagere på din provokation:
>
>Det er ikke afhængigt af klientens browser eller _operativsystem_. ;)

Jeg må indrømme, at jeg stadigvæk ikke er fuldt overbevist

Jeg kan godt banke en side op, og så se, hvad loggen siger - evt. have en
pakkesniffer kørende til formålet.

Jeg tror, din proxydimse laver tricks. Der er blandt andet nævnt noget om
nogle options til at konvertere linjeskift.

Prøv eventuelt direkte med en pakkesniffer:
http://www.wireshark.org/

--
- Peter Brodersen
Kendt fra Internet

Stig Johansen (30-03-2008)
Kommentar
Fra : Stig Johansen


Dato : 30-03-08 12:19

Peter Brodersen wrote:

[snip]
> Hvis du vil have det, kan jeg også varme op under en pakkesniffer.
[og snip]

Ikke snip fordi det ikke er relevant, men jeg varmede op under en test.
Du har ret i, at ved almindelig GET og POST fra en form, så _bliver_ der
sendt %D%A.

Jeg var squ lige ved at tro jeg havde taget fejl.

Men der hvor jeg havde/har 'problemet' er ved AJAX kald via FF.
Altså ved document.getElementBiId('xx').value og en efterfølgende
encodeURIComponent / POST via XMLHTTPRequest.
Det er åbenbart _her_ de adskiller sig, og ikke ved almindelige POST/GET's.


--
Med venlig hilsen
Stig Johansen

Bertel Lund Hansen (25-03-2008)
Kommentar
Fra : Bertel Lund Hansen


Dato : 25-03-08 19:59

Erik Hansen skrev:

> Mit problem er at når jeg sender en mail med mail(), så når jeg gør
> det på min lokale WinXP så er der linjeskift, men hvis jeg sender det
> på Linux serveren så er der IKKE nogen linjeskift.

Er linjeskiftet kodet som "\r\n"?

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408924
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste