ISO-8859-1 (Latin-1) oder UTF-8, Vor-/Nachteile

[pangu]

Erzählt mal, welche Encodings verwendet ihr denn so und vor allem warum? Deutsche Umlaute bieten ja beide, aber was spricht für das eine odere andere? Freue mich auf eure Eindrücke und persönliche Meinungen.

[wanne]

Vorteile UTF-8:

• Wird praktisch überall genutzt.
• Enthällt so tolle Sonderzeichen wie →↓ø. Gerade in Phydsik oder Mathe super schön. (AΔB=A∪B\A∩B) oder (ε·σ·T⁴·A) sind einfach lesbare Formeln das ist mitLatin1 nicht möglich.
• Enthält deustsche Anführungszeichen „“ und €
• Smylies☺
• Enthält auch Zeichen anderer Länder z.B. Kyrillisch kann man hin und wieder dann doch mal für nen Eigennamen gebrauchen.

Nachteile

• Schwerer zu verarbeiten. (Interessiert dich nicht.)
• Um etwa 2% größer (bzip macht das aber selbst bei -1 (kleinste Kompressionsstufe) praktisch vollständig weg)
  Habe das GG mal durchlaufen lassen:

  Code: Alles auswählen

  $ls -l gg*
  -rw-r--r-- 1 wanne wanne 16770 Jun 24 13:10 gg.latin1.bz2
  -rw-r--r-- 1 wanne wanne 16790 Jun 24 13:08 gg.utf-8.bz2
  $bunzip2 gg*
  $ls -l gg*
  -rw-r--r-- 1 wanne wanne 62242 Jun 24 13:10 gg.latin1
  -rw-r--r-- 1 wanne wanne 63455 Jun 24 13:08 gg.utf-8

• Noch weniger kompatibel zu windows

[Meillo]

Ich verwende moeglichst UTF-8. Da das von Thompson und Pike entworfen worden ist kann es nur hochwertig sein. Genau genommen verwende ich wenn moeglich aber nur das ASCII-Subset von UTF-8. Damit haben sich dann auch alle (relevanten) Encodingfragen auf einmal geloest.

ISO8859 ist ein Legacy-Encoding, das ist obsolete. Es ist eine Schande, dass es das ueberhaupt noch gibt. (Leider kommt man bei BSDs, abgesehen von MirOS, meiner Erfahrung nach gar nicht so einfach davon weg.) Das einzige Szenario in dem ISO8859-1 Sinn macht, ist das fuer das es entworfen wurde: Kommunikation ausschliesslich innerhalb des Westeuropaeischen Sprachraumes.

[pangu]

Angenommen ich hab mit dpkg-reconfigure locales auf meinem debian OS eingestellt, dass DE.UTF-8 verwendet werden soll. Nun logg ich mich von einem entfernten Host (=test1) per SSH an die Maschine an, egal ob mit dem Windows-Putty oder mit einem anderen SSH-Client. Dieser Client hat nun DE.UTF-8 in seinen Einstellungen gesetzt. Ich kann ganz normal arbeiten, kann Umlaute verwenden, Sonderzeichen, usw... alles wird mir korrekt angezeigt und verarbeitet.

Nun logge ich mich von einem anderen entfernten Host (=test2) an meine Debian-Maschine ein, und in diesem Beispiel hat der SSH-Client defaultmäßig ISO-8859-1 eingestellt. Wenn ich jetzt ein "ls -l" absetze und mir die zuvor erstellten Ordner+Dateien anschaue, die ich mit dem ersten Testhost (test1) erstellte, seh ich nur ein Fragezeichen anstatt des Umlautes. Und vice-versa ist es genauso. Der User der sich mit dem ISO-8859-1 sshclient angemeldet hat, erstellt einen testordner namens "Öffentlich", so kann ihn test1 nur mit Zeichensalat sehen.

Wie kann man das denn umgehen oder evtl. dem ssh-client forcieren, er soll eine bestimmte codepage verwenden?

[wanne]

luit ist was du suchst. Oder du stellst das Encoding für die eine Konsole um. (10 sec. suchen hilft.)

[pangu]

Ich möchte ja nicht in den ssh clients immer einstellen müssen, welches encoding ich nutzen möchte. Außerdem muss hierzu auf dem openssh Dämon die AcceptEnv Direktive verwendet werden, dass wiederum kann auch ein Sicherheitsrisiko darstellen. Mir geht's eher darum, dass der ssh server dem client bei der Verbindung mitteilt, er soll ein bestimmtes encoding nutzen (UTF-8). Ein SSH-Client behrerrscht ja so ziemlich alle Encodings, aber wie bringe ich dem openssh Server bei, er soll die ssh-clients forcieren sein eingestelltes encoding zu nutzen?

