Bug im Syntaxhighlighting?

[Stefan B. (Gast)]

In den folgenden Zeilen eines Anhangs wird die if-Zeile fälschlich in 
der Farbe eines Kommentars angezeigt.

    // Auf ANSI ESCAPE SEQUENZ pr�fen
    if (byte == 0x1B) // ESC?

Beispiel aus Beitrag "Re: Daten vom UART am LCD ausgeben"

Verwirrt das Sonderzeichen in "pr�fen" den Syntaxparser?

[Flo (Gast)]

mach halt mal aus dem ü n ue.

Außerdem sollten Umlaute in einem Softwareprogramm sowieso nicht 
vorkommen, da sie länderspezifisch sind und die Programmierumgebung das 
kennen muss.

[g457 (Gast)]

Flo schrieb:
> Außerdem sollten Umlaute in einem Softwareprogramm sowieso nicht
> vorkommen, da sie länderspezifisch sind und die Programmierumgebung das
> kennen muss.

Dafür gibts erstens seit vielen Jahren einen gemeinsamen Standard 
(Unicode) und zweitens kann das jeder anständige(tm) Compiler (richtig) 
interpretieren. Wenn eine 'Programmierumgebung' das nicht kann, dann 
würde zumindest ich schwer über einen Wechsel selbiger nachdenken, das 
wäre ja sonst geradezu steinzeitlich.

Nix für ungut

[Uhu U. (uhu)]

Und ändert das auch nur ein Jota daran, daß der Syntaxhighlighter hier 
im Forum Probleme deswegen bekommt?

Was bitte hat der mit der benutzten 'Programmierumgebung' zu tun?

[g457 (Gast)]

Uhu Uhuhu schrieb:
> Und ändert das auch nur ein Jota daran, daß der Syntaxhighlighter hier
> im Forum Probleme deswegen bekommt?

Nope, nicht mal ein ε, brauchts auch nicht.

> Was bitte hat der mit der benutzten 'Programmierumgebung' zu tun?

Nix. Du hast den Kontext falsch verstanden (oder nicht gelesen). Dort 
ging es um die Frage, ob man in Quellcode überhaupt Sonderzeichen 
antreffen ★kann★ (respektive erwarten muss, dass welche kommen könnten) 
oder ob die dort grundsätzlich nix verloren haben, weil wir selbigen eh 
in 7bit-ASCII verfassen. Und da Sonderzeichen vorkommen ★können★ 
(Unicode sei Dank sogar plattformübergreifend einheitlich), heisst das 
automagisch auch, dass auch der Parser des Syntaxhighlighters damit 
umgehen können sollte.

..sofern obiges Problem überhaupt an jenem liegt. Könnte prinzipiell 
auch dessen Lexer oder Compiler sein, der die Grätsche macht. So oder 
so: es sollte nicht auftreten, und nur darum gehts :-)

[yalu (Gast)]

> (Unicode sei Dank sogar plattformübergreifend einheitlich)

Leider nicht, wie das fragliche Programm beweist: Es scheint in der
Windows-üblichen Latin1-Codierung verfasst worden zu sein.

Das Sonderzeichen scheint aber nicht der Grund für den Fehler zu sein.
Weiter unten im Code gibt es eine ähnliche Konstellation, die richtig
gehighlightet wird:

      // ohne Kontrolle auf G�ltigkeit
      data |= byte;

[yalu (Gast)]

Wenn man das Windows-'ü' durch ein UTF-8-'ü' ersetzt, wird auch der 
andere Code-Abschnitt richtig dargestellt, s. Anhang.

[yalu (Gast)]

Da die Windows-Umlaute auf einer UTF-8-codierten Webseite ohnehin falsch
dargestellt werden, wäre es evtl. sinnvoll, alle hochgeladenen Quell-
codedateien serverseitig in UTF-8 zu konvertieren. Mit dem file-Befehl
könnte festgestellt werden, wann eine Konvertierung erforderlich ist. Er
gibt eine der drei Meldungen

  ISO-8859 ... text ...
  UTF-8 ... text ...
  ASCII ... text ...

