Python und Sonderzeichen

William schrieb:
> wird eine Muschung aus Win 7 und Win 10 verwendet

Wichtiger ist in diesem Fall die Python-Version!

https://docs.python.org/3/howto/unicode.html
https://docs.python.org/2/howto/unicode.html

Gruß,
Dennis

William schrieb:
> Soweit ich das analysieren könnte gibt es Probleme mit print Ausgaben.

Wohin erfolgen diese Ausgaben? In das Windows-Konsolenfenster?

Und wie sieht die fehlerhafte Ausgabe aus?

William schrieb:
> print ("Sönderzeichen")
>
> schreibe, wie bekomme ich das auch in der UK genau so angezeigt?
>
> gibt es sowas ähnliches wie z.B.
>
> print ("S"\xf6"nderzeichen")

Nein, tu das nicht! Auf gar keinen Fall! Damit nagelst Du es auf eine 
Zeichen-Kodierung (deine eigene) fest und das wird oftmals nicht die 
Kodierung der Konsole des Endanwenders sein, dort liegt das ö vielleicht 
ganz wo anders.

Es gibt stattdessen das:

print u"Sönderzeichen"

dann ist es ein Unicode-String, der funktioniert international wird bei 
der Ausgabe (egal wo) on the fly passend zur Kodierung des dortigen 
Ausgabegerätes kodiert und wenn der Zeichensatz des Ausgabegerät 
irgendwo ein "ö" enthält dann kommt das auch raus. Wenns natürlich den 
Kringel mit den zwei Punkten nirgendwo in seinem Zeichensatz hat, dann 
natürlich nicht.

Und den Quelltext würde ich natürlich grundsätzlich als UTF8 codieren 
und den Editor mit dem Du arbeitest entsprechend einstellen (wichtig!), 
das ist Voraussetzung wenn Du unbedingt Strings mit Umlauten direkt im 
Quelltext stehen haben willst.

Die Zeiten von Windows1252 und Iso-88-schlagmichtot sind gottseidank 
vorbei, UTF-8 ersetzt sie alle. Überall dort wo Du es einstellen kannst 
(fast überall): Nur noch UTF-8.

Also zusammengefasst:

  * Editor (IDE oder wasauchimmer) auf UTF-8 umstellen, evtl vorhandene 
Dateien neu als UTF-8 speichern, bei der Umstellung zerschossene Umlaute 
wieder korrigieren so daß sie jetzt in UTF-8 vorliegen.
  * den open genannten Header in alle Python2 Dateien einbauen
  * Stringliterale mit Umlauten nur noch u"Hölle" statt "Hölle"

dann wirds klappen.

William schrieb:

> wir benutzen bei uns ein paar Python Scripte die irgendwann mal
> zusammengeschraubt wurden. Bei uns in Deutschland funktioniert das auch
> ohne Probleme. Allerdings bei unseren Kollegen in Großbritannien die
> Begutachtung diese Anwendungen bekommen sollen gibt es Probleme. Hier
> wird eine Muschung aus Win 7 und Win 10 verwendet.

Bitte die Kollegen doch mal, den Output des Kommandos "chcp" (ohne 
Argumente) mitzuteilen und vielleicht auch, was sich nach Eingabe von 
"chcp 850" und dann Programmstart als Output ergibt.

Da Python 3.4 verwendet wird, ist es wurscht, ob eine Stringkonstante 
als "Grüßlich" oder als u"Grüßlich" geschrieben wurde. Sollte der Code 
allerdings auch mit Python 2.7 kompatibel sein sollen, wäre als 
einheitliche Schreibweise der u-Prefix zu bevorzugen.

Ist das Skript denn auch in utf-8 abgespeichert, oder steht da nur oben 
"utf-8" drin?

William schrieb:
> ICh habe gerade einen Versuch geastartet
>
> Ich habe in der ersten Zeile nach den impotfiles folgendes geschrieben:
>
> os.system('chcp 850')

Das ist nicht das, was ich meinte. Es wird Verwirrung stiften, weil es 
erst beim zweiten Programmstart funktioniert.

1

# -*- coding: utf-8 -*-

2

import os

3

os.system("chcp")

4

os.system("chcp 850")

5

os.system("chcp")

6

print("Grüßlich")

7

print(u"Grüßlich")

8

9

C:\temp>chcp 1250

10

Aktive Codepage: 1250.

11

12

C:\temp>\Python34\python umleute.py

13

Aktive Codepage: 1250.

14

Aktive Codepage: 850.

15

Aktive Codepage: 850.

16

Gr³▀lich

