Czy przeglądarki wysyłają „\ r \ n” lub „\ n”, czy też zależy to od przeglądarki?

102

To pytanie niepokoi mnie od milionów lat ... za każdym razem, gdy tworzę stronę internetową z obszarem tekstowym, który pozwala na wiele linii (np. „Bio” w profilu użytkownika), zawsze kończy się na pisaniu następującego paranoicznego kodu:

// C# code sample...
bio = bio.Replace("\r\n", "\n").Replace("\r", "\n");
bio = Regex.Replace(@"\n{2,}", "\n\n");

Więc co wysyłają przeglądarki, <textarea name="Bio"></textarea>jeśli ma wiele wierszy?

— Timothy Khouri
źródło

Wow, pomyślałem, że to dziwne pytanie, na które nikt nie zwróci uwagi ... ale 16 głosów w 1 godzinę, szaleństwo.

— Timothy Khouri

Myśląc o tym, nigdy nie natknąłem się na problem z tym związany. Jeśli ktoś wprowadzi nową linię, jest ona wyświetlana jako nowa linia we wszystkich systemach operacyjnych, klientach MySQL, przeglądarkach itp. Wygląda na to, że oznacza to, że większość oprogramowania ma dość spójne podejście do sprawy. Oczywiście, jeśli mam z tym zrobić coś ważnego, zawsze normalizuję.

— Halil Özgür

Problem pojawiłby się, gdybym polegał na „\ r \ n”, a potem tworzyłem „w formacie HTML” wersję biografii użytkownika, a ponieważ nigdy nie natrafiłem na „\ r \ n”, wrzucam to wszystko jeden <p>tag.

— Timothy Khouri

Odpowiedzi:

Specyfikacje HTTP i MIME określają, że wiersze nagłówka muszą kończyć się na \ r \ n, ale nie są jasne (niektórzy twierdzą, że nie jest jasne, czy są jasne), co zrobić z zawartością TEXTAREA. (Zobacz na przykład ten wątek grupy roboczej ds. HTML dotyczący tego problemu).

Oto cytat ze specyfikacji HTTP / 1.1 dotyczący nagłówków wiadomości:

Terminatorem wiersza dla pól nagłówka komunikatu jest sekwencja CRLF. Jednak zalecamy, aby aplikacje podczas analizowania takich nagłówków rozpoznawały pojedynczy LF jako terminator linii i ignorowały wiodącą CR.

Myślę, że ogólnie jest to dobra strategia: bądź surowa w stosunku do tego, co produkujesz, ale liberalna w tym, co akceptujesz. Powinieneś założyć, że otrzymasz różnego rodzaju terminatory linii. (Zauważ, że oprócz CRLF i LF, Mac OS-9 używał samego CR i wciąż jest ich kilka. Standard Unicode (sekcja 5.8) określa szeroki zakres sekwencji znaków, które powinny być rozpoznawane jako terminatory linii; jest ich lista tutaj .)

— Ted Hopp
źródło

Nie sądzę, aby specyfikacje precyzowały, co produkuje textarea.

— Mark Thomas,

@Will: Przeczytaj ponownie pierwotne pytanie. W szczególności pyta o to, w jaki sposób przeglądarki kodują zawartość textarea(czego nie ogranicza specyfikacja lub przynajmniej cytowana przez Teda jej sekcja).

— John Bartholomew

@Mark - masz rację. Na różnych forach toczą się niekończące się dyskusje na ten temat. (Zobacz ten wątek z 1995 roku z grupy roboczej HTML.

— Ted Hopp,

Ta odpowiedź wymaga edycji. Zaczyna cytując specyfikację HTTP, ale nie dotyczy to obszarów tekstowych.

— DuckMaestro

Tak, ale odpowiedź nadal zaczyna się od cytowania protokołu HTTP, który jest złą specyfikacją, którą należy podkreślać, jeśli w ogóle ją wymieniam. Dołączony cytat dotyczy w szczególności „pól nagłówka wiadomości”, ale textareanie są one wysyłane jako pola nagłówka wiadomości. textareas zostają zakodowane w treści wiadomości, która jest inna.

— DuckMaestro

co wysyłają przeglądarki, <textarea></textarea>jeśli ma wiele wierszy?

Wszystkie nowoczesne przeglądarki wysyłają CRLF ( \r\n). Jednak nie jest to coś, co zostało zadowalająco ustandaryzowane, więc zdecydowanie uznałbym, że warto znormalizować znaki nowej linii w całym wielowierszowym tekście wejściowym.

Gdy wartość jest odczytywana przez JavaScript, a nie przesyłana bezpośrednio z formularza, zachowanie przeglądarki różni się. IE i Opera zwracają ciągi znaków z CRLF w; Firefox i WebKit zwracają LF. Zatem każdy formularz, który zostanie przesłany za pomocą pomocy JavaScript / XMLHttpRequest, prawdopodobnie przyjdzie w dowolnej formie.

— bobince
źródło

Czy JavaScript działa spójnie w określonej przeglądarce na różnych platformach? (Na przykład, czy Firefox zwraca ciągi znaków z LF na Windows, Macach i platformach mobilnych?)

— Ted Hopp,

@Ted: To zachowanie jest spójne na wszystkich platformach w przeglądarkach Firefox, Opera i WebKit. IE5 / Mac nie testowałem, ponieważ jest już dawno martwy, ale ta przeglądarka ma wiele różnic w porównaniu z IE5 / Win.

— bobince