Mailman 3 - python-de

Fwd: Codepage-Methode vs. UTF8
by Erich Schnoor Aug. 17, 2024

Aug. 17, 2024

Hallo, Herr Büchel, eine schriftliche Zusammenfassung der Codepage-Methode ist noch in Arbeit. Hier die Grundlagen für neue Erkenntnisse: _____________________________ _______________________________ "Seit Einführung der Unicode-Tabelle ist die Zeichencodierung (codepage, charset) der wichtigste Schritt in der Informatik. Die Codierung geschieht grundsätzlich nach den Regeln des Unicode Transformation Formats (UTF). Die Zeichen werden mit ihrem <point> in Bytes aufgerufen [#1]. Die gesamte Unicode-Tabelle stellt eine einheitliche Codepage dar. Diese Erkenntnis ist jedoch neu. Für eine Codepage sind zwei Merkmale erforderlich: „skalierbarer Sachverhalt“ „sachbezogenes Ordnungssystem“ Für das gesamte Unicode-Verfahren sind diese Voraussetzungen erfüllt. Die Zeichen aller Sprachen sind in einer skalierbaren Reihenfolge geordnet und werden in einem sachgerechten Ordnungssystem aufgerufen (Zahlensysteme zur Basis 10, 16). Allerdings gilt das nur für definierte Codeages und die dort erfassten Unicode-Zeichen ((z.B: ‎ISO/IEC 8859-1/www. cscvt.de). n diesem Bereich zeigt die Informatik eine essenzielle Lücke: Zahlensysteme oberhalb der Basis 16 und darauf aufbauende Schritte werden bisher nicht benutzt. Das Zahlensystem zur Basis 4096 ist von besonderer Bedeutung. Es bildet die Grundlage für eine neue Zeichenkodierung mit einem String von 4096 Zeichen: Zahlenstring: 123456789Abcdefghijklmno . . . . . . . . . .. . . . . . . . . . . . . .ꮌꮍꮎꮏꮐꮑꮒꮓꮔꮕꮖꮗꮘꮙꮚꮛꮜ Die Zeichen des Strings als<index>Ziffern ersetzen die bisherigen <point>Zahlen. Für die Kodierung von Unicode-Zeichen sind nur 1 oder 2 Byte (16 bit) erforderlich. Von <point>256 bis <point>65535 genügen zweistellige <index>Ziffern. Mit 3 Bytes (24 bit) werden die <points> von 65536 bis 16777215 angesprochen. Die Position der Ziffer im String stellt ihren <index> Wert dar. Die Kodierung führt zu identischen Binärziffern wie <point>Zahlen.” _____________________________________________________________ > Anfang der weitergeleiteten Nachricht: > > Von: Wolfgang J. Büchel <wjb131(a)web.de> > Betreff: Aw: [Python-de] Codepage-Methode vs. UTF8 > Datum: 17. August 2024 um 18:06:22 MESZ > An: Erich Schnoor <eschnoor(a)multi-matrix.de> > > Hallo Herr Schnoor, > > wie geht denn das CPM-Verfahren? Gibt es darüber eine gute Darstellung? > > mfg > W. Büchel > > > Am 17.08.24 um 14:19 schrieb Erich Schnoor über python-de: >> Hallo, sehr geehrter Herr Büchel, >> >> Sie schreiben: >> >>> Da wird lediglich jede Indexzahl in eine äquivalente Dezimalzahl unmgewandelt. >>> >>> Dies zeigt auch der mir zugesandte Programmcode der Datei Zahlensysteme.py: >>> >> Das ist ja wohl auch die Aufgabe eines jeden Zahlensystems ! >> Nur eines wird mir hier klar: Sie argumentieren offensichtlich ausschließlich >> im bekannten “UTF-8”-Verfahren, während ich versuche, den im neu entdeckten >> Informatik-Bereich - . hier mit “CPM”-Verfahren bezeichnet - zu arbeiten. >> Dazu würde ich gern Ihre Meinung erfahren? >> >> Mit freundlichen Grüßen >> Erich Schnoor >> >> >> _______________________________________________ >> python-de Mailingliste -- python-de(a)python.org <mailto:python-de@python.org> >> Zur Abmeldung von dieser Mailingliste senden Sie eine Nachricht an python-de-leave(a)python.org <mailto:python-de-leave@python.org> >> https://mail.python.org/mailman3/lists/python-de.python.org/ >> Mitgliedsadresse: wjb131(a)web.de <mailto:wjb131@web.de> >

1 0

Codepage-Methode vs. UTF8
by Erich Schnoor Aug. 17, 2024

Aug. 17, 2024

