Czy znak powrotu karetki jest uważany za przestarzały

26

Napisałem bibliotekę open source, która analizuje uporządkowane dane, ale celowo pomijałem wykrywanie powrotu karetki, ponieważ nie widzę sensu. Dodaje dodatkową złożoność i ogólne koszty dla niewielkiej / zerowej korzyści.

Ku mojemu zdziwieniu użytkownik zgłosił błąd, w którym analizator składni nie działał, a ja odkryłem, że przyczyną problemu było to, że dane używały zakończeń linii CR w przeciwieństwie do LF lub CRLF.

Czy OSX nie używa zakończeń linii w stylu LF od czasu przejścia na platformę uniksową?

Wiem, że istnieją aplikacje takie jak Notepad ++, w których zakończenia linii można zmienić, aby jawnie używać CR, ale nie rozumiem, dlaczego ktoś chciałby to zrobić.

Czy bezpiecznie jest wykluczyć obsługę statystycznie nieistotnego odsetka użytkowników, którzy decydują się (z jakiegokolwiek powodu) na zakończenia linii w starym stylu Mac OS?

Aktualizacja:

Aby to wyjaśnić, obsługa zakończeń linii Windows (tj. CRLF) nie wymaga rozpoznawania tokenów CR. Dla celów wydajności leksyk dopasowuje się na podstawie jednego znaku. Ignorując znaki CR po cichu, token CRLF upraszcza się do LF. W związku z tym sam token CRLF można uznać za anachronizm sam w sobie, ale nie o to chodzi w tym pytaniu.

Ostatnim systemem operacyjnym, który zapewnił wsparcie systemowe dla zakończeń linii w stylu CR, był Mac OS 9 . Jak na ironię, jedyną aplikacją, która nadal używa go jako domyślnej w OSX, jest Microsoft Excel.

— Evan Plaice
źródło

21

„Dodaje dodatkową złożoność i koszty ogólne”: Myślę, że dodatkowa złożoność i koszty ogólne są naprawdę niewielkie.

— Giorgio

11

@EvanPlaice, czy nie dałoby to mniej bólu głowy i więcej czasu na lenistwo, aby po prostu podłączyć obsługę CR, którą celowo pominąłeś?

— Pieter B

11

„W kategoriach biznesowych koszt alternatywny jest zbyt wysoki. Mówiąc prościej, wolę znaleźć powody, aby uzasadnić swoje lenistwo, niż tracić czas na dodanie wsparcia dla martwej platformy.”: W kategoriach biznesowych zajęłoby mniej czasu wdrożyć wsparcie dla CR niż zadać pytanie tutaj, aby zbadać znaczenie tej funkcji.

— Giorgio

4

@EvanPlaice bezwładność kulturowa jest całkowicie dobrym powodem.

— Pieter B

5

@EvanPlaice: Napisanie tego pytania kosztuje już więcej czasu niż zwykłe przerzucenie wsparcia dla CRnowych linii do bazy kodu. (... a jeśli mocno wierzysz, że tak nie jest, konstrukcja twojego parsera musi być dość gorączkowa)

— ZJR

37

Istnieje dobra praktyka, w której jesteś „liberalny w tym, co akceptujesz, i konserwatywny w tym, co wysyłasz” .

Innymi słowy, jeśli istnieje szansa (choćby niewielka), że ktoś da ci koniec linii cr (i spodziewa się, że będzie działał poprawnie), będziesz musiał go wesprzeć.

TBH, nie widzę, jak dodanie obsługi CR trwałoby tak długo.

Kiedy zobaczysz znak crw leksykach, zerknij na następny znak, a jeśli jest to nl, połknij znak nowej linii i wyślij token nowej linii, jeśli następny znak nie jest nlpo prostu wyślij token nowej linii i kontynuuj.

— maniak zapadkowy
źródło

23

