UTF-8 kyrillisch nach ISO8859-5

[Noob A. (strippenzieher)]

Moin,

ich versuche gerade herauszufinden wie man UTF-8 nach ISO8859 umwandelt 
und habe dazu hier ein super Beispiel gefunden:

Beitrag "UTF-8 nach ISO 8859-1"

Allerdings zielt das auf die Latin1 codepage ab, ich möchte aber 
kyrillische Zeichen konvertieren, also nach ISO8859-5

Das haut mit dem Beispielcode aber nicht hin da das explizit abgefangen 
wird

Ich suche nun schon eine ganze Weile nach Konvertierungen, finde aber 
nur generelle Hinweise beim Webseitenerstellen oder 
Bibliotheksfunktionen wie iconv. Ich hab sogar versucht den Quelltext 
dieser Funktionen zu finden, blicke da aber überhaupt nicht durch.
Siehe: 
https://code.woboq.org/userspace/glibc/iconv/gconv_open.c.html#__gconv_open

Deswegen der Versuch ob mir hier jemand helfen kann wie ich das 
konvertieren kann, oder wo ich die richtigen Infos finden kann...
Jörg W. hatte 2012 ja auch irgendwo Infos für seinen Algorithmus 
gefunden, dann muss es doch was dazu geben???

Grüßle,
Bob

[yesitsme (Gast)]

Hmm...

UTF8 0xD0 0xBE nach Unicode U+043E dann per mapping nach ISO 0xDE


ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-5.TXT

[DPA (Gast)]

In der Shell:

iconv -f utf-8 -t iso-8859-5

Aber wozu? Wir haben 2019, alles ist UTF-8, und das ist auch gut so.

[S. R. (svenska)]

Bob A. schrieb:
> ich versuche gerade herauszufinden wie man UTF-8 nach ISO8859 umwandelt

Der kyrillische Block liegt in Unicode ab U+0400.
Der kytillische Block liegt in ISO8859-1 ab 0xA0.

Ich habe die Reihenfolge nur überflogen, aber du müsstest den Block 
direkt mappen können. Also U+0400 => 0xA0 bis U+045F => 0xFF.

Du musst aber in jedem Fall zuerst dein UTF-8 in Unicode-Codepoints 
decodieren, genau das tut der Code von Jörg (prüft aber auf Gültigkeit 
in latin1, was du nicht willst).

[Noob A. (strippenzieher)]

DPA schrieb:
> In der Shell:
>

> iconv -f utf-8 -t iso-8859-5
>

>
> Aber wozu? Wir haben 2019, alles ist UTF-8, und das ist auch gut so.

wo ist die Shell beim MC68328?
Ja ich weiss, das da auch Linux drauf laufen könnte, tut es aber 
nicht...
Ich soll einem alten System nachträglich kyrillisch beibringen, sowas 
gibt es auch noch in 2019!

[Noob A. (strippenzieher)]

S. R. schrieb:
> Bob A. schrieb:
>> ich versuche gerade herauszufinden wie man UTF-8 nach ISO8859 umwandelt
>
> Der kyrillische Block liegt in Unicode ab U+0400.
> Der kytillische Block liegt in ISO8859-1 ab 0xA0.
>
> Ich habe die Reihenfolge nur überflogen, aber du müsstest den Block
> direkt mappen können. Also U+0400 => 0xA0 bis U+045F => 0xFF.
>
> Du musst aber in jedem Fall zuerst dein UTF-8 in Unicode-Codepoints
> decodieren, genau das tut der Code von Jörg (prüft aber auf Gültigkeit
> in latin1, was du nicht willst).

Danke, das hilft mir weiter!

Ist mir auch vorhin aufgefallen, da gibt es nur einen Offset von 0xB0 zu 
Latin-1 gibt.
Könnt ich abfangen wenn kyrillisch eingestellt ist.
Vielleicht kann man das aber auch von den Start-Bytes ableiten?
Bei Latin scheint das 0xC2 resp. 0xC3 zu sein, cyrillic hat 0xD0 und 
0xD1
mal ein wenig mit den bits jonglieren...

