Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #114574 > unrolled thread

Re: ubuntu releas-upgrade

Back to article view | Back to de.comp.os.unix.linux.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: ubuntu releas-upgrade Jan Novak <repcom@gmail.com> - 2021-02-04 07:06 +0100
    Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-04 12:17 -0500
      Re: ubuntu releas-upgrade Claus Reibenstein <creibens@gmail.com> - 2021-02-04 18:32 +0100
        Re: ubuntu releas-upgrade Enrik Berkhan <Enrik.Berkhan@inka.de> - 2021-02-04 19:52 +0000
          Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-04 18:08 -0500
            Re: ubuntu releas-upgrade Helmut Waitzmann <nn.throttle@xoxy.net> - 2021-02-05 01:25 +0100
              Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-04 23:45 -0500
            Re: ubuntu releas-upgrade Claus Reibenstein <creibens@gmail.com> - 2021-02-05 13:06 +0100
              Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-05 13:08 -0500
        Re: ubuntu releas-upgrade Juergen Ilse <news@usenet-verwaltung.de> - 2021-02-06 19:14 +0000
          Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-06 16:55 -0500
            Re: ubuntu releas-upgrade Christian Garbs <mitch@cgarbs.de> - 2021-02-17 22:17 +0100
              Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-17 17:29 -0500
                Re: ubuntu releas-upgrade Christian Garbs <mitch@cgarbs.de> - 2021-02-20 17:51 +0100
          Re: ubuntu releas-upgrade Claus Reibenstein <creibens@gmail.com> - 2021-02-07 14:25 +0100
      Re: ubuntu releas-upgrade Hans CraueI <crauel_usenet@freenet.de> - 2021-02-04 21:51 +0000
        Re: ubuntu releas-upgrade Claus Reibenstein <creibens@gmail.com> - 2021-02-05 13:08 +0100
          Re: ubuntu releas-upgrade Hans CraueI <crauel_usenet@freenet.de> - 2021-02-05 12:27 +0000
            Re: ubuntu releas-upgrade Claus Reibenstein <creibens@gmail.com> - 2021-02-05 17:06 +0100
              [OT] trn (was: ubuntu releas-upgrade) Michael Bäuerle <michael.baeuerle@stz-e.de> - 2021-02-05 18:02 +0100
                Re: [OT] trn "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-02-05 17:39 +0000
                  Re: [OT] trn Hans CraueI <crauel_usenet@freenet.de> - 2021-02-06 00:34 +0000
              [OT] trn Hans CraueI <crauel_usenet@freenet.de> - 2021-02-06 00:16 +0000
                Re: [OT] trn "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-02-06 23:28 +0000
                  Re: [OT] trn Andreas Kohlbach <ank@spamfence.net> - 2021-02-06 19:27 -0500
                Re: [OT] trn Claus Reibenstein <creibens@gmail.com> - 2021-02-07 14:28 +0100
            Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-05 13:22 -0500
              Alte Newsreader (was: ubuntu releas-upgrade) Clemens Schüller <cs.usenet@mailbox.org> - 2021-02-05 20:12 +0100
              Re: ubuntu releas-upgrade Hans CraueI <crauel_usenet@freenet.de> - 2021-02-06 00:28 +0000
                Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-05 20:12 -0500
                Re: ubuntu releas-upgrade Frank Miller <miller@posteo.ee> - 2021-02-06 05:20 +0100
                  Re: ubuntu releas-upgrade Claus Reibenstein <creibens@gmail.com> - 2021-02-06 13:13 +0100
                    Re: ubuntu releas-upgrade klaus reile <klaus.reile@x-mail.org> - 2021-02-06 13:18 +0100
                      Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-06 09:24 -0500
                        Re: ubuntu releas-upgrade klaus reile <klaus.reile@x-mail.org> - 2021-02-06 19:17 +0100
                      Re: ubuntu releas-upgrade Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-02-06 18:19 +0100
                        Re: ubuntu releas-upgrade klaus reile <klaus.reile@mail.ru> - 2021-02-06 19:30 +0100
                          Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-06 13:50 -0500
                            Re: ubuntu releas-upgrade klaus reile <klaus.reile@x-mail.org> - 2021-02-06 20:09 +0100
                              Re: ubuntu releas-upgrade Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-02-07 12:43 +0100
                          Re: ubuntu releas-upgrade Claus Reibenstein <creibens@gmail.com> - 2021-02-07 14:33 +0100
                            Re: OT: Was Grundsaetzliches was: ubuntu releas-upgrade klaus reile <klaus.reile@mail.ru> - 2021-02-07 14:55 +0100
                              Re: OT: Was Grundsaetzliches was: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-07 13:10 -0500
                                Re: OT: Was Grundsaetzliches was: ubuntu releas-upgrade Gernot Griese <ggriese@gmx.de> - 2021-02-07 20:02 +0100
                                  Re: OT: Was Grundsaetzliches was: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-07 15:30 -0500
                                    Re: OT: Was Grundsaetzliches was: ubuntu releas-upgrade Gernot Griese <ggriese@gmx.de> - 2021-02-07 21:55 +0100
                                      Re: OT: Was Grundsaetzliches was: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-07 17:14 -0500
                                    Jaywalking (was: OT: Was Grundsaetzliches) Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-02-08 07:40 +0100
                                    Re: OT: Was Grundsaetzliches was: ubuntu releas-upgrade Claus Reibenstein <creibens@gmail.com> - 2021-02-08 10:37 +0100
                      Re: ubuntu releas-upgrade Wolfgang Kynast <wky@gmx.de> - 2021-02-07 08:42 +0100
                        Re: ubuntu releas-upgrade klaus reile <klaus.reile@x-mail.org> - 2021-02-07 10:03 +0100
                          OT (was: Re: ubuntu releas-upgrade) Andreas Neumann <an5275@sedo.com> - 2021-02-07 12:08 +0200
                            Re: OT (was: Re: ubuntu releas-upgrade) klaus reile <klaus.reile@mail.ru> - 2021-02-07 11:17 +0100
                  Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-06 09:27 -0500
                  Re: ubuntu releas-upgrade Paul Muster <exp-311221@news.muster.net> - 2021-02-06 19:50 +0100
                    Re: ubuntu releas-upgrade Frank Miller <miller@posteo.ee> - 2021-02-07 06:21 +0100
                    Re: ubuntu releas-upgrade Arno Welzel <usenet@arnowelzel.de> - 2021-02-07 17:39 +0100
                Re: ubuntu releas-upgrade Juergen Ilse <news@usenet-verwaltung.de> - 2021-02-06 20:17 +0000
                  Re: ubuntu releas-upgrade Arno Welzel <usenet@arnowelzel.de> - 2021-02-07 17:41 +0100
                    [OT] Artikel Codierung (was: ubuntu releas-upgrade) Michael Bäuerle <michael.baeuerle@gmx.net> - 2021-02-07 19:29 +0100
                      Re: [OT] Artikel Codierung (was: ubuntu releas-upgrade) Arno Welzel <usenet@arnowelzel.de> - 2021-02-07 21:09 +0100
                        Re: [OT] Artikel Codierung Michael Bäuerle <michael.baeuerle@stz-e.de> - 2021-02-08 11:00 +0100
                        Re: [OT] Artikel Codierung Michael Ottenbruch <M.Ottenbruch@sailor.ping.de> - 2021-03-09 11:00 +0100
                          Re: [OT] Artikel Codierung Helmut Waitzmann <nn.throttle@xoxy.net> - 2021-03-10 11:27 +0100
                            Re: [OT] Artikel Codierung Michael Bäuerle <michael.baeuerle@stz-e.de> - 2021-03-10 14:35 +0100
                              Re: [OT] Artikel Codierung Thomas Dorner <de.comp.os.unix.linux.misc.210310.dorner@spamgourmet.com> - 2021-03-10 15:14 +0100
                                Re: [OT] Artikel Codierung Michael Bäuerle <michael.baeuerle@stz-e.de> - 2021-03-10 16:56 +0100
                          Re: [OT] Artikel Codierung Arno Welzel <usenet@arnowelzel.de> - 2021-03-10 13:36 +0100
                            Re: [OT] Artikel Codierung Michael Ottenbruch <M.Ottenbruch@sailor.ping.de> - 2021-03-11 09:44 +0100
                  Re: ubuntu releas-upgrade Florian Weimer <fw@deneb.enyo.de> - 2021-02-07 21:19 +0100
                    Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-07 15:22 -0500
                      Re: ubuntu releas-upgrade Claus Reibenstein <creibens@gmail.com> - 2021-02-08 10:39 +0100
                Re: ubuntu releas-upgrade Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-03-09 14:07 +0100
            Re: ubuntu releas-upgrade Juergen Ilse <news@usenet-verwaltung.de> - 2021-02-06 19:53 +0000
              Re: ubuntu releas-upgrade Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-02-06 20:36 +0000
                Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-06 16:58 -0500
                  Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-06 17:00 -0500
                  Re: ubuntu releas-upgrade Juergen Ilse <news@usenet-verwaltung.de> - 2021-02-07 13:14 +0000
                    Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-07 13:04 -0500
                Re: ubuntu releas-upgrade "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-02-06 23:21 +0000
                  Re: ubuntu releas-upgrade Andreas Kohlbach <ank@spamfence.net> - 2021-02-06 19:26 -0500
          Re: ubuntu releas-upgrade Juergen Ilse <news@usenet-verwaltung.de> - 2021-02-06 19:47 +0000
            Re: ubuntu releas-upgrade Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-02-07 20:22 +0100
              [OT] Newsreader (was: ubuntu releas-upgrade) Michael Bäuerle <michael.baeuerle@stz-e.de> - 2021-02-08 11:07 +0100
                Re: [OT] Newsreader (was: ubuntu releas-upgrade) Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-02-08 14:27 +0100
                  Re: [OT] Newsreader Michael Bäuerle <michael.baeuerle@stz-e.de> - 2021-02-08 16:36 +0100
                    Re: [OT] Newsreader Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-02-08 21:42 +0100
                      Re: [OT] Newsreader Andreas Kohlbach <ank@spamfence.net> - 2021-02-08 16:56 -0500
                        Re: [OT] Newsreader Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-02-09 07:27 +0100
                          Re: [OT] Newsreader Michael Uplawski <michael.uplawski@uplawski.eu> - 2021-02-09 07:47 +0100
                          Re: [OT] Newsreader Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-02-09 08:32 +0000
                            Re: [OT] Newsreader Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-02-09 10:46 +0100
                              Re: [OT] Newsreader Başar Alabay <alabay@gmx.net> - 2021-02-09 12:09 +0000
                                Re: [OT] Newsreader Thomas Hochstein <thh@thh.name> - 2021-02-09 13:59 +0100
                                  Re: [OT] Newsreader Stefan Reuther <stefan.news@arcor.de> - 2021-02-09 17:36 +0100
                          Re: [OT] Newsreader Claus Reibenstein <creibens@gmail.com> - 2021-02-09 15:07 +0100
                          Re: [OT] Newsreader Klaus von der Heyde <asc.soc@freenet.de> - 2021-02-09 19:25 +0000
                        Re: [OT] Newsreader Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-02-09 07:53 +0100
                          Re: [OT] Newsreader Andreas Kohlbach <ank@spamfence.net> - 2021-02-09 12:14 -0500
                            Re: [OT] Newsreader Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-02-09 19:58 +0100
                              Re: [OT] Newsreader Andreas Kohlbach <ank@spamfence.net> - 2021-02-09 17:49 -0500
                                Re: programm zu langsam (war:[OT] Newsreader) Albrecht Mehl <unvalid@invalid.invalid> - 2021-02-10 08:09 +0100
                                  Re: programm zu langsam (war:[OT] Newsreader) Frank Miller <miller@posteo.ee> - 2021-02-11 03:22 +0100
                                    Re: programm zu langsam (war:[OT] Newsreader) Albrecht Mehl <unvalid@invalid.invalid> - 2021-02-11 07:46 +0100
                                      Re: programm zu langsam (war:[OT] Newsreader) Helmut Waitzmann <nn.throttle@xoxy.net> - 2021-02-11 13:45 +0100
                                      Re: programm zu langsam (war:[OT] Newsreader) Frank Miller <miller@posteo.ee> - 2021-02-14 05:25 +0100
                                Re: [OT] Newsreader Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-02-10 12:29 +0100
                                  Re: [OT] Newsreader Andreas Kohlbach <ank@spamfence.net> - 2021-02-10 11:51 -0500
                                    Re: [OT] Newsreader Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-02-10 20:28 +0100
                                      Ist "nur" hinreichend oder notwendig? (was: [OT] Newsreader) Andreas Kohlbach <ank@spamfence.net> - 2021-02-10 16:06 -0500
                                    Re: [OT] Newsreader Helmut Waitzmann <nn.throttle@xoxy.net> - 2021-02-10 21:43 +0100
                                      Re: [OT] Newsreader Andreas Kohlbach <ank@spamfence.net> - 2021-02-10 21:56 -0500
                      Re: [OT] Newsreader Thomas Hochstein <thh@thh.name> - 2021-02-11 21:39 +0100
                  Re: [OT] Newsreader Clemens Schüller <cs.usenet@mailbox.org> - 2021-02-08 22:37 +0100
                    Re: [OT] Newsreader Thomas Dorner <de.comp.os.unix.linux.misc.210209.dorner@spamgourmet.com> - 2021-02-09 19:36 +0100
                      Re: [OT] Newsreader Clemens Schüller <cs.usenet@mailbox.org> - 2021-02-09 21:03 +0100
                        Re: [OT] Newsreader Thomas Dorner <de.comp.os.unix.linux.misc.210210.dorner@spamgourmet.com> - 2021-02-10 19:12 +0100
                          Re: [OT] Newsreader Clemens Schüller <cs.usenet@mailbox.org> - 2021-02-10 21:42 +0100
                      Re: [OT] Newsreader Andreas Kohlbach <ank@spamfence.net> - 2021-02-09 17:55 -0500
                        Re: [OT] Newsreader Clemens Schüller <cs.usenet@mailbox.org> - 2021-02-10 00:00 +0100
                Re: [OT] Newsreader Clemens Schüller <cs.usenet@mailbox.org> - 2021-02-08 22:35 +0100
                  Re: [OT] Newsreader Michael Bäuerle <michael.baeuerle@stz-e.de> - 2021-02-10 13:50 +0100

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#114686 — Re: [OT] Artikel Codierung (was: ubuntu releas-upgrade)