@ZJR: prawo pocztowe jest niebezpieczne: zachowaj ostrożność, stosując zasadę solidności, ponieważ często się odwraca. Bałagan parsowania HTML, w którym wciąż jesteśmy, można przypisać temu nastawieniu. Kiedy program akceptuje zniekształcone dane wejściowe, jego zachowanie wkrótce staje się oczekiwane i zależy od zachowania, a wszelkie późniejsze zmiany, które traktują źle sformułowane dane wejściowe inaczej lub wcale, choć nie są poprawne technicznie, są często uważane za wadliwe.

— whatsisname

4

@whatsisname: Nie zgadzam się. Myślę, że oprogramowanie o jakości produkcyjnej powinno być solidne. Łańcuchy narzędzi programistycznych powinny jednak zdecydowanie odradzać poleganie na takiej solidności i generować tylko prawidłowe wyniki. Bałagan w html jest spowodowany przez prawie dwie dekady słabych narzędzi, a nie przez łagodność przeglądarek.

— back2dos,

2

@ back2dos: _ _ so? słabe oprzyrządowanie jest spowodowane łagodnością przeglądarek.

— amara

4

słabe oprzyrządowanie jest wynikiem wojny przeglądarki

— maniak zapadkowy

2

@Dibbeke: Obsługa zniekształconych danych wejściowych jedynie odwzorowuje większą przestrzeń wejściową na istniejącą przestrzeń stanów, a zatem nie ma na nią wpływu - pod warunkiem, że oprogramowanie ma przyzwoity podział problemów.

— back2dos

21

Nie. CR nie jest przestarzały (zdefiniowany jako „już nie produkowany ani używany”). Ty sam to udowodniłeś. Być może jest to rzadkie , ale nie przestarzałe .

Jeśli chodzi o „czy bezpiecznie jest wykluczyć wsparcie” dla CR? Jak mówisz, nie jest to kwestia utraty sprzedaży i nie możesz obsłużyć każdej dziwnej kombinacji znaków i formatu plików na świecie, a tylko Ty znasz swoje oprogramowanie i bazę użytkowników. Powiedziałbym więc, że można go bezpiecznie wykluczyć, jeśli jesteś przekonany, że obciążenie związane z brakiem dodawania (jak wyjaśnia mouviciel) nie przeważa nad nakładem czasu na dodanie. Ale nie wiedząc dużo więcej o produkcie i bazie użytkowników, nie jestem pewien, jak być bardziej szczegółowym.

— Szczęśliwy kot
źródło

13

+1 - IMO, OP próbuje oznaczyć CR jako „przestarzały”, aby miał pretekst, by go nie wspierać.

— Stephen C

1

@StephenC Nie próbuję ukryć tego faktu. To nie tak, że naprawdę potrzebuję wymówki, jestem autorem i dlatego mam ostatnie słowo. Chodzi o to, że rodzi interesujące pytanie.

— Evan Plaice,

18

O lenistwie: musisz zrównoważyć:

wysiłek w celu zmiany kodu, aby CR był bezpiecznie obsługiwany (a następnie o nim zapomniał).
wysiłek w wyjaśnianiu użytkownikom, dlaczego pliki, z których byli zadowoleni przez dziesięciolecia, nagle powodują awarię aplikacji, znajdowanie obejść, z których mogą korzystać bez narażania sprzedaży, oraz proszenie o argumenty i odpowiedzi na komentarze tutaj.

Od Ciebie zależy, która ścieżka jest najbardziej leniwa.

— mouviciel
źródło

Dobre punkty, wsparcie zdecydowanie wiąże się z kosztem czasu. W tym konkretnym przypadku „sprzedaż” nie stanowi problemu (tj. Jest to oprogramowanie typu open source), ale warto rozważyć szerszy obraz. Podobnie, mogę również zgłosić wyjątek w kodzie, gdy napotkamy CR wskazujący na niepoprawny / nieobsługiwany znak.

— Evan Plaice,

7

