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

Groups > de.comp.os.unix.shell > #14640 > unrolled thread

System und Shell-Scripte: Latin-1 zu UTF-8

Back to article view | Back to de.comp.os.unix.shell

Contents

  System und Shell-Scripte: Latin-1 zu UTF-8 Martin Klaiber <usenet.martinkl@gmx.de> - 2026-03-07 13:07 +0100
    Re: System und Shell-Scripte: Latin-1 zu UTF-8 Tim Ritberg <tim@server.invalid> - 2026-03-07 13:17 +0100
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Martin Klaiber <usenet.martinkl@gmx.de> - 2026-03-07 16:34 +0100
    Re: System und Shell-Scripte: Latin-1 zu UTF-8 Ralph Aichinger <ra@h5.or.at> - 2026-03-07 12:35 +0000
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Martin Klaiber <usenet.martinkl@gmx.de> - 2026-03-07 16:33 +0100
    Re: System und Shell-Scripte: Latin-1 zu UTF-8 Thomas Hochstein <thh@thh.name> - 2026-03-07 14:04 +0100
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Urs Janßen <urs@niko.tin.org> - 2026-03-07 15:36 +0000
        Re: System und Shell-Scripte: Latin-1 zu UTF-8 ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-07 16:38 +0000
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-07 16:48 +0000
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Urs Janßen <urs@niko.tin.org> - 2026-03-07 16:51 +0000
        Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2026-03-07 20:02 +0000
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Urs Janßen <urs@niko.tin.org> - 2026-03-07 20:45 +0000
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Urs Janßen <urs@niko.tin.org> - 2026-03-07 20:50 +0000
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Helmut Waitzmann <nn.throttle@erine.email> - 2026-03-08 01:25 +0100
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Martin Klaiber <usenet.martinkl@gmx.de> - 2026-03-07 16:29 +0100
    Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-07 23:12 +0100
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Martin Klaiber <usenet.martinkl@gmx.de> - 2026-03-08 00:42 +0100
        Re: System und Shell-Scripte: Latin-1 zu UTF-8 Helmut Waitzmann <nn.throttle@erine.email> - 2026-03-08 03:40 +0100
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 06:14 +0100
            Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 10:47 +0100
            Re: System und Shell-Scripte: Latin-1 zu UTF-8 Helmut Waitzmann <nn.throttle@erine.email> - 2026-03-08 19:05 +0100
              Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 20:40 +0100
                Re: System und Shell-Scripte: Latin-1 zu UTF-8 Helmut Waitzmann <nn.throttle@erine.email> - 2026-03-08 22:29 +0100
                  Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 23:27 +0100
        Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 09:36 +0100
    Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 07:17 +0100
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 09:56 +0100
        Re: System und Shell-Scripte: Latin-1 zu UTF-8 Ralph Aichinger <ra@h5.or.at> - 2026-03-08 09:11 +0000
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 10:19 +0100
            Re: System und Shell-Scripte: Latin-1 zu UTF-8 Ralph Aichinger <ra@h5.or.at> - 2026-03-08 10:25 +0000
              Re: System und Shell-Scripte: Latin-1 zu UTF-8 Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2026-03-08 10:41 +0000
              Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 11:52 +0100
    Re: System und Shell-Scripte: Latin-1 zu UTF-8 Hergen Lehmann <hlehmann-usenet26@snafu.de> - 2026-03-08 10:03 +0100
      Re: System und Shell-Scripte: Latin-1 zu UTF-8 Michael Bäuerle <michael.baeuerle@gmx.net> - 2026-03-08 10:56 +0100
        Re: System und Shell-Scripte: Latin-1 zu UTF-8 Stefan Wiens <s.wi@gmx.net> - 2026-03-08 11:19 +0100
          Re: System und Shell-Scripte: Latin-1 zu UTF-8 Michael Bäuerle <michael.baeuerle@gmx.net> - 2026-03-08 14:09 +0100

Page 2 of 2 — ← Prev page 1 [2]

#14672

 Stefan Wiens <s.wi@gmx.net>:
