ACHTUNG. Das ist ein Archiv des alten forum.ruby-portal.de. Die aktuelle Mailingliste gibt es auf lists.ruby-lang.org/pipermail/ruby-de.

NOTICE. This is a ready-only copy of the old forum.ruby-portal.de. You can find the current mailing list at lists.ruby-lang.org/pipermail/ruby-de.

Die Programmiersprache Ruby

Blog|

Forum|

Wiki  


Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]

Ein neues Thema erstellen Auf das Thema antworten  [ 14 Beiträge ] 
Autor Nachricht
BeitragVerfasst: 24 Okt 2013, 11:58 
Offline
Lehrling

Registriert: 13 Mai 2009, 11:18
Beiträge: 57
Hallo,

ich hab folgendes Problem, dass Daten von einem externen Dienstleister ziemlich zerschossen ankommen. Es geht schon damit los, dass die Datei kein sauberes Encoding aufweist. Schaue ich mir die Dateiattribute per Shell mit "file -I import.txt" an, kommt als Ausgabe schonmal "import.txt: text/plain; charset=unknown-8bit".

Ruby hingegen zeigt als external encoding "UTF-8" an (per File.open...). Jetzt ist aber das Problem, dass z.B. in einer Zeile steht "Text^Text^T?", korrekt müsste da aber stehen "Text^Text^Töxt". Das eigentliche problem ist nun, dass CSV.foreach()... die komplette Datei verweigert. Mir würde es ja schon reichen, wenn die entsprechende Zeile dann einfach nicht importiert werden kann.

Wenn ich die Datei "import.txt" mit Sublime Text 2 öffne und dann sage "Save with encoding -> UTF-8" kann die Datei von Ruby's CSV problemlos gelesen werden. Der Fehler im Text ist zwar dann immer noch da, aber das ist mir erstmal egal. Darum dürfen sich dann andere kümmern ;)

Jetzt dachte ich mir, wenn ST2 die Datei umwandeln kann und somit CSV.foreach(...) klappt, müsste es ja auch mit Ruby funktionieren. Aber Pustekuchen. Egal, was ich probiere, es funktioniert nicht. Probiert habe ich folgendes:

CSV.foreach mit Encoding 'utf-8' => invalide byte character
CSV.foreach mit Encoding 'windows-1251:utf-8' => invalid byte character
CSV.foreach mit Encoding 'iso-8851-1:utf-8' => invalid byte character
CSV.foreach mit Encoding 'utf-8:utf-8' => invalid byte character
CSV.foreach mit Encoding 'ascii:utf-8' => invalid byte character

Dann hab ich noch probiert, die Datei mit File.open() ohne Encoding zu öffnen und den kompletten Inhalt nach utf8 zu konvertieren per String#encode. Das hat auch nicht geklappt. Ich bin hier mit meinem Latein am Ende.

Habt ihr irgendeine Idee wie ich das Problem lösen kann? Mein letzter Versuch war, die Datei in der Shell per iconv zu konvertieren, auch das hat nicht funktionieren.

Ich bin dankbar für jeden Hinweis!


Viele Grüße
Martin

P.S.: Mir sind die Daten relativ egal, wenn die falsch importiert werden, ist das halt so. Es geht darum, dass die komplette Datei nicht importiert werden kann, wenn in 1 Zeile fehlerhafte Kodierungen drin sind. Mir würde es auch reichen nur diese eine Zeile zu ignorieren.


Nach oben
 Profil  
 
BeitragVerfasst: 24 Okt 2013, 12:24 
Offline
Interpreter
Benutzeravatar

Registriert: 18 Sep 2008, 22:32
Beiträge: 1821
Wohnort: NRW → UN
So wie du es beschreibst, scheinst du von Rubys Encoding-System zu viel zu erwarten.

maddin hat geschrieben:
Ruby hingegen zeigt als external encoding "UTF-8" an (per File.open...).
Ruby „zeigt“ dir in diesem Sinne überhaupt kein Encoding an. Ruby rät Encodings nicht — es benutzt IMMER eine voreingestellte Standardkodierung, wenn du ihm nichts anderes sagst. Bis Ruby 2 war das ASCII-8Bit, seit Ruby 2 ist das eben UTF-8. Welche Kodierung die Datei selbst aufweist, ist Ruby dabei ziemlich egal. Das Ergebnis ist, wie du siehst, dass bei der weiteren Verarbeitung Exceptions auftreten.