Michael Bäuerle:

> Arno Welzel wrote:
>> Juergen Ilse:
>>>
>>> [...]
>>> Nein, das Problem entsteht dadurch, dass nicht von allen die "kleinste" (im
>>> Sinne von "wenigsten aufwendige") Codierung verwendet wird, die zum codieren
>>> des jeweiligen Textes ausreicht (wird das nicht irgendwo auch vorgeschrieben,
>>> auch wenn sich fast keiner an diese Regel haelt?).
>>
>> Nein, es gibt keine solche Regel, dass man nur bestimmte Codierungen
>> benutzen soll. Und ob nun ISO-8859-x oder UTF-8 macht bzgl. Aufwand
>> keinen substantiellen Unterschied.
> 
> RFC 2046 sagt dazu:
> <https://tools.ietf.org/html/rfc2046#section-4.1.2>
> (Kapitel 4.1.2, letzter Absatz)
> 
> | In general, composition software should always use the "lowest common
> | denominator" character set possible.  For example, if a body contains
> | only US-ASCII characters, it SHOULD be marked as being in the US-
> | ASCII character set, not ISO-8859-1, which, like all the ISO-8859
> | family of character sets, is a superset of US-ASCII.  More generally,
> | if a widely-used character set is a subset of another character set,
> | and a body contains only characters in the widely-used subset, it
> | should be labelled as being in that subset.  This will increase the
> | chances that the recipient will be able to view the resulting entity
> | correctly.