@Evan: Oczywiście to open source. Gdyby tak nie było, twój szef powiedziałby ci: „Nie obchodzi mnie to, że„ nikt ”nie używa CR! Klienci narzekają. : P Jest to wielka rzecz w OSS, która mnie wkurza: brak zainteresowania prawdziwymi przypadkami , na które narzekali użytkownicy. Niezależnie od tego, czy uważasz, że jest przestarzały, czy nie, ktoś nadal go używa.

— cHao 13.12.12

1

ponieważ jest to oprogramowanie typu open source, możesz napisać list otwarty do wszystkich użytkowników, że zaakceptujesz każdą łatkę, aby to naprawić.

— rwong

1

@EvanPlaice: Ta „uwaga jest ... walutą” działa w obie strony. Jeśli chcesz, aby ludzie korzystali z Twojej aplikacji, musi działać i musi rozwiązać ich problem. Zepsuta aplikacja nie jest odporna na krytykę tylko dlatego, że jest darmowa. Nie mówię, że musisz robić wszystko , o co proszą użytkownicy; Państwo powinno odwołać skandaliczne żądania. Ale jeśli nie rozwiążesz prawdziwych problemów użytkowników, stracisz użytkowników.

— cHao

1

@EvanPlaice: A tak przy okazji, kiedy mam na myśli „narzekać”, mam na myśli „złóż raport o błędzie, opisując, co jest zepsute i jak”, a nie „narzekaj losowo o tym, jak złe jest oprogramowanie”.

— cHao

8

Czy bezpiecznie jest wykluczyć obsługę statystycznie nieistotnego odsetka użytkowników, którzy decydują się (z jakiegokolwiek powodu) na zakończenia linii w starym stylu Mac OS?

Być może niewielu użytkowników to wykryje, ale w pokoju jest słoń: zakończenia linii Windows ( CRLF). Jeśli je popierasz (generalnie tak, chociaż używam tylko Windowsa do gier), obsługa trzeciej części tego historycznego trójkąta bermudzkiego powinna być trywialna.

Jeśli nie obsługujesz czegoś takiego, powinieneś przynajmniej wspomnieć o tym w dokumentacji (styl „To nie jest błąd”) oraz o tym, jak zmieniać pliki, aby działały z twoim narzędziem w najprostszy możliwy sposób ( dos2unixna przykład).

— 10b0
źródło

2

+1 za wzmiankę o używaniu systemu Windows CRLF- jest to domyślna linia kończąca się w tym systemie operacyjnym. I nie ma sposobu, aby zagwarantować źródło pliku .csv, więc łatwo można go utworzyć w systemie Windows.

1

Wzmianka o CRLF w systemie Windows nie ma znaczenia, ponieważ jeśli łapiesz LF jako punkt przerwania, automatycznie otrzymasz CRLF jako bonus. OP wie o tym, jak widać w tekście jego postu.

— davidethell

@davidethell Tak, tak to się robi. Obecnie znaki CR są po cichu ignorowane. Niezależnie od słoni.

— Evan Plaice,

6

Istnieje wiele urządzeń szeregowych, które polegają na CRzakończeniu strumienia danych przed ETXwysłaniem. To konwencja, która nigdy nie odejdzie.

— Brian
źródło

3

Potraktowałbym tę prośbę jako każdą prośbę o funkcję, w której trzeba porównać koszty z korzyściami.

Jeśli dokładnie jedna osoba poprosiła o wsparcie CR, być może nie jest to konieczne. Zobacz poniższy rozdział książki z 37 sygnałów, które mówią, że powinieneś martwić się tylko bardzo popularnymi żądaniami funkcji.

http://gettingreal.37signals.com/ch05_Forget_Feature_Requests.php

— Aaron Kurtzhals
źródło

1

Wreszcie dobry kontrapunkt. Gdybym mógł wybrać dwie odpowiedzi, wybrałbym również tę jedną.

— Evan Plaice

1

Systemy MS OS od MSDOS używają kombinacji CR + LF jako separatora linii (myślę, że głównie z powodu drukarek matrycowych, które ich potrzebują).

Więc tak, to kłótnia, ale wciąż potrzebujesz wsparcia dla tego cholerstwa.

— linkerro
źródło