Das Konzept von Encodings in Ruby ist eigentlich banal: Jeder String bekommt ein Tag, in dem das Encoding drinsteht. Du kannst dieses Tag explizit mit String#force_encoding setzen; tust du das nicht, bekommen deine Strings ein Standardtag, neuerdings eben UTF-8. Ob das Tag auch stimmt, ist dabei eine ganz andere Frage, die Ruby nicht für dich beantworten kann.

Beim Einlesen von Dateien kannst du Ruby explizit sagen, welches Encoding dort vorliegt:




File.open("mywindowsfile", "r:Windows-1252"){|f| f.read}


Das liest mywindowsfile ein und taggt es mit Windows-1252 als Encoding. Das könntest du dann bei Bedarf mittels String#encode nach UTF-8 umwandeln.

Merke: String#force_encoding setzt das Tag, ändert aber den Inhalt des Strings nicht. String#encode ändert den Inhalt des Strings und setzt dann das Tag neu.

Dazu musst du zunächst wissen, in welchen Encoding deine externen Textdateien vorliegen (nachfragen). Das liest du dann wie oben gezeigt ein, transkodierst es nach UTF-8 und übergibst das Ergebnis dann an CSV. Wenn die Dateien zu groß für den Speicher sind, willst du das transkodierte Ergebnis evtl. in eine temporäre (oder sogar permanente) Datei schreiben.

maddin hat geschrieben:
P.S.: Mir sind die Daten relativ egal, wenn die falsch importiert werden, ist das halt so.
Ich bin mir sicher, die Leute, die nach dir damit arbeiten müssen, sind über ein korrektes Encoding glücklich :-). Wenn aber wirklich alles egal ist, dann:




File.open("myfile", "rb"){|f| f.read}


Das liest myfile als Binärblob ein (der String wird mit BINARY als Encoding getaggt). Danach solltest du dich aber hüten, irgendwelche zeichenbezogenen Operationen oder gar Umkodierungen vorzunehmen.

Vale.

_________________
Habe den Mut, dich deines eigenen Verstandes zu bedienen! — Immanuel Kant

Ich bin freischaffender Softwareentwickler und freue mich über jedes neue Projekt. Kontaktinformation auf meiner Website.

Mein Blog | GitHub-Profil | Auf Twitter: @qquintilianus | PGP/GPG-Schlüssel: B1FE 958E D5E8 468E AA20 8F4B F1D8 799F BCC8 BC4F


Nach oben
 Profil  
 
BeitragVerfasst: 24 Okt 2013, 15:30 
Offline
Lehrling

Registriert: 13 Mai 2009, 11:18
Beiträge: 57
Hallo Vale,

erstmal danke für deine ausführliche Antwort. Tatsächlich bin ich was Ruby und Kodierung angeht noch nicht wirklich fit ;) Aber das hat sich jetzt geändert. Wenn ich es richtig verstanden habe, ist Ruby die tatsächliche Kodierung eines String egal. Es gibt standardmäßig eine Kodierung die voreingestellt ist (je nach Version, System, Umgebung und was man selbst mit force_encoding angibt), wie aber die tatsächlichen Daten kodiert sind, steht wieder auf einem anderen Blatt.

Ich bin bisher immer davon ausgegangen, dass die Daten in UTF-8 oder Windows-1252 ankommen. Mein Ziel war es, das immer nach UTF-8 zu konvertieren. Und ich denke hier lag auch der Fehler. Beim Konvertieren gab es immer irgendwelche Fehler.

Ich habe jetzt probehalber einfach mal die Konvertierung weggelassen und die Datei mit CSV.foreach() und encoding = 'windows-1252' laufen lassen und die Umwandlung in UTF-8 rausgeschmissen. Der erste Test war soweit erfolgreich, es gab zumindest keine Exception mehr.

Ich werde das jetzt mal weiter testen und auch die anderen Dateien prüfen. Danke auf jeden Fall für deine Antwort, jetzt sehe ich das alles schon etwas klarer. Und ja, die Leute freuen sich, wenn die Daten richtig kodiert sind ;) Aber lieber bekommen sie Daten, bei denen ein geringer Prozentsatz fehlerhaft ist als gar keine Daten ;)

Viele Grüße
Martin

P.S.: Da ich für die Richtigkeit der Daten nicht sorgen kann, kann ich da sowieso nicht viel machen. Wenn Daten falsch kodiert ankommen, kann ich die ja niemals richtig umwandeln.


Nach oben
 Profil  
 
BeitragVerfasst: 24 Okt 2013, 16:40 
Offline
Lehrling

Registriert: 13 Mai 2009, 11:18
Beiträge: 57
Hm,