Das sagt eigentlich nicht aus, dass man nur einen möglichst einfachen
Zeichensatz verwenden soll, sondern dass die angegebene Codierung gemäß
MIME den kleinst mögliche Variante passend zum Inhalt verwenden soll.

Wenn also ein Text faktisch US-ASCII ist, soll er nicht als ISO-8859-1
oder UTF-8 deklariert werden, selbst wenn das rein technisch zulässig wäre.

Dass man aber z.B. für deutsche Umlaute generell ISO-8859-1 nutzen soll,
und nicht UTF-8, weil Software möglicherweise ISO-8859-1 beherrscht,
aber UFT-8 nicht, ist dort nicht erkennbar.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#114697 — Re: [OT] Artikel Codierung

Arno Welzel wrote:
> Michael Bäuerle:
> > Arno Welzel wrote:
> > > Juergen Ilse:
> > > > 
> > > > [...]
> > > > Nein, das Problem entsteht dadurch, dass nicht von allen die "kleinste" (im
> > > > Sinne von "wenigsten aufwendige") Codierung verwendet wird, die zum codieren
> > > > des jeweiligen Textes ausreicht (wird das nicht irgendwo auch vorgeschrieben,
> > > > auch wenn sich fast keiner an diese Regel haelt?).
> > > 
> > > Nein, es gibt keine solche Regel, dass man nur bestimmte Codierungen
> > > benutzen soll. Und ob nun ISO-8859-x oder UTF-8 macht bzgl. Aufwand
> > > keinen substantiellen Unterschied.
> > 
> > RFC 2046 sagt dazu:
> > <https://tools.ietf.org/html/rfc2046#section-4.1.2>
> > (Kapitel 4.1.2, letzter Absatz)
> > 
> > | In general, composition software should always use the "lowest common
> > | denominator" character set possible.  For example, if a body contains
> > | only US-ASCII characters, it SHOULD be marked as being in the US-
> > | ASCII character set, not ISO-8859-1, which, like all the ISO-8859
> > | family of character sets, is a superset of US-ASCII.  More generally,
> > | if a widely-used character set is a subset of another character set,
> > | and a body contains only characters in the widely-used subset, it
> > | should be labelled as being in that subset.  This will increase the
> > | chances that the recipient will be able to view the resulting entity
> > | correctly.
> 
> Das sagt eigentlich nicht aus, dass man nur einen möglichst einfachen
> Zeichensatz verwenden soll, sondern dass die angegebene Codierung gemäß
> MIME den kleinst mögliche Variante passend zum Inhalt verwenden soll.
> 
> Wenn also ein Text faktisch US-ASCII ist, soll er nicht als ISO-8859-1
> oder UTF-8 deklariert werden, selbst wenn das rein technisch zulässig wäre.

Thunderbird deklariert da z.B. UTF-8.
 
> Dass man aber z.B. für deutsche Umlaute generell ISO-8859-1 nutzen soll,
> und nicht UTF-8, weil Software möglicherweise ISO-8859-1 beherrscht,
> aber UFT-8 nicht, ist dort nicht erkennbar.

Es ist jedenfalls auch ein "Subset" von Unicode:
Alle Codepoints von ISO-8859-1 wurden 1:1 in Unicode übernommen (d.h.
wenn man das UTF decodiert kommt ISO-8859-1 heraus, sofern keine
Codepoints jenseits U+00FF vorhanden sind¹).