[Noob A. (strippenzieher)]

yesitsme schrieb:
> Hmm...
>
> UTF8 0xD0 0xBE nach Unicode U+043E dann per mapping nach ISO 0xDE
>
>
> ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-5.TXT

Vielen Dank, schau ich mir mal in Ruhe an!

[Stefan F. (Gast)]

Bob A. schrieb:
> wo ist die Shell beim MC68328?

Dann sage doch gleich im Eröffnungsbeitrag worum es geht, nicht in einer 
beschwerde!

[Noob A. (strippenzieher)]

Stefanus F. schrieb:
> Bob A. schrieb:
>> wo ist die Shell beim MC68328?
>
> Dann sage doch gleich im Eröffnungsbeitrag worum es geht, nicht in einer
> beschwerde!

Wir sind doch hier im µC-Forum, oder?

Hätte ich bei PC-Software gefragt wäre das was Anderes.
Ich dachte auch, dass aus der Fragestellung heraus klar wird dass ich 
das "zu Fuss" machen will/muss.

Aber ja, ich hätte da etwas präziser sein können...

[Stefan F. (Gast)]

Bob A. schrieb:
> Ich dachte auch, dass aus der Fragestellung heraus klar wird dass ich
> das "zu Fuss" machen will/muss.

Naja, Unicode ist scheiße kompliziert (wie du bereits bemerkt hast). Das 
würde ich auf Mikrocontrollern höchstens 1:1 durch reichen aber auf 
keinen Fall versuchen zu konvertieren oder gar zu rendern.

Ich hatte angenommen, dass du mit dem PC einen Unicode Text für die 
Verwendung auf einem Mikrocontroller auf 8bit konvertieren wolltest.

[NichtWichtig (Gast)]

Kommt halt auf die Anforderungen an, manchmal hat man keine Wahl.

Aber soo schlimm ist das auch nicht, bischen Bitpopelei, das würde auch 
ein 8-Bitter schaffen.

[W.S. (Gast)]

Bob A. schrieb:
> Wir sind doch hier im µC-Forum, oder?

Ja klar.

War zumindest mir von Anfang an klar - und zwar deshalb, weil ich 
schon vor langem für meine Geräte alle möglichen und unmöglichen 
Sprachen implementieren mußte, damit sich das Zeug besser verkauft als 
die Konkurrenz.

Und je kleiner das Land, desto mehr gucken die Anwender drauf, daß sich 
ihre Sprache einstellen läßt. Die ist wichtiger als etwaige 
Schreibfehler.

Das ganze ergibt aber nur dann einen Sinn, wenn man mit einem grafischen 
LCD am Gerät daherkommt. Sonst ist es albern - mangels Darstellbarkeit.

Also, wie ist das bei dir?
Da kommen vermutlich Font-Probleme auf dich zu.

Ich hatte das dann so gemacht, daß ich mir nur die Zeichen ausgesucht 
hatte, die deutlich von den üblichen lateinischen Zeichen abweichen. Bei 
französisch, polnisch, türkisch, "serbo-kroatisch" (..) sind das nur 
recht wenige Zeichen, zumeist nur ein Kringel drüber/drunter, griechisch 
ist schon ein bissel schlimmer, russisch geht grad so.

Und all die so gesammelten Extrazeichen hatte ich dann in den Bereich ab 
80h verpflanzt - ohne Rücksicht auf irgendwelche Codepages. Diese 
Zeichen lassen sich im Original nämlich ohnehin nicht wirklich in einer 
C-Quelle hinschreiben.

Das Schreiben der Menütexte ist dann allerdings stressig.

W.S.

[Noob A. (strippenzieher)]

W.S. schrieb:
> Also, wie ist das bei dir?

grafisches LCD ist dran, die Fonts kann ich mir generieren. EA hat in 
seinem LCD-Editor ein Tool das Windows Fonts konvertieren kann. Da kann 
ich die Codepage auswählen und erhalte dann eine Text-Datei