> Helmut Waitzmann <nn.throttle@erine.email> writes:
>
>> Alternativ könnte man auch die Ausgabe von „bc“ durch „tr“ 
>> schieben, um jegliche Punkte durch Kommata zu ersetzen: 
>>
>>
>> printf '%s\n' '4/3' | [...]
>
> tr(1) ist ein gutes Beispiel, wo es hakeln könnte.
> Hier (GNU coreutils) 9.1:
>
> ,----[ (coreutils) Character arrays ]
> |    The interpretation of STRING1 and STRING2 depends on locale.  GNU
> | ‘tr’ fully supports only safe single-byte locales, where each possible
> | input byte represents a single character.  Unfortunately, this means GNU
> | ‘tr’ will not handle commands like ‘tr $'\u7530' $'\u68EE'’ the way you
> | might expect, since (assuming a UTF-8 encoding) this is equivalent to
> | ‘tr '\347\224\260' '\346\243\256'’ and GNU ‘tr’ will simply
> | transliterate all ‘\347’ bytes to ‘\346’ bytes, etc.  POSIX does not
> | clearly specify the behavior of ‘tr’ in locales where characters are
> | represented by byte sequences instead of by individual bytes, or where
> | data might contain invalid bytes that are encoding errors.  To avoid
> | problems in this area, you can run ‘tr’ in a safe single-byte locale by
> | using a shell command like ‘LC_ALL=C tr’ instead of plain ‘tr’.
> `----
>

 Ja, richtig.  LC_ALL=C kann auch in meinem Fall, in dem sowohl 
 das Komma als auch der Punkt Teil des ASCII sind, nicht schaden. 


> $ echo klöä | LC_ALL=de_DE.UTF8 tr [:lower:] [:upper:]

 Und es empfiehlt sich, ins Shell‐Quoting zu investieren.  Ein 
 Beispiel, wo man ohne Shell‐Quoting scheitert: 


   touch -- e &&
   printf '%s\n' klein | LC_ALL=C tr [:lower:] [:upper:]

 zeigt, warum 


   LC_ALL=C tr '[:lower:]' '[:upper:]'

 nötig ist. 

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

#14673

[Quoting repariert]

Helmut Waitzmann <nn.throttle@erine.email> writes:

> Stefan Wiens <s.wi@gmx.net>:
>> Helmut Waitzmann <nn.throttle@erine.email> writes:
>>
>>> Alternativ könnte man auch die Ausgabe von „bc“ durch „tr“
>>> schieben, um jegliche Punkte durch Kommata zu ersetzen: printf
>>> '%s\n' '4/3' | [...]
>>
>> tr(1) ist ein gutes Beispiel, wo es hakeln könnte.
>> Hier (GNU coreutils) 9.1:
[...]
>
> Ja, richtig.  LC_ALL=C kann auch in meinem Fall, in dem sowohl  das
> Komma als auch der Punkt Teil des ASCII sind, nicht schaden.

>> $ echo
>> klöä | LC_ALL=de_DE.UTF8 tr [:lower:] [:upper:]
>
> Und es empfiehlt sich, ins Shell‐Quoting zu investieren.  Ein
> Beispiel, wo man ohne Shell‐Quoting scheitert:    touch -- e &&
>   printf '%s\n' klein | LC_ALL=C tr [:lower:] [:upper:]
>
> zeigt, warum    LC_ALL=C tr '[:lower:]' '[:upper:]'
> nötig ist.

Könntest du erklären, was bei deinem Beispiel passiert?
(Mein Beispiel betrifft es nicht direkt.)

-- 
Stefan

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

#14674

 Stefan Wiens <s.wi@gmx.net>:
> Helmut Waitzmann <nn.throttle@erine.email> writes:
>> Stefan Wiens <s.wi@gmx.net>:
>>> $ echo
>>> klöä | LC_ALL=de_DE.UTF8 tr [:lower:] [:upper:]
>>
>> Und es empfiehlt sich, ins Shell‐Quoting zu investieren.  Ein 
>> Beispiel, wo man ohne Shell‐Quoting scheitert: 
>>
>>
>>   touch -- e &&
>>   printf '%s\n' klein | LC_ALL=C tr [:lower:] [:upper:]
>>
>> zeigt, warum 
>>
>>
>>   LC_ALL=C tr '[:lower:]' '[:upper:]'
>>
>> nötig ist. 
>>
>
> Könntest du erklären, was bei deinem Beispiel passiert? 
>

 Wenn man „set -x“ einschaltet, sieht man es direkt: 


   touch -- e
   printf '%s\n' klein |
   ( set -x && LC_ALL=C tr [:lower:] [:upper:] )


 Erklärung: 


 „[:lower:]“ ist für das Shell gleichzeitig ein filename globbing 
 pattern, das auf einen Dateinamen passt, der aus einem einzigen 
 Zeichen aus der Menge der Zeichen „:“, „l“, „o“, „w“, „e“ und „r“ 
 besteht. 


 Da es wegen „touch -- e“ einen Dateinamen gibt, der auf dieses 
 Dateinamensmuster passt, ersetzt das Shell „[:lower:]“ durch „e“ 
 (und weitere Dateinamen, falls es im Arbeitsverzeichnis noch 
 weitere passende geben sollte). 


 Nur im Fall, dass kein passender Dateiname vorhanden oder die 
 Shell‐Option „set -f“ eingeschaltet ist, übergibt das Shell (beim 
 Bash: abhängig von den Shell‐Optionen „nullglob“ und „failglob“) 
 den Parameter „[:lower:]“ so, wie er dasteht, an „tr“. 

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

#14675

Helmut Waitzmann <nn.throttle@erine.email> writes:

> Stefan Wiens <s.wi@gmx.net>:
>> Helmut Waitzmann <nn.throttle@erine.email> writes:
>>> Stefan Wiens <s.wi@gmx.net>:
>>>> $ echo
>>>> klöä | LC_ALL=de_DE.UTF8 tr [:lower:] [:upper:]
>>>
>>> Und es empfiehlt sich, ins Shell‐Quoting zu investieren.  Ein
>>> Beispiel, wo man ohne Shell‐Quoting scheitert:   touch -- e &&
>>>   printf '%s\n' klein | LC_ALL=C tr [:lower:] [:upper:]
>>>
>>> zeigt, warum   LC_ALL=C tr '[:lower:]' '[:upper:]'
>>>
>>> nötig ist. 
>>
>> Könntest du erklären, was bei deinem Beispiel passiert? 
>
> Wenn man „set -x“ einschaltet, sieht man es direkt:    touch -- e
>   printf '%s\n' klein |
>   ( set -x && LC_ALL=C tr [:lower:] [:upper:] )
>
>
> Erklärung:  „[:lower:]“ ist für das Shell gleichzeitig ein filename
> globbing  pattern, das auf einen Dateinamen passt, der aus einem
> einzigen  Zeichen aus der Menge der Zeichen „:“, „l“, „o“, „w“, „e“
> und „r“  besteht.  Da es wegen „touch -- e“ einen Dateinamen gibt, der
> auf dieses  Dateinamensmuster passt, ersetzt das Shell „[:lower:]“
> durch „e“  (und weitere Dateinamen, falls es im Arbeitsverzeichnis
> noch  weitere passende geben sollte).  Nur im Fall, dass kein
> passender Dateiname vorhanden oder die  Shell‐Option „set -f“
> eingeschaltet ist, übergibt das Shell (beim  Bash: abhängig von den
> Shell‐Optionen „nullglob“ und „failglob“)  den Parameter „[:lower:]“
> so, wie er dasteht, an „tr“. 

Danke.

-- 
Stefan

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

#14660

Martin Klaiber <usenet.martinkl@gmx.de> writes:

> Stefan Wiens <s.wi@gmx.net> wrote:
>
>> Abgesehen vom Konvertieren der Skripte
>> mittels iconv sollte man auch darauf
>> achten, dass sämtliche dort verwendeten
>> Tools UTF-8-kompatibel sind und auf die
>> locale, insbesondere LC_CTYPE adäquat
>> reagieren.
>
> Ja, danke, guter Tipp!
>
> Denkst Du an ein bestimmtes Szenario?
>
> Ich habe jetzt schon das "Problem", dass printf das Komma als
> Dezimaltrennzeichen bei einer deutschen locale kennt, aber bc nicht,
> sondern nur den Punkt.
>
> Ich meine so etwas wie:
>
>| martinkl@maurice:~$ printf "%f\n" $(echo "4/3" | bc -l)
>| -bash: printf: 1.33333333333333333333: invalid number
>| 1,000000
>
> Ich muss immer LC_NUMERIC=C setzen, damit printf den Dezimalpunkt
> akzeptiert:

Bei bc(1) ist der Punkt als Dezimaltrenner
tatsächlich festgelegt.

LC_CTYPE könnte den Umbruch bei überlanger
Ausgabe beeinflussen, darüber hinaus, was
als LETTER als Variablen- oder Funktionsname 
akzeptiert wird.

Aber bei GNU bc 1.07.1:

,----[ bc(1) ]
|    DIFFERENCES
|        [...]
|        LANG environment
|               This  version does not conform to the POSIX standard in the pro‐
|               cessing of the LANG environment  variable  and  all  environment
|               variables starting with LC_.
`----
-- 
Stefan

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