Andersherum bedeutet das, dass ein Newsreader auch direkt ein beliebiges
UTF auf Daten in ISO-8859-1 anwenden kann (die Unterstützung also recht
simpel zu implementieren ist). Wenn er z.B. intern mit UTF-16 arbeitet,
reicht es mit Nullen aufzufüllen.

"Widely-used" ist es zumindest im USENET auch nach wie vor.

Für Mail macht es wohl mittlerweile keinen Sinn mehr, im USENET sind
aber nach wie vor viele Leute mit steinalter Software unterwegs.


____________
¹ Auch die C0/C1-Steuerzeichen wurden 1:1 übernommen

[toc] | [prev] | [next] | [standalone]

#115558 — Re: [OT] Artikel Codierung

Am Sun, 7 Feb 2021 21:09:42 +0100, schrieb Arno Welzel:

> Michael Bäuerle:
> 
> > Arno Welzel wrote:
> >> Juergen Ilse:
> >>>
> >>> [...]
> >>> Nein, das Problem entsteht dadurch, dass nicht von allen die "kleinste" (im
> >>> Sinne von "wenigsten aufwendige") Codierung verwendet wird, die zum codieren
> >>> des jeweiligen Textes ausreicht (wird das nicht irgendwo auch vorgeschrieben,
> >>> auch wenn sich fast keiner an diese Regel haelt?).
> >>
> >> Nein, es gibt keine solche Regel, dass man nur bestimmte Codierungen
> >> benutzen soll. Und ob nun ISO-8859-x oder UTF-8 macht bzgl. Aufwand
> >> keinen substantiellen Unterschied.
> > 
> > RFC 2046 sagt dazu:
> > <https://tools.ietf.org/html/rfc2046#section-4.1.2>
> > (Kapitel 4.1.2, letzter Absatz)
> > 
> > | In general, composition software should always use the "lowest common
> > | denominator" character set possible.  For example, if a body contains
> > | only US-ASCII characters, it SHOULD be marked as being in the US-
> > | ASCII character set, not ISO-8859-1, which, like all the ISO-8859
> > | family of character sets, is a superset of US-ASCII.  More generally,
> > | if a widely-used character set is a subset of another character set,
> > | and a body contains only characters in the widely-used subset, it
> > | should be labelled as being in that subset.  This will increase the
> > | chances that the recipient will be able to view the resulting entity
> > | correctly.
> 
> Das sagt eigentlich nicht aus, dass man nur einen möglichst einfachen
> Zeichensatz verwenden soll, sondern dass die angegebene Codierung gemäß
> MIME den kleinst mögliche Variante passend zum Inhalt verwenden soll.
> 
> Wenn also ein Text faktisch US-ASCII ist, soll er nicht als ISO-8859-1
> oder UTF-8 deklariert werden, selbst wenn das rein technisch zulässig wäre.
> 
> Dass man aber z.B. für deutsche Umlaute generell ISO-8859-1 nutzen soll,
> und nicht UTF-8, weil Software möglicherweise ISO-8859-1 beherrscht,
> aber UFT-8 nicht, ist dort nicht erkennbar.

| > | More generally,
| > | if a widely-used character set is a subset of another character set,
| > | and a body contains only characters in the widely-used subset, it
| > | should be labelled as being in that subset.

Für mich ist das da schon erkennbar, oder ist für Dich ISO-8859 kein
"widely-used subset" von UTF-8?
-- 
...und tschuess!

Michael
E-mail: M.Ottenbruch@sailor.ping.de

[toc] | [prev] | [next] | [standalone]

#115561 — Re: [OT] Artikel Codierung

Michael Ottenbruch <M.Ottenbruch@sailor.ping.de>:
>Am Sun, 7 Feb 2021 21:09:42 +0100, schrieb Arno Welzel:
>> Michael Bäuerle:

>>> RFC 2046 sagt dazu:
>>> <https://tools.ietf.org/html/rfc2046#section-4.1.2>
>>> (Kapitel 4.1.2, letzter Absatz)
>>>
>>> | In general, composition software should always use the "lowest
>>> | common denominator" character set possible. For example, if a
>>> | body contains only US-ASCII characters, it SHOULD be marked as
>>> | being in the US- ASCII character set, not ISO-8859-1, which,
>>> | like all the ISO-8859 family of character sets, is a superset
>>> | of US-ASCII. More generally, if a widely-used character set is
>>> | a subset of another character set, and a body contains only
>>> | characters in the widely-used subset, it should be labelled as
>>> | being in that subset. This will increase the chances that the
>>> | recipient will be able to view the resulting entity correctly.
>>
>> Das sagt eigentlich nicht aus, dass man nur einen möglichst 
>> einfachen Zeichensatz verwenden soll, sondern dass die angegebene 
>> Codierung gemäß MIME den kleinst mögliche Variante passend zum 
>> Inhalt verwenden soll.
>>
>> Wenn also ein Text faktisch US-ASCII ist, soll er nicht als 
>> ISO-8859-1 oder UTF-8 deklariert werden, selbst wenn das rein 
>> technisch zulässig wäre.
>>
>> Dass man aber z.B. für deutsche Umlaute generell ISO-8859-1 
>> nutzen soll, und nicht UTF-8, weil Software möglicherweise 
>> ISO-8859-1 beherrscht, aber UFT-8 nicht, ist dort nicht 
>> erkennbar.

>Für mich ist das da schon erkennbar, oder ist für Dich ISO-8859 
>kein "widely-used subset" von UTF-8?

Das kommt darauf an, was genau «character set» meint.  «Character 
set» könnte eine Menge von Zeichen sein, etwa: alle lateinischen 
Groß‐ und Kleinbuchstaben, die Ziffern Null, Eins, Zwei, Drei, Vier, 
Fünf, Sechs, Sieben, Acht und Neun, die Leerstelle, alle im 
Englischen verwendeten Satzzeichen, die Anführungszeichen, der 
Apostroph, die runden, spitzen, eckigen und geschweiften Klammern… 

Das wäre eine Beschreibung einer Zeichenmenge noch ohne eine Aussage 
über die Kodierung.  Wenn RFC 2046 unter character set so eine 
Beschreibung versteht, könnte man den mit UTF-8 darstellbaren 
Zeichensatz als Obermenge des mit ISO-8859-1 darstellbaren 
Zeichensatzes sehen, und den zitierten Abschnitt könnte man so 
interpretieren, dass ein Nachrichteninhalt, der mit ISO-8859-1 
kodiert werden kann, nicht mit UTF-8 kodiert werden soll. 

=> Beide Kodierungen liefern unterschiedliche Oktettfolgen.  


