Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Prośba o sprawdzenie pierwszej wiadomości
2 views
Skip to first unread message
Borneq
Jan 4, 2020, 10:42:07 AM1/4/20
to
Wiadomość na pl.test "Test AUR"
Message-ID: <5e10b122$0$17361$6578...@news.neostrada.pl>
czy w UTF8 ma być tytuł zakodowany, nawet gdy nie używam akurat znaków UTF8?
Message-ID: <5e10b122$0$17361$6578...@news.neostrada.pl>
czy w UTF8 ma być tytuł zakodowany, nawet gdy nie używam akurat znaków UTF8?
Borneq
Jan 4, 2020, 10:47:40 AM1/4/20
to
W dniu 2020-01-04 o 16:41, Borneq pisze:
===================
Path:
news.neostrada.pl!unt-num.news.neostrada.pl!unt-spo-b-01.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail
User-Agent: AUR2020 Windows 10
From: "Borneq" <bor...@antyspam.hidden.pl>
Subject: Test AUR
Newsgroups: pl.test
Date: Sat, 4 Jan 2020 16:37:08 +0100
Lines: 4
Message-ID: <5e10b122$0$17361$6578...@news.neostrada.pl>
Organization: Telekomunikacja Polska
NNTP-Posting-Host: 37.47.9.20
X-Trace: 1578152226 unt-rea-a-01.news.neostrada.pl 17361 37.47.9.20:6416
X-Complaints-To: ab...@news.neostrada.pl
Xref: news.neostrada.pl pl.test:311451
Line 1.
Line 2.
Line 3.
===========
Dlaczego komponent Indy napisał mi Lines: 4 zamiast 3?
Bo są kropki , aby nie traktował kropki jako końca?
Path:
news.neostrada.pl!unt-num.news.neostrada.pl!unt-spo-b-01.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail
User-Agent: AUR2020 Windows 10
From: "Borneq" <bor...@antyspam.hidden.pl>
Subject: Test AUR
Newsgroups: pl.test
Date: Sat, 4 Jan 2020 16:37:08 +0100
Lines: 4
Message-ID: <5e10b122$0$17361$6578...@news.neostrada.pl>
Organization: Telekomunikacja Polska
NNTP-Posting-Host: 37.47.9.20
X-Trace: 1578152226 unt-rea-a-01.news.neostrada.pl 17361 37.47.9.20:6416
X-Complaints-To: ab...@news.neostrada.pl
Xref: news.neostrada.pl pl.test:311451
Line 1.
Line 2.
Line 3.
===========
Dlaczego komponent Indy napisał mi Lines: 4 zamiast 3?
Bo są kropki , aby nie traktował kropki jako końca?
Andrzej P. Wozniak
Jan 4, 2020, 12:18:56 PM1/4/20
to
Osoba podpisana jako Borneq <bor...@antyspam.hidden.pl>
w artykule <news:5e10b37f$0$548$6578...@news.neostrada.pl> pisze:
> W dniu 2020-01-04 o 16:41, Borneq pisze:
>> Wiadomość na pl.test "Test AUR"
>> Message-ID: <5e10b122$0$17361$6578...@news.neostrada.pl>
>>
>> czy w UTF8 ma być tytuł zakodowany, nawet gdy nie używam akurat znaków
>> UTF8?
Pola nagłówka muszą być zakodowane, kiedy występuje w nich jakikolwiek
znak spoza us-ascii (czyli znaki 8-bitowe). Są na to stosowne standardy
MIME.
> Dlaczego komponent Indy napisał mi Lines: 4 zamiast 3?
> Bo są kropki , aby nie traktował kropki jako końca?
Pole "Lines" świadczy o tym, że używasz przestarzałego komponentu. W nowym
standardzie nie używa się tego pola, jednak ze względu na kompatybilność
ze starszymi programami spotyka się zalecenie, aby podawać je z wartością
różną od zera (zero oznacza brak treści, czyli błąd/test/spam itp.)
Niektóre programy zliczają linie przed połamaniem, czyli akapity. Zatem –
cokolwiek to jest niezerowe, jest nieistotne.
Może zacznij czytać właściwe RFC zamiast klepać kod na pałę?
Jeśli chcesz cokolwiek sprawdzać, zacznij od tego:
- Używaj ogonków i różnych języków w nagłówku i w treści.
- Napisz temat i akapit dłuższy niż 256 znaków.
- Wklej do treści link dłuższy niż 80 znaków.
- Dołączaj sygnaturkę.
- Odpowiedz na głęboko zagnieżdżoną wiadomość (w przypadku własnych testów
zagnieżdzenie musi przekraczać 20-24 odpowiedzi do odpowiedzi}.
--
Andrzej P. Woźniak us...@pochta.onet.pl (zamień miejscami z⇔h w adresie)
w artykule <news:5e10b37f$0$548$6578...@news.neostrada.pl> pisze:
> W dniu 2020-01-04 o 16:41, Borneq pisze:
>> Wiadomość na pl.test "Test AUR"
>> Message-ID: <5e10b122$0$17361$6578...@news.neostrada.pl>
>>
>> czy w UTF8 ma być tytuł zakodowany, nawet gdy nie używam akurat znaków
>> UTF8?
znak spoza us-ascii (czyli znaki 8-bitowe). Są na to stosowne standardy
MIME.
> Dlaczego komponent Indy napisał mi Lines: 4 zamiast 3?
> Bo są kropki , aby nie traktował kropki jako końca?
standardzie nie używa się tego pola, jednak ze względu na kompatybilność
ze starszymi programami spotyka się zalecenie, aby podawać je z wartością
różną od zera (zero oznacza brak treści, czyli błąd/test/spam itp.)
Niektóre programy zliczają linie przed połamaniem, czyli akapity. Zatem –
cokolwiek to jest niezerowe, jest nieistotne.
Może zacznij czytać właściwe RFC zamiast klepać kod na pałę?
Jeśli chcesz cokolwiek sprawdzać, zacznij od tego:
- Używaj ogonków i różnych języków w nagłówku i w treści.
- Napisz temat i akapit dłuższy niż 256 znaków.
- Wklej do treści link dłuższy niż 80 znaków.
- Dołączaj sygnaturkę.
- Odpowiedz na głęboko zagnieżdżoną wiadomość (w przypadku własnych testów
zagnieżdzenie musi przekraczać 20-24 odpowiedzi do odpowiedzi}.
--
Andrzej P. Woźniak us...@pochta.onet.pl (zamień miejscami z⇔h w adresie)
Piotr Dałek
Jan 16, 2020, 1:39:37 PM1/16/20
to
W dniu sobota, 4 stycznia 2020 o godzinie 18:11:52, Andrzej P. Wozniak
napisał(a):
> Osoba podpisana jako Borneq <bor...@antyspam.hidden.pl>
> w artykule <news:5e10b37f$0$548$6578...@news.neostrada.pl> pisze:
>> W dniu 2020-01-04 o 16:41, Borneq pisze:
czytanie mana/doców to zupełnie nie-agile'owy relikt lat 80-tych i 90-tych,
ale komponenty i biblioteki nie zastąpią znajomości protokołu. Jeśli nie
będziesz znał nawet z grubsza zawartości RFC dot. MIME oraz NNTP, to w życiu
nie wyprodukujesz sensownego programu bo będziesz się bujać z błędami
wynikającymi z rozjazdu między RFC i "de-facto-standardami", wyobrażeniami
autorów komponentów i Twoją interpretacją tego, jak działają
komponenty/biblioteki.
> Jeśli chcesz cokolwiek sprawdzać, zacznij od tego:
> - Używaj ogonków i różnych języków w nagłówku i w treści.
Polecam miksować polski, rosyjski i tajski (dłuższe kody UTF8).
> - Napisz temat i akapit dłuższy niż 256 znaków.
1000. RFC limituje do 1000 znaków per wiersz i łatwo tu wpaść w buforową
pułapkę.
> - Wklej do treści link dłuższy niż 80 znaków.
i 1000 znaków.
> X-Operating-System: Windows XP Home PL / POSReady 2009
Serio? :)
Pozdrawiam,
--
.oooO /~) (~\ Oooo. "Programowanie to | Piotr Dałek
( ) / ( ) \ ( ) *najprzyjemniejsza* | enigm...@interia.pl
\ ( ( ) ( ) ) / rzecz, jaką można | http://www.hellcore-mailer.pl
\_)'oooO Oooo'(_/ robić w ubraniu" |
napisał(a):
> Osoba podpisana jako Borneq <bor...@antyspam.hidden.pl>
> w artykule <news:5e10b37f$0$548$6578...@news.neostrada.pl> pisze:
>> W dniu 2020-01-04 o 16:41, Borneq pisze:
>> Dlaczego komponent Indy napisał mi Lines: 4 zamiast 3?
>> Bo są kropki , aby nie traktował kropki jako końca?
> Pole "Lines" świadczy o tym, że używasz przestarzałego komponentu. W nowym
> standardzie nie używa się tego pola, jednak ze względu na kompatybilność
> ze starszymi programami spotyka się zalecenie, aby podawać je z wartością
> różną od zera (zero oznacza brak treści, czyli błąd/test/spam itp.)
> Niektóre programy zliczają linie przed połamaniem, czyli akapity. Zatem –
> cokolwiek to jest niezerowe, jest nieistotne.
> Może zacznij czytać właściwe RFC zamiast klepać kod na pałę?
Dokładnie. Ja rozumiem, że w dzisiejszych czasach pisanie "na pałę" to norma a
>> Bo są kropki , aby nie traktował kropki jako końca?
> Pole "Lines" świadczy o tym, że używasz przestarzałego komponentu. W nowym
> standardzie nie używa się tego pola, jednak ze względu na kompatybilność
> ze starszymi programami spotyka się zalecenie, aby podawać je z wartością
> różną od zera (zero oznacza brak treści, czyli błąd/test/spam itp.)
> Niektóre programy zliczają linie przed połamaniem, czyli akapity. Zatem –
> cokolwiek to jest niezerowe, jest nieistotne.
> Może zacznij czytać właściwe RFC zamiast klepać kod na pałę?
czytanie mana/doców to zupełnie nie-agile'owy relikt lat 80-tych i 90-tych,
ale komponenty i biblioteki nie zastąpią znajomości protokołu. Jeśli nie
będziesz znał nawet z grubsza zawartości RFC dot. MIME oraz NNTP, to w życiu
nie wyprodukujesz sensownego programu bo będziesz się bujać z błędami
wynikającymi z rozjazdu między RFC i "de-facto-standardami", wyobrażeniami
autorów komponentów i Twoją interpretacją tego, jak działają
komponenty/biblioteki.
> Jeśli chcesz cokolwiek sprawdzać, zacznij od tego:
> - Używaj ogonków i różnych języków w nagłówku i w treści.
> - Napisz temat i akapit dłuższy niż 256 znaków.
pułapkę.
> - Wklej do treści link dłuższy niż 80 znaków.
> X-Operating-System: Windows XP Home PL / POSReady 2009
Serio? :)
Pozdrawiam,
--
.oooO /~) (~\ Oooo. "Programowanie to | Piotr Dałek
( ) / ( ) \ ( ) *najprzyjemniejsza* | enigm...@interia.pl
\ ( ( ) ( ) ) / rzecz, jaką można | http://www.hellcore-mailer.pl
\_)'oooO Oooo'(_/ robić w ubraniu" |
Andrzej P. Wozniak
Jan 16, 2020, 2:15:57 PM1/16/20
to
Osoba podpisana jako Piotr Dałek <p...@nowhere.net>
w artykule <news:HCM7E401...@bmw.the.butterfly> pisze:
> W dniu sobota, 4 stycznia 2020 o godzinie 18:11:52, Andrzej P. Wozniak
> napisał(a):
>
referencjach wysyłanych przez OE, ten pamięta też liczbę z RFC:
998 (+CRLF) oktetów (bajtów, nie znaków), nie 1000 ani 1024.
;-P
Dla zawartości pól nagłówka znaków może być mniej w zależności od użytego
kodowania, linki w kanonicznej postaci też mają wszystko przekodowane do
US-ASCII.
Jednak w zależności od języka/kompilatora pułapka może być już przy 256
bajtach (dla pól nagłówka korci użycie innego typu zmiennej) – taki haczyk
pamiętam z dawnych czasów. Gdyby pierwszy próg został pokonany, pokazałbym
wyższy, po co od razu rzucać kłody pod nogi…
Potem przyszłoby sprawdzanie, czy łamie wyrazy przy przenoszeniu do linii
kontynuacji, jakim znakiem zaczyna linie kontynuacji itd.
>> X-Operating-System: Windows XP Home PL / POSReady 2009
> Serio? :)
Serioserio. Home też się dało przerobić, a OE nauczyć sygnaturek z pismem
niełacińskim. HCM/ECM potrafi takie sygnaturki?
Przy testach ElectroMailera pewnie będzie Windows Embedded Standard 7
(aktualizacje do końca 2021 roku).
…во-первых — учиться, во-вторых — учиться и в-третьих — учиться,
и затем проверять… — Владимир Ильич Ленин
w artykule <news:HCM7E401...@bmw.the.butterfly> pisze:
> W dniu sobota, 4 stycznia 2020 o godzinie 18:11:52, Andrzej P. Wozniak
> napisał(a):
>
>> - Napisz temat i akapit dłuższy niż 256 znaków.
> 1000. RFC limituje do 1000 znaków per wiersz i łatwo tu wpaść w buforową
> pułapkę.
Kto pamięta komunikat serwera "Line 3 too long" przy zbyt długich
> 1000. RFC limituje do 1000 znaków per wiersz i łatwo tu wpaść w buforową
> pułapkę.
referencjach wysyłanych przez OE, ten pamięta też liczbę z RFC:
998 (+CRLF) oktetów (bajtów, nie znaków), nie 1000 ani 1024.
;-P
Dla zawartości pól nagłówka znaków może być mniej w zależności od użytego
kodowania, linki w kanonicznej postaci też mają wszystko przekodowane do
US-ASCII.
Jednak w zależności od języka/kompilatora pułapka może być już przy 256
bajtach (dla pól nagłówka korci użycie innego typu zmiennej) – taki haczyk
pamiętam z dawnych czasów. Gdyby pierwszy próg został pokonany, pokazałbym
wyższy, po co od razu rzucać kłody pod nogi…
Potem przyszłoby sprawdzanie, czy łamie wyrazy przy przenoszeniu do linii
kontynuacji, jakim znakiem zaczyna linie kontynuacji itd.
>> X-Operating-System: Windows XP Home PL / POSReady 2009
> Serio? :)
niełacińskim. HCM/ECM potrafi takie sygnaturki?
Przy testach ElectroMailera pewnie będzie Windows Embedded Standard 7
(aktualizacje do końca 2021 roku).
…во-первых — учиться, во-вторых — учиться и в-третьих — учиться,
и затем проверять… — Владимир Ильич Ленин
Piotr Dałek
Jan 16, 2020, 4:36:59 PM1/16/20
to
W dniu czwartek, 16 stycznia 2020 o godzinie 20:15:04, Andrzej P. Wozniak
napisał(a):
> Osoba podpisana jako Piotr Dałek <p...@nowhere.net>
> w artykule <news:HCM7E401...@bmw.the.butterfly> pisze:
>> W dniu sobota, 4 stycznia 2020 o godzinie 18:11:52, Andrzej P. Wozniak
>> napisał(a):
>>
>>> - Napisz temat i akapit dłuższy niż 256 znaków.
>> 1000. RFC limituje do 1000 znaków per wiersz i łatwo tu wpaść w buforową
>> pułapkę.
> Kto pamięta komunikat serwera "Line 3 too long" przy zbyt długich
> referencjach wysyłanych przez OE, ten pamięta też liczbę z RFC:
> 998 (+CRLF) oktetów (bajtów, nie znaków), nie 1000 ani 1024.
> ;-P
Oczywiście. :)
> Dla zawartości pól nagłówka znaków może być mniej w zależności od użytego
> kodowania, linki w kanonicznej postaci też mają wszystko przekodowane do
> US-ASCII.
> Jednak w zależności od języka/kompilatora pułapka może być już przy 256
> bajtach (dla pól nagłówka korci użycie innego typu zmiennej) – taki haczyk
> pamiętam z dawnych czasów. Gdyby pierwszy próg został pokonany, pokazałbym
> wyższy, po co od razu rzucać kłody pod nogi…
Po co rzucać wiele małych kłód, skoro można jedną wielką i mieć pewność, że
potem z mniejszymi sobie poradzi?
> Potem przyszłoby sprawdzanie, czy łamie wyrazy przy przenoszeniu do linii
> kontynuacji, jakim znakiem zaczyna linie kontynuacji itd.
O tak, łamanie nagłówków to fajne ćwiczenie.
>>> X-Operating-System: Windows XP Home PL / POSReady 2009
>> Serio? :)
> Serioserio. Home też się dało przerobić, a OE nauczyć sygnaturek z pismem
> niełacińskim. HCM/ECM potrafi takie sygnaturki?
A chyba nie przyjmie óteefa (tylko lokalną stronę kodową) jeśli użyjesz
losowych wstawek albo sygnaturki z konfiguracji, ale w szablonie możesz mieć
całe utf8 test/demo i będzie klikać.
> Przy testach ElectroMailera pewnie będzie Windows Embedded Standard 7
> (aktualizacje do końca 2021 roku).
W sumie ciekawe jak mu się to zawidzi.
napisał(a):
> Osoba podpisana jako Piotr Dałek <p...@nowhere.net>
> w artykule <news:HCM7E401...@bmw.the.butterfly> pisze:
>> W dniu sobota, 4 stycznia 2020 o godzinie 18:11:52, Andrzej P. Wozniak
>> napisał(a):
>>
>>> - Napisz temat i akapit dłuższy niż 256 znaków.
>> 1000. RFC limituje do 1000 znaków per wiersz i łatwo tu wpaść w buforową
>> pułapkę.
> Kto pamięta komunikat serwera "Line 3 too long" przy zbyt długich
> referencjach wysyłanych przez OE, ten pamięta też liczbę z RFC:
> 998 (+CRLF) oktetów (bajtów, nie znaków), nie 1000 ani 1024.
> ;-P
> Dla zawartości pól nagłówka znaków może być mniej w zależności od użytego
> kodowania, linki w kanonicznej postaci też mają wszystko przekodowane do
> US-ASCII.
> Jednak w zależności od języka/kompilatora pułapka może być już przy 256
> bajtach (dla pól nagłówka korci użycie innego typu zmiennej) – taki haczyk
> pamiętam z dawnych czasów. Gdyby pierwszy próg został pokonany, pokazałbym
> wyższy, po co od razu rzucać kłody pod nogi…
potem z mniejszymi sobie poradzi?
> Potem przyszłoby sprawdzanie, czy łamie wyrazy przy przenoszeniu do linii
> kontynuacji, jakim znakiem zaczyna linie kontynuacji itd.
>>> X-Operating-System: Windows XP Home PL / POSReady 2009
>> Serio? :)
> Serioserio. Home też się dało przerobić, a OE nauczyć sygnaturek z pismem
> niełacińskim. HCM/ECM potrafi takie sygnaturki?
losowych wstawek albo sygnaturki z konfiguracji, ale w szablonie możesz mieć
całe utf8 test/demo i będzie klikać.
> Przy testach ElectroMailera pewnie będzie Windows Embedded Standard 7
> (aktualizacje do końca 2021 roku).
Queequeg
Jan 21, 2020, 4:57:15 AM1/21/20
to
Piotr Dałek <p...@nowhere.net> wrote:
>> Potem przyszłoby sprawdzanie, czy łamie wyrazy przy przenoszeniu do linii
>> kontynuacji, jakim znakiem zaczyna linie kontynuacji itd.
>
> O tak, łamanie nagłówków to fajne ćwiczenie.
Jeszcze kropkę bym wstawił w osobnej linii i po niej treść.
>> Potem przyszłoby sprawdzanie, czy łamie wyrazy przy przenoszeniu do linii
>> kontynuacji, jakim znakiem zaczyna linie kontynuacji itd.
>
> O tak, łamanie nagłówków to fajne ćwiczenie.
.
treść
--
https://www.youtube.com/watch?v=9lSzL1DqQn0
0 new messages