ü-Fehler in channels.conf aus w_scan: UTF-8 ist %C3%BC statt %C3%BE

  • Wegen einer Zugangsumstellung auf M-net musste ich für diverse Geräte im Haus neue Sendersuchläufe durchführen.


    Dabei fallen Einträge wie "Energy Nþrnberg" in channels.w_scan.2016-01-04.conf z.B. wie unten hervorge- und behoben unter Ubuntu 14.04 auf:

    Fürs Wiki habe ich die Liste (auch entsprechend http://www.vdr-portal.de/board…3%A4t-qam-256#post1103530) angepasst.
    Oben zugleich ein aktuelles Beispiel, automagisch DVB-T&C unter einen Hut zu bringen, Kryptoeinträge loszuwerden und die "channel groups" (Rechts/Links-Umschaltung) einfach nutzbar zu machen.


    Beispielsweise ein Standalone-DVB-C-Tuner von Wisi zeigt "Nürnberg" aber richtig an.


    Kommt die falsche Zeichenkodierung vom (informierten) Anbieter oder doch aus einer lokalen Anwendung oder Bibliothek?

  • Kann man so aus deinen Infos nicht so ohne weiteres sagen, wer nun der Schuldige ist.


    Vom Prinzip her bekommt man nicht 'character' gesendet, sondern man bekommt bytes, welche man dann als Character bzw. Zeichen interpretieren muss.
    Solange die Bytes kleiner oder gleich 0x7F (7bit character codes) sind, verhalten sich ISO8859-xx, ASCII und UTF-8 gleich,
    oberhalb muss man wissen in welchem Format gesendet wird.


    Solange man also weiß, welche input Kodierung gesendet wurde die zu den gesendeten bytes gehört, kann man dann in fast beliebige andere
    Kodierungen auf dem lokalen System umwandeln, z.B. in UFT-8. Solange bei DVB keine Kodierung nicht angegeben wurde, gilt ISO-6937. Allerdings
    kann mit definierten Steuerzeichen innerhalb eines Textes in den DVB SI Daten beliebig oft hin und her geschaltet werden.


    w_scan selbst benutzt iconv() aus der glibc zum Konvertieren in die angegebene Zielkodierung. Stimmt also entweder die input Kodierung des
    Anbieters nicht oder die Zielkodierung des lokalen Systems nicht, kommt für Zeichen oberhalb von 0x7F Unsinn heraus. Die gerade verwendete
    input Kodierung liest w_scan laut der Spec aus den versteckten Bytes im Text. Die Zielkodierung wird aus den Umgebungsvariablen deines
    Systems erraten(!) und kann von dir überschrieben werden.

  • Welche Tables vom DVB-C-Provider kommen, müsste ich Dir ja mit dvbstream aus Paket dvb-tools dumpen können:
    Welcher Abruf genau würde benötigt? (Problematisch scheint nur QAM_256 f = 482000 kHz S6900C34 zu sein.)


    LANG=en_US.UTF-8 habe ich schon seit einigen Ubuntu-Versionen, und mich natürlich vergewissert, daß der Fehler trotz ergänztem Parameter in der Ausgabe landet:
    w_scan -fc -c DE -C UTF-8 >channels.UTF-8.conf
    Diese und v.a. auch das Log dazu (um Wiederholungszeilen gekürzt) anbei.


    Ein gültiges ü bekomme ich ja bei zahlreichen Sendern, grundsätzlich scheint also UTF-8 erzeugt zu werden (als %C3%BC, wohingegen %C3%BE kein Umlaut wäre).

  • Das Ausgeben der Rohdaten kann w_scan selbst, einfach die komplette Ausgabe von w_scan (stdout + stderr) in eine Datei schreiben und w_scan mit '-v -v -v' starten.


    Die Kodierung ist hier erklärt:
    http://www.etsi.org/deliver/et…_40/en_300468v011001o.pdf , Seite 98 bis 110

  • ü ist in den SDTs jeweils als %FC kodiert (ISO-Latin 1/5/9)
    Der Unterschied scheint mir zu sein, daß es bei München (z.B. BetaDigital) aus ISO-8859-9, bei Nürnberg und Würzburg (M-net) aber aus ISO_6937-2 nach UTF-8 konvertiert wird:

    Ist die Frage, ob die SDT fehlerhaft ist und z.B. vom WISI nur durch Annahme von ISO-8859-? "versehentlich" berichtigt wird, oder ob w_scan sie anders parsen sollte.





  • "For the European languages a set of five character tables are available.
    If no character selection information is given in a text item, then the
    default character coding table (table 00 - Latin alphabet) of figure
    A.1 is assumed."


    Bytes mit 0x01 bis 0x1F zur Selektion einer andren character table gibt es nicht,
    also gilt die default character coding table.




    Nach figure A.1 table 00, Seite 100 ist 0xFC -> 'þ'


    Alles korrekt.

  • Nur eben nicht der Eintrag des Providers, der den richtigen Zeichensatz mitgeben müsste (wenn das nicht Nþrnberg & Wþrzburg an der Wolga sind :]) ?
    Danke nochmal, daß Du es Dir so schnell angesehen hast! Hoffe die Informationen waren so wie benötigt aufbereitet.

  • PS: im Falle von München wird mit dem character selction byte 0x05 -> Figure A.6: Character code table 05 - Latin alphabet number 5 selektiert.
    In dem Falle ist 0xFC dann 'ü', siehe Seite 105.



    Also kein w_scan Problem.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!