[Python-de] diakritische Zeichen

[Diez B. Roggisch]

On 11/7/12 11:43 PM, "Armin Stroß-Radschinski" <developer at acsr.de> wrote:

> 
> Am 07.11.2012 um 20:46 schrieb Hermann Riemann:
> 
>> Armin Stroß-Radschinski schrieb:
>> 
>>> Deine Frage ist meiner Meinung nach unbewusst unpräzise, wenn nicht
>>> sogar falsch, formuliert.
>> 
>>> Geht es Dir nur um dieses eine Zeichen oder eine generelle Info zu
>>> Unicode mit diakritischen Zeichen?
>> 
>> Es geht mir um die Programmierung mit Python,
>> wenn diakritische Zeichen auftauchen.
>> 
>> Wenn ich z.B. in Schriftart monospace ( Zeichen alle gleich breit)
>> durch Anordnung der Zeichen eine Tabelle aufbaue,
>> so brauche ich die Stelle.
>> Und das ist, wenn diakritische Zeichen im string sind,
>> nicht mehr der Index im string.
>> Hinzu kommt auch z.B. Buchstaben scan,
>> string.split('ü') ..
>> 
> Benutzt Du Python 3 oder 2.7,
> Bei Python 3 bist Du vermutlich aus dem Schneider, denn da wird ja
> nicht mehr mit Binär Daten rumgefummelt und jedes Zeichen ist sicher
> ein Element, wenn der Export es nicht verbastelt hat.

Du hast das Problem nicht verstanden. Es geht hier nicht um eine Encoding
wie zB UTF-8, welches Codepoints aus Unicode in mehrere Bytes codiert.

Es geht um diakritische Zeichen *in unicode*, die mal aus einem einzigen
Codepoint bestehen, mal aus zwei. Je nach Normalform.

Folgende Beispielprogramm verdeutlicht das (Python 2.7):

# -*- coding: utf-8 -*-
import unicodedata

oe =  u"Ö"
print oe.encode("utf-8"), len(oe)
print unicodedata.name(oe)
oe_n = unicodedata.normalize("NFKD", oe, )
print repr(oe_n), len(oe_n)
for c in oe_n:
   print unicodedata.name(c)

new_oe = unicodedata.normalize("NFC", oe_n)
print oe.encode("utf-8"), len(oe)



Das kommt raus:

Ö 1
LATIN CAPITAL LETTER O WITH DIAERESIS
u'O\u0308' 2
LATIN CAPITAL LETTER O
COMBINING DIAERESIS
Ö 1


Ich habe die repr-Variante fuer das oe_n gewaehlt, weil mein Terminal die
Kombination nicht verarbeitet, und nur "O " ausspuckt.

Hermann's (eher gefuehltes, weil wohl nicht real aufgetretenes) Problem
bezieht sich also darauf, dass zwei visuell äquivalente Unicode-Strings
unterschiedliche Länge haben.

Und da es hier um tabellarische *Ausgaben* ging, wo auch im Jahre 12 nach
der Jahrtausendwende korrekte Spaltenbreiten relevant sind, hat das mit
dBase und CSV alles nichts zu tun.

Das Snippet zeigt Hermann auch die Lösung seines Problems (zumindest
dieses, Martin von Loewis kennt bestimmt noch ein paar andere dunkle Ecken
von Unicode): Wenn man beliebige unicode-Strings so formatiert darstellen
will, sollte man sich im normalisieren üben. Und offensichtlich kann auch
nicht jede Textengine (zB die von iTerm unter OSX) nicht mit den
Kombinationszeichen umgehen.

Diez