aus, je nachdem, ob die Datei Windows-Umlaute, UTF-8-Umlaute oder nur
ASCII-Zeichen enthält.

Damit wäre gleich beide Probleme gelöst.

[Stefan B. (Gast)]

Der Quellcode im genannten Anhang hat das ? drin, weil ich den Text aus 
Beitrag "Re: Daten vom UART am LCD ausgeben" per Copy&Paste ins 
AVR Studio übertragen hatte. Dabei entstanden die ? aus den Umlauten. 
Dann in AVR Studio die Quelldatei gespeichert hatte. Dann die Quelldatei 
hochgeladen hatte. In meinem Browser (Seamonkey) ist Zeichensatz Unicode 
(UTF-8) eingestellt, falls das beim Copy&Paste oder Hochladen relevant 
ist.

[Uhu U. (uhu)]

g457 schrieb:
>> Was bitte hat der mit der benutzten 'Programmierumgebung' zu tun?
>
> Nix. Du hast den Kontext falsch verstanden (oder nicht gelesen). Dort
> ging es um die Frage, ob man in Quellcode überhaupt Sonderzeichen
> antreffen ★kann★

Und was bitte hat das mit dem Thema dieses Threads zu tun?

[Stefan B. (Gast)]

Muss mich korrigieren (man darf ab einem gewissen Alter nicht aus dem 
Gedächnis schreiben). Die Umlaute des Copy&Paste-Textes sind im AVR 
Studio immer noch vorhanden und noch nicht in ? gewandelt.

[Sven P. (Gast)]

yalu schrieb:
> Da die Windows-Umlaute auf einer UTF-8-codierten Webseite ohnehin falsch
> dargestellt werden, wäre es evtl. sinnvoll, alle hochgeladenen Quell-
> codedateien serverseitig in UTF-8 zu konvertieren.

Dazu müsste man aber angeben, aus welcher Kodierung die Originaldaten 
kommen. latin1 (iso8859-1) z.B. sieht im Wesentlichen genauso aus, wie 
latin9 (iso8859-15), nur statt ¤ ist da ein €.
Es unterscheiden sich ja nur die Zeichenzuordnungen.

[yalu (Gast)]

Sven P. schrieb:
> Dazu müsste man aber angeben, aus welcher Kodierung die Originaldaten
> kommen.

Das geht leider nicht. Einmal davon abgesehen, dass es etwas nervig ist,
jedesmal die Zeichenkodierung mit anzugeben, wissen insbesondere die
Benutzer der Zeichenkodierung *-1252 oft gar nicht, dass sie selbige
benutzen (Wer weiß, wofür der Stern steht, braucht sich übrigens nicht
angesprochen und damit auch nicht gekränkt zu fühlen).

Aber eine automatische Erkennung der Kodierung ist doch ok. Auch wenn
sie nicht 100%ig zuverlässig ist, funktioniert sie bei gewöhnlichem
Text, wie er auch in C-Kommentaren zu finden ist, fast immer. Und wenn
sie einmal versagt, ist das auch nicht tragisch.

> latin1 (iso8859-1) z.B. sieht im Wesentlichen genauso aus, wie latin9
> (iso8859-15), nur statt ¤ ist da ein €.

Man macht beim Auftreten dieses Zeichencodes in den allerseltensten
Fällen einen Fehler, wenn man ihn als '€' interpretiert.

[Jörg W. (dl8dtl) (Moderator)]

yalu schrieb:

> Man macht beim Auftreten dieses Zeichencodes in den allerseltensten
> Fällen einen Fehler, wenn man ihn als '€' interpretiert.

Man macht noch weniger einen Fehler, wenn man ihn als ¤ interpretiert,
denn das ist das generische Währungssymbol. :-)

[Andreas S. (andreas) (Admin)]

Problem ist behoben. Wenn der Zeichensatz kein gültiges UTF-8 ist, dann 
wird angenommen dass er ISO-8859-15 ist und nach UTF-8 konvertiert.

begin
  Iconv.conv('utf-8', 'utf-8', s)
rescue Iconv::IllegalSequence
  Iconv.conv('utf-8', 'iso-8859-15', s)
end