Einfache Datei mit Umlauten einlesen

[api]

@CM

Danke für den Hinweis. Habe das Script dann mal so angepasst:

Code: Alles auswählen

#! /opt/python3.1/bin/python3
# -*- coding: ascii -*-

##################################################################################################
### -*- coding: iso-8859-15 -*-
##################################################################################################
import os
import sys
import codecs
import locale

infile = "/tmp/umlaut.txt"

FileEncoding = "ISO-8859-15"

with codecs.open(infile, 'r', FileEncoding) as f:
  for line in f:
    print (line.encode(FileEncoding))

Muss ich denn jetzt bei diesem Kontrukt am Ende noch ein

Code: Alles auswählen

f.close()

einsetzen oder nicht?

Und dann noch zu deinem Statement...

Alles klar? Das hat was mit 'file' und Deiner Datei, aber nicht mit Deinem OS flavour zu tun.

Was meinst du damit? Ich habe schließlich eine ganz normale Datei (mit vi erzeugt).

CU,
Api

[CM]

Muss ich denn jetzt bei diesem Kontrukt am Ende noch ein

Code: Alles auswählen

f.close()

einsetzen oder nicht?

Nein, with kümmert sich drum.

Was meinst du damit? Ich habe schließlich eine ganz normale Datei (mit vi erzeugt).

Das kann schon sein. Aber aus irgendeinem Grund erkennt file nicht mehr als 'data'. Das kann an vielen Dingen liegen, aber nicht daran, daß Du ein bestimmtes Unix-flavour nutzt. Vielleicht ist magic (worauf file zurückfällt) bei dem System irgendwie nicht so umfangreich?

[api]

@CM

Also, wenn ich mit vi eine Datei erfasse (test.txt), mit folgendem Inhalt:

test:

Dann der test mit "file"

file test.txt
test.txt: ascii text

Wenn die Datei Umlaute enthält:

test:Ö

Dann der test mit "file"

file test.txt
test.txt: data

Das müsste doch bedeuten, dass das OS das nicht lesen kann, oder?

[BlackJack]

@api: Wie ja schon von deets geschrieben wurde, kann man die Kodierung einer Textdatei nicht automatisch ermitteln, sondern höchstens raten. Wenn nur Werte im (druckbaren) ASCII-Bereich vorkommen, vermutet ``file``, dass es sich wohl um ASCII handelt. Bei ``test:Ö`` ist (fast) unabhängig von der verwendeten Kodierung klar, dass es nicht ASCII ist. Also sagt Dein ``file`` es sind allgemein Daten. Das ist der Fallback, der nie falsch ist. Denn ganz allgemein enthält eine Datei immer Daten.

[CM]

Nee, file sollte das Beispiel eindeutig als ein Unicode-flavour erkennen - auch wenn das encoding nicht im vimrc gesetzt ist. Der Algorithmus von file sieht vor systematisch durchzuraten und erst wenn gar nichts Näherliegendes erkannt wird, greift file auf 'data' zurück. Aber, api, ich würd' mich mal davon frei machen den Fehler beim OS zu suchen. Allenfalls, wenn Du an einer wirklich alten Maschine sitzt, könnte die mangelnde Wartbarkeit dazu führen, daß Deine 'file'-Version schlechter rät. Aber 'data'? - Das kommt mir immer noch komisch vor. (Auf VAX/VMS habe ich unabsichtlich immer wieder mal Zeichen erzeugt, die zum Teil gar nicht dargestellt wurden. Da war Debugging ein besonderer Spaß . Selbst da war das OS "unschuldig".)

[lunar]

@CM: "file" ist nicht überall "file" Es gibt verschiedene Implementierungen für verschiedene Systeme, manche besser, manche schlechter. Nach POSIX ist "file" nicht verpflichtet, die Kodierung einer Textdatei zu erraten. Die Ausgabe "data" ist vollkommen konform zu den Erfordernissen von POSIX, und mithin auch nicht komisch, sondern insbesondere auf alten Unix-Systemen sogar zu erwarten. Das Erraten der Kodierung ist nicht Pflicht, sondern Kür.

Insofern ist in diesem Fall doch das System des OP Schuld an dieser nicht sonderlich hilfreichen Ausgabe

[snafu]

@api

Ein Hinweis noch zum von dir verwendeten Shebang:

Code: Alles auswählen

#! /opt/python3.1/bin/python3

Du machst dein Skript portabler, wenn du den Zwischenschritt über das Tool `env` gehst:

Code: Alles auswählen

#!/usr/bin/env python3

Das geht die Verzeichnisse aus dem `$PATH` in der gegebenen Reihenfolge durch und führt die erste Möglichkeit aus, die sich aus Verzeichnis + `python3` ergibt. Klappt dementsprechend natürlich nur, wenn `/opt/python3.1/bin` in deinem `$PATH` auftaucht und (sofern relevant) *vor* dem Verzeichnis steht, welches einen anderen (nicht zu nutzenden) Python 3 Interpreter beinhaltet. Der Vorteil daran ist, dass andere Anwender, die ihren Interpreter beispielsweise in `/usr/bin` haben, den Shebang vor Ausführung des Skripts nicht extra anpassen müssen. `env` übernimmt also im Grunde das, was eine Shell üblicherweise nach Eingabe von einem schlichten `python3` tun würde (was ja als Shebang nicht funktioniert).

Im Übrigen finde ich es etwas ungewöhnlich, ein `/bin` unter `/opt/python3.1` zu haben (hätte es wohl eher direkt unter `/opt` gelegt), aber du wirst schon wissen, was du tust (falls du es beeinflussen kannst).

[BlackJack]

@snafu: Unter ``/opt/`` sind Programme in der Regel unter ``/opt/{produkt}/bin/`` oder ``/opt/{hersteller}/{produkt}/bin`` zu finden. Beispiele von dem Rechner an dem ich gerade tippe:

Code: Alles auswählen

bj@s8n:~$ ls /opt/Adobe/Reader9/bin/
acroread
bj@s8n:~$ ls /opt/jython-2.5.1/bin/
jython
bj@s8n:~$ ls /opt/IBM/informix/bin/
check_version  esql      glfiles         infxserver  onpassword
chkenv         esqldemo  ifx_getversion  msgfile     rofferr
crtcmap        finderr   infxmsg         oncmsm      sqliprint

Der Filesystem Hierarchy Standard (FHS) sagt dazu:

A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider's LANANA registered name.

Ein ``/opt/bin/``-Verzeichnis fänd ich ziemlich überraschend.

[snafu]

Stehen die denn dann im $PATH?

[BlackJack]

@snafu: Teilweise. Bei anderen gibt es symbolische Links in ``/usr/local/bin`` auf die ausführbaren Binärdateien. Wieder andere starte ich mit dem kompletten Pfad.