U+202C
4 views
Skip to first unread message
Markus Schaaf
Sep 30, 2021, 7:18:40 AM9/30/21
to
Es passt nirgends richtig. Deshalb hier für die, die es interessiert:
Ein per Programm erstelltes Dokument ods->csv->tex->pdf blieb
nach einem Update der Daten mit blödsinniger Fehlermeldung im
pdflatex hängen. Verdacht war schon irgendein Zeichen nicht
richtig escape-t. Csv angesehen, tex angesehen, alles im Editor
angeschaltet, less, vi, nichts! (Jaja, locale auf C oder Posix,
hinterher ist man schlauer.) Tex immer weiter reduziert, bis die
3 möglichen Zeilen klar waren. Zum Schluss mit hexdump -C geschaut.
Gibt's einen Editor/Pager, der das auch mit einer Utf-8-Locale
sichtbar gemacht hätte?
MfG
Ein per Programm erstelltes Dokument ods->csv->tex->pdf blieb
nach einem Update der Daten mit blödsinniger Fehlermeldung im
pdflatex hängen. Verdacht war schon irgendein Zeichen nicht
richtig escape-t. Csv angesehen, tex angesehen, alles im Editor
angeschaltet, less, vi, nichts! (Jaja, locale auf C oder Posix,
hinterher ist man schlauer.) Tex immer weiter reduziert, bis die
3 möglichen Zeilen klar waren. Zum Schluss mit hexdump -C geschaut.
Gibt's einen Editor/Pager, der das auch mit einer Utf-8-Locale
sichtbar gemacht hätte?
MfG
Stefan Reuther
Sep 30, 2021, 12:34:44 PM9/30/21
to
Am 30.09.2021 um 13:18 schrieb Markus Schaaf:
> Gibt's einen Editor/Pager, der das auch mit einer Utf-8-Locale sichtbar
> gemacht hätte?
Sowohl joe als auch less zeigen das bei mir als <202C> an.
> Gibt's einen Editor/Pager, der das auch mit einer Utf-8-Locale sichtbar
> gemacht hätte?
Getestet auf einer älteren Debian-Installation mit joe 3.7, less 458,
sowie unter Cygwin, joe 3.7, less 471.
Stefan
Markus Schaaf
Sep 30, 2021, 1:15:49 PM9/30/21
to
Am 30.09.21 um 18:31 schrieb Stefan Reuther:
> Sowohl joe als auch less zeigen das bei mir als <202C> an.
>
> Getestet auf einer älteren Debian-Installation mit joe 3.7, less 458,
> sowie unter Cygwin, joe 3.7, less 471.
Das ist ein Windows-Ding, wahrscheinlich Utf-16. Siehe:
$LANG=C less bla
dummy-text<E2><80><AC>
bla (END)
MfG
> Sowohl joe als auch less zeigen das bei mir als <202C> an.
>
> Getestet auf einer älteren Debian-Installation mit joe 3.7, less 458,
> sowie unter Cygwin, joe 3.7, less 471.
$LANG=C less bla
dummy-text<E2><80><AC>
bla (END)
MfG
Marc Olschok
Sep 30, 2021, 5:31:29 PM9/30/21
to
zeigen (im xterm) auch das direkt an. Yudit bemerkt
das Zeichen gar nicht.
--
M.O.
Marc Olschok
Sep 30, 2021, 5:49:36 PM9/30/21
to
Aber ein Editor wird natürlich den Unicode anzeigen, weil das auch
die (kodierungsunabhängige) Information ist, auf die andere Werkzeuge
zurückgreifen, z.B.
$ bmore bla
00000000 E2 80 AC 0A ....
$ uni2ascii <bla
0x202C
$ grep 202C: /usr/local/share/unifont.hex | hexdraw.pl
202C: ----------------
----------------
----------------
----------------
-###--###--####-
-#--#-#--#-#----
-###--#--#-####-
-#----#--#-#----
-#----###--#----
----------------
----------------
----------------
----------------
----------------
----------------
----------------
--
M.O
Markus Schaaf
Oct 1, 2021, 12:52:21 AM10/1/21
to
Am 30.09.21 um 23:31 schrieb Marc Olschok:
> Bei mir zeigen vim und less es als <202c> an, more und cat
> zeigen (im xterm) auch das direkt an. Yudit bemerkt
> das Zeichen gar nicht.
Tatsächlich scheint das Terminal eine Rolle zu spielen. Im
xfce4-teminal sehe ich mit less und more nichts. Im xterm ist so
ein Rechteck zu sehen. Aber vim war ein Tipp. Der zeigt es als
<202c>. Wobei ich mich frage, ob das Absicht ist, oder nur die
Unfähigkeit, dieses Zeichen auszuwerten. So wie bei Stefans
älterem less. Hat ja wohl irgendwas mit der Leserichtung von
Fonts zu tun. Die Frage ging eher in die Richtung einer Funktion
wie "zeige Leerzeichen" und "zeige Zeilenumbrüche". Also ein
Programm, welches das Zeichen schon versteht, aber dann trotzdem
hervorheben kann. <202c> sieht nach "ich verstehe das (noch)
nicht" aus.
MfG
> Bei mir zeigen vim und less es als <202c> an, more und cat
> zeigen (im xterm) auch das direkt an. Yudit bemerkt
> das Zeichen gar nicht.
xfce4-teminal sehe ich mit less und more nichts. Im xterm ist so
ein Rechteck zu sehen. Aber vim war ein Tipp. Der zeigt es als
<202c>. Wobei ich mich frage, ob das Absicht ist, oder nur die
Unfähigkeit, dieses Zeichen auszuwerten. So wie bei Stefans
älterem less. Hat ja wohl irgendwas mit der Leserichtung von
Fonts zu tun. Die Frage ging eher in die Richtung einer Funktion
wie "zeige Leerzeichen" und "zeige Zeilenumbrüche". Also ein
Programm, welches das Zeichen schon versteht, aber dann trotzdem
hervorheben kann. <202c> sieht nach "ich verstehe das (noch)
nicht" aus.
MfG
Markus Schaaf
Oct 1, 2021, 12:54:04 AM10/1/21
to
Am 30.09.21 um 23:49 schrieb Marc Olschok:
> Unicode 202C wird unter UTF-8 als E2 80 AC codiert, das passt schon.
> Aber ein Editor wird natürlich den Unicode anzeigen, weil das auch
> die (kodierungsunabhängige) Information ist, auf die andere Werkzeuge
> zurückgreifen, z.B.
Ja, habe mich geirrt.
> Unicode 202C wird unter UTF-8 als E2 80 AC codiert, das passt schon.
> Aber ein Editor wird natürlich den Unicode anzeigen, weil das auch
> die (kodierungsunabhängige) Information ist, auf die andere Werkzeuge
> zurückgreifen, z.B.
Michael van Elst
Oct 1, 2021, 1:26:02 AM10/1/21
to
Markus Schaaf <msc...@elaboris.de> writes:
>Am 30.09.21 um 23:31 schrieb Marc Olschok:
>> Bei mir zeigen vim und less es als <202c> an, more und cat
>> zeigen (im xterm) auch das ‬ direkt an. Yudit bemerkt
>Am 30.09.21 um 23:31 schrieb Marc Olschok:
>> Bei mir zeigen vim und less es als <202c> an, more und cat
>> das Zeichen gar nicht.
>Tatsächlich scheint das Terminal eine Rolle zu spielen. Im
Der verwendete Zeichensatz. Wenn es keine Glyphe für einen Code
gibt, dann wird die eventuell ersetzt durch ein leeres Rechteck
(xterm) oder ein Fragezeichen (nvi) oder irgend eine Kodierug wie
<U+202c> (less).
>Fonts zu tun. Die Frage ging eher in die Richtung einer Funktion
>Programm, welches das Zeichen schon versteht, aber dann trotzdem
>hervorheben kann. <202c> sieht nach "ich verstehe das (noch)
>nicht" aus.
Ein Editor oder Pager, der in einem Text-Terminal läuft, kann auch
>hervorheben kann. <202c> sieht nach "ich verstehe das (noch)
>nicht" aus.
prinzipiell damit nichts anfangen, wenn er weder WYSIWYG kann noch
will. Bei Textverarbeitungen sieht es vermutlich anders aus.
Markus Schaaf
Oct 1, 2021, 5:50:22 AM10/1/21
to
Am 01.10.21 um 07:18 schrieb Michael van Elst:
>> Tatsächlich scheint das Terminal eine Rolle zu spielen. Im
>
> Der verwendete Zeichensatz. Wenn es keine Glyphe für einen Code
> gibt, dann wird die eventuell ersetzt durch ein leeres Rechteck
> (xterm) oder ein Fragezeichen (nvi) oder irgend eine Kodierug wie
> <U+202c> (less).
Von der Beschreibung her klingt es nach einem Steuerzeichen für
die Umschaltung RTL LTR. Es gibt keine Glyphe dafür. Neuere
Software versteht das und zeigt nichts an, reicht das Zeichen
aber entsprechend an den Renderer weiter. Latex scheint es
komplett zu verwirren. Es verhält sich wie ein Trojanisches
Pferd. Vermutlich ist es beim Copy&Paste (unsichtbar) in die
Office-Tabelle gekommen. Ich habe das vor allem als Warnung für
andere geschrieben, weil es mich doch sinnlos Zeit gekostet hat.
Ich vermute, mein Arch-Linux ist einfach frisch genug, um dieses
Zeichen "korrekt" zu verarbeiten, ältere stolpern da noch drüber
und zeigen etwas an. Ein richtig guter Editor sollte auf Wunsch
alle unsichtbaren Steuerzeichen hervorheben können.
Erzeugt hat dieses Ding Thunderbird beim Rendern einer HTML-Mail,
in der das Zeichen nicht vorkommt. So ein typischer Unsinn mit
Font-Auszeichnungen an jedem zweiten Wort.
MfG
>> Tatsächlich scheint das Terminal eine Rolle zu spielen. Im
>
> Der verwendete Zeichensatz. Wenn es keine Glyphe für einen Code
> gibt, dann wird die eventuell ersetzt durch ein leeres Rechteck
> (xterm) oder ein Fragezeichen (nvi) oder irgend eine Kodierug wie
> <U+202c> (less).
die Umschaltung RTL LTR. Es gibt keine Glyphe dafür. Neuere
Software versteht das und zeigt nichts an, reicht das Zeichen
aber entsprechend an den Renderer weiter. Latex scheint es
komplett zu verwirren. Es verhält sich wie ein Trojanisches
Pferd. Vermutlich ist es beim Copy&Paste (unsichtbar) in die
Office-Tabelle gekommen. Ich habe das vor allem als Warnung für
andere geschrieben, weil es mich doch sinnlos Zeit gekostet hat.
Ich vermute, mein Arch-Linux ist einfach frisch genug, um dieses
Zeichen "korrekt" zu verarbeiten, ältere stolpern da noch drüber
und zeigen etwas an. Ein richtig guter Editor sollte auf Wunsch
alle unsichtbaren Steuerzeichen hervorheben können.
Erzeugt hat dieses Ding Thunderbird beim Rendern einer HTML-Mail,
in der das Zeichen nicht vorkommt. So ein typischer Unsinn mit
Font-Auszeichnungen an jedem zweiten Wort.
MfG
Stefan Reuther
Oct 1, 2021, 12:01:52 PM10/1/21
to
Am 01.10.2021 um 06:52 schrieb Markus Schaaf:
> Am 30.09.21 um 23:31 schrieb Marc Olschok:
>> Bei mir zeigen vim und less es als <202c> an, more und cat
>> zeigen (im xterm) auch das direkt an. Yudit bemerkt
>> das Zeichen gar nicht.
>
> Tatsächlich scheint das Terminal eine Rolle zu spielen.
Und/oder die Locale-Datenbank. Wenn die sagt, "null problemo, zeig das
> Am 30.09.21 um 23:31 schrieb Marc Olschok:
>> Bei mir zeigen vim und less es als <202c> an, more und cat
>> zeigen (im xterm) auch das direkt an. Yudit bemerkt
>> das Zeichen gar nicht.
>
> Tatsächlich scheint das Terminal eine Rolle zu spielen.
Zeichen an", ...
> Im xfce4-teminal sehe ich mit less und more nichts. Im xterm ist so
> ein Rechteck zu sehen.
> Die Frage ging eher in die Richtung einer Funktion wie "zeige
> Leerzeichen" und "zeige Zeilenumbrüche". Also ein Programm, welches
> das Zeichen schon versteht, aber dann trotzdem hervorheben kann.
> <202c> sieht nach "ich verstehe das (noch) nicht" aus.
grep '[^ -~]'
auf die Datei los, um erstmal die problematischen Zeilen einzugrenzen,
was da faul sein könnte. Optional mit LC_ALL=C.
Wenn es sich bei der Datei um ein russisch/griechisch-Wörterbuch mit
schwedischen Anmerkungen handelt bringt das natürlich nix.
Stefan
Reply all
Reply to author
Forward
0 new messages