Luit ist ja eher was andres, und wenn ich es richtig verstanden habe, müsste der Client Luit als Kommandozeile aufrufen. Dann kann ich ja gleich den ssh client anpassen (was ich aber nicht möchte). Luit ist in den x11-utils vorhanden, richtig? Kann man eigentlich so ein einzelnes binary extrahieren wenn man den Rest der Utils aus x11-utils nicht benötigt? Das ist so 'ne Nebenfrage, wenn wir schon mal dabei sind

[wanne]

Ne man sagt einfach

Code: Alles auswählen

luit -encoding 'ISO 8859-1' ssh server.tdl

Dann spricht der Client mit dem Server ISO 8859-1 obwohl der Client UTF-8 ist. (Solange du nur Zeichen machst, die auch in ISO 8859-1)

Promlematischer wird's umgekehrt, wenn der client kein utf-8 kann.
Dann kanst du zumindest die ausgabe so trixen: (Bei der eingabe musst du dann halt fantasievoll sein, wie du keine sonderzeichen brauchst.)
bash | luit -c -encoding 'ISO 8859-1'

Schöner währe das ganze mit iconv aber das puffert, und das bekommt man ihm auch nicht abgewöhnt.

[ralli]

Ich verwende natürlich utf8 als Encoding. Das ist doch mittlerweile der Standard und es führt kein Weg daran vorbei. Schon openSUSE hatte 2005 utf8 eingeführt. Warum FreeBSD und OpenBSD noch immer an ISO8859-15 festhält, wird mir ein ewiges Rätsel bleiben. Natürlich kannst Du es umstellen, aber dann gibt es Probleme mit den deutschen Umlauten.

[pangu]

Ok, nehmen wir an ich stell meinen Serverhost auf UTF-8. Nun loggen sich ein Dutzen User per ssh an diesem Server an. Der eine kommt über Windows via putty, ein anderer über Mac, ein anderer über Linux, usw... die verwenden ganz unterschiedliche Encodings in ihren Clients. Wenn ein User, der sich mit Latin-1 angemeldet hat, ein Verzeichnis namens "Öffentlich" erstellt, dann können wirklich nur diejenigen User den Umlaut korrekt darstellen via "ls" wenn sie selbst auch Latin-1 (ISO-8859-1) verwenden. All die anderen kriegen einen Zeichensalat. Ein weiteres Problem das ich selbst schon hatte --> ich musste so ein Verzeichnis auf Wunsch hin mal löschen. Meint ihr ich hab das in meiner shell auf dem Server hingekriegt? Pustekuchen , von wegen! Wie zum Geier lösche ich denn ein Verzeichnis, welches mir auf der Shell durch "ls -l" mit einem ganz komischen ASCII-Character angezeigt wird statt dem Ö am Anfang? Das Verzeichnis hieß Öffentlich, da der User das jedoch über ein andres Encoding erstellte, sah es in der Shell irgendwie so aus Ãffentlich. Ich kann das Zeichen so nicht eingeben. Gibts irgendwelche besondere Vorgehensweisen in diesem Fall damit man das Verzeichnis oder so eine Datei ansprechen kann?

Genau dieses Problem will ich eignetlich vermeiden. Wenn ein User ein Verzeichnis oder Dateien erstellt die Umlaute beinhalten, so möchte ich sicherstellen, dass es die anderen User auch richtig dargestellt bekommen und vice-versa. Daher war mein Gedanken, ob ich dem SSH-Server beibringen könnte, er soll ein besimmtes Encoding bei seinen Clients forcieren. Das Luit ist ja schön und gut, aber das müssten alle User bei sich verwenden, und das tun sie sicherlich nicht aus Bequemlichkeit :p danke aber für den Tip mit Luit.

[wanne]

Ein weiteres Problem das ich selbst schon hatte --> ich musste so ein Verzeichnis auf Wunsch hin mal löschen. Meint ihr ich hab das in meiner shell auf dem Server hingekriegt? Pustekuchen , von wegen! Wie zum Geier lösche ich denn ein Verzeichnis, welches mir auf der Shell durch "ls -l" mit einem ganz komischen ASCII-Character angezeigt wird statt dem Ö am Anfang? Das Verzeichnis hieß Öffentlich, da der User das jedoch über ein andres Encoding erstellte, sah es in der Shell irgendwie so aus Ãffentlich. Ich kann das Zeichen so nicht eingeben. Gibts irgendwelche besondere Vorgehensweisen in diesem Fall damit man das Verzeichnis oder so eine Datei ansprechen kann?