also doch zu früh gefreut. Ich hab gerade die Info bekommen, dass die Datei selbst mit UTF-8 kodiert ist. Soweit also in Ordnung. Ich lese die Datei mit UTF-8 ein und soweit funktioniert ja auch alles. Die Sonderzeichen werden alle richtig dargestellt und auch korrekt in die Datenbank übertragen.

Jetzt ist es aber so, dass eine Zeile wohl ein Kodierungsproblem hat. Denn dort gibt es immer die Meldung:

Zitat:
`sub!': invalid byte sequence in UTF-8 (ArgumentError)


Ich hab mir die Zeile mal angeschaut und dort steht beim Namen "... Aufl?^123^...". Es sollte eigentlich "Auflösung" heißen. Hier scheint die Kodierung wirklich nicht zu stimmen. Soweit wäre das nicht schlimm, gäbe es eine Möglichkeit die Zeile zu ignorieren und mit der nächsten weiter zu machen.

Leider ist es aber so, dass ich den Fehler nicht abfangen kann und somit der ganze CSV.foreach(...) Block abbricht. Gibt es denn da keine Möglichkeit das irgendwie zu umgehen?

Ich hab schon versucht die Datei von UTF-8 zu UTF-8 zu konvertieren und problematische Zeichen einfach rauszulöschen. Denn scheinbar ist der Fehler ja in der Datei und das kann ich niemals sicherstellen, dass das nicht nochmal vorkommt.

Weiß vielleicht doch noch jemand Rat?

Danke & viele Grüße
Martin


Nach oben
 Profil  
 
BeitragVerfasst: 24 Okt 2013, 17:54 
Offline
Interpreter
Benutzeravatar

Registriert: 18 Sep 2008, 22:32
Beiträge: 1821
Wohnort: NRW → UN
PS: Der Forums-Highlighter ist offensichtlich angeschlagen. Der Code enthält eine ganze Menge Unicode-Zeichen zur Demonstration, was so natürlich überhaupt nicht funktioniert. Hier der gesamte Code noch einmal in Form von Pastes mit korrekter Darstellung:


maddin hat geschrieben:
Hallo Vale,
Der Blick auf den Nick hilft ;-). Das ist nur ein Abschiedsgruß.

maddin hat geschrieben:
Wenn ich es richtig verstanden habe, ist Ruby die tatsächliche Kodierung eines String egal. Es gibt standardmäßig eine Kodierung die voreingestellt ist (je nach Version, System, Umgebung und was man selbst mit force_encoding angibt), wie aber die tatsächlichen Daten kodiert sind, steht wieder auf einem anderen Blatt.
Exakt.

maddin hat geschrieben:
Leider ist es aber so, dass ich den Fehler nicht abfangen kann und somit der ganze CSV.foreach(...) Block abbricht. Gibt es denn da keine Möglichkeit das irgendwie zu umgehen?
Ruby wäre nicht Ruby, wenn es nicht auch mit kaputten Dateien umgehen könnte, also solchen mit Encoding-Fehlern. Ich wollte nur erst sicherstellen, dass deine Exceptions nicht schlicht das Ergebnis falschen Taggings waren.

Jetzt zum Problem. Du kannst Ruby zwingen, kaputte Strings zu „reparieren“, d.h. die kaputten Bytesequenzen durch eine valide deiner Wahl zu ersetzen. Dafür musst du die Daten allerdings einmal umkodieren, weil Ruby eine Konvertierung von UTF-8 nach UTF-8 leider als No-Op betrachtet:

Ruby-Dokumentation hat geschrieben:
Please note that conversion from an encoding enc to the same encoding enc is a no-op, i.e. the receiver is returned without any changes, and no exceptions are raised, even if there are invalid bytes.


String#encode enthält im Übrigen alles, was wir brauchen. Das ganze sieht dann so aus:



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
irb(main):001:0> str = "��l\x178\x88lkjdfg" # Erzeuge einen kaputten String (der mit UTF-8 getaggt ist)
=> "��l\u00178\x88lkjdfg"
irb(main):002:0> str.encoding
=> #<Encoding:UTF-8>
irb(main):003:0> str.valid_encoding? # Pr��ft, ob ein String kaputt ist
=> false
irb(main):004:0> str.encode("UTF-16LE") # Geht nicht, weil der String ja kaputt ist
Encoding::InvalidByteSequenceError: "\x88" on UTF-8
from (irb):12:in `encode`
from (irb):12
from /opt/rubies/mri/bin/irb:4:in `<main>`
irb(main):005:0> str2 = str.encode("UTF-16LE", :invalid => :replace, :replace => "?") # Reparieren; wir k��nnen leider nicht von UTF-8 nach UTF-8, siehe oben
=> "\uFEFF\u00F6l\u00178?lkjdfg"
irb(main):006:0> str.encoding
=> #<Encoding:UTF-8>
irb(main):007:0> str2.encoding
=> #<Encoding:UTF-16LE)>
irb(main):008:0> str2.valid_encoding? # Jetzt ist alles in Ordnung
=> true
irb(main):009:0> str3 = str2.encode("UTF-8") # Zur��ck nach UTF-8
=> "��l\u00178?lkjdfg"
irb(main):010:0> str3.encoding
=> #<Encoding:UTF-8>
irb(main):011:0> str3.valid_encoding? # Perfekt!
=> true
irb(main):012:0> puts str3
��l8?lkjdfg
=> nil
irb(main):012:0>


Der Code ersetzt alle kaputten (also nicht ins Encoding passenden) Bytesequenzen einfach durch Fragezeichen.

Aufgrund des Problems, dass String#encode leider nicht zum bloßen Replacement verwendet werden kann, müssen wir wie oben gezeigt außerdem stattdessen ein Drittencoding, hier UTF-16LE, als Zwischenschritt verwenden. Wenn du deine Daten bereits als etwas anderes als UTF-8 erhältst, enfällt dieser Zwischenschritt natürlich.

Das kann man abkürzen:



1
2
3
4
5
6
irb(main):013:0> str4 = str.encode("UTF-16LE", :invalid => :replace, :replace => "?").encode("UTF-8")
=> "��l\u00178?lkjdfg"
irb(main):014:0> str4.encoding
=> #<Encoding:UTF-8>
irb(main):015:0> str4.valid_encoding?
=> true


Da kann man eine Methode drumherum basteln:



1
2
3
4
def fix_encoding(str, replacement = "���")
encoding = str.encoding
str.encode("UTF-16LE", :invalid => :replace, :replace => replacment).encode(encoding)
end


Beachte, dass ich hier außerdem das spezielle Unicode-Zeichen � (das Fragezeichen im Karo, U+FFFD) verwendet habe, das explizit für solche Dinge gedacht ist. Die Methode ist nicht perfekt; wenn du einen String reingibst, der in UTF-16LE kodiert ist, hast du halt wieder das No-Op-Phänomen.

Vale,
Quintus

_________________
Habe den Mut, dich deines eigenen Verstandes zu bedienen! — Immanuel Kant

Ich bin freischaffender Softwareentwickler und freue mich über jedes neue Projekt. Kontaktinformation auf meiner Website.

Mein Blog | GitHub-Profil | Auf Twitter: @qquintilianus | PGP/GPG-Schlüssel: B1FE 958E D5E8 468E AA20 8F4B F1D8 799F BCC8 BC4F


Nach oben
 Profil  
 
BeitragVerfasst: 24 Okt 2013, 18:21 
Offline
Lehrling

Registriert: 13 Mai 2009, 11:18
Beiträge: 57
Quintus hat geschrieben:
Der Blick auf den Nick hilft ;-). Das ist nur ein Abschiedsgruß.


Es war definitiv zu lang gestern :D Ich entschuldige mich und hoffe, du kannst darüber hinwegsehen ;)

Ich hab mir das jetzt nochmal zur Gemüte geführt. Tatsächlich hab ich schon fast das gleiche probiert und damit teilweise einen Erfolg erzielt. Allerdings habe ich nicht nach UTF-16LE konvertiert und wieder zurück zu UTF-8, sondern nach Windows-1252. Das hat soweit funktioniert, dass die "invalid byte" Meldung zwar weg war, aber in der Datenbank dann plötzlich die Sonderzeichen nicht mehr korrekt waren.

Mit der Umwandlung auf UTF-16LE funktioniert das, tausend Dank an dich, Quintus! Im Nachhinein ist es ja aber auch logisch, aber korrigier mich bitte, wenn ich falsch liege. UTF-8 ist ja ein "größerer" Zeichensatz als Windows-1252 und UTF-16LE ist noch größer als UTF-8. Liegt es also daran, dass man nicht nach "unten" konvertieren kann um Kodierungsfehler zu beseitigen, sondern immer nur in einen gleichwertigen oder höheren?

Danke dir vielmals!


Viele Grüße
Martin


Nach oben
 Profil  
 
BeitragVerfasst: 24 Okt 2013, 19:18 
Offline
Interpreter
Benutzeravatar

Registriert: 18 Sep 2008, 22:32
Beiträge: 1821
Wohnort: NRW → UN
maddin hat geschrieben:
Mit der Umwandlung auf UTF-16LE funktioniert das, tausend Dank an dich, Quintus!
Gern geschehen. :)

maddin hat geschrieben:
Im Nachhinein ist es ja aber auch logisch, aber korrigier mich bitte, wenn ich falsch liege. UTF-8 ist ja ein "größerer" Zeichensatz als Windows-1252 und UTF-16LE ist noch größer als UTF-8. Liegt es also daran, dass man nicht nach "unten" konvertieren kann um Kodierungsfehler zu beseitigen, sondern immer nur in einen gleichwertigen oder höheren?
Tatsächlich ist das nicht ganz falsch, und daher habe ich auch UTF-16 gewählt. Zur Klärung muss ich hier etwas weiter ausholen.

Aller Koderierungen Mutter ist US-ASCII. Diese Kodierung verwendet 7 Bit und war lange Jahre der Standard, weil die bösen USA ja alles in der Computerbranche tyrannisiert, ähm, verwaltet haben. Die geringe Zeichenanzahl (128 minus ein paar Steuerzeichen) reichte für US-Englisch aus, daher war man mit dem Thema erst einmal durch.

Als man schließlich nicht mehr leugnen konnte, dass es tatsächlich auch noch andere Staaten außer den USA gibt, die Computer verwenden, musste man sich etwas neues überlegen. Wenn verschiedene Konzerne in verschiedenen Ländern sich an demselben Problem versuchen, ist das Ergebnis natürlich klar: Jeder findet seine eigene Lösung, die hunderttausendmal besser ist als die des Konkurrenten aus dem andern Land. So entstanden die Koderierungen Windows-125* für den westlichen Raum, im asiatischen Raum kämpften BIG-5, Shift-JIS und einige andere um die Vorherrschaft. Die westeuropäischen Kodierungen wurden leicht verändert von der ISO als ISO-885*-* standardisiert, so entsprach ISO-8859-1 etwa (aber eben nicht ganz, mit Unterschieden zum Beispiel beim €-Zeichen) Windows-1252. Diese regional entwickelten Koderierungen machten denselben Fehler wie schon vorher die USA: Sie waren zu regional. Es entstand eine Fülle an Kodierungen, die aber alle eines gemeinsam hatten: Sie kodifizierten nur die Zeichen, die in ihrem Einsatzgebiet erforderlich waren. Musste eine westeuropäische Firma Korrespondenz mit einer japanischen abwickeln, waren massive Kodierungsprobleme die Folge, denn die asiatischen Kodierungen konnten keine westeuropäischen Sonderzeichen (etwa ä, ü, etc.), die europäischen keine asiatischen Zeichen darstellen. Zur Ehrenrettung muss gesagt werden, das fast alle Kodierungen immerhin den grundlegenden lateinischen Zeichensatz kodieren konnten.

Soweit zur Entstehung der verschiedenen Kodierungen. Kernproblem war, dass sie alle nur regional funktionierten. Man suchte nach Lösungen und 1991 kam dann auf einmal etwas neues: Unicode. Unicode ist keine Zeichenkodierung, sondern die Liste aller weltweit anerkannten Schrift- und Bildzeichen. Also wirklich nur eine banale Auflistung, die nichts mit Computern zu tun hat (und die laufend aktualisiert wird). Diese Liste zu kodieren, war nun die Aufgabe. Dazu entstanden im Wesentlichen drei Kodierungen:

  • UTF-8
  • UTF-16
  • UTF-32

Alle drei sind in der Lage, das gesamten Unicode-Spektrum abzudecken. Deine These, UTF-16 sei „größer“ als UTF-8 i.S.d. Zeichenmenge, stimmt so also nicht. Alle drei Kodierungen decken den gleichen Zeichenraum ab. Unterscheiden tun sie sich nur bei der Technik, wie die Zeichen kodiert werden.

UTF-8 ist ein Encoding mit variables Bytezahl pro Zeichen. Die ersten paar Zeichen sind nur ein Byte groß (und die ersten 128 entsprechen netterweise sogar US-ASCII). Danach werden Steuerzeichen gebraucht, die anzeigen, wie viele Bytes das nächste Zeichen formen, gefolgt von den Bytes. Das führt insbesondere im asiatischen Raum zu dem Problem, dass die dortigen Schriftzeichen viele Bytes benötigen und so sehr, sehr viel Speicher belegen. In Zeiten von Gibibyte-RAM erledigt sich das allerdings langsam von selbst, sodass sich UTF-8 als die de-facto-Kodierung durchgesetzt hat.

UTF-16 verwendet zwei Byte (→ 16 Bit, daher der Name) pro Zeichen und bietet eine weitestgehend fixe Bytelänge. Erst bei wirklich exotischen Zeichen bedient man sich einer ähnlichen Technik wie UTF-8. Die Bytereihenfolge kann entweder vorwärts (Big Endian, UTF-16BE) oder rückwärts (UTF-16LE) sein, was durch ein Byte-Order-Mark (BOM) kenntlich gemacht werden muss.

UTF-32 ist die eigentlich „richtige“ Kodierung für Unicode. Jedes Zeichen belegt 4 Byte (→ 32 Bit), das Encoding hat also eine absolut fixe Bytelänge und ist supereinfach zu parsen, der Traum für jeden Parserschreiber. Es gibt keine Unterschiede mehr zwischen westlichen und asiatischen Schriftzeichen, alles ist einfach einheitlich. Nur leider: Einheitlich groß. Dieses Encoding verbraucht nun wirklich sehr viel Speicherplatz. Es ist aber denkbar, dass auch dies sich im Laufe der nächsten Jahre relativieren wird, sodass es gut möglich ist, dass wir in Zukunft überhaupt keine Umkodierungen mehr brauchen und alles in UTF-32 vorliegen wird. Auch in UTF-32 kann man die vier Bytes natürlich vorwärts (UTF32-BE) oder rückwärts (UTF32-LE) anordnen, was mit einem BOM angezeigt werden muss.

Anmerkung: Auch die Multibyte-Zeichen in UTF-8 kann man natürlich vorwärts oder rückwärts kodieren. Hier hat sich aber eine Reihenfolge durchgesetzt, sodass man das hier üblicherweise nicht angibt. Jetzt frag mich aber nicht, welche Variante sich durchgesetzt hat (vermutlich Little Endian).

Konkret auf deine Frage bezogen: UTF-* umfasst alle anerkannten Zeichen dieser Erde. Windows-125* nur einen sehr, sehr begrenzten Teil. Während du also verlustfrei von etwa Windows-1252 nach UTF-8 konvertieren kannst, wirst du bei der Konvertierung von UTF-8 nach Windows-1252 möglicherweise Probleme in Form von Exceptions bekommen. Also: Ja, du kannst verlustfrei nur in ein gleichwertiges oder größeres Encoding konvertieren.

Vale,
Quintus

_________________
Habe den Mut, dich deines eigenen Verstandes zu bedienen! — Immanuel Kant

Ich bin freischaffender Softwareentwickler und freue mich über jedes neue Projekt. Kontaktinformation auf meiner Website.

Mein Blog | GitHub-Profil | Auf Twitter: @qquintilianus | PGP/GPG-Schlüssel: B1FE 958E D5E8 468E AA20 8F4B F1D8 799F BCC8 BC4F


Nach oben
 Profil  
 
BeitragVerfasst: 25 Okt 2013, 10:16 
Offline
Lehrling

Registriert: 13 Mai 2009, 11:18
Beiträge: 57
Wow, vielen vielen Dank für diese ausführlichen Informationen. Ich wollte, sowas hätte man mal an der Uni gelernt ;) Sowas in der Art hab ich mir schon gedacht, nur kann ich es nicht so gut beschreiben und erklären wie du.

Danke!


Viele Grüße
Martin

P.S.: Der Import dauer jetzt zwar minimal länger, weil die Dateien vorher immer konvertiert werden müssen, aber die paar Sekunden hin oder her ist auch egal ;)


Nach oben
 Profil  
 
BeitragVerfasst: 25 Okt 2013, 23:07 
Offline
Metaprogrammierer

Registriert: 20 Nov 2011, 21:51
Beiträge: 693
Wenn es die Uni nicht unterrichtet, dann komm zu mir an die FH, da war es gestern Stoff in unserer zweiten Informationstechnik Vorlesung für dieses Semester und ich bin erst seit 10 Tagen Student…

_________________
Ubuntu Gnome 14.04 LTS
rvm mit App-spezifischer Ruby-Version (meist 2.2.x) und -Gemset

Github ProfilBitbucket Profil


Nach oben
 Profil  
 
BeitragVerfasst: 07 Jan 2014, 14:08 
Offline
Meister

Registriert: 02 Jan 2010, 16:42
Beiträge: 204
Wohnort: Schweiz
Herzlichen Dank für die tollen Erklärungen hier zu Kodierungen.

meine Frage ich etwas banal: Wie kann ich eigentlich UTF-8 Zeichen in einem (Windows)Editor eingeben, wenn dieses Zeichen auf meiner Tastatur nicht vorhanden ist? Ist der einzige Weg der über die das Programm "Zeichentabelle"? oder gibt es irgendwelche Kürzel?

Ein konkretes Beispiel:

Das Zeichen "y" ist dort angegeben mit U+0079. Wie ist das zu verstehen? Ist es nur eine Information oder gibt es mir auch einen Hinweis darauf, welche Tasten (analog zu [ALT] und [0][0][7][9] für das Zeichen "O") ich verwenden muss, um das Zeichen "y" zu bekommen, ohne die "y"-Taste zu drücken.

Gruss,

Jean

_________________


1
2
Betriebssysteme: Windows 10, Linux Mint 17.3
Rubyversion : 2.2.4-p230


Nach oben
 Profil  
 
BeitragVerfasst: 07 Jan 2014, 14:21 
Offline
Metaprogrammierer

Registriert: 20 Nov 2011, 21:51
Beiträge: 693
Das Zeichen "y" mit Unicode U+0079 kannst du erreichen indem du die Taste "y" drückst, Alt +0079, Alt 0121 oder Alt 121.

Die direkte Verwendung der 4-stelligen Unicode Nummer zusammen mit Alt und dem + dazwischen sollte eigentlich immer funktionieren. Und meines Wissens nach muss man die Ziffern vom Ziffernblock benutzen, nicht die auf der Haupttastatur!b

Falls du bestimmte Zeichen und ihre verschiedenen Represantationen in verschiedenen Sprachen, Encodings oder Eingabemöglichkeiten suchst, dann schau dir mal http://www.fileformat.info/info/unicode/index.htm an. Das Beispiel mit dem "y" (LATIN SMALL LETTER Y) findest du zum Beispiel unter http://www.fileformat.info/info/unicode/char/0079/index.htm

Aber bitte beachte, der Trick mit dem Alt funktioniert unter Linux nicht immer, ich würde mich nur unter Windows drauf verlassen.

Aber falls jemand eine vergleichbare Eingabemethode kennt, die unter Linux zuverlässig funktioniert wäre ich dankbar!

_________________
Ubuntu Gnome 14.04 LTS
rvm mit App-spezifischer Ruby-Version (meist 2.2.x) und -Gemset

Github ProfilBitbucket Profil


Nach oben
 Profil  
 
BeitragVerfasst: 07 Jan 2014, 16:54 
Offline
Meister

Registriert: 02 Jan 2010, 16:42
Beiträge: 204
Wohnort: Schweiz
Hallo NobbZ,

herzlichen Dank für deinen Beitrag und die hilreichen Links. Du schreibst
Zitat:
Das Zeichen "y" mit Unicode U+0079 kannst du erreichen indem du die Taste "y" drückst, Alt +0079, Alt 0121 oder Alt 121.


Bisher funktioniert es bei mir wie folgt

Alt+0079, Alt+79 -> O
Alt 0121, Alt 121 -> y

Hierbei habe ich mich an die Anleitung in deinem Link gehalten:


1
2
3
4
5
This method works regardless of any of your language settings, but is the most cumbersome to type.
- Press and hold down the Alt key.
- Press the + (plus) key on the numeric keypad.
- Type the hexidecimal unicode value.
- Release the Alt key.

Ich vermute einmal, dass es an dem folgenden Hinweis liegt:
Zitat:
... Under HKEY_Current_User/Control Panel/Input Method, set EnableHexNumpad to "1". If you have to add it, set the type to be REG_SZ.

Werde es zu Hause ausprobieren und bei Erfolg unsere IT höflich bitten, diese auf meinem Computer umzusetzen, ahnend, dass wer Begriffe wie "Registry" kennt von unserer IT als "Störenfriend" und "potentieller Hacker" angesehen wird. :-)

Herzlichen Dank für die hervorragenden Links.

_________________


1
2
Betriebssysteme: Windows 10, Linux Mint 17.3
Rubyversion : 2.2.4-p230


Nach oben
 Profil  
 
BeitragVerfasst: 07 Jan 2014, 20:19 
Offline
Interpreter
Benutzeravatar

Registriert: 18 Sep 2008, 22:32
Beiträge: 1821
Wohnort: NRW → UN
NobbZ hat geschrieben:
Aber falls jemand eine vergleichbare Eingabemethode kennt, die unter Linux zuverlässig funktioniert wäre ich dankbar!
Wie so vieles im GUI-Bereich ist das keine „linuxspezifische“ Frage, sondern vielmehr eine Xorg-spezifische. Die Eingabe von Zeichen wird unter Xorg durch eine sogenannte Keymap gesteuert, die die vom Kernel (Linux) gelieferten Keycodes in ein Zeichen übersetzt. Modifizieren lässt sich die aktive Keymap mithilfe von xmodmap(1) und anderen Tools (ausführliche Informationen). Da kaum jemand die diversen Belegungen über [ALTGR]+[Shift]+<Taste> braucht*, kann man sich da genausogut diejenigen Zeichen hinlegen, die man häufiger braucht.

Mit den richtigen Keymaps kann man X bestimmt dazu bewegen, über [Alt] Unicode-Keys einzugeben, aber wie genau das möglich ist, weiß ich leider auch nicht.

Speziell für Emacs (mit dem ich ja ohnehin meistens arbeite) gibt es nämlich eine sehr viel einfachere Methode: Ctrl-x 8 <Ret>, dann den Namen (mit Autocomplete per Tab! :-)) wie etwa GREEK SMALL LETTER ALPHA eingeben (oder wahlweise auch den Hexwert) und fertig.

Vale,
Quintus

* Xorg kennt keine [ALTGR]-Taste. Korrekterweise muss man von der ISOLevel3-Shift-Taste sprechen. Einfach mal mit xev(1) anschauen.

_________________
Habe den Mut, dich deines eigenen Verstandes zu bedienen! — Immanuel Kant

Ich bin freischaffender Softwareentwickler und freue mich über jedes neue Projekt. Kontaktinformation auf meiner Website.

Mein Blog | GitHub-Profil | Auf Twitter: @qquintilianus | PGP/GPG-Schlüssel: B1FE 958E D5E8 468E AA20 8F4B F1D8 799F BCC8 BC4F


Nach oben
 Profil  
 
BeitragVerfasst: 07 Jan 2014, 23:54 
Offline
Metaprogrammierer

Registriert: 20 Nov 2011, 21:51
Beiträge: 693
Quintus hat geschrieben:
Modifizieren lässt sich die aktive Keymap mithilfe von xmodmap(1) und anderen Tools (ausführliche Informationen).


Werd ich mir mal ansehen… Mal schauen wann ich dazu komme…

Quintus hat geschrieben:
Da kaum jemand die diversen Belegungen über [ALTGR]+[Shift]+<Taste> braucht*, kann man sich da genausogut diejenigen Zeichen hinlegen, die man häufiger braucht.


Du wirst es kaum glauben, aber ich nutze die 4 Ebenen doch recht ausschöpfend… (<= Da zum Beispiel gerade wieder) Wobei… Wenn ich ehrlich bin, Ebenen 3 und 4 auch nur in der obersten und untersten Reihe der Tastatur, für die beiden Reihen dazwischen kann ich mit Sicherheit ein paar nette Belegungen finden… Ärgert mich schon seit Wochen, dass ich mir „≈“ ewig aus einer Textdatei kopieren muss, die eigens dazu immer im Hintergrund geöffnet ist.

Quintus hat geschrieben:
Speziell für Emacs (mit dem ich ja ohnehin meistens arbeite) gibt es nämlich eine sehr viel einfachere Methode: Ctrl-x 8 <Ret>, dann den Namen (mit Autocomplete per Tab! :-)) wie etwa GREEK SMALL LETTER ALPHA eingeben (oder wahlweise auch den Hexwert) und fertig.


Da werden wir uns nicht einig. Mit Emacs bin ich bis heute nicht warm geworden. Ich probiere ihn immer wieder mal aus, aber er ist einfach nichts für mich, ich bleibe bei vim… Auch wenn ich ihn momentan nur in Grundzügen bedienen kann. Konfiguration, die über abschreiben hinausgeht oder gar kleine Scripte gehen für mich gar nicht :)

Aber ich brauche solch eine Funktion ja nicht nur in Programmtexten – im Browserfenster, im Chat oder einfach nur auf der Konsole, da brauche ich auch mal den einen oder anderen Unicode-Char, daher suche ich eben nach einer einheitlichen Eingabemethode auf Basis des Tastaturtreibers (oder einer anderen Schicht, die irgendwo zwischen Tastatur und Bildschrim sitzt ;) )

MfG
NobbZ

_________________
Ubuntu Gnome 14.04 LTS
rvm mit App-spezifischer Ruby-Version (meist 2.2.x) und -Gemset

Github ProfilBitbucket Profil


Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 14 Beiträge ] 

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 6 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
cron