#14659

Martin Klaiber <usenet.martinkl@gmx.de> writes:

[...]>
> Diese Scripte haben alle einen 8-bit-Zeichensatz (Latin-1, ISO-8859-1).
> Die gesamte Bildschirmausgabe, Formatierung, usw. ist darauf ausgelegt.
> Wenn ich einen neuen Rechner in meinen "Zoo" aufgenommen habe, hatte
> ich seinen Zeichensatz ebenfalls auf Latin-1 eingestellt.
>
> Nun wird aber UTF-8 in den letzten Jahren immer mehr zum default. Ich
> merke es daran, dass es immer häufiger Hakeleien gibt. Und anstatt
> ständig gegen die Veränderung anzukämpfen, die sich ohnehin nicht
> mehr aufhalten lässt, überlege ich, alle meine selbstgeschriebenen
> Script-Programme auf UTF-8 umzustellen. Es geht um rund 1200 Scripte.

Ein weiterer Aspekt:

Dateinamen außerhalb des

,----[ <https://pubs.opengroup.org/onlinepubs/009695399/> ]
| 3.276 Portable Filename Character Set
| The set of characters from which portable filenames are constructed.
| 
| A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
| a b c d e f g h i j k l m n o p q r s t u v w x y z
| 0 1 2 3 4 5 6 7 8 9 . _ -
`----

sind interpretationsabhängig.

Dateinamen sind vom Typ char * (nicht wchar_t *);
Dateinamen, die in einer ISO-8859-1-Umgebung
erzeugt wurden, entsprechen nicht unbedingt
denen unter UTF-8.

-- 
Stefan

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

#14661

Ingrid Stefan Wiens <s.wi@gmx.net> writes:

> ,----[ <https://pubs.opengroup.org/onlinepubs/009695399/> ]
>| 3.276 Portable Filename Character Set

Der vollständige Link:
<https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276>

-- 
Stefan

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

#14662

Stefan Wiens <s.wi@gmx.net> wrote:
> Ingrid Stefan Wiens <s.wi@gmx.net> writes:
> 
>> ,----[ <https://pubs.opengroup.org/onlinepubs/009695399/> ]
>>| 3.276 Portable Filename Character Set
> 
> Der vollständige Link:
> <https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276>

Sorry falls es schon erwähnt wurde: Gehört der Space prinzipiell auch
dazu?

/ralph

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

#14663

Ralph Aichinger <ra@h5.or.at> writes:

> Stefan Wiens <s.wi@gmx.net> wrote:
>> Ingrid Stefan Wiens <s.wi@gmx.net> writes:
>> 
>>> ,----[ <https://pubs.opengroup.org/onlinepubs/009695399/> ]
>>>| 3.276 Portable Filename Character Set
>> 
>> Der vollständige Link:
>> <https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276>
>
> Sorry falls es schon erwähnt wurde: Gehört der Space prinzipiell auch
> dazu?

| The last three characters are the period, underscore, and hyphen characters, respectively.

Sonst nichts außer ALNUM.

Ich selbst nutze ':' ausgiebig in
zeitstempelbasierten Dateinamen,
geht halt nicht bei Windows, und
'~' ist bei vielen Textverarbeitungen
beliebt.

-- 
Stefan

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

#14668

Stefan Wiens <s.wi@gmx.net> wrote:
> Ralph Aichinger <ra@h5.or.at> writes:
> 
>> Stefan Wiens <s.wi@gmx.net> wrote:
>>> Ingrid Stefan Wiens <s.wi@gmx.net> writes:
>>> 
>>>> ,----[ <https://pubs.opengroup.org/onlinepubs/009695399/> ]
>>>>| 3.276 Portable Filename Character Set
>>> 
>>> Der vollständige Link:
>>> <https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276>
>>
>> Sorry falls es schon erwähnt wurde: Gehört der Space prinzipiell auch
>> dazu?
> 
> | The last three characters are the period, underscore, and hyphen characters, respectively.
> 
> Sonst nichts außer ALNUM.

OK, darf ich dann so dumm fragen *warum* der Space (ASCII 0x20) nicht
dazugehört? Ideen dazu?

> Ich selbst nutze ':' ausgiebig in
> zeitstempelbasierten Dateinamen,
> geht halt nicht bei Windows, und
> '~' ist bei vielen Textverarbeitungen
> beliebt.

Wenn man "naive" Nutzer hat wird es Spaces in Dateien geben.

/ralph

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

#14669

Ralph Aichinger <ra@h5.or.at> wrote:

>>>>> ,----[ <https://pubs.opengroup.org/onlinepubs/009695399/> ]
>>>>>| 3.276 Portable Filename Character Set
>>>> 
>>>> Der vollständige Link:
>>>> <https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276>
>>>
>>> Sorry falls es schon erwähnt wurde: Gehört der Space prinzipiell auch
>>> dazu?
>> 
>> | The last three characters are the period, underscore, and hyphen characters, respectively.
>> 
>> Sonst nichts außer ALNUM.
> 
> OK, darf ich dann so dumm fragen *warum* der Space (ASCII 0x20) nicht
> dazugehört? Ideen dazu?

Meine Vermutung:
Es gibt POSIX Systeme, bei denen Space im Filename nicht erlaubt ist.
Ausserdem sind solche Dateinamen UHHAERX in der Shell :-}


> Wenn man "naive" Nutzer hat wird es Spaces in Dateien geben.

Nur wenn das Filesystem das unterstuetzt.

-- 
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:    https://www.tik.uni-stuttgart.de/

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

#14670

Ralph Aichinger <ra@h5.or.at> writes:

> Stefan Wiens <s.wi@gmx.net> wrote:
>> Ralph Aichinger <ra@h5.or.at> writes:
>> 
>>> Stefan Wiens <s.wi@gmx.net> wrote:
>>>> Ingrid Stefan Wiens <s.wi@gmx.net> writes:
>>>> 
>>>>> ,----[ <https://pubs.opengroup.org/onlinepubs/009695399/> ]
>>>>>| 3.276 Portable Filename Character Set
>>>> 
>>>> Der vollständige Link:
>>>> <https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276>
>>>
>>> Sorry falls es schon erwähnt wurde: Gehört der Space prinzipiell auch
>>> dazu?
>> 
>> | The last three characters are the period, underscore, and hyphen characters, respectively.
>> 
>> Sonst nichts außer ALNUM.
>
> OK, darf ich dann so dumm fragen *warum* der Space (ASCII 0x20) nicht
> dazugehört? Ideen dazu?

Vielleicht weiß jemand anderes mehr zu
dieser Entscheidung des POSIX-Komitees.


>> Ich selbst nutze ':' ausgiebig in
>> zeitstempelbasierten Dateinamen,
>> geht halt nicht bei Windows, und
>> '~' ist bei vielen Textverarbeitungen
>> beliebt.
>
> Wenn man "naive" Nutzer hat wird es Spaces in Dateien geben.

Bei ext4 gehen halt alle 8-Bit-Zeichen
im Dateinamen außer '\0' und '/'. 

Leerzeichen sind noch harmlos
(da in ASCII) , ich empfehle die aber nicht.

-- 
Stefan

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

#14664

Am 07.03.26 um 13:07 schrieb Martin Klaiber:

> Diese Scripte haben alle einen 8-bit-Zeichensatz (Latin-1, ISO-8859-1).
> Die gesamte Bildschirmausgabe, Formatierung, usw. ist darauf ausgelegt.
> Wenn ich einen neuen Rechner in meinen "Zoo" aufgenommen habe, hatte
> ich seinen Zeichensatz ebenfalls auf Latin-1 eingestellt.

Das ist schon seit wenigstens 20 Jahren eine eher unglückliche Idee.
In den 90ern konnte man sich wenigstens noch damit herausreden, das die 
Welt sich noch nicht so recht einig war, ob der Weg zu UTF-8, UTF-16, 
UCS-2 oder UCS-4 führt, aber spätestens seit der Jahrtausendwende ist 
die Zielrichtung eigentlich eindeutig. ^_-


> Hat das schon mal jemand gemacht? Da lässt sich sicher viel
> automatisieren. Aber theoretisch ist UTF-8 ja doppelt so breit, aber
> AFAIK auch nicht bei allen Zeichen, damit dürfte dann die Formatierung
> am Bildschirm hinüber sein.

Die ersten 128 Zeichen sind 1:1 identisch zwischen ASCII, ISO-8859 und 
UTF-8. Alle Neuerungen spielen sich im Bereich des gesetztem 8.Bit ab, 
wobei bei UTF8 jedes Sonderzeichen aus zwei bis sechs Bytes besteht.

Falls deine Scripte also 1. niemals mit festen Stringlängen arbeiten und 
2. als Trenn- und Steuerzeichen immer nur Zeichen aus dem ASCII-Vorrat 
verwenden, werden sämtliche Algorithmen ohne Änderung weiter 
funktionieren. Strings mit Sonderzeichen werden einfach nur etwas 
länger, verhalten sich ansonsten aber wie gewohnt.

BTDT, vor rund 20 Jahren, mit einer komplexen Web-Anwendung mit 
hunderten von Scripten (nicht Shell, sondern proprietär, tut aber nix 
zur Sache).


> Oder kompensiert das die Konsole irgendwie automatisch?

Wenn du die Konsole aus Ausgabekanal verwendest, ja.

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

#14666

Hergen Lehmann wrote:
> 
> [...]
> Die ersten 128 Zeichen sind 1:1 identisch zwischen ASCII, ISO-8859 und
> UTF-8. Alle Neuerungen spielen sich im Bereich des gesetztem 8.Bit ab,
> wobei bei UTF8 jedes Sonderzeichen aus zwei bis sechs Bytes besteht.

ISO-8859-1 (256 Zeichen, inklusive C0 und C1) hat ebenfalls ein 1:1
Mapping in Unicode.
In dem hier diskutierten Fall werden die Codepoints also immer identisch
sein. Der Konverter muss lediglich das UTF darauf anwenden.

Die Probleme fangen erst jenseits U+00FF an, z.B. Umlaute in decomposed
Darstellung.

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

#14667

Michael Bäuerle <michael.baeuerle@gmx.net> writes:

> Hergen Lehmann wrote:
>> 
>> [...]
>> Die ersten 128 Zeichen sind 1:1 identisch zwischen ASCII, ISO-8859 und
>> UTF-8. Alle Neuerungen spielen sich im Bereich des gesetztem 8.Bit ab,
>> wobei bei UTF8 jedes Sonderzeichen aus zwei bis sechs Bytes besteht.
>
> ISO-8859-1 (256 Zeichen, inklusive C0 und C1) hat ebenfalls ein 1:1
> Mapping in Unicode.
> In dem hier diskutierten Fall werden die Codepoints also immer identisch
> sein. Der Konverter muss lediglich das UTF darauf anwenden.

Das Dübelzeichen (0xa4) wird trotzdem nicht
zum Eurozeichen. Vielleicht hat der OP
ISO-8859-15 (Latin-9) parallel verwendet?

-- 
Stefan

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

#14671

Stefan Wiens wrote:
> Michael Bäuerle <michael.baeuerle@gmx.net> writes:
> > Hergen Lehmann wrote:
> > > 
> > > [...]
> > > Die ersten 128 Zeichen sind 1:1 identisch zwischen ASCII, ISO-8859 und
> > > UTF-8. Alle Neuerungen spielen sich im Bereich des gesetztem 8.Bit ab,
> > > wobei bei UTF8 jedes Sonderzeichen aus zwei bis sechs Bytes besteht.
> > 
> > ISO-8859-1 (256 Zeichen, inklusive C0 und C1) hat ebenfalls ein 1:1
> > Mapping in Unicode.
> > In dem hier diskutierten Fall werden die Codepoints also immer identisch
> > sein. Der Konverter muss lediglich das UTF darauf anwenden.
> 
> Das Dübelzeichen (0xa4) wird trotzdem nicht
> zum Eurozeichen. [...]

Nein, es bleibt was es vorher war (1:1 Mapping).

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | de.comp.os.unix.shell

csiph-web