Liste und List Comprehension unzuverlässig?

[Sophus]

Ich bin gerade mit meinem Smartphone online, daher werde ich mich etwas kürzer fassen. Das man in den Modulen bestimmte Kodierungen anwendet, wenn etwas außerhalb des ASCII-Wertes ist , weiss ich ja Aber weiten wir mal mein Beispiel etwas weiter aus. Wenn ich mit der GUI arbeite und der Anwender in der lineEdit bestimmte Informationen eingibt, Enter drückt bzw. eine Schaltfläche betätigt, sollen die Informationen zunächst in eine Liste hinzugefügt werden. Über der Konsole hätte ich wohl keine Probleme wenn ich mit raw_input() arbeite. Aber im Falle der GUI kann ich das Modul schlecht kodieren, wenn ein Russe dran sitzt und Informationen eingibt .

[Sirius3]

@Sophus: GUI-Rahmenwerke liefern ja im Normalfall schon Zeichen und keine Bytes. Du hast also das Problem gar nicht.

[BlackJack]

@Sophus: Oder anders ausgedrückt beim `raw_input()` *hättest* Du gerade das Problem das das Bytestrings liefert die Du dekodieren musst und dazu wissen müsstest in welcher Kodierung der Russe seine Texte übergibt.

[Sophus]

Hallo BlackJack und Sirius3,

wenn ich euch also richtig verstehe, kann ich die Daten, die über das GUI-Rahmenwerk eingegeben wurde, ohne "Umwege" verarbeiten? Zum Beispiel, kann ich dann die Daten aus dem Rahmenwerk ohne De bzw. Umkodierung in eine Datenbank übernehmen? Was mir aber in diesem Zuge noch einfällt. Wenn ich bestimmte Informationen aus dem GUI-Rahmenwerk in einen SHA- und/oder MD5-Wert umwandeln will, brauche ich auch hier keine Umkodierung vornehmen? Nehmen wir an, der Russe gibt sein Passwort ein, dieses will ich dann in einen entsprechenden Wert (md5, SHA etc...) umwandeln, muss ich da nicht erst in Unicode umschwenken?

[Sirius3]

@Sophus: hash-Funktionen arbeiten normalerweise auf Byte-Ebene. Deshalb muß ein Passwort encodiert werden. Am besten mit utf8.

[Sophus]

Also doch wieder mit De- und/oder Kodierungen arbeiten?

[Sirius3]

@Sophus: natürlich mußt Du wissen, wo Du Bytes und wo Du mit Zeichen arbeiten mußt. Und dazwischen wird de- und encodiert. Das "also doch" zeigt mir, daß Du das Thema Kodierung noch nicht ganz verstanden hast und daß es nicht das Problem sondern die Lösung ist. Du mußt Dir einfach immer klar machen, wann eine Variable natürlicherweise Bytes und wann Zeichen enthält.

[jerch]

Zum Glück wird in Python die Problematik relativ früh an die Programmierer herangetragen und ist schön abstrahiert (ich sprech mal nur für Python 2, mit Python 3 hab ich kaum Erfahrung). Von PHP, C, C++ bis Java kenne ich wüste Transkodierorgien, wo bei Nachfrage klar wurde, dass die Idee hinter Zeichenkodierungen nicht verstanden war.

[Hyperion]

@jerch: Naja, ich denke in Python gibt es auch verdammt viele Entwickler, die sich damit überhaupt nicht auskennen! Die klassischen Java Anwendungen sind eben auch selten CLI-Tools, bei denen man mit Plain Text Dateien umgehen muss und innerhalb des J2EE Ökosystems findest Du eben wenig, was Wissen über Encoding verlangt. Bei den als sogenannte Script-Sprachen wahrgenommenen Sprachen spielt Dateihandling und Benutzereingaben auf Terminalebene eine größere Rolle und deswegen stößt man oft auf Probleme.

[jerch]

Wie lösen eigentlich Ruby und Perl die Zeichendarstellung? Gibts in Perl als awk(-ward) Sprache einen standardisierten "dekodierten" Unicodetypen ala Python für die interne Repräsentation oder kodiert man da in ein Unicode-Encoding seiner Wahl?