Auf der anderen Seite könnte man auch die Kodierung mit 
berücksichtigen:  Dann wäre die Kodierung (also die Abbildung der 
Zeichen auf die Oktette) des ASCII dasselbe wie die Einschränkung 
der ISO-8859‐Kodierungen oder der UTF-8‐Kodierung auf die 128 
Zeichen, deren Oktette die Werte 0 bis 127 haben.  Die Kodierung des 
ISO-8859-1‐Zeichensatzes könnte man dann aber nicht als 
Einschränkung der Kodierung des UTF-8‐Zeichensatzes betrachten, da 
die Oktettfolgen sich von einander unterscheiden. 


Nochmal zum zitierten Abschnitt von oben:  Der Satz 


«More generally, if a widely-used character set is a subset of 
another character set, and a body contains only characters in the 
widely-used subset, it should be labelled as being in that subset.» 

legt für mich wegen dem Begriff «labelled», also beschriftet, nahe, 
dass das Prinzip «nimm den Zeichensatz des kleinsten gemeinsamen 
Nenners» nur dann angewendet werden kann, wenn man beispielsweise 
bei einem in UTF-8 kodierten Text den Aufkleber UTF-8 entfernen und 
den Aufkleber ISO-8859-1 drankleben kann.  Das ist aber nur dann der 
Fall, wenn der kodierte Text nur ASCII‐Zeichen enthält – und dann 
kann man ihn auch mit dem Aufkleber ASCII statt ISO-8859-1 
versehen.  Wenn der Text aber beispielsweise Umlaute enthält, 
entsteht durch das bloße Auswechseln des Aufklebers ohne Umkodierung 
der Umlaute von UTF-8 nach ISO-8859-1 Unsinn. 