Code: Alles auswählen

rmdir ?ffentlich #oder sauber:
rmdir $(echo Öffentlich | iconv -t ISO_8859-1 -f UTF-8)

Genau dieses Problem will ich eignetlich vermeiden. Wenn ein User ein Verzeichnis oder Dateien erstellt die Umlaute beinhalten, so möchte ich sicherstellen, dass es die anderen User auch richtig dargestellt bekommen und vice-versa. Daher war mein Gedanken, ob ich dem SSH-Server beibringen könnte, er soll ein besimmtes Encoding bei seinen Clients forcieren. Das Luit ist ja schön und gut, aber das müssten alle User bei sich verwenden, und das tun sie sicherlich nicht aus Bequemlichkeit :p danke aber für den Tip mit Luit.

Das geht nicht am Ende wird der Client doch machen was er will. Und vor allem können die meisten Zeichensätze gar keine Umlaute. Es gibt zwar ein paar Clients, die umstellen können (sshg3 oder Win-scp), aber wenn einer kommt der nicht kann ist eben wieder rum.
Du könntest aber vermutlich die allermeisten Feheler abfangen, wenn du eine shell suchst, die nur ASCII zeichen (Oder nur UTF-8) akzeptiert, und alles andere ignoriert. Das kann man zwar umgehen aber die, die das hinbekommen, die werden vermutlich auch UTF-8 richtig einstellen.

[Meillo]

Ok, nehmen wir an ich stell meinen Serverhost auf UTF-8. Nun loggen sich ein Dutzen User per ssh an diesem Server an. Der eine kommt über Windows via putty, ein anderer über Mac, ein anderer über Linux, usw... die verwenden ganz unterschiedliche Encodings in ihren Clients.

Die muessen natuerlich das Encoding in ihren SSH-Clients auf UTF-8 stellen (warum das z.B. bei Putty noch nicht der Standard ist verstehe ich nicht).

Wenn ein User, der sich mit Latin-1 angemeldet hat, ein Verzeichnis namens "Öffentlich" erstellt, dann können wirklich nur diejenigen User den Umlaut korrekt darstellen via "ls" wenn sie selbst auch Latin-1 (ISO-8859-1) verwenden.

Natuerlich, denn nur die sprechen die gleiche Sprache.

Wie zum Geier lösche ich denn ein Verzeichnis, welches mir auf der Shell durch "ls -l" mit einem ganz komischen ASCII-Character angezeigt wird statt dem Ö am Anfang? Das Verzeichnis hieß Öffentlich, da der User das jedoch über ein andres Encoding erstellte, sah es in der Shell irgendwie so aus Ãffentlich. Ich kann das Zeichen so nicht eingeben. Gibts irgendwelche besondere Vorgehensweisen in diesem Fall damit man das Verzeichnis oder so eine Datei ansprechen kann?

