Skąd wzięły się znaki końca wiersza? Przecież logicznie myśląc są one całkowicie niepotrzebne. Informacja na ekranie może być zawijana, a szerokość tekstu zależy od rozmiaru pola edycyjnego. Pojedynczym elementem tekstu (pomijając słowa i zdania) powinien być akapit. Niestety, komputery za swoje pierwowzory miały maszyny do pisania. a tam, wiadomo - był taki mały śmieszny dzwoneczek, który się odzywał, gdy wałek na którym nawinięta była kartka papieru przejeżdżał maksymalnie w prawo (pamiętajmy, że w maszynach do pisania kursor-karetka był nieruchomy, za to ruchome było pole edycyjne.. Wtedy to, maszynistka przy pomocy odpowiedniej dźwigienki przymocowanej do wałka przesuwała wałek i kartkę w lewo (Carriage Return) a odpowiedni mechanizm przesuwał kartkę o linię do góry (Line Feed).

Tak powstały znaki końca wiersza, oznaczane kiedyś jako CR/LF. W chwili, gdy powstały komputery a wraz z nimi podstawowa tablica ASCII, znaki te zostały w niej ujęte i otrzymały swoją reprezentację. Dziesiętnie znaki te maja kody ASCII 10 (LF) i 13 (CR). Dzięki temu, można było wysłać te kody do drukarki, która mogła zrobić to, co do tej pory robiła maszynistka po usłyszeniu dzwonka.

Aktualnie znaki te zapisuje się:

• Cariage-Return (CR) - \r
• Line Feed (LF) - \n

W tym miejscu należy zwrócić uwagę na fakt, iź systemy Windows używają obu znaków, czyli \r\n, Unixy tylko jednego: \n, a MacOS dla odmiany stosuje tylko \r. Niewielka to różnica, jeśli się tylko o niej pamięta. Zwykle do problemów ze znakami dochodzi w chwili, gdy mamy formularz, a w nim pole typu <textarea>. Użytkownik coś w nim pisze, wysyła, a my mamy problem, co z tym zrobić. Nasze postępowanie zależne jest od tego, co z danymi chcemy zrobić. Wydzielić można następujące operacje:

1. Zapis do pliku tekstowego
2. Zapis do bazy danych
3. Wyświetlenie jako treść
4. Wyświetlenie w polu edycyjnym