17

Gr³▀lich

18

19

C:\temp>\Python34\python umleute.py

20

Aktive Codepage: 850.

21

Aktive Codepage: 850.

22

Aktive Codepage: 850.

23

Grüßlich

24

Grüßlich

Mein Vorschlag lief darauf hinaus, zunächst zu prüfen, was die 
voreingestellte Codepage ist, diese dann in einem cmd.exe Konsolfenster 
zu ändern und dann dort das besagte Programm auszuführen. Falls das 
funktioniert, kann man immer noch überlegen, wie man das je nach den 
konkreten Umständen etwas zickige Verhalten von Python mit Codepages in 
den Griff bekommt.

Kaj schrieb:

> Das ist ja schon wieder steinalter mist, von leuten, die auf Python 2.x
> haengen geblieben sind und sich nicht weiterbilden... Hier geht es aber
> um Python 3!

Nun, selbst die eifrigsten Fans von Python 3 rudern inzwischen deutlich 
zurück und räumen ein, daß im wirklichen Leben, dort, wo Python benutzt 
und nicht nur drüber fabuliert wird, Python 3 zehn Jahre nach der 
Einführung weiterhin nur eine Fußnote ist.

Eine aktuelle Zweiwochen-Downloadstatistik von pypi weist aus

1

2.7     85.90%

2

2.6      6.66%

3

3.4      4.64%

4

3.5      2.09%

5

3.3      0.56%

6

3.2      0.12%

Mit anderen Worten, Python-Pakete für alle Python 3.x-Versionen 
zusammengerechnet werden etwa so häufig eingesetzt wie die alte, längst 
aus der Wartung genommene 2.6.

Man wird mit der Spaltung, die die unüberlegte Einführung einer halbgar 
kompatiblen Sprachvariante verursacht hat, wohl noch die nächsten zehn 
oder zwanzig Jahre leben müssen. Ich habe Verständnis für diejenigen, 
die sich für neue Projekte mit wenig Umgebungsabhängigkeiten, was Python 
betrifft, der fraglos moderneren Implementation bedienen. Ich bitte aber 
auch um Verständnis für z.B. diejenigen, die Python schon vor langer 
Zeit ihrem Repertoire hinzugefügt haben und wenig Sinn darin sehen, das 
alles, was sich da an kleinen und größeren Hilfsmitteln angesammelt hat, 
für zweifelhafte Vorteile wegzuwerfen, deren Nutzen sich evtl. erst spät 
oder nie manifestiert.

Jedenfalls treiben dumme Sprüche wie der obige ("steinalter Mist") die 
Leute eher von Python weg als zu Python 3 hin.  Die klügeren der Fans 
haben inzwischen gelernt, daß derartiges Proselytentum vornehmlich 
motiviert, sich mal bei Alternativen wie Go, Julia, Rust, Lua, Java, 
Swift etc. pp umzuschauen.

Wolfgang S. schrieb:
> Mit anderen Worten, Python-Pakete für alle Python 3.x-Versionen
> zusammengerechnet werden etwa so häufig eingesetzt wie die alte, längst
> aus der Wartung genommene 2.6.
Nein. Diese Statistik ist nicht "randomly sampled" und damit nutzlos.

Wenn ich einen alten Rechner habe, auf dem Python 2.6 oder 2.7 läuft, 
lade ich Pakete dafür natürlich viel eher aus dem package index runter 
als wenn ich irgendwas neueres benutze. Wenn ich 3.5 verwende, 
installier' ich mir unter Windows so einen blob wo eh alles drin ist 
oder kriege unter Linux alles aud meinem Paketmanager, und 99% der 
Nutzer werden den package index nie verwenden. Deshalb tauchen die auch 
nicht in der Statistik auf.

Wolfgang S. schrieb:
> Jedenfalls treiben dumme Sprüche wie der obige ("steinalter Mist") die
> Leute eher von Python weg als zu Python 3 hin.  Die klügeren der Fans
> haben inzwischen gelernt, daß derartiges Proselytentum vornehmlich
> motiviert, sich mal bei Alternativen wie Go, Julia, Rust, Lua, Java,
> Swift etc. pp umzuschauen.

Ehrlich gesagt, und ohne dir auf die Füße treten zu wollen weil du 
prinzipiell Recht hast, hättest du dir das ganze Gebrubbel sparen 
können. Der TO sucht eine Lösung für v3.4. Wen interessieren da 
irgendwelche Downloadstatistiken?

Gruß Dennis