Hallo, sehr geehrter Herr Büchel, Sie schreiben: > Da wird lediglich jede Indexzahl in eine äquivalente Dezimalzahl unmgewandelt. > > Dies zeigt auch der mir zugesandte Programmcode der Datei Zahlensysteme.py: > Das ist ja wohl auch die Aufgabe eines jeden Zahlensystems ! Nur eines wird mir hier klar: Sie argumentieren offensichtlich ausschließlich im bekannten “UTF-8”-Verfahren, während ich versuche, den im neu entdeckten Informatik-Bereich - . hier mit “CPM”-Verfahren bezeichnet - zu arbeiten. Dazu würde ich gern Ihre Meinung erfahren? Mit freundlichen Grüßen Erich Schnoor

1 0

Codepage-Methode vs. UTF8
by Wolli Buechel Aug. 17, 2024

Aug. 17, 2024

Hallo Herr Schnoor, > hier komnmt der Code: > if modus == "x": > ziffer = input(" insert <index>number > ") > point = nachdez(basis,ziffer) > point = int(point) > zeichen = chr(point) > digit = nachsys(2,point) > print(" Digit: ",digit) > print() > print(" sign: ",zeichen) > print(" point: ",point ) > print(" binär: ",digit) > lg = len(digit) > print(" bit: ",lg) den habe ich etwas verbessert: def decodeIndex(index, ziffern): """ index : ein Zahlzeichen (aus beliebig vielen Ziffern) des Positionssystems zur Basis b = len(ziffern) Voreinstellung: b = 4096 ziffern : Ziffernstring (aus UTF8-Zeichen) zur Notation von Zahlzeichen dieses Positionsystems index codiert die dezimale Ordnungsnummer point = ord(ch) eines UTF8-Zeichens ch also index = nachsys(basis, point, ziffern) zulässige Werte für index: index < nachsys(basis, 2**24-1, ziffern) """ MaxUTF8 = 1114111 point = nachdez(basis, index, ziffern) # point = ord(ch) eines UTF8-Zeichens ch digit = nachsys(2, point, ziffern) # point = ord(ch) als Dualzahl print("\nIndex: %s" % index) print(" Dual: ", digit) print(" point: ", point ) # print(" binär: ", digit) # irreführende Bezeichnung: dual != binär # siehe: https://www.danisch.de/blog/2024/07/26/vom-unterschied-zwischen-einem-binae… lg = len(digit) # Anzahl der Dualziffern (0,1) von digit print(" bit: ", lg) # irreführende Bezeichnung: Dualziffer != bit if point > MaxUTF8: print("Fehler: point > %d" % MaxUTF8) print("ValueError: chr() arg not in range(0x110000)") return zeichen = chr(point) # UTF8-Zeichen, ord(zeichen) = point print(" sign: ", zeichen) und damit etwas herumgespielt: for k in range(4, 18, 2): point = 2**(2*k) - 1 index = nachsys(basis, point, ziffern) decodeIndex(index, ziffern) ergibt: Basis : 4096 Index: Ɖ Dual: 11111111 point: 255 bit: 8 sign: ÿ Index: ꓰ Dual: 111111111111 point: 4095 bit: 12 sign: ࿿ Index: Fꓰ Dual: 1111111111111111 point: 65535 bit: 16 sign: Index: Ɖꓰ Dual: 11111111111111111111 point: 1048575 bit: 20 sign: 󿿿 Index: ꓰꓰ Dual: 111111111111111111111111 point: 16777215 bit: 24 Fehler: point > 1114111 ValueError: chr() arg not in range(0x110000) Index: Fꓰꓰ Dual: 1111111111111111111111111111 point: 268435455 bit: 28 Fehler: point > 1114111 ValueError: chr() arg not in range(0x110000) Index: Ɖꓰꓰ Dual: 11111111111111111111111111111111 point: 4294967295 bit: 32 Fehler: point > 1114111 ValueError: chr() arg not in range(0x110000) ------------------------------ Da Sie -- vielleicht wegen des Sommerwetters? -- offensichtlich nur CPM-Codeschnipsel-Gedöns und etwas Python sprechen können, muss ich wohl oder übel meine Frage Muß in einem längeren Indexstring aus einziffrigen (Typ A) und mehrziffrigen (Typ B) 4096-er Systemzahlen zwischen diesen unterschiedlichen Zeichentypen ein Trennzeichen (z.B. Leerzeichen) stehen? selbst beantworten, und zwar mit einem JA. Dies vollkommen analog dem Leerzeichen, um zwischen den drei Zahlen 4711 und 47 11 unterscheiden zu können. Was bedeutet das für den Byte-Gehalt B(N) der beiden Nachrichten, (1) der Original-Nachricht (= N1) eines Textes aus -- clever konzipierten -- UTF8-Zeichen und (2) der zu Index-Zahlen des 4096-er Systems übersetzten Nachricht (= N2) -- "angereichert'' mit Leerzeichen zwecks Zahlzeichentrennung? Ich denke, das bedeutet B(N2) > B(N1). Oder irre ich mich da? W. Büchel