Sieht dann so aus:

65  $41  'A'
........
........
........
...##...
...##...
..#..#..
..#..#..
.#....#.
.#....#.
.######.
#......#
#......#
........
........

66  $42  'B'
........
........
........
.####...
.#...#..
.#...#..
.#...#..
.#####..
.#....#.
.#....#.
.#....#.
.#####..
........
........

67  $43  'C'
.........
.........
.........
...####..
..#....#.
.#.......
.#.......
.#.......
.#.......
.#.......
..#....#.
...####..
.........
.........

Speicherplatz ist kein Problem, die Fonts liegen halt alle doppelt 
vor...

[S. R. (svenska)]

Bob A. schrieb:
> Vielleicht kann man das aber auch von den Start-Bytes ableiten?
> Bei Latin scheint das 0xC2 resp. 0xC3 zu sein, cyrillic hat 0xD0
> und 0xD1

Ich würde schlicht die gesamte Eingabe immer decodieren. Heuristiken 
dafür sind doof. Wenn der Decoder wegen ungültigem UTF-8 (oder 
unbekannten Codepoints) abbricht, kannst du den Fallback da einbringen.

Intern kannst du entweder komplett mit den Unicode-Codepoints 
weiterarbeiten, oder in der entsprechenden Codepage (musst du aber 
mitführen). Hängt von deinem System ab, wie schwierig das wird.

Interessant wird der Umgang mit Eingaben, die kyrillisch und Umlaute 
enthalten. Das kann bei Namen leicht passieren ("Eго зовут Müller.")

Stefanus F. schrieb:
> Naja, Unicode ist scheiße kompliziert (wie du bereits bemerkt hast). Das
> würde ich auf Mikrocontrollern höchstens 1:1 durch reichen aber auf
> keinen Fall versuchen zu konvertieren oder gar zu rendern.

Nicht unbedingt. UTF-8 zu decodieren ist nicht schwer, Buchstaben zu 
rendern auch nicht. Wenn man natürlich Sprachen wie Arabisch, 
Burmesisch, Äthiopisch (mit verschiedenen oder wechselnden 
Schreibrichtungen) braucht, die neuesten Emoji in allen Hautfarben 
unterstützen will und auch bei zusammengesetzten Zeichen noch rückwärts 
suchen können will, dann wird's tatsächlich schnell eklig.

Aber für ein "wir wollen jetzt auch noch den russischen Markt bedienen" 
ist das nicht komplizierter als eine beliebige andere Codepage. Selbst 
Isländisch und Vietnamesisch lassen sich da noch einfach einbinden.

W.S. schrieb:
> Da kommen vermutlich Font-Probleme auf dich zu.

Das sind eher Kleinigkeiten in der Implementierung.
Nervig, aber nicht wirklich problematisch.

Wenn das Projekt langfristig auf Unicode wanden sollte, würde ich da 
einzelne Fontblöcke mit Mapping anlegen (U+0000..U+007F, U+0080..U+00FF, 
U+0400..U+045F), andernfalls einfach einen Font pro Codepage. Eigene 
Codepages definieren finde ich schwachsinnig, wenn man nicht gerade mit 
jedem Byte haushalten muss.

[yesitsme (Gast)]

S. R. schrieb:
> dann wird's tatsächlich schnell eklig.

Unterschiedliche normalisierungen gibts dann ja auch noch...

https://de.wikipedia.org/wiki/Normalisierung_(Unicode):
>> Der Buchstabe Ä existiert als eigenes Zeichen U+00C4, kann aber auch als Folge 
von U+0041 U+0308 kodiert werden.

[Jemand (Gast)]

S. R. schrieb:
> Nicht unbedingt. UTF-8 zu decodieren ist nicht schwer, Buchstaben zu
> rendern auch nicht. Wenn man natürlich Sprachen wie Arabisch,
> Burmesisch, Äthiopisch (mit verschiedenen oder wechselnden
> Schreibrichtungen) braucht, die neuesten Emoji in allen Hautfarben
> unterstützen will und auch bei zusammengesetzten Zeichen noch rückwärts
> suchen können will, dann wird's tatsächlich schnell eklig.

