nicht angemeldet
Der Martin
Der Martin
Felix Riesterer
dedlfix
Gunnar Bittersmann
dedlfix
dedlfix
Felix Riesterer
Gunnar Bittersmann
Rolf b
Hallo, um den Chat aus einem Video-Livestream auszufiltern, entwickle ich ein Javascript (*.htm Seite), und eine Applikation (in der Programmiersprache Visual Basic 6) wertet die Strings aus. -Leider kommen auch Smileys durch, die in der Visual Basic 6 Applikation in einem Textfeld als doppeltes Fragezeichen "??" und vierfaches Fragezeichen "????" erscheinen. -In dem JavaScript sollen die Smileys geblockt werden, sodass nur der Text durchkommt. -Kann man mit geringen Aufwand die Smileys im Javascript blocken?
Stichwörter: alert(unescape("meinText")); decodeURI, decodeURIComponent normalize() method UTF-8 UTF-16 utf8Converter [U+1F600, GRINNING FACE]
Hi,
um den Chat aus einem Video-Livestream auszufiltern, entwickle ich ein Javascript (*.htm Seite), und eine Applikation (in der Programmiersprache Visual Basic 6) wertet die Strings aus. -Leider kommen auch Smileys durch, die in der Visual Basic 6 Applikation in einem Textfeld als doppeltes Fragezeichen "??" und vierfaches Fragezeichen "????" erscheinen.
das lässt mich vermuten, dass nicht alle beteiligten Komponenten dieselbe Zeichencodierung verwenden und deshalb an den Schnittstellen Probleme entstehen.
-In dem JavaScript sollen die Smileys geblockt werden, sodass nur der Text durchkommt.
Das wäre ein Bekämpfen der Symptome, nicht der Ursachen. Abgesehen davon kann ich mir vorstellen, dass das Kind längst in den Brunnen gefallen ist, bis das Javascript endlich zum Zug kommt.
Stichwörter:
Oh, und den Keyword-Spam lass doch bitte bleiben.
So long,
Martin
Leider kommen auch Smileys durch, die in der Visual Basic 6 Applikation in einem Textfeld als doppeltes Fragezeichen "??" und vierfaches Fragezeichen "????" erscheinen. das lässt mich vermuten, dass nicht alle beteiligten Komponenten dieselbe Zeichencodierung verwenden und deshalb an den Schnittstellen Probleme entstehen.
Nein es liegt daran, dass im Chat des Livestreams manchmal ein Smiley, und manchmal zwei Smileys gepostet werden. Wenn ein Smiley gepostet wird, erscheint in dem Textfeld von meiner Visual Basic 6 Anwendung ein "??". Wenn ein doppeltes Smiley gepostet wird, erscheint "????". Es hat also nichts mit einem Schnittstellen-Problem zu tun.
Hallo,
das lässt mich vermuten, dass nicht alle beteiligten Komponenten dieselbe Zeichencodierung verwenden und deshalb an den Schnittstellen Probleme entstehen.
Nein es liegt daran, dass im Chat des Livestreams manchmal ein Smiley, und manchmal zwei Smileys gepostet werden. Wenn ein Smiley gepostet wird, erscheint in dem Textfeld von meiner Visual Basic 6 Anwendung ein "??".
ja, das meinte ich. Vermutlich kommt das Smiley-Zeichen in UTF-8 codiert an, und deine VB-Applikation versteht kein UTF-8. Also kommt Murks raus.
Wenn ein doppeltes Smiley gepostet wird, erscheint "????".
Ja. Doppel-Murks.
Es hat also nichts mit einem Schnittstellen-Problem zu tun.
Ganz sicher doch. Womit sonst?
So long,
Martin
Das Problem ist, dass die *.htm Javascript-Seite mit UTF-8 kodiert ist und somit Smiley-Zeichen liefert. Die Smileys sollte die Javascript-Seite aber nicht liefern, da sie bei der Auswertung des Chat-Textes gar nicht benötigt werden.
Die Javascript-Seite müsste leicht geändert werden, dass sie keine Smileys mehr liefert, sondern nur noch reine ASCII-Zeichen.
Die Javascript Routine, die den Chat String liefert, sieht etwa so aus. -Mit der "Form1.Callback" zeile wird der String an Visual Basic 6 (das String- Auswertungsprogramm) übergeben:
Matthias ApselMyChat.prototype.addChatMessage = function(message)
{
//alert(message.name+': '+message.comment);
if (Form1) Form1.Callback(message.comment);
};
Wie muss die Javascript Routine geändert werden, damit sie nur noch ASCII Zeichen liefert / bzw. durchlässt?
Genügt es vielleicht schon, zu definieren dass die Seite zukünftig im ASCII Stil sein soll? Momentan ist der Head folgendermaßen aus, und die unerwünschten Smileys des UTF-8 Stils kommen durch:
<head><meta charset=utf-8 />
Liebe(r) Vb1988,
Die Javascript-Seite müsste leicht geändert werden, dass sie keine Smileys mehr liefert, sondern nur noch reine ASCII-Zeichen.
es gibt keine ASCII-Zeichen. Es gibt in UTF-8 Daten. Deine Verarbeitung versteht sie nicht. Ändere Deine Verarbeitung und nicht die "Seite"! Oder willst Du Martin nicht verstehen?
Liebe Grüße,
Felix Riesterer.
Moin Felix,
Die Javascript-Seite müsste leicht geändert werden, dass sie keine Smileys mehr liefert, sondern nur noch reine ASCII-Zeichen.
also beispielsweise auch keine Umlaute mehr.
es gibt keine ASCII-Zeichen.
Doch, gibt es - weil ASCII nämlich anders als UTF-8 nicht nur eine Zeichencodierung, sondern auch einen Zeichensatz festlegt.
Oder willst Du Martin nicht verstehen?
Tja, manche Leute möchten halt lieber die Haustür verbarrikadieren, damit man den Dreck im Treppenhaus nicht sieht.
So long,
Martin
Tach!
Das Problem ist, dass die *.htm Javascript-Seite mit UTF-8 kodiert ist und somit Smiley-Zeichen liefert. Die Smileys sollte die Javascript-Seite aber nicht liefern, da sie bei der Auswertung des Chat-Textes gar nicht benötigt werden.
Die Kodierung ist nicht das Problem. Wenn du irgendwelche Zeichen nicht haben möchtest, ersetze sie durch andere oder Leerstring. Dazu kann man einen Regex mit Zeichenklasse nehmen, und darin den ungewünschten Unicode-Bereich angeben.
Genügt es vielleicht schon, zu definieren dass die Seite zukünftig im ASCII Stil sein soll?
Genügt es, auf einen Briefumschlag einen Geldbetrag zu schreiben, damit die entsprechende Menge darin liegt?
Zeichenkodierungsangaben geben dem Empfänger bekannt, welche Kodierung verwendet wurden. Es ist üblicherweise nicht so, dass Programme die zu versendende Datenmenge durchsuchen, um darin eine Angabe zu finden, wie die Datenmenge denn kodiert werden soll. Dazu müsste ja erstmal bekannt sein, in welcher Kodierung die Datenmenge selbst vorliegt, damit man sie richtig interpretieren kann. Und was wäre mit dem Teil, der bereits gesendet wurde, bevor die Zeichenkodierungsangabe auftaucht? - Nein, so funktioniert das nicht. Man ist selbst dafür verantwortlich, dass die Daten korrekt kodiert sind.
Javascript arbeitet jedoch im Allgemeinen nicht mit einer konkreten Kodierung, es arbeitet auf der Ebene von Zeichen, und da mit allen Zeichen aus dem Unicode-Zeichensatz. Deshalb wäre es die Lösung deines Problems, auf der Zeichen-Ebene die ungewünschten zu ersetzen.
dedlfix.
@@dedlfix
Es ist üblicherweise nicht so, dass Programme die zu versendende Datenmenge durchsuchen, um darin eine Angabe zu finden, wie die Datenmenge denn kodiert werden soll. Dazu müsste ja erstmal bekannt sein, in welcher Kodierung die Datenmenge selbst vorliegt, damit man sie richtig interpretieren
Bei UTF-16 und UTF-32 ist das schon üblich. Und auch bei UTF-8 kann eine solche Angabe in der Datenmenge stehen; und da müsste auch nichts durchsucht werden, denn die Angabe steht ganz zu Anfang.
♫ Und dazu eisgekühlter BOMerlunder …
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Tach!
Es ist üblicherweise nicht so, dass Programme die zu versendende Datenmenge durchsuchen, um darin eine Angabe zu finden, wie die Datenmenge denn kodiert werden soll. Dazu müsste ja erstmal bekannt sein, in welcher Kodierung die Datenmenge selbst vorliegt, damit man sie richtig interpretieren
Bei UTF-16 und UTF-32 ist das schon üblich. Und auch bei UTF-8 kann eine solche Angabe in der Datenmenge stehen; und da müsste auch nichts durchsucht werden, denn die Angabe steht ganz zu Anfang.
Ok, da hat beziehungsweise hätte man es. Aber woher weiß dann das Programm, dass es in den Ausgabestrom einfach so eingreifen darf? Das wäre ein unerwartetes Verhalten, auch wenn es so dokumentiert wäre. Wenn man nun einen Parameter einbaut, der das Verhalten abschalten kann, kann man es auch gleich richtig machen und stattdessen einen Parameter einfügen, über den man die gewünschte Kodierung explizit angeben kann.
dedlfix.
dedlfix wrote: Deshalb wäre .. die Lösung deines Problems, auf der Zeichen-Ebene die ungewünschten Zeichen zu ersetzen.
Habe die javascript "replace" -Funktion in die *.htm Seite eingebaut, und nun werden die Smileys erfolgreich geblockt!
Der Parameter /ig bedeutet ignoriere Gross- und Kleinschreibung(/i) und der (/g) -Parameter führt ein "globales Ersetzen" durch.
MyChat.prototype.addChatMessage = function(message)
{
//alert(message.name+': '+message.comment);
var jetzt = message.comment.replace(/[^a-z0-9äöüÄÖÜß !?:,.]/ig,'');
if (Form1) Form1.Callback(jetzt);
};
Die von mir als "erlaubt" definierten Zeichen sind:
a-z A-Z 0-9 äöüÄÖÜß SPACE !?:,.
-Lässt man das Leer-Zeichen hinter "ß" weg, also
[^a-z0-9äöüÄÖÜß!?:,.]
statt
[^a-z0-9äöüÄÖÜß !?:,.]
..dann werden alle Wörter im Chat quasi "zusammengebacken", und der Chat-Text lässt sich nicht mehr gut lesen.
Was würde passieren, wenn man den "global" Parameter weglässt, und was würde passieren wenn man das Hochzeichen(^) vor dem "a" weglässt?
Tach!
-Lässt man das Leer-Zeichen hinter "ß" weg, also
[^a-z0-9äöüÄÖÜß!?:,.] statt [^a-z0-9äöüÄÖÜß !?:,.]..dann werden alle Wörter im Chat quasi "zusammengebacken", und der Chat-Text lässt sich nicht mehr gut lesen.
Logisch, das Leerzeichen ist ein Zeichen wie jedes andere auch.
Was würde passieren, wenn man den "global" Parameter weglässt, und was würde passieren wenn man das Hochzeichen(^) vor dem "a" weglässt?
Das was in jeder Regex-Anleitung dokumentiert ist. Ohne global wird nur das erste Zeichen behandeln. Das ^ am Anfang einer Zeichenklasse ist ein Negator. Lässt du es weg, findet der Ausdruck stattdessen die angegebenen Zeichen.
dedlfix.
Liebe(r) Vb1988,
Die von mir als "erlaubt" definierten Zeichen sind:
a-z A-Z 0-9 äöüÄÖÜß SPACE !?:,.
was hast Du gegen Semikola? Und warum verbietest Du z.B. spanisch-sprachigen Benutzern die initialen Interpunktionszeichen ¡ und ¿ und vielleicht in anderen Sprachen noch andere? Oder ist MyChat für einen rein deutsch-sprachigen Chat und wird niemals nie nicht international?
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Oder ist
MyChatfür einen rein deutsch-sprachigen Chat und wird niemals nie nicht international?
Auch in einem rein deutsch-sprachigen Chat wird man sich mit Zoë in einem Café verabreden wollen.
In anderen Worten: Die Einschränkung des Zeichensatzes ist keine so gute Idee.
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Moin,
Oder ist
MyChatfür einen rein deutsch-sprachigen Chat und wird niemals nie nicht international?Auch in einem rein deutsch-sprachigen Chat wird man sich mit Zoë in einem Café verabreden wollen.
das hängt sehr stark von Zoë ab. :-)
Aber unabhängig davon beobachte ich gerade bei Namen mit diakritischen Zeichen in den letzten Jahren (oder eher Jahrzehnten) einen Trend zur Vereinfachung aus Bequemlichkeit - im Englischen noch stärker als im Deutschen. So wird der Name Zoë auch ab und zu als Zoe geschrieben, oder René als Rene. Und zwar auch von Inhabern dieser Namen bzw. deren Eltern bei der Namensgebung.
In anderen Worten: Die Einschränkung des Zeichensatzes ist keine so gute Idee.
Sehe ich auch so. Zumal mir bei der vorgeschlagenen Auswahl erlaubter Zeichen auch sonst einige fehlen würden. Klammern () zum Beispiel. Ein Schrägstrich / zum Beispiel. Gelegentlich mal ein µ (my). Hin und wieder ein ± (plusminus). Und noch einige andere.
So long,
Martin
@@Der Martin
Zumal mir bei der vorgeschlagenen Auswahl erlaubter Zeichen auch sonst einige fehlen würden. Klammern () zum Beispiel. Ein Schrägstrich / zum Beispiel …
Anführungszeichen zum Bespiel. Womit nicht " gemeint ist.
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Hallo Gunnar Bittersmann,
Anführungszeichen zum Bespiel. Womit nicht " gemeint ist.
Sondern 「…」.
Bis demnächst
Matthias
Hallo,
Anführungszeichen zum Bespiel. Womit nicht " gemeint ist.
Sondern 「…」.
oops, was ist das denn? Ist das irgendwo eine übliche Darstellung, oder gerade eine spontane Idee von dir? Sieht zumindest interessant aus. Könnte ich mir in einem esoterisch orientierten Dokument wohl vorstellen ...
Ciao,
Martin
Tach!
Anführungszeichen zum Bespiel. Womit nicht " gemeint ist.
Sondern 「…」.
oops, was ist das denn?
Ist das irgendwo eine übliche Darstellung, oder gerade eine spontane Idee von dir? Sieht zumindest interessant aus. Könnte ich mir in einem esoterisch orientierten Dokument wohl vorstellen ...
Zwei esoterische Inselvölker verwenden diese.
dedlfix.
Hallo,
Sondern 「…」.
oops, was ist das denn?
Ist das irgendwo eine übliche Darstellung, oder gerade eine spontane Idee von dir? Sieht zumindest interessant aus. Könnte ich mir in einem esoterisch orientierten Dokument wohl vorstellen ...
Zwei esoterische Inselvölker verwenden diese.
und nicht mal gar so undbedeutende. Aber geographisch, kulturell und sprachlich weit weg von uns, darum hatte ich diese Variante noch nie (bewusst) gesehen.
So long,
Martin
@@Der Martin
Sondern 「…」.
oops, was ist das denn? Ist das irgendwo eine übliche Darstellung
Ja. In Japan und Taiwan.
Im Japanischen stehen übrigens verschiedene Zeichen für verschiedene Dinge, die bei uns alle mit denselben Anführungszeichen gekennzeichnet werden.
“You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user.” —Stefan Tilkov
Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Tach!
Im Japanischen stehen übrigens verschiedene Zeichen für verschiedene Dinge, die bei uns alle mit denselben Anführungszeichen gekennzeichnet werden.
"Die missbräuchliche Verwendung dieser Elemente kann die Lokalisierung (Übersetzung) von Inhalten erschweren."
Kann es sein, dass dieser Text zu erwähnen vergessen hat, dass diese Probleme eigentlich nur für Übersetzungsautomaten existieren? Ich stelle mir eher vor, dass es Aufgabe des Übersetzers ist, die für die Zielsprache passende Zeichensetzung entsprechend des Inhalts zu verwenden. Es ist ja nicht so, dass ich das CSS austausche und kann dann japanische Texte lesen. Da sorgt ja auch schon die andere Grammatik dafür, dass bestimmte Teile ganz anders angeordnet werden und sich somit auch ein anderes DOM ergeben kann (wenn man mal davon absieht, dass die TextNodes unterschiedlichen Inhalt haben).
Nun hat mir der Übersetzer einen Text in der Fremdsprache geliefert. Entweder steht das im selben Dokument an anderer Position oder es steht in einem eigenen Dokument. Welche Probleme gibt es nun für den jeweils anderen Text, wenn da unterschiedliche Auszeichnungen drin sind?
Und wo soll die Microauszeichnung hinführen? Muss ich als Autor zum Beispiel wissen, dass andere Sprachen mehrere Mehrzahlformen haben und für welche Zahlen die gelten? Das wäre ja dann in meinem Dokument eine sinnlose bis falsche Auszeichnung, weil das nicht den Regeln meiner Sprache entspricht.
Vielleicht gibt es ja auch einen real existierenden Anwendungsfall, den ich nur nicht (er)kenne. Das will ich ja nicht ausschließen. Aber ich verstehe den Nutzen für solch einen Aufwand (das Auszeichnen und das dazu nötige Erlernen der Feinheiten anderer (im Prinzip sämtlicher) Sprachen) nicht.
dedlfix.
@@dedlfix
"Die missbräuchliche Verwendung dieser Elemente kann die Lokalisierung (Übersetzung) von Inhalten erschweren."
Kann es sein, dass dieser Text zu erwähnen vergessen hat, dass diese Probleme eigentlich nur für Übersetzungsautomaten existieren?
Glaub ich nicht. Weil das IMHO auch für menschliche Übersetzer gilt.
Beispiel:
In his 1974 The Real Paper article, Jon Landau called Bruce Springsteen the “rock and roll future” du jour.[1]
Wenn das Markup fälschlicherweise so aussieht:
<p>In his 1974 <em>The Real Paper</em> article, Jon Landau called Bruce Springsteen the <em>“rock and roll future” du jour</em>.</p>
dann könnte ein Übersetzer die unterschiedliche Bedeutung der Kursivschrift für The Real Paper, “rock and roll future” und du jour übersehen und in der Zielsprache typografisch falsch setzen.
Richtiges Markup
<p>In his 1974 <i class="magazine">The Real Paper</i> article, Jon Landau called Bruce Springsteen the <em>“rock and roll future”</em> <i lang="fr" class="foreign-phrase">du jour</i>.</p>
kann dem Übersetzer helfen, die Bedeutung von kursiv geschriebenen Phrasen besser zu verstehen und diese in der Zielsprache korrekt umzusetzen.
Wobei das Markup auch so aussehen könnte (mit q-Elementen):
<p>In his 1974 <i class="magazine">The Real Paper</i> article, Jon Landau called Bruce Springsteen the <em><q>rock and roll future</q></em> <i lang="fr" class="foreign-phrase">du jour</i>.</p>
Womit wir bei der Frage wären, die du auch im Kopf hattest: Sollten Anführungszeichen (bzw. deren Äquivalente in anderen Schriftsystemen) anhand des Markups mit CSS generiert werden oder vom Autor bzw. Übersetzer selbst in den Text geschrieben werden?
Die lässt sich mit einem klaren Njain beantworten. ;-)
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Anhängsel „du jour“ von mir. Man verzeihe mir das; mir fiel gerade kein anderes Beispiel ein. Bruce Springsteen ist die Zukunft des Rock’n’Roll. Immer noch. ↩︎
Die von mir als "erlaubt" definierten Zeichen sind: a-z A-Z 0-9 äöüÄÖÜß SPACE !?:,.
Felix Riesterer wrote:
was hast Du gegen Semikola? Und warum verbietest Du z.B. spanisch-sprachigen Benutzern die initialen Interpunktionszeichen ¡ und ¿ und vielleicht in anderen Sprachen noch andere? Oder ist
MyChatfür einen rein deutsch-sprachigen Chat und wird niemals nie nicht international?
Die Visual Basic 6 Anwendung soll eine Anwendung für ein "Livestream-Quiz-Spiel" sein, z.B. der Streamer stellt im Livestream die Frage "was ist das Wahrzeichen von Paris?". Der Chat wird anschließend auf das Lösungswort "eiffelturm" (Gross- und Kleinschrift wird ignoriert) überwacht. Der User, der zuerst das Lösungswort in den Chat geschrieben hat, gewinnt die Runde. -Deshalb werden zunächst keine weiteren Zeichen außer a-z A-Z 0-9 äöüÄÖÜß SPACE !?:,. benötigt.
D.h. du hostest in VB6 einen Server, der die Quiz-Chats managed. Du definierst ein deutschsprachiges Publikum und gibst einen reduzierten verwendbaren Zeichesatz vor. Das ist für Webentwickler per Default ein Graus, weil sie die ganze Welt als ihre Kunden sehen :D Aber wenn Du mit dieser Einschränkung leben kannst und willst - na gut.
Dein Problem ist nur, dass VB6 nicht Unicode-fähig ist. VB6 ist ja sowas von 1998... Wie wär's mit VB.NET oder C#? Die .net Umgebung ist von Hause aus Unicode-Fähig, da brauchst Du keinerlei Bocksprünge.
Aber für deine konkrete Problemstellung ist es ja auch so, dass du nach Lösungworten im Stream suchst. D.h. du bekommst als Antwort auf "Welches Blechmonster steht in Paris" ggf "Eifelturm", "??Eiffelturm" oder "Eifellturm????" zur Antwort. Du suchst im Stream nach "Eiffelturm". Das wirst Du in "??Eiffelturm" doch auf jeden Fall finden, auch wenn die UTF-8 Trümmer mit drin herumschwimmen.
Die Umlaute sind aber so eine Sache - wieso kommen die überhaupt richtig an? UTF-8 codiert sie bereits in 2 Zeichen. Und der Smiley müsste eigentlich in 3 Zeichen geliefert werden (Unicode 263a); ich glaube, da passiert jetzt schon mehr als Dir eigentlich recht ist. Hast Du mal im Brauser den Netzwerktracer laufen lassen um zu schauen, was da real über die Leitung geht?
Rolf