2 3

Codepage-Methode vs. UTF8
by Wolli Buechel Aug. 16, 2024

Aug. 16, 2024

Hallo Herr Schnoor, wie ich zuletzte dargelegt habe, verwendet UTF8 einen "Geheimcode" der Bytes eines Zeichens, mit dem diese Bytes markiert werden als Solo-Bytes oder als zusammengehörige Bytes eines Mehr-Byte-Zeichens. Hier noch mal zur Erinnerung: > In der folgenden Tabelle sind die Intervalle der Ordnungszahlen für 1/2/3/4 Bytes > sowie die geheime Bit-Struktur des Codes dargestellt ( vgl. https://en.wikipedia.org/wiki/UTF-8#Encoding ): > > Code point ↔ UTF-8 conversion > First code point Last code point Byte 1 Byte 2 Byte 3 Byte 4 > U+0000 U+007F 0xxxxxxx > U+0080 U+07FF 110xxxxx 10xxxxxx > U+0800 U+FFFF 1110xxxx 10xxxxxx 10xxxxxx > U+010000 U+10FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx > Dieser Geheimcode ist doch clever gemacht von den Entwicklern der UTF8-Codierung der Unicode-Zeichen, oder? Jetzt meine Frage an sie als Schöpfer der Codepage-Methode (CPM): Wie löst Ihre CPM dieses Problem, ob ein Zeichen in einem Indexstring ein Solo-Zeichen ist oder ob zwei (oder mehr ?) Zeichen zusammengehören als Codierung einer Systemzahl. Ein konkretes Beispiel: Angenommen, der Ziffernstring für das 4096-er System lautet schlicht ziffern = ''.join( [ chr(x) for x in range(1,4097) ] ) und ich habe den Indexstring 'èé '. Das könnten theoretisch zwei einziffrige Zahlzeichen sein oder eine zweiziffrige Systemzahl. Wie löst Ihr CPM-Programm dieses Problem? W. Büchel

2 3

Re: for unpacking
by Patrick Rudin Aug. 16, 2024

Aug. 16, 2024

Stefan Ram wrote: > Patrick schrieb, er sei "auf die Python-Eigenheiten" bei Klassen > "gespannt". Wenn er nun dazu ein genau passendes Beispiel erhält > und dies dann als "nutzlos" bezeichnet, ist dies zwar unpassend > und respektlos, Eigentlich hatte ich Dir für das Beispiel explizit gedankt. Mir scheint, dass Leute, die tief in einer Materie drin sind, oft grosse Mühe haben, gute Beispiele zu bringen, die Anfängern das Ganze verständlich machen. Ich hab hier neulich zig Python-Bücher aus drei Bibliotheken zusammengetragen und war etwas schockiert, wie miserabel das Zeug teilweise noch immer zusammengestümpert sind. Von den Nichtübersetzungen bei deutschsprachigen Versionen ganz zu schweigen. Insofern war das keine Spitze gegen Dich. > aber Patrick sagt ja von sich selber, daß er > Klassen in Python erst noch erlernen will, Welpenschutz im Usenet. Ich fühl mich wieder wie 16... Gruss Patrick

1 0

Re: for unpacking
by Hermann Riemann Aug. 15, 2024

Aug. 15, 2024

Am 14.08.24 um 18:56 schrieb Stefan Ram: > Hermann Riemann <nospam.ng(a)hermann-riemann.de> schrieb oder zitierte: >> Am 14.08.24 um 15:30 schrieb Stefan Ram: >>> oder die Makros >>> den Programmierer dazu verlocken, eine Lösung mit Makros auch dort zu >>> verwenden, wo eine Lösung mit den Mitteln von Python passender wäre. >> Gilt nicht auch das Umgekehrte? > > Mein derzeitiger Web-Platz wird ja von mehreren "verschachtelten" > Präprozessoren erzeugt. Das heißt ein Präprozessor generiert > Makros für den nächsten. Hier ein Beispiel meines Codes: Mein derzeitiges Websytem besteht aus Quelle: 2 Start-Ordner Eins für Dateien , die ich mit grep lesen kann darunter der Ordner src in der alle html und js Quellen stehen eins für andere wie Bilder. Das Ziel sind 5 html provider, die teilweise unterschiedliche Datei Inhalte und Anordnungen haben. php und diverse tools gehen nicht, da diese auf server bei provider laufen. Außerdem mag ich nicht viele Verwaltungsbuchstaben in Quelltexte. Also habe ich die Quelltexte mit einer eigenen Minisprache überlagert. Anfangs verwendete ich « », da diese Zeichen mit AltGr x y auf der Tastatur leicht tippbar sind. Jetzt nehme ich eigene html tags, die mit _ enden. z.B. if_ Und eigene html Parameter die mit $ beginnen. ( </_> zugehörige endtag da </if_> redundant und zu viel Arbeit ist. Einrückung a la Python wäre mir lieber, passt aber nicht zu html ) Hinzu kommt, dass ich internes und externes html habe. Intern brauche ich kein <head> author etc. Trennung geht dann mit <body_> Weniger Tipparbeit und bessere Lesbarkeit. html habe ich von Anfang an aufbereitet. Erst mit Netscape; das war unpassend, da die Seiten danach anders aussahen. Dann mit eigenem C Programm. Danach habe ich es in Python neu geschrieben. Die neueste Version ist eine Mischung aus 767 Zeilen Python und 489 Zeilen C C scannt Dateien byteweise durch und liefert Dateien ( Platz in tmpfs ), die mit Python kommandos=open(name).read().split('\t') eingelesen werden. Die zwischen Dateien können gut lesbar mit Editoren kontrolliert werden. Und die Kommandos sind ( mit Erfahrung aus Compilerbau und LISP ) mit Python gut verwaltbar. -- <http://www.hermann-riemann.de>

1 0

Re: for unpacking
by Patrick Rudin Aug. 14, 2024

Aug. 14, 2024

Stefan Ram wrote: > Als Ausgangspunkt für eigene Experimente: Danke für das Beispiel, aber derzeit ist mir das (insbesondere im Zusammenhang mit threading) zu hoch. Es gibt also keine Systemvariable, die man auslesen kann, um aus einer Instanz heraus eine Methode der vorherigen oder nächsten Instanz aufzurufen? Gruss Patrick

2 2

Re: for unpacking
by Patrick Rudin Aug. 14, 2024

Aug. 14, 2024

Stefan Ram wrote: > # Beispielverwendung > obj1 = MeineKlasse( 1 ) > obj2 = MeineKlasse( 2 ) > obj3 = MeineKlasse( 3 ) Ah, oki, indem man also jeweils den Index bei der Erstellung der Instanz bereits mitgibt. Muss das mal in Ruhe mit eigenem Beispiel ausprobieren, am Wochenende soll ja das Wetter schlecht werden... Gruss Patrick

1 0

Re: for unpacking
by Ralph Aichinger Aug. 14, 2024

Aug. 14, 2024

Stefan Ram <ram(a)zedat.fu-berlin.de> wrote: > (insgesamt mehr als 8000 Zeilen). Da mir das ganze System > mit einer Kette diverser Programme und Präprozessoren als > zu unübersichtlich erscheint, bin ich jetzt dabei alles neu > in Python zu schreiben, und für mich erscheint es portabler und > übersichtlicher nur Python als Programmiersprache zu verwenden! Warum nimmst du nicht einen fertigen Generator für statische Webseiten, z.B. Hugo? https://gohugo.io/ /ralph

1 0

Re: for unpacking
by Hermann Riemann Aug. 14, 2024

Aug. 14, 2024

Am 14.08.24 um 15:30 schrieb Stefan Ram: > Hermann Riemann <nospam.ng(a)hermann-riemann.de> schrieb oder zitierte: >> Am 14.08.24 um 11:21 schrieb Stefan Ram: >>> Python hat ja keinen Präprozessor für bedingte Compilierung >>> jedoch kann man manchmal das normale "if" dafür verwenden! >> Was spricht dagegen, den Präprozessor von C zu nehmen? > > Es könnte sein, daß einzelne Python-Werkzeuge, wie Editoren oder > Debugger, C-Makros nur eingeschränkt unterstützen, C Präprozessor Macros in Python stehen aus Python Sicht in # Kommentare, was keinen Editor ernstlich stören dürfte. > der Code mit den Makros für einzelne Programmierer weniger lesbar ist Das hängt wie bei C vom Programmierstil ab. > oder die Makros > den Programmierer dazu verlocken, eine Lösung mit Makros auch dort zu > verwenden, wo eine Lösung mit den Mitteln von Python passender wäre. Gilt nicht auch das Umgekehrte? Der bisher einzige Grund sehe ich in der fehlerhafte Zeilennummer bei Syntaxfehler, was ich irgendwie per Programm korrigieren müsste. -- <http://www.hermann-riemann.de>

1 0