Meist ist `rm *ffentlich' eindeutig. Das ist schneller getippt als wannes Vorschlag.


Vielleicht waere ein Hinweis in der MOTD hilfreich: ``Wenn diese Umlaute (äöü) kaputt sind, dann stelle das Encoding deines SSH-Clients auf UTF-8 um.''

Kann man nicht beim Einloggen (in .profile) automatisch ``luit -encoding UTF-8 bash'' oder so ausfuehren lassen?

[wanne]

Kann man nicht beim Einloggen (in .profile) automatisch ``luit -encoding UTF-8 bash'' oder so ausfuehren lassen?

Nein leider nicht. luit setzt nur von UTF-8 nach beliebig um aber nicht nicht von beliebig nach UTF-8.

[Meillo]

luit setzt nur von UTF-8 nach beliebig um aber nicht nicht von beliebig nach UTF-8.

Das ist ja enttaeuschend.

[wanne]

Naja die umkehrrichtung bietet halt die Gefahr das es nicht geht. (Was wenn das Programm ein ⁷ ausgibt?) Aber versuchen hätten sie's können.

[wanne]

Ich habe hier mal was gebaut, das alles was nicht ascii ist wegwirft. (zu 90% von stackoverflow kopiert)
Leider zerstört das autocompetion und shell promt (Ich habe keine Ahnung wie der shell-Promt auf die shell kommt.)

Code: Alles auswählen

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <errno.h>
#include <signal.h>
#include <string.h>

static void child_handler(int sig)
{
    exit(0);
}

void rmnonascii(int pfds_1[2])
{
  unsigned char* buf=malloc(1);
  ssize_t ret=read(0, buf,1);//read from stdin
  while(ret)//as long we can read form stdin
  {
    if(buf[0]<0x80)
    {
      ssize_t isshell=write(pfds_1[1],buf,1);//to stdin of shell
      if(!isshell)
      {
        fprintf(stderr,"Broken pipe\n");
        exit(1);
      }
    }
    ret=read(0, buf,1);
  }
}
int main(int argc, char *argv[], char *envp[])
{
  if(argv[1]==0)
  {
    argv=calloc(sizeof(void*),3);
    char* defaultsh="/bin/sh";
    argv[1]=malloc(sizeof(char)*8);
    memcpy(argv[1],defaultsh,7);
  }
  int pfds_1[2];
  pipe(pfds_1); // pipe descriptors 
  
  switch (fork()) {
    case 0: // child 
      // close write ends of pipe
      close(pfds_1[1]);

      // redirect stdin to read end of pipe, 4 to read end of pipe 
      dup2(pfds_1[0], 0);

      // the original read ends of the pipe is not needed anymore 
      close(pfds_1[0]);
      
      execve(argv[1],argv+1,envp);
      fprintf(stderr,"Could not execute %s. ",argv[1]);
      perror("");
      return 1;

    case -1:
      fprintf(stderr,"Can't create new Process.\n");
      return 1;

    default: // parent 
      signal(SIGCHLD,child_handler);
      close(pfds_1[0]);// close read end of pipe 
      rmnonascii(pfds_1);
  }
}

amd64 Binary:
ftp://wanne.t-8ch.de/progs/asciionlysh/asciionlysh
i486 Binary:
ftp://wanne.t-8ch.de/progs/asciionlysh/asciionlysh32

Ansonsten kann man das dann einfach als shell in die /etc/passwd reinhängen, oder einfach einmal ./asciionlysh /bin/bash ausführen.
Aber wie gesagt irgend wie noch nicht nutzungsfähig weiß i-jemand, wie man den shell promt wieder bekommt?

[Drache]

Nur UTF-8 genau aus diesem Grund :

• Noch weniger kompatibel zu windows

[r4pt0r]

Nur UTF-8 genau aus diesem Grund :

• Noch weniger kompatibel zu windows

*unterschreib*

Selbst alle Mailclients laufen bei mir mit UTF-8 als Standard. Wer noch Clients nutzt die das nicht erkennen/darstellen können hat Pech gehabt. Wenn man auf alles rückständige Rücksicht nehmen müsste würden wir heute noch Morsen

[wanne]

Selbst alle Mailclients laufen bei mir mit UTF-8 als Standard. Wer noch Clients nutzt die das nicht erkennen/darstellen können hat Pech gehabt. Wenn man auf alles rückständige Rücksicht nehmen müsste würden wir heute noch Morsen

Im Internet hat sich UTF-8 durchgesetzt. (Mal abgesehen von China.) Ist in erster Linie geht's eigentlich nur noch um Textdateien.

[NAB]

Ok, nehmen wir an ich stell meinen Serverhost auf UTF-8. Nun loggen sich ein Dutzen User per ssh an diesem Server an. Der eine kommt über Windows via putty, ein anderer über Mac, ein anderer über Linux, usw... die verwenden ganz unterschiedliche Encodings in ihren Clients.

Die spannende Frage wäre doch eher, wie man Clients mit falschem Encoding den Zugriff verbietet. Geht das irgendwie?

[wanne]

Kicken sobalt er einen „bösen“ Buchstaben schreibt geht einfach. Aber bevor der Cleient sich durch ein nicht ASCII-Zeichen verrät kannst du das nicht machen. Alternativ ginge villeicht ein nachgeschalteter login it ß im passwort Sowas lässt sich leicht implementieren.
Aber das sind halt alles worarounds.

[pangu]

Ok, nehmen wir an ich stell meinen Serverhost auf UTF-8. Nun loggen sich ein Dutzen User per ssh an diesem Server an. Der eine kommt über Windows via putty, ein anderer über Mac, ein anderer über Linux, usw... die verwenden ganz unterschiedliche Encodings in ihren Clients.

Die spannende Frage wäre doch eher, wie man Clients mit falschem Encoding den Zugriff verbietet. Geht das irgendwie?

Würde es denn nicht ausreichen, wenn man in die sshd_config einfach die Zeile

Code: Alles auswählen

#AcceptEnv LANG LC_*

kommentiert, so daß die ssh-clients ihre Env's nicht mehr durchreichen dürfen?