In dieselbe Richtung weisen zwei Absätze aus Abschnitt 2.2 in RFC 
2045 (<https://tools.ietf.org/html/rfc2045#section-2.2>):

«The term "character set" is used in MIME to refer to a method of 
converting a sequence of octets into a sequence of characters.» 

und

«NOTE: The term "character set" was originally to describe such 
straightforward schemes as US-ASCII and ISO-8859-1 which have a 
simple one-to-one mapping from single octets to single characters. 
Multi-octet coded character sets and switching techniques make the 
situation more complex. For example, some communities use the term 
"character encoding" for what MIME calls a "character set", while 
using the phrase "coded character set" to denote an abstract mapping 
from integers (not octets) to characters.» 

=> «character set» meint die Abbildung von Oktettfolgen auf 
Zeichen. 

Ich verstehe das so:  Wenn ein Nachrichteninhalt aus nur 
ASCII‐Zeichen besteht, dann soll die Nachricht nicht als in 
ISO-8859-1 oder als in UTF-8 sondern als in ASCII kodiert 
ausgezeichnet werden, obwohl die Auszeichnung als ISO-8859-1 oder 
UTF-8 korrekt wäre:  Jedes ASCII‐Zeichen hat sowohl im ASCII‐, im 
ISO-8859-1‐ als auch in UTF-8‐Zeichensatz dieselbe Kodierung, also 
dasselbe Oktett.  Die Abbildungen (character sets) UTF-8 und 
ISO-8859-1, eingeschränkt auf die Definitions‐ und Wertemenge der 
Abbildung ASCII, ergeben die Abbildung ASCII.  Im Gegensatz dazu 
ergibt die Abbildung UTF-8, eingeschränkt auf die Definitions‐ und 
Wertemenge der Abbildung ISO-8859-1, nicht die Abbildung 
ISO-8859-1.  Anders ausgedrückt:  Die Kommandos

   iconv -f ASCII -t ISO-8859-1

und

   iconv -f ASCII -t UTF-8


haben dieselbe Wirkung wie das Kommando 


   cat


Sie stellen mathematisch betrachtet die identische Abbildung dar.  


Anders sieht es mit Zeichen aus, die sowohl im ISO-8859-1‐ (und 
damit auch im UTF-8‐) aber nicht im ASCII‐Zeichensatz enthalten 
sind.  Das Kommando

   iconv -f ISO-8859-1 -t UTF-8


ist etwas anderes als das Kommando 


   cat

[toc] | [prev] | [next] | [standalone]

#115564 — Re: [OT] Artikel Codierung

Helmut Waitzmann wrote:
> Michael Ottenbruch <M.Ottenbruch@sailor.ping.de>:
> > Am Sun, 7 Feb 2021 21:09:42 +0100, schrieb Arno Welzel:
> > > Michael Bäuerle:
> > > > 
> > > > RFC 2046 sagt dazu:
> > > > <https://tools.ietf.org/html/rfc2046#section-4.1.2>
> > > > (Kapitel 4.1.2, letzter Absatz)
> > > > 
> > > > | In general, composition software should always use the "lowest
> > > > | common denominator" character set possible. For example, if a
> > > > | body contains only US-ASCII characters, it SHOULD be marked as
> > > > | being in the US- ASCII character set, not ISO-8859-1, which,
> > > > | like all the ISO-8859 family of character sets, is a superset
> > > > | of US-ASCII. More generally, if a widely-used character set is
> > > > | a subset of another character set, and a body contains only
> > > > | characters in the widely-used subset, it should be labelled as
> > > > | being in that subset. This will increase the chances that the
> > > > | recipient will be able to view the resulting entity correctly.
> > > 
> > > Das sagt eigentlich nicht aus, dass man nur einen möglichst einfachen 
> > > Zeichensatz verwenden soll, sondern dass die angegebene Codierung gemäß 
> > > MIME den kleinst mögliche Variante passend zum Inhalt verwenden soll.
> > > 
> > > Wenn also ein Text faktisch US-ASCII ist, soll er nicht als ISO-8859-1 
> > > oder UTF-8 deklariert werden, selbst wenn das rein technisch zulässig 
> > > wäre.
> > > 
> > > Dass man aber z.B. für deutsche Umlaute generell ISO-8859-1 nutzen 
> > > soll, und nicht UTF-8, weil Software möglicherweise ISO-8859-1 
> > > beherrscht, aber UFT-8 nicht, ist dort nicht erkennbar.
> > 
> > Für mich ist das da schon erkennbar, oder ist für Dich ISO-8859 kein 
> > "widely-used subset" von UTF-8?
> 
> Das kommt darauf an, was genau «character set» meint.  «Character set» 
> könnte eine Menge von Zeichen sein, etwa: alle lateinischen Groß‐ und 
> Kleinbuchstaben, die Ziffern Null, Eins, Zwei, Drei, Vier, Fünf, Sechs, 
> Sieben, Acht und Neun, die Leerstelle, alle im Englischen verwendeten 
> Satzzeichen, die Anführungszeichen, der Apostroph, die runden, spitzen, 
> eckigen und geschweiften Klammern… 
> 
> Das wäre eine Beschreibung einer Zeichenmenge noch ohne eine Aussage 
> über die Kodierung.  Wenn RFC 2046 unter character set so eine 
> Beschreibung versteht, könnte man den mit UTF-8 darstellbaren 
> Zeichensatz als Obermenge des mit ISO-8859-1 darstellbaren 
> Zeichensatzes sehen,

Dazu kommt, dass auch die Nummern der Codepoints von ISO-8859-1 und
des entsprechenden Subsets von Unicode identisch sind (genau wie bei
US-ASCII).

> und den zitierten Abschnitt könnte man so 
> interpretieren, dass ein Nachrichteninhalt, der mit ISO-8859-1 kodiert 
> werden kann, nicht mit UTF-8 kodiert werden soll. 
> 
> => Beide Kodierungen liefern unterschiedliche Oktettfolgen.  

Aber nur durch das Unicode Transformation Format (UTF), das für den
Codepoint-Bereich bis U+00FF technisch eigentlich unnötig ist, entsteht
in diesem Fall eine andere Oktettfolge.

Würde man die Unicode-Codepoints aus dem Subset bis U+00FF direkt als
Oktette einsetzen, dann wäre das MIME-Label "ISO-8859-1" dafür gültig.

Die Anwendung eines UTF macht die Sache hier also komplizierter als sie
sein müsste.


Deinen Ausführungen zu UTF-8 stimme ich ansonsten zu. Die Frage ist ob
für den Unicode-Bereich bis U+00FF überhaupt ein UTF sinnvoll ist.

[toc] | [prev] | [next] | [standalone]

#115566 — Re: [OT] Artikel Codierung

Michael Bäuerle <michael.baeuerle@stz-e.de> writes:
> Aber nur durch das Unicode Transformation Format (UTF), das für den
> Codepoint-Bereich bis U+00FF technisch eigentlich unnötig ist, entsteht
> in diesem Fall eine andere Oktettfolge.
>
> Würde man die Unicode-Codepoints aus dem Subset bis U+00FF direkt als
> Oktette einsetzen, dann wäre das MIME-Label "ISO-8859-1" dafür gültig.

Dann hättest Du aber keine Möglichkeit mehr, irgendein anderes Zeichen
ab U+0100 zu kodieren.  ISO-8859-n ist wenn man die Sonderzeichen
dazunimmt für alle Werte definiert.

Theoretisch könnte man für U+0080 bis U+00C1 den Wert direkt nehmen,
dann wäre der UTF-8 Zeichenstrom aber weniger robust, weil man nicht
mehr erkennen könnte, daß man gerade ein Folgebyte vor sich hat.

Viele Grüße, Thomas
PS: Außerdem: Warum immer ISO-8859-1 und nicht z.B. ISO-8859-15 oder
noch einen anderen.  Meistens passen mehrere.  (Von EBCDIC 273 will ich
gar nicht erst anfangen. ;-)
-- 
Adresse gilt nur kurzzeitig!

[toc] | [prev] | [next] | [standalone]

#115567 — Re: [OT] Artikel Codierung

Thomas Dorner wrote:
> Michael Bäuerle <michael.baeuerle@stz-e.de> writes:
> > 
> > Aber nur durch das Unicode Transformation Format (UTF), das für den
> > Codepoint-Bereich bis U+00FF technisch eigentlich unnötig ist, entsteht
> > in diesem Fall eine andere Oktettfolge.
> > 
> > Würde man die Unicode-Codepoints aus dem Subset bis U+00FF direkt als
> > Oktette einsetzen, dann wäre das MIME-Label "ISO-8859-1" dafür gültig.
> 
> Dann hättest Du aber keine Möglichkeit mehr, irgendein anderes Zeichen
> ab U+0100 zu kodieren.

Ja natürlich. Dafür Unicode mit UTF-8 zu nehmen ist heute Standard.

> ISO-8859-n ist wenn man die Sonderzeichen
                              ^^^^^^^^^^^^^
Steuerzeichen

> dazunimmt für alle Werte definiert.

Jein. Bei z.B. ISO-8859-6 sind einige Codepoints nicht belegt. Es gibt
dort außerdem "combining characters", d.h. potentielle Probleme mit
Sachen, die nicht zur Kombination vorgesehen sind.

> Theoretisch könnte man für U+0080 bis U+00C1 den Wert direkt nehmen,
> dann wäre der UTF-8 Zeichenstrom aber weniger robust, weil man nicht
> mehr erkennen könnte, daß man gerade ein Folgebyte vor sich hat.

Für modifiziertes UTF-8 gibt es aber kein MIME-Label das "widely-used"
wäre. Bei den Unicode-Codepoints des Bereichs bis U+00FF und dem MIME-
Label "ISO-8859-1" ist das anders.
 
> PS: Außerdem: Warum immer ISO-8859-1 und nicht z.B. ISO-8859-15 oder
> noch einen anderen.  Meistens passen mehrere. [...]

Weil von allen ISO-8859-n nur ISO-8859-1 ein 1:1 Mapping der Codepoints
auf Unicode hat.

[toc] | [prev] | [next] | [standalone]

#115562 — Re: [OT] Artikel Codierung

Michael Ottenbruch:

> Am Sun, 7 Feb 2021 21:09:42 +0100, schrieb Arno Welzel:
> 
>> Michael Bäuerle:
>>
>>> Arno Welzel wrote:
>>>> Juergen Ilse:
>>>>>
>>>>> [...]
>>>>> Nein, das Problem entsteht dadurch, dass nicht von allen die "kleinste" (im
>>>>> Sinne von "wenigsten aufwendige") Codierung verwendet wird, die zum codieren
>>>>> des jeweiligen Textes ausreicht (wird das nicht irgendwo auch vorgeschrieben,
>>>>> auch wenn sich fast keiner an diese Regel haelt?).
>>>>
>>>> Nein, es gibt keine solche Regel, dass man nur bestimmte Codierungen
>>>> benutzen soll. Und ob nun ISO-8859-x oder UTF-8 macht bzgl. Aufwand
>>>> keinen substantiellen Unterschied.
>>>
>>> RFC 2046 sagt dazu:
>>> <https://tools.ietf.org/html/rfc2046#section-4.1.2>
>>> (Kapitel 4.1.2, letzter Absatz)
[...]
> | > | More generally,
> | > | if a widely-used character set is a subset of another character set,
> | > | and a body contains only characters in the widely-used subset, it
> | > | should be labelled as being in that subset.
> 
> Für mich ist das da schon erkennbar, oder ist für Dich ISO-8859 kein
> "widely-used subset" von UTF-8?

Hier gibt es wohl ein Mißverständnis.

Ich wollte mit meinem Einwand klarstellen, dass es nicht darum geht,
dass man UTF-8 generell nicht benutzen soll, sondern dass man die
Codierung angeben soll, die zum Inhalt passt. Und wenn ISO-8859-1
ausreicht, soll das auch angegeben werden und nicht UTF-8, nur weil
UTF-8 zufällig auch passt.

Daraus leitet sich aber nicht ab, dass im Umkehrschluss möglichst auf
UTF-8 verzichten soll und keine Zeichen benutzen soll, die nur mit UTF-8
darstellbar sind.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#115571 — Re: [OT] Artikel Codierung

Am Wed, 10 Mar 2021 13:36:12 +0100, schrieb Arno Welzel:

> Michael Ottenbruch:
> 
> > Am Sun, 7 Feb 2021 21:09:42 +0100, schrieb Arno Welzel:
> > 
> >> Michael Bäuerle:
> >>
> >>> Arno Welzel wrote:
> >>>> Juergen Ilse:
> >>>>>
> >>>>> [...]
> >>>>> Nein, das Problem entsteht dadurch, dass nicht von allen die "kleinste" (im
> >>>>> Sinne von "wenigsten aufwendige") Codierung verwendet wird, die zum codieren
> >>>>> des jeweiligen Textes ausreicht (wird das nicht irgendwo auch vorgeschrieben,
> >>>>> auch wenn sich fast keiner an diese Regel haelt?).
> >>>>
> >>>> Nein, es gibt keine solche Regel, dass man nur bestimmte Codierungen
> >>>> benutzen soll. Und ob nun ISO-8859-x oder UTF-8 macht bzgl. Aufwand
> >>>> keinen substantiellen Unterschied.
> >>>
> >>> RFC 2046 sagt dazu:
> >>> <https://tools.ietf.org/html/rfc2046#section-4.1.2>
> >>> (Kapitel 4.1.2, letzter Absatz)
> [...]
> > | > | More generally,
> > | > | if a widely-used character set is a subset of another character set,
> > | > | and a body contains only characters in the widely-used subset, it
> > | > | should be labelled as being in that subset.
> > 
> > Für mich ist das da schon erkennbar, oder ist für Dich ISO-8859 kein
> > "widely-used subset" von UTF-8?
> 
> Hier gibt es wohl ein Mißverständnis.

Yup.
 
> Ich wollte mit meinem Einwand klarstellen, dass es nicht darum geht,
> dass man UTF-8 generell nicht benutzen soll, sondern dass man die
> Codierung angeben soll, die zum Inhalt passt. Und wenn ISO-8859-1
> ausreicht, soll das auch angegeben werden und nicht UTF-8, nur weil
> UTF-8 zufällig auch passt.

So hatte ich Dich in der Tat nicht verstanden; aber dann sind wir uns
völlig einig.
 
> Daraus leitet sich aber nicht ab, dass im Umkehrschluss möglichst auf
> UTF-8 verzichten soll und keine Zeichen benutzen soll, die nur mit UTF-8
> darstellbar sind.

Wenn man seit 25 Jahren den Forté Agent nutzt, sieht man das naturgemäß
etwas anders. Man könnte sich allerdings auch mal an einen etwas
moderneren Newsreader gewöhnen. ;-\
-- 
...und tschuess!

Michael
E-mail: M.Ottenbruch@sailor.ping.de

[toc] | [prev] | [next] | [standalone]

#114687

* Juergen Ilse:

> Nein, das Problem entsteht dadurch, dass nicht von allen die "kleinste" (im
> Sinne von "wenigsten aufwendige") Codierung verwendet wird, die zum codieren
> des jeweiligen Textes ausreicht (wird das nicht irgendwo auch vorgeschrieben,
> auch wenn sich fast keiner an diese Regel haelt?).

Es gab einige Hierarchien mit Regeln dazu, glaube ich.
gnus-group-posting-charset-alist hat ein paar Einstellungen dazu.
Früher nutzte das tatsächlich ISO-8859-1 für de.*.

[toc] | [prev] | [next] | [standalone]

#114688

On Sun, 07 Feb 2021 21:19:17 +0100, Florian Weimer wrote:
>
> * Juergen Ilse:
>
>> Nein, das Problem entsteht dadurch, dass nicht von allen die "kleinste" (im
>> Sinne von "wenigsten aufwendige") Codierung verwendet wird, die zum codieren
>> des jeweiligen Textes ausreicht (wird das nicht irgendwo auch vorgeschrieben,
>> auch wenn sich fast keiner an diese Regel haelt?).
>
> Es gab einige Hierarchien mit Regeln dazu, glaube ich.
> gnus-group-posting-charset-alist hat ein paar Einstellungen dazu.
> Früher nutzte das tatsächlich ISO-8859-1 für de.*.

Aber dann kam der €uro. ;-)
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#114695