Dennis S. schrieb:
> Wolfgang S. schrieb:
>> Jedenfalls treiben dumme Sprüche wie der obige ("steinalter Mist") die
>> Leute eher von Python weg als zu Python 3 hin.  Die klügeren der Fans
>> haben inzwischen gelernt, daß derartiges Proselytentum vornehmlich
>> motiviert, sich mal bei Alternativen wie Go, Julia, Rust, Lua, Java,
>> Swift etc. pp umzuschauen.
>
> Ehrlich gesagt, und ohne dir auf die Füße treten zu wollen weil du
> prinzipiell Recht hast, hättest du dir das ganze Gebrubbel sparen
> können. Der TO sucht eine Lösung für v3.4.

Dem TO habe ich die Lösung längst auf dem silbernen Tablett serviert, 
passend für das von ihm genannte Python 3.4 und mit komplettem Beispiel.

> Wen interessieren da
> irgendwelche Downloadstatistiken?

Diejenigen, denen solche dummen Sprüche auf Dauer auf die Nerven gehen. 
Mich zum Beispiel. Wobei das eigentliche Argument ein inhaltliches ist, 
die Statistik diente nur der Illustration.  Und ja, ich kenne die ganze 
Rabulistik, die dazu dient, diesen offensichtlichen Sachverhalt 
wegzureden und habe auch keine Lust, das zu vertiefen. Das kann man 
anderswo nachlesen.

TL;DR Python 2.x-Benutzer öffentlich zu beschimpfen wurde zehn Jahre 
lang versucht, es hat nicht funktioniert, jedenfalls nicht in der 
gewünschten Weise. Zeit, etwas anderes zu probieren.

William schrieb:
r in unseren Scripten verwenden.
>
> Jetzt die Frage aller Fragen, wie gehe ich das Problem am besten an?

Das tun, was ich vorschlug. Und dann den kompletten (!) Input und Output 
zeigen.

William schrieb:
> Wolfgang S. schrieb:
>> Bitte die Kollegen doch mal, den Output des Kommandos "chcp" (ohne
>> Argumente) mitzuteilen und vielleicht auch, was sich nach Eingabe von
>> "chcp 850" und dann Programmstart als Output ergibt.
>
>
>
> Du meinst das hier?
>
>>"chcp" (ohne Argumente)
>
> Code Page 437

Nein, denn das hattest Du ja schon geschrieben.

>
>> nach Eingabe von "chcp 850" und dann Programmstart als Output ergibt.
>
>

1

UnicodeEncodeError: 'charmap' codec can´t encode character '\xf8' in

2

> position 0: character maps to <undefined> test_script returned -1

>
> Wenn das programm dann direkt nochmal gestartet wird geht es dann

Jetzt fehlt mir nur noch das Programm dazu. Mein Beispiel kann es nicht 
sein, denn das produziert auch mit Codepage 437 keinen Traceback.

0xf8 ist nicht utf-8, sondern ø in Latin-1 ø aka ø

William schrieb:
> # coding: utf-8
> import os
> os.system("chcp")
> os.system("chcp 850")
> print ("ø % ö ä ü ")
>
>
> Ok, dann denke ich, dass ich in Eclipse nochmal nachsehen muss das alle
> Dateien in UTF-8 gespeichert werden.

Ich denke eher, meine ursprüngliche Diagnose stimmt: Das Zeichen ø ist 
in der Codepage 437 nicht enthalten. Das Problem ist nicht, wie es im 
Programm codiert ist, sondern ob es in die gewünschte Outputcodierung 
überführt werden kann. Der erste chcp zeigt die beim Programmstart 
gültige Codepage, das ist die, welche Python 3.4 verwendet. Der zweite 
Aufruf setzt zwar die Codepage des aufrufenden Prozesses (cmd.exe), das 
hat auf den laufenden Python-Interpreter aber keine Wirkung mehr.

Ob man die von Python verwendete Codepage für console output im 
laufenden Programm ändern kann bzw. wie, habe ich noch nicht 
herausgefunden, allerdings habe ich auch nicht intensiv gesucht.  Mein 
Vorschlag bleibt, die Codepage vor Start des Programms auf 850 zu 
setzen.

Das wird nicht gehen, der Interpreter ist derselbe auch wenn du ein 
import machst. Du müsstest schon einen neuen Prozess starten, wenn ich 
mich nicht sehr täusche.

William schrieb:
> In dem Testscript habe ich alle Sonderzeichen in print reingeknallt was
> wir in unseren Scripten verwenden.
>
> Jetzt die Frage aller Fragen, wie gehe ich das Problem am besten an?

Hab ich doch schon geschrieben:


