Python verschluckt sich an chinesischen Schriftzeichen
Moin,
bei bestimmten chin. Schriftzeichen (𠃓𤔔𤴓𠕁𠂇𦍌𠂉𠀎 und weitere, alle aus dem Bereich U+2xxxx) meint Python len(s) ist gleich 2. Außerdem beendet sich IDLE einfach, wenn man das Zeichen in die Konsole kopieren will (unter Windows, Python 3.2.2).
Kann das evtl. jemand bestätigen?
bei bestimmten chin. Schriftzeichen (𠃓𤔔𤴓𠕁𠂇𦍌𠂉𠀎 und weitere, alle aus dem Bereich U+2xxxx) meint Python len(s) ist gleich 2. Außerdem beendet sich IDLE einfach, wenn man das Zeichen in die Konsole kopieren will (unter Windows, Python 3.2.2).
Kann das evtl. jemand bestätigen?
Klar. "Verschlucken" ist allerdings etwas falsch beschrieben: das passiert in voller Absicht. Es handelt sich um Zeichen außerhalb der Basic Multilingual Plane, mit Codes größer 0xFFFF. Diese Zeichen können nicht in 2 Byte kodiert werden.
Python 3.2 benutzt unter Windows deshalb UTF-16, und da werden für so ein Zeichen 2 "code units" benötigt; für BMP-Zeichen aber nur eins. Unter Linux verwendet Python i.d.R. UTF-32, wo die "code unit" vier Byte groß ist und jedes Zeichen also die Länge 1 hat. Unter Windows wird UTF-16 verwendet aus Kompatibilität zum Windows-API.
In Python 3.3 wird, dank PEP 393, auf allen Systemen einheitlich eine variable interne Darstellung verwendet, sodass diese Zeichen dann die Länge 1 haben (und vier Byte im Speicher benötigen).
Der IDLE-Absturz wird in 3.3 auch behoben sein. Allerdings kann IDLE die Zeichen nicht darstellen, weil Tk auf die BMP beschränkt ist.
Ciao, Martin
nachdem ich noch etwas über surrogate pairs usw. nachgelesen habe, kann ich wohl davon ausgehen, dass das Verhalten von len() so korrekt ist. Allerdings sollte IDLE wohl trotzdem nicht abstürzen.
Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...
On 2012-04-21, wb wrote:
nachdem ich noch etwas über surrogate pairs usw. nachgelesen habe, kann ich wohl davon ausgehen, dass das Verhalten von len() so korrekt ist. Allerdings sollte IDLE wohl trotzdem nicht abstürzen.
Das stimmt allerdings.
Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...
Das heißt, dass dann nicht jedes Unicodezeichen intern abgespeichert werden kann, also nicht nur nicht dargestellt werden kann. Und das kann sehr gut der Grund für dieses Fehlverhalten sein.
Du solltest entweder einen Wideunicode-Build, also mit 32-Bit Zeichen testen, oder auf Python 3.3 wechseln, welches es aber leider erst in einer Alpha-Version gibt. Aber dort wird grundsätzlich jedes Unicodezeichen unterstützt und es gibt auch keine Unterscheidung in wide- (32-Bit) und narrow (16 Bit) Builds mehr. Stattdessen wird automatische zur Laufzeit für jeden String die speicherplatzeffizienteste Methode (8, 16 oder 32 Bit) gewählt. Von letzterem wirst Du als Programmierer aber nichts bemerken. Nach außen verhält sich alles genau wie ein 32-Bit wide-build, nur dass es deutlich weniger Speicher benötigt.
Bernd
Hallöchen!
Bernd Nawothnig schreibt:
[...]
[...] oder auf Python 3.3 wechseln, welches es aber leider erst in einer Alpha-Version gibt. Aber dort wird grundsätzlich jedes Unicodezeichen unterstützt und es gibt auch keine Unterscheidung in wide- (32-Bit) und narrow (16 Bit) Builds mehr. Stattdessen wird automatische zur Laufzeit für jeden String die speicherplatzeffizienteste Methode (8, 16 oder 32 Bit) gewählt. Von letzterem wirst Du als Programmierer aber nichts bemerken. Nach außen verhält sich alles genau wie ein 32-Bit wide-build, nur dass es deutlich weniger Speicher benötigt.
Wow, klingt sehr gut. Damit hat man weiteres Kanonenfutter für die UTF-8-vs-UCS-irgendwas-Diskussionen mit Perl-, Lua- und PHP-Freunden.
Tschö, Torsten.
On 2012-04-21, Torsten Bronger wrote:
[...] oder auf Python 3.3 wechseln, welches es aber leider erst in einer Alpha-Version gibt. Aber dort wird grundsätzlich jedes Unicodezeichen unterstützt und es gibt auch keine Unterscheidung in wide- (32-Bit) und narrow (16 Bit) Builds mehr. Stattdessen wird automatische zur Laufzeit für jeden String die speicherplatzeffizienteste Methode (8, 16 oder 32 Bit) gewählt. Von letzterem wirst Du als Programmierer aber nichts bemerken. Nach außen verhält sich alles genau wie ein 32-Bit wide-build, nur dass es deutlich weniger Speicher benötigt.
Wow, klingt sehr gut. Damit hat man weiteres Kanonenfutter für die UTF-8-vs-UCS-irgendwas-Diskussionen mit Perl-, Lua- und PHP-Freunden.
Das ist für mich *das* neue Feature in Python 3.3. Interessant auch, dass die Laufzeitkosten erstaunlich moderat, eigentlich vernachlässigbar sind. Man gewinnt dadurch nur. Lediglich wird der Laufzeitinterpreter so natürlich ein wenig komplexer, aber ich denke, das ist es Wert.
Und es ist made in Germany - bedank Dich bei Martin von Löwis :-)
Gibt es solch einen Ansatz eigentlich schon in einer anderen Programmiersprache?
Bernd
Bernd Nawothnig schrieb:
On 2012-04-21, Torsten Bronger wrote:
[...] oder auf Python 3.3 wechseln, welches es aber leider erst in einer Alpha-Version gibt. Aber dort wird grundsätzlich jedes Unicodezeichen unterstützt und es gibt auch keine Unterscheidung in wide- (32-Bit) und narrow (16 Bit) Builds mehr. Stattdessen wird automatische zur Laufzeit für jeden String die speicherplatzeffizienteste Methode (8, 16 oder 32 Bit) gewählt. Von letzterem wirst Du als Programmierer aber nichts bemerken. Nach außen verhält sich alles genau wie ein 32-Bit wide-build, nur dass es deutlich weniger Speicher benötigt.
Wow, klingt sehr gut. Damit hat man weiteres Kanonenfutter für die UTF-8-vs-UCS-irgendwas-Diskussionen mit Perl-, Lua- und PHP-Freunden.
Das ist für mich *das* neue Feature in Python 3.3. Interessant auch, dass die Laufzeitkosten erstaunlich moderat, eigentlich vernachlässigbar sind. Man gewinnt dadurch nur. Lediglich wird der Laufzeitinterpreter so natürlich ein wenig komplexer, aber ich denke, das ist es Wert.
Und es ist made in Germany - bedank Dich bei Martin von Löwis :-)
$ hg log -k "PEP 393" -b default --template "{author}\n" | sort | uniq Antoine Pitrou solipsis@pitrou.net Ezio Melotti ezio.melotti@gmail.com Georg Brandl georg@python.org Martin v. Löwis martin@v.loewis.de Victor Stinner victor.stinner@haypocalc.com Éric Araujo merwok@netwok.org
"made in Germany" trifft es da wohl nicht so ganz.
Markus
Markus Zapke-Gründemann, 21.04.2012 14:34:
Bernd Nawothnig schrieb:
On 2012-04-21, Torsten Bronger wrote:
[...] oder auf Python 3.3 wechseln, welches es aber leider erst in einer Alpha-Version gibt. Aber dort wird grundsätzlich jedes Unicodezeichen unterstützt und es gibt auch keine Unterscheidung in wide- (32-Bit) und narrow (16 Bit) Builds mehr. Stattdessen wird automatische zur Laufzeit für jeden String die speicherplatzeffizienteste Methode (8, 16 oder 32 Bit) gewählt. Von letzterem wirst Du als Programmierer aber nichts bemerken. Nach außen verhält sich alles genau wie ein 32-Bit wide-build, nur dass es deutlich weniger Speicher benötigt.
Wow, klingt sehr gut. Damit hat man weiteres Kanonenfutter für die UTF-8-vs-UCS-irgendwas-Diskussionen mit Perl-, Lua- und PHP-Freunden.
Das ist für mich *das* neue Feature in Python 3.3. Interessant auch, dass die Laufzeitkosten erstaunlich moderat, eigentlich vernachlässigbar sind. Man gewinnt dadurch nur. Lediglich wird der Laufzeitinterpreter so natürlich ein wenig komplexer, aber ich denke, das ist es Wert.
Und es ist made in Germany - bedank Dich bei Martin von Löwis :-)
$ hg log -k "PEP 393" -b default --template "{author}\n" | sort | uniq Antoine Pitrou solipsis@pitrou.net Ezio Melotti ezio.melotti@gmail.com Georg Brandl georg@python.org Martin v. Löwis martin@v.loewis.de Victor Stinner victor.stinner@haypocalc.com Éric Araujo merwok@netwok.org
"made in Germany" trifft es da wohl nicht so ganz.
Na ja, immerhin ein gutes Drittel der Autoren und auch ein knappes Drittel der (leicht auffindbaren) Commits. Und das (initiale) Design ist von Martin, wenn auch wohl der Löwenanteil (oder nicht-Löwis-Anteil?) der Implementierung von Thorsten Becker stammt (GSoC 2011).
Aber ansonsten hast du natürlich Recht, in einen PEP sind immer auch etliche andere Meinungen und Anmerkungen eingeflossen. Von Victor Stinner stammt zum Beispiel die Idee, die Objektstruktur reiner ASCII-Strings so zu spezialisieren, dass sie noch weniger Speicher benötigen als anfangs geplant. Also wirklich eher ein Gemeinschaftswerk, wie es sich für Open-Source Software gehört.
Stefan
Und es ist made in Germany - bedank Dich bei Martin von Löwis :-)
Gibt es solch einen Ansatz eigentlich schon in einer anderen Programmiersprache?
In der Form ist mir nichts anderes bekannt; ich halte es also schon für meine Idee (und den Start der Implementierung kommt von Torsten Beckers GSoC-Projekt).
Vom Speicherbedarf ist Python damit ungefähr gleichauf mit Perl, was standardmäßig UTF-8 als Unicode-Repräsentation benutzt. "Ungefähr" heißt: In manchen Fällen (z.B. Latin-1, deutsche Umlaute usw.) braucht Python weniger; in anderen Fällen (viel ASCII mit ein paar nicht-Latin-1-Sonderzeichen) braucht Perl weniger (weil im Python-String dann alle Zeichen auf 2 Byte ausgedehnt werden, wenn ein Zeichen 2 Bytes braucht). Der Vorteil der Python-Repräsentation ist m.E., dass der Indexzugriff in konstanter Zeit passiert (was UTF-8 nicht erlaubt).
Ciao, Martin
Moin,
danke für die Info!
On 2012-04-21, wb wrote:
danke für die Info!
Wobei ich nach einer erhaltenen Mail dazu mein "Made in Germany" noch mal korrigieren wollte. An der Umsetzung waren schon deutlich mehr Personen beteiligt. Also ein reines "Made in Germany" ist das nicht mehr.
Bernd
Bernd Nawothnig wrote:
On 2012-04-21, wb wrote:
Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...
Das heißt, dass dann nicht jedes Unicodezeichen intern abgespeichert werden kann, also nicht nur nicht dargestellt werden kann.
Wie kommst Du auf dies schmale Brett? Man kann mit *jeder* Unicode- Codierung *jedes* Unicode-Zeichen darstellen. Ob UTF-7, UTF-8, UTF-16 oder UTF-32 ist völlig egal. Die Codierung definiert nur die Länge einer Code- Einheit (und im Fall von UTF-16BE vs. UTF-16LE die Bytereihenfolge), nicht aber die Maximallänge einer Codesequenz und somit auch keinen Maximalwert bezüglich des codierbaren Codepunkts.
Am 1. Juni 2012 16:01 schrieb Thomas 'PointedEars' Lahn PointedEars@web.de:
Bernd Nawothnig wrote:
On 2012-04-21, wb wrote:
Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...
Das heißt, dass dann nicht jedes Unicodezeichen intern abgespeichert werden kann, also nicht nur nicht dargestellt werden kann.
Wie kommst Du auf dies schmale Brett? Man kann mit *jeder* Unicode- Codierung *jedes* Unicode-Zeichen darstellen. Ob UTF-7, UTF-8, UTF-16 oder UTF-32 ist völlig egal. Die Codierung definiert nur die Länge einer Code- Einheit (und im Fall von UTF-16BE vs. UTF-16LE die Bytereihenfolge), nicht aber die Maximallänge einer Codesequenz und somit auch keinen Maximalwert bezüglich des codierbaren Codepunkts.
UCS 2 kann nur und ausschließlich Zeichen aus der BMP kodieren. Code-Points außerhalb der BMP lassen sich in UCS 2 nicht darstellen. Mithin kann auch ein UCS-2-Build von CPython nur und ausschließlich Zeichen aus der BMP in Zeichenketten verarbeiten.
On Fri, 1 Jun 2012 16:17:33 +0200 Sebastian Wiesner lunaryorn@googlemail.com wrote:
Am 1. Juni 2012 16:01 schrieb Thomas 'PointedEars' Lahn PointedEars@web.de:
Bernd Nawothnig wrote:
On 2012-04-21, wb wrote:
Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...
Das heißt, dass dann nicht jedes Unicodezeichen intern abgespeichert werden kann, also nicht nur nicht dargestellt werden kann.
Wie kommst Du auf dies schmale Brett? Man kann mit *jeder* Unicode- Codierung *jedes* Unicode-Zeichen darstellen. Ob UTF-7, UTF-8, UTF-16 oder UTF-32 ist völlig egal. Die Codierung definiert nur die Länge einer Code- Einheit (und im Fall von UTF-16BE vs. UTF-16LE die Bytereihenfolge), nicht aber die Maximallänge einer Codesequenz und somit auch keinen Maximalwert bezüglich des codierbaren Codepunkts.
UCS 2 kann nur und ausschließlich Zeichen aus der BMP kodieren. Code-Points außerhalb der BMP lassen sich in UCS 2 nicht darstellen. Mithin kann auch ein UCS-2-Build von CPython nur und ausschließlich Zeichen aus der BMP in Zeichenketten verarbeiten.
Zu beachten ist dass ab Python 3.3 diese ganze Unterscheidung wegfällt weil PEP 393 einige Veränderungen mit sich bringt. So wie früher unter Windows Python üblicherweise ein UCS-2 Build war verhält es sich nun wie ein UCS-4 Build (wie es in den meisten Linux-Distributionen schon seit langem üblich ist). Siehe What's New In Python 3.3[1].
grüße, Marek
Thomas 'PointedEars' Lahn wrote:
Bernd Nawothnig wrote:
On 2012-04-21, wb wrote:
Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...
Es ist dann ein UCS-2-Build:
--enable-unicode[=ucs[24]] Enable Unicode strings (default is ucs2)
Das heißt, dass dann nicht jedes Unicodezeichen intern abgespeichert werden kann, also nicht nur nicht dargestellt werden kann.
Wie kommst Du auf dies schmale Brett?
Ist sys.maxunicode nicht die max. Anzahl der Unicode Code Points?
So richtig verstehe ich das hier nicht: What is the difference between UCS-2 and UTF-16? http://unicode.org/faq/basic_q.html#14
"[..] Sometimes in the past an implementation has been labeled "UCS-2" to indicate that it does not support supplementary characters and doesn't interpret pairs of surrogate code points as characters. Such an implementation would not handle processing of character properties, code point boundaries, collation, etc. for supplementary characters."
Ciao, Michael.
Michael Ströder wrote:
Thomas 'PointedEars' Lahn wrote:
Bernd Nawothnig wrote:
On 2012-04-21, wb wrote:
Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...
Es ist dann ein UCS-2-Build:
--enable-unicode[=ucs[24]]beinahe Enable Unicode strings (default is ucs2)
ACK, das ergibt Sinn.
Das heißt, dass dann nicht jedes Unicodezeichen intern abgespeichert werden kann, also nicht nur nicht dargestellt werden kann.
Wie kommst Du auf dies schmale Brett?
Ist sys.maxunicode nicht die max. Anzahl der Unicode Code Points?
Es ist "An integer giving the largest supported code point for a Unicode character." [1], was fast auf dasselbe hinausläuft (die max. Anzahl der dann möglichen Codepunkte ist genau 1 mehr, denn U+0000 wird darin eingeschlossen).
Das hat aber mit der Zeichencodierung UTF-16 nichts zu tun. Die Bezeichnung "UTF-16 build" ist daher fhcsal. Man könnte es eben höchstens (veraltet) als "UCS-2-Build" bezeichnen, weil UCS-2 eben jene Einschränkungen mit sich brachte, die der Unicode-2.0+-Zeichensatz und UTF-16 nicht mehr haben (AIUI, CMIIW):
So richtig verstehe ich das hier nicht: What is the difference between UCS-2 and UTF-16? http://unicode.org/faq/basic_q.html#14
"[..] Sometimes in the past an implementation has been labeled "UCS-2" to indicate that it does not support supplementary characters and doesn't interpret pairs of surrogate code points as characters. Such an implementation would not handle processing of character properties, code point boundaries, collation, etc. for supplementary characters."
UCS-2 steht für Universal Character Set-2, eine 2-Byte Codierung für einen Zeichensatz gleichen Namens aus ingesamt *genau* 65536 möglichen Zeichen. Das heisst, eine Codesequenz für die Darstellung eines Zeichens besteht aus *genau* *einer* Code-Einheit von 16 Bit Länge (damit lassen sich genau 65536 verschiedene Zustände darstellen). Bevor das Unicode Consortium im Jahr 1996 "The Unicode Standard" 2.0 (mit "surrogate pairs") und darin unter anderem auch die dazugehörige Codierung UTF-16 entwickelte [2a], gab es bereits per ISO/IEC 10646-1:1993 UCS-2 als Standard für die Codierung (mehr oder weniger) aller Zeichen der (inzwischen so genannten) Basic Multilingual Plane (BMP; U+0000 bis U+FFFF [2b]) und nur genau dieser Zeichen. [2c]
Mit UTF-16 werden hingegen Zeichen des *erweiterbaren* Unicode 2.0+- Zeichensatzes [3] codiert (ggf. als Kombination von Zeichen mit verschiedenen Codepunkten). Diese Codierung hat gegenüber der für UCS-2 verwendeten den Vorteil, dass auch Zeichen jenseits der BMP (die in Unicode standardisiert sind) dargestellt werden können. Dazu wird eine zweite Code- Einheit – von ebenfalls 16 Bit Länge – vorangestellt, die angibt, dass die erste und nachfolgende zu einer Codesequenz gehören, d. h. *gemeinsam* den Codepunkt für eine solches Zeichen beschreiben. [4] Die Implementierung muss dies aber unterstützen, sonst kommt Zeichensalat heraus.
Andere in Unicode 2.0+ definierte Codierungen, wie etwa UTF-8, haben gegenüber UCS-2 und UTF-16 wiederum den Vorteil, dass für die Darstellung von Zeichen mit niedrigeren Codepunkten ggf. nur 1 Code-Einheit, d. h. bei UTF-8 also 8 Bit, erforderlich ist. Die Datei wird bei gleichem Informationsgehalt also tendenziell kleiner. Dies trifft für alle Zeichen zu, die auch mit US-ASCII codiert werden konnten/können (U+0000 bis U+007F). [5]
Gleichzeitig kann man aber mit Surrogatcodes (spezielle Ersatzcodes in einer Codesequenz, deren Wert allein einen mit keinem Zeichen belegten Codepunkt und somit auch kein Zeichen beschreibt) aber auch Zeichen jenseits der BMP (ab U+10000) darstellen und ist somit maximal flexibel (entsprechende Schriftarten zur Anzeige von Glyphen jenseits der BMP, wie etwa antike Schriften – Linear B [6], ägyptische Hieroglyphen [7] etc. –, vorausgesetzt).
Einen sehr guten Einblick, wie Unicode funktioniert, erhält man mit den Unicode-Tools von Richard Ishida (W3C, Unicode Editorial Committee) [8a], angefangen mit dem Unicode Code Converter [8b]. Beispielsweise lohnt es sich bereits, etwa ein "ä" in "Mixed input" einzugeben, die "Convert"- Schaltfläche zu aktivieren und sich die Darstellung dieses Zeichens in den verschiedenen Codierungen anzusehen. UniView [8c] bietet dann eine grafische Darstellung der Zeichen und einen Überblick über die Bereiche des Zeichensatzes. (Für Letzteres ebenfalls gut geeignet sind auch die Linux- Programme gucharmap [9a] und KCharSelect [9b], wobei ich ersteres bevorzuge.)
______ [1] http://docs.python.org/library/sys.html#sys.maxunicode [2a] http://en.wikipedia.org/wiki/Unicode#Versions [2b] http://en.wikipedia.org/wiki/Basic_Multilingual_Plane [2c] http://en.wikipedia.org/wiki/UCS-2 [3] http://www.unicode.org/faq/basic_q.html#1 [4] http://www.unicode.org/faq/basic_q.html#13 [5] http://www.unicode.org/faq/utf_bom.html [6] http://rishida.net/scripts/uniview/?codepoints=10000 [7] http://rishida.net/scripts/uniview/?codepoints=13142 [8a] http://www.rishida.net/ [8b] http://www.rishida.net/tools/conversion/ [8c] http://rishida.net/scripts/uniview/ [9a] https://live.gnome.org/Gucharmap [9b] http://utils.kde.org/projects/kcharselect/
Thomas 'PointedEars' Lahn wrote:
Michael Ströder wrote:
Thomas 'PointedEars' Lahn wrote:
Bernd Nawothnig wrote:
On 2012-04-21, wb wrote:
Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...
Es ist dann ein UCS-2-Build:
--enable-unicode[=ucs[24]]beinahe Enable Unicode strings (default is ucs2)
ACK, das ergibt Sinn.
Das heißt, dass dann nicht jedes Unicodezeichen intern abgespeichert werden kann, also nicht nur nicht dargestellt werden kann.
Wie kommst Du auf dies schmale Brett?
Ist sys.maxunicode nicht die max. Anzahl der Unicode Code Points?
Es ist "An integer giving the largest supported code point for a Unicode character." [1], was fast auf dasselbe hinausläuft (die max. Anzahl der dann möglichen Codepunkte ist genau 1 mehr, denn U+0000 wird darin eingeschlossen).
Also hatte Bernd durchaus recht mit der Vermutung, dass bei der betreffenden Python-Installation nicht alle Unicode-Zeichen intern verarbeitet werden können, auch wenn er sich vielleicht bzgl. Unicode-Begrifflichkeiten ungeschickt ausgedrückt haben mag.
Ciao, Michael.
Michael Ströder, 01.06.2012 21:30:
Thomas 'PointedEars' Lahn wrote:
Michael Ströder wrote:
Thomas 'PointedEars' Lahn wrote:
Bernd Nawothnig wrote:
On 2012-04-21, wb wrote:
Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...
Es ist dann ein UCS-2-Build:
--enable-unicode[=ucs[24]]beinahe Enable Unicode strings (default is ucs2)
ACK, das ergibt Sinn.
Das heißt, dass dann nicht jedes Unicodezeichen intern abgespeichert werden kann, also nicht nur nicht dargestellt werden kann.
Wie kommst Du auf dies schmale Brett?
Ist sys.maxunicode nicht die max. Anzahl der Unicode Code Points?
Es ist "An integer giving the largest supported code point for a Unicode character." [1], was fast auf dasselbe hinausläuft (die max. Anzahl der dann möglichen Codepunkte ist genau 1 mehr, denn U+0000 wird darin eingeschlossen).
Also hatte Bernd durchaus recht mit der Vermutung, dass bei der betreffenden Python-Installation nicht alle Unicode-Zeichen intern verarbeitet werden können, auch wenn er sich vielleicht bzgl. Unicode-Begrifflichkeiten ungeschickt ausgedrückt haben mag.
Doch, es können alle verarbeitet werden. Schau mal unter "surrogate pairs" nach. Das ist die Hilfskodierung für Zeichen außerhalb der BMP, mit der diese Zeichen gespeichert werden können.
Surrogate pairs sind auch der Grund, weshalb manche Ein-Zeichen Strings in "UCS-2" Builds die Länge 2 haben, nämlich genau die, die nicht in der BMP enthalten sind. CPython macht intern einige Klimmzüge, um diese Zeichen trotzdem korrekt zu verarbeiten, z.B. wenn es um das Einordnen dieser Zeichen in Zeichengruppen geht (Buchstaben, Ziffern, ...).
Stefan
Michael Ströder wrote:
Thomas 'PointedEars' Lahn wrote:
Michael Ströder wrote:
Thomas 'PointedEars' Lahn wrote:
Bernd Nawothnig wrote:
On 2012-04-21, wb wrote:
Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...
Es ist dann ein UCS-2-Build:
--enable-unicode[=ucs[24]]beinahe Enable Unicode strings (default is ucs2)
ACK, das ergibt Sinn.
Das heißt, dass dann nicht jedes Unicodezeichen intern abgespeichert werden kann, also nicht nur nicht dargestellt werden kann.
Wie kommst Du auf dies schmale Brett?
Ist sys.maxunicode nicht die max. Anzahl der Unicode Code Points?
Es ist "An integer giving the largest supported code point for a Unicode character." [1], was fast auf dasselbe hinausläuft (die max. Anzahl der dann möglichen Codepunkte ist genau 1 mehr, denn U+0000 wird darin eingeschlossen).
Also hatte Bernd durchaus recht mit der Vermutung, dass bei der betreffenden Python-Installation nicht alle Unicode-Zeichen intern verarbeitet werden können, auch wenn er sich vielleicht bzgl. Unicode-Begrifflichkeiten ungeschickt ausgedrückt haben mag.
Möglicherweise. Da eine Codesequenz mit Surrogat-Codepunkten für Zeichen *jenseits* der BMP auch nur aus den Codes von zwei oder mehr Codepunkten *innerhalb* der BMP besteht, kann man das auch anders interpretieren.
Ich frage mich allerdings, wo er den flcsahlen Begriff "UTF-16 build" dafür überhaupt her hat. Aus der Python-Dokumentation offensichtlich nicht, und aus der python-Hilfe offensichtlich auch nicht. Udiags.
participants (10)
-
Bernd Nawothnig -
Marek Kubica -
Markus Zapke-Gründemann -
martin＠v.loewis.de -
Michael Ströder -
Sebastian Wiesner -
Stefan Behnel -
Thomas 'PointedEars' Lahn -
Torsten Bronger -
wb