Andreas Kohlbach schrieb am 07.02.2021 um 21:22:

> On Sun, 07 Feb 2021 21:19:17 +0100, Florian Weimer wrote:
>
>> * Juergen Ilse:
>>
>>> Nein, das Problem entsteht dadurch, dass nicht von allen die "kleinste" (im
>>> Sinne von "wenigsten aufwendige") Codierung verwendet wird, die zum codieren
>>> des jeweiligen Textes ausreicht (wird das nicht irgendwo auch vorgeschrieben,
>>> auch wenn sich fast keiner an diese Regel haelt?).
>>
>> Es gab einige Hierarchien mit Regeln dazu, glaube ich.
>> gnus-group-posting-charset-alist hat ein paar Einstellungen dazu.
>> Früher nutzte das tatsächlich ISO-8859-1 für de.*.
>
> Aber dann kam der €uro. ;-)

Und mit ihm ISO-8859-15 ;-)

Gruß
Claus

[toc] | [prev] | [next] | [standalone]

#115559

Am 06.02.21 um 01:28 schrieb Hans CraueI:

> Das Problem entsteht doch dadurch, dass teils Umlaute immer
> noch mit ISO-8859-X kodiert werden, obwohl Standard mittlerweile
> eigentlich UTF-8 ist.
Njein.