* script in UTF-8 speichern
* # -*- coding: utf-8 oben einbauen um python das auch mitzuteilen
* print u"äöüß" anstelle von print "äöüß"

Deine Fehlermeldung sagt aus daß Du den u-Prefix vergessen hast.

Himmel, das u-Präfix ist tot seit 3.x, das existiert nur noch aus 
Kompatibilitätsgründen. Das wurde doch jetzt auch schon fünf mal gesagt.

Sven B. schrieb:
> Himmel, das u-Präfix ist tot seit 3.x, das existiert nur noch aus
> Kompatibilitätsgründen. Das wurde doch jetzt auch schon fünf mal gesagt

Er hat ebenfalls gesagt daß das Script dort mit 2.7 ausgeführt wird.

Hier um Abnhang zur Demonstration wie das funktioniert. Problem gelöst, 
Thread kann geschlossen werden.

Bernd K. schrieb:
> Hier um Abnhang zur Demonstration wie das funktioniert. Problem gelöst,
> Thread kann geschlossen werden.

Thema verfehlt. Wenn man den Teststring des Threaderöffners verwendet, 
stellt sich heraus, wie ich bereits vor einer Weile schrieb und 
vorführte, daß das Zeichen ø nicht encodiert werden kann, wenn die 
Codepage 437 eingestellt ist. Darauf, daß man unter 2.7 den u-Prefix 
verwendet sollte, hatte ich ebenfalls schon zu Beginn hingewiesen.

1

#!/usr/bin/env python

2

# -*- coding: utf-8 -*-

3

4

import sys

5

6

# erstes:       Den codoing header oben nicht vbergessen

7

# zweitens:     u-Prefix nicht vergessen, das macht Unicode-Strings

8

# drittens:     IDE so einstellen daß sie UTF-8 verwendet.

9

10

11

# und los gehts...

12

def main():

13

    print(sys.version)

14

    print(sys.stdout.encoding)

15

    print(u"dies geht noch: % ö ä ü ")

16

    print(u"dies nicht mehr: ø % ö ä ü ")

17

18

19

# Das folgende Brimborium existiert haupsächlich

20

# um die Konsole offen zu halten falls jemand es im

21

# Explorer doppelklickt.

22

if __name__ == '__main__':

23

    try:

24

        main()

25

    except:

26

        print(sys.exc_info()[0])

27

        import traceback

28

        print(traceback.format_exc())

29

    finally:

30

        print ("Press Enter to continue ...")

31

        if sys.version_info[0] < 3:

32

            raw_input()

33

        else:

34

            input()

Und der Output

1

C:\temp>python_UTF8_broken_with_cp437.py

2

2.7.10 (default, May 23 2015, 09:44:00) [MSC v.1500 64 bit (AMD64)]

3

cp437

4

dies geht noch: % ö ä ü

5

<type 'exceptions.UnicodeEncodeError'>

6

Traceback (most recent call last):

7

  File "C:\temp\python_UTF8_broken_with_cp437.py", line 24, in <module>

8

    main()

9

  File "C:\temp\python_UTF8_broken_with_cp437.py", line 16, in main

10

    print(u"dies nicht mehr: ø % ö ä ü ")

11

  File "c:\python27\lib\encodings\cp437.py", line 12, in encode

12

    return codecs.charmap_encode(input,errors,encoding_map)

13

UnicodeEncodeError: 'charmap' codec can't encode character u'\xf8' in position 1

14

7: character maps to <undefined>

15

16

Press Enter to continue ...

Daß das Programm diese Exception nicht wirft, wenn man auf den u-Prefix 
verzichtet, aber die Codepage 850 einstellt, sondern nur eine falsche 
Darstellung produziert, lasse ich mal als Übungsaufgabe stehen. :-)

Ein besserer Ansatz wäre das Aufrufen der Win32-API-Funktion 
SetConsoleOutputCP aus dem Python-Programm heraus.

Rufus Τ. F. schrieb:
> Ein besserer Ansatz wäre das Aufrufen der Win32-API-Funktion
> SetConsoleOutputCP aus dem Python-Programm heraus.

Besserer Ansatz als was? Auch win32console.SetConsoleOutputCP(850) hilft 
einem nicht aus der Sackgasse und das ist so dokumentiert:

"Sets the output code page for calling process's console".

William schrieb:
> kurzes Feedback. Ich habe eine Rückmeldung von den Kollegen erhalten.
>
> Die haben sich da etwas über eine Windows .bat gebastelt.
>
> Die startet erst du Konsole, stellt die Codeoage um und startet das
> eigentliche Programm.
>
> Ist ein kleiner Umweg, aber geht.