Firefox bekommt nicht mal Deutsch völlig fehlerfrei hin.

[yesitsme (Gast)]

Jemand schrieb:
> Firefox bekommt nicht mal Deutsch völlig fehlerfrei hin.

Hast du mal ein Beispiel?

[Jemand (Gast)]

yesitsme schrieb:
> Jemand schrieb:
>> Firefox bekommt nicht mal Deutsch völlig fehlerfrei hin.
>
> Hast du mal ein Beispiel?

Die Textsuche geht nicht ordentlich mit den verschiedenen 
Normalisierungsformen um, z. B. kann 'ö' nicht mit 'ö' gefunden werden 
und umgekehrt.

Dann gibt es noch speziell Probleme mit der kombinierten Form:
PdfLaTeX erzeugt diese beispielsweise, kopiere ich einen so geformten 
Umlaut aus der PDF je mit Firefox' PDF-Anzeige und Okular als Vergleich, 
erhalte ich andere Codesequenzen, ich glaube die von Firefox' ist sogar 
völlig falsch. Jedenfalls wird das Ergebnis, eingefügt verschiedenen 
Textfeldern, unterschiedlich dargestellt (auch unterschiedlich falsch), 
abhängig von der Konstellation der Planeten oder so.

Das im Bild ist der Text "ö ö ̈o" im DuckDuckGo-Suchfeld.

[Jemand (Gast)]

Jemand schrieb:
> Das im Bild ist der Text "ö ö ̈o" im DuckDuckGo-Suchfeld.

Falschen Buchstaben genommen, aber es gilt entsprechend ;p

[W.S. (Gast)]

Bob A. schrieb:
> EA hat in
> seinem LCD-Editor ein Tool das Windows Fonts konvertieren kann. Da kann
> ich die Codepage auswählen und erhalte dann eine Text-Datei
>
> Sieht dann so aus:
> ....

O ha, das kenne ich doch irgendwie.

Siehe:

Ch_41:   { "A" }
   ................
   ......MMM.......
   ......MMMM......
   .....MMMMM......
   .....MMMMM......
   .....M..MMM.....
   ....MM..MMM.....
   ....M....MMM....
   ...MM....MMM....
   ...MM....MMM....
   ..MMMMMMMMMMM...
   ..MM......MMM...
   ..M........MMM..
   .MM........MMM..
   .MM........MMM..
   MM..........MMM.
-- ................
   ................
   ................
   ................
;

Das ist Lucida20 von meinem steinalten Fontcompiler.



S. R. schrieb:
> Das sind eher Kleinigkeiten in der Implementierung.

Hä? Das sind wesentliche Probleme, denn Fonts schlucken eigentlich 
immer ne Menge Platz im immer zu knappen Flash. Soweit ich das vestanden 
habe, hat der Bob ein älteres System mit nem MC68328 vor der Nase. Da 
wird er wohl seine noch freien Bytes einzeln zählen müssen.

W.S.

[Noob A. (strippenzieher)]

W.S. schrieb:
>
> S. R. schrieb:
>> Das sind eher Kleinigkeiten in der Implementierung.
>
> Hä? Das sind wesentliche Probleme, denn Fonts schlucken eigentlich
> immer ne Menge Platz im immer zu knappen Flash. Soweit ich das verstanden
> habe, hat der Bob ein älteres System mit nem MC68328 vor der Nase. Da
> wird er wohl seine noch freien Bytes einzeln zählen müssen.
>
> W.S.

Nö, Platzprobleme hab ich nicht, mein Vorgänger hat das System stark 
überdimensioniert, ich denke der hatte so 'ne Ahnung ;-)

Und die Fonts liegen im LCD und das hat ein fettes EEPROM drauf.
Das Teil von EA ist selber "intelligent", da muss ich mich nicht um viel 
kümmern. Dafür halt teuer...