knode hat das Verschicken von email Anhängen vom Typ *.txt verweigert,
weil da utf8-Zeichen drin waren.

raspbian hat hat bei mit cgi mit utf8 Zeichen verweigert.
Bei SuSE ging das noch mit ungewohnter Umgehung.

Kann man universelle utf-8 Zeichen mit
deinem Arduino ( z.B. Leonardo ) Tastatur emulator verschicken?

Tastatur Treiber bekommen Tastennummern und setzten sie
  sie irgendwie um Sondererzeichen wie € übe eine AltGr Tabelle.

Unterschiedliche Programme wie emacs haben eventuell unterschiedliche
Möglichkeiten von  utf Eingabe.

Und Banken versenden in ihren Daten eventuell immer noch ISO.
( Mag an COBOL oder EBCDIC liegen. )

Hermann
    der manchmal den Eindruck hat, dass immer noch 7 bit ASCII
    Standard ist.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#114648

Hallo,

Hans CraueI <crauel_usenet@freenet.de> wrote:
> Dafür pardon. War Antwort auf einen Beitrag in ISO-8859, 
> ein Format aus längst vergangenen Zeiten. Sowas muss man 
> dann händisch auf UTF8 wandeln, was ich versehentlich 
> versäumt hatte. 

ISO-8859-1 ist eine sehr gaengige und auch heute noch gebraeuchliche 
Codierung, die u.a. auch deutsche Sonderzeichen enthaelt. ISO-8859-15
enthaelt daneben auch noch das EURO Zeichen. gegenueber UTF-8 hat sie
den Vorteil, dass jedes Zeichen in nur einem Oktett codiert ist.

Tschuess,
	Juergen Ilse			(juergen@usenet-verwaltung.de)

[toc] | [prev] | [next] | [standalone]

#114651

Juergen Ilse <news@usenet-verwaltung.de> wrote:

> ISO-8859-1 ist eine sehr gaengige und auch heute noch gebraeuchliche 
> Codierung

Die zB viele Consumergeraete verwenden, zB mein Autoradio.
Deshalb verwende ich durchgaengig ISO-8859-1 auf allen Systemen.
Alle Sprachen, die ich auch nur rudimentaer beherrsche kommen mit
ISO-8859-1 aus. Ich brauch kein UTF-8.

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#114654

On Sat, 6 Feb 2021 20:36:13 +0000 (UTC), Ulli Horlacher wrote:
>
> Juergen Ilse <news@usenet-verwaltung.de> wrote:
>
>> ISO-8859-1 ist eine sehr gaengige und auch heute noch gebraeuchliche 
>> Codierung
>
> Die zB viele Consumergeraete verwenden, zB mein Autoradio.
> Deshalb verwende ich durchgaengig ISO-8859-1 auf allen Systemen.
> Alle Sprachen, die ich auch nur rudimentaer beherrsche kommen mit
> ISO-8859-1 aus. Ich brauch kein UTF-8.

Schoener Artikel. Es kommen (bewusst?) keine Umlaute oder anderes vor,
dass der Content-Type richtigerweise nicht mal deklariert ist.

Bin nun gespannt, wie meiner das haendelt.
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#114655

[Sekunde später]

Meiner hat es auch nicht deklariert, wie zu erwarten. (In diesem wegen
dem "ä" aber schon).
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#114672

Hallo,

Andreas Kohlbach <ank@spamfence.net> wrote:
> On Sat, 6 Feb 2021 20:36:13 +0000 (UTC), Ulli Horlacher wrote:
>> Juergen Ilse <news@usenet-verwaltung.de> wrote:
>>> ISO-8859-1 ist eine sehr gaengige und auch heute noch gebraeuchliche 
>>> Codierung
>> Die zB viele Consumergeraete verwenden, zB mein Autoradio.
>> Deshalb verwende ich durchgaengig ISO-8859-1 auf allen Systemen.
>> Alle Sprachen, die ich auch nur rudimentaer beherrsche kommen mit
>> ISO-8859-1 aus. Ich brauch kein UTF-8.
> Schoener Artikel. Es kommen (bewusst?) keine Umlaute oder anderes vor,
> dass der Content-Type richtigerweise nicht mal deklariert ist.
> Bin nun gespannt, wie meiner das haendelt.

Wenn dein Newsreader korrekt arbeitet, geht er bei nicht deklarierter 
Zeichencodierung von us-ascii aus. Das ist das (sinnvollerweise) ver-
einbarte "Kompatibilitaetszugestaendnis" an Nachrichten, die *vor* dem
MIME Standard geschrieben wurde. Man wollte ja nicht alle alten Texte
"ungueltig" machen ...
Auch wenn einige Leute meinen, der Default bei undeklarierter Zeichen-
codierung haette sich geaendert: Das ist *nicht* der Fall: undeklariert
bedeutet us-ascii, aus oben genannten Gruenden (Kompatibilitaet zur Zeit
vor MIME).

Tschuess,
	Juergegn Ilse			(juergegn@usenet-verwaltung.de)

[toc] | [prev] | [next] | [standalone]

#114681

On 07 Feb 2021 13:14:22 GMT, Juergen Ilse wrote:
>
> Andreas Kohlbach <ank@spamfence.net> wrote:
>
>> Schoener Artikel. Es kommen (bewusst?) keine Umlaute oder anderes vor,
>> dass der Content-Type richtigerweise nicht mal deklariert ist.
>> Bin nun gespannt, wie meiner das haendelt.
>
> Wenn dein Newsreader korrekt arbeitet, geht er bei nicht deklarierter 
> Zeichencodierung von us-ascii aus.

Right. Aber hier ging es um das Senden. Wie in meinem Folgeartikel
erwähnt, verhielt er sich wie erwartet: er hat, da keine Umlaute
vorkamen, nichts deklariert.
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#114656

Ulli Horlacher schrieb am 6/2/2021 21:36:

> Juergen Ilse <news@usenet-verwaltung.de> wrote:
>
>> ISO-8859-1 ist eine sehr gaengige und auch heute noch gebraeuchliche 
>> Codierung
>
> Die zB viele Consumergeraete verwenden, zB mein Autoradio.
> Deshalb verwende ich durchgaengig ISO-8859-1 auf allen Systemen.
> Alle Sprachen, die ich auch nur rudimentaer beherrsche kommen mit
> ISO-8859-1 aus. Ich brauch kein UTF-8.

Du verweigerst lustige, bunte Smileys? :o)

-- 
Gerald

[toc] | [prev] | [next] | [standalone]

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web