Danke für die Rückmeldung. Dies ist jedenfalls ein sauberer Weg.

Zwischenzeitlich habe ich ein wenig herumgelesen und hätte noch 
folgendes anzubieten:

1

import codecs

2

sys.stdout = codecs.getwriter("850")(sys.stdout)

Mit Python 2.7.11 hat das die gewünschte unmittelbare Wirkung, daß auch 
"¢" ausgegeben werden kann. Mögliche negative Seiteneffekte habe ich 
nicht weiter untersucht.

Unter Python 3.4 funktioniert das so nicht. Eine evtl. Lösung möge 
jemand aus der 3.x-Fraktion beisteuern, mir fehlt diesbezüglich jeder 
Ehrgeiz.

Wolfgang S. schrieb:
> Besserer Ansatz als was?

Ein besserer Ansatz als das per Batch zu machen.

Ansonsten funktioniert die Ausgabe von Sonderzeichen in der Konsole nur 
dann wirklich brauchbar, wenn ein Truetype-Font verwendet wird. Die 
standardmäßig aktiven Pixelfonts (z.B. VGA850.FON) umfassen nur einen 
8-Bit-Zeichensatz der bei der Installation des OS aktiven Codepage (das 
ist meistens CP850). Das lässt sich im Betrieb kaum sinnvoll wechseln.

Rufus Τ. F. schrieb:
> Wolfgang S. schrieb:
>> Besserer Ansatz als was?
>
> Ein besserer Ansatz als das per Batch zu machen.

Ist es ja nicht. Per Batch läßt sich die Codepage vor dem Starten des 
Python-Interpreters einstellen, per win32console-Aufruf nicht.

Man müsste also auch hier einen neuen Prozess starten. Das ist nun ganz 
bestimmt nicht eleganter oder einfacher, als in einer 
Aufruf-Batchprozedur die Codepage zu setzen.

Da das Script ja offenbar mit Pyinstaller in ein exe verpackt werden 
soll, böte sich an, dessen runtime-hook in analoger Weise zu einer 
Batchprozedur zu verwenden, denn genau für so etwas ist der vorgesehen.

"Path to a custom runtime hook file. A runtime hook is code that is 
bundled with the executable and is executed before any other code or 
module to set up special features of the runtime environment. This 
option can be used multiple times."

Die Datails möge aber bitte der Threaderöffner (i.e. "William") selber 
untersuchen, denn das artet dann langsam doch in Arbeit aus.


> Ansonsten funktioniert die Ausgabe von Sonderzeichen in der Konsole nur
> dann wirklich brauchbar, wenn ein Truetype-Font verwendet wird.

Mag im allgemeinen Fall so sein, ist aber eine ganz andere Baustelle.

> Die
> standardmäßig aktiven Pixelfonts (z.B. VGA850.FON) umfassen nur einen
> 8-Bit-Zeichensatz der bei der Installation des OS aktiven Codepage (das
> ist meistens CP850). Das lässt sich im Betrieb kaum sinnvoll wechseln.

Mit dem ¢ gibt es jedenfalls auch mit den Rasterfonts kein Problem.

Den vorhanden Satz an Zeichen und die Codierung kann man sich übrigens 
mit der kaum noch bekannten Utility "Zeichentabelle" anschauen.

Wolfgang S. schrieb:
> Ist es ja nicht. Per Batch läßt sich die Codepage vor dem Starten des
> Python-Interpreters einstellen, per win32console-Aufruf nicht.

Das ist aber ein Unterschied. Im Batch-Fall wird die Codepage auch auf 
den Quelltext angewandt, im anderen Fall aber nur auf die Ausgabe.

> Den vorhanden Satz an Zeichen und die Codierung kann man sich übrigens
> mit der kaum noch bekannten Utility "Zeichentabelle" anschauen.

Das ist charmap.exe, wenn man keine Lust hat, es in den Tiefen 
irgendwelcher Startmenüs o.ä. zu suchen, oder es auf einer nicht-deutsch 
lokalisierten Windows-Version sucht.

Rufus Τ. F. schrieb:
> Das ist aber ein Unterschied. Im Batch-Fall wird die Codepage auch auf
> den Quelltext angewandt,

Unfug. Den Quelltext bekommt nur der Python-Interpreter zu Gesicht und 
der liest den direkt aus der Datei. Wie die Kodierung von stdout gerade 
eingestellt ist kümmert ihn nur wenn er was auf stdout ausgeben will und 
umcodieren muss.