staging.inyokaproject.org

Hallo,

in einer Textdatei stehen zwei Strings, die im Mousepad identisch aussehen, es aber nicht sind. Mit Copy&Paste jeweils geht der Login auf einer Webseite nur mit String1.

1
2

example.com
example.com

Also ob bei dem ersten String "example.com" ein unsichtbares Zeichen (am Anfang) stehen würde.

Das Beispiel-Script gibt "gleich" aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

#!/bin/bash

VAR1ok="example.com"
VAR2er="example.com"

if [ "$VAR1" = "$VAR2" ]; then
    echo "Strings are equal."
else
    echo "Strings are not equal."
fi

In "Clipman" haben die die Strings in der Zwischenablage zwei unterschiedliche Symbole, siehe Screenshot.

Damit https://stackoverflow.com/questions/4714322/what-is-the-hidden-character-in-this-string habe ich auch experimentiert:

1

$ echo "String" | perl -CS -ne 'printf "%v02X\n", $_'

sehe aber keinen Unterschied im Output.

Wie können unsichtbare Zeichen sichtbar machen? Danke.

hexdump -C [Name-der-Textdatei]

juribel schrieb:

hexdump -C [Name-der-Textdatei]

Wenn ich die Strings aus der einen Textdatei in zwei einzelne Dateien kopiere, um jeweils für die einzelnen Dateien "hexdump -C" zu machen, geht der Effekt (unsichtbares Zeichen) verloren. Das ist beim Test in dem Webformular überprüfbar.

Wie könnten die zwei Zeilen einzeln aus der Textdatei gelesen werden, ohne dass ich einen Bash Programmierkurs absolvieren muss?

Etwa so? 😀

1

hexdump -C [Name-der-Textdatei, Zeile1], [Name-der-Textdatei, Zeile2]

Danke.

Eine einzelne Zeile aus einer Datei ausgeben:

sed -n "Zeilennummer p" Dateiname

Mehrere aufeinanderfolgende Zeilen ausgeben:

sed -n "Von-Zeilennummer, Bis-Zeilennummer p" Dateiname

Die Ausgaben jeweils mit dem Pipe-Zeichen in den hexdump-Befehl umleiten.

Deine Variablen heißen VAR1ok ... aber Du testest auf $VAR1 … Das muss schiefgehen. ☺

Hallo Kuume,

aus deiner Problembeschreibung kann man vermuten, dass du mit einem <CR> Problem zu tun hast. Bei Windows ist ein Zeilenende standardmäßig <CR><LF> (\r\n=0d0a). Bei Linux ist es nur <LF> (\n=0a). Leider verwendest du mit "mousepad" einen für diese Aufgabenstellung ungeeigneten Editor. Wenn du einen richtigen Editor wie z.B. "geany" nutzen würdest, könntest du im Menü unter "Ansicht" → "Zeilenenden anzeigen" dir diese unsichtbaren Zeichen auch anzeigen lassen.

Um dein Problem nachzustellen, habe ich folgenden Versuch gemacht:

$ # Erzeuge die Testdatei x.x
$ echo -e "example.com\r\nexample.com" >x.x
$ cat x.x
example.com
example.com
$ # Zeige, wo ein nicht-druckbares Zeichen steht durch "°" mit sed ([^...]):
$ sed 's/[^[:print:]]/°/g' x.x
example.com°
example.com
$ # oder wie mit dem Beispiel von juribel:
$ sed -n '1p' x.x | xxd
00000000: 6578 616d 706c 652e 636f 6d0d 0a         example.com..
$ sed -n '2p' x.x | xxd
00000000: 6578 616d 706c 652e 636f 6d0a            example.com.
$ 

Wenn dich nicht druckbare Zeichen stören, kannst du diese mit "tr -d" oder mit "sed 's/...//g'" löschen.

@Kuume: Für das anschauen mit hexdump musst Du die Zeilen aus der Ausgangsdatei doch gar nicht in zwei neue Dateien kopieren sondern kannst einfach die Ausgangsdatei mit hexdump anschauen.

juribel schrieb:

sed -n "Von-Zeilennummer, Bis-Zeilennummer p" Dateiname

Die Ausgaben jeweils mit dem Pipe-Zeichen in den hexdump-Befehl umleiten.

Ok, Versuch:

1
2

$ sed -n "1,2 p" datei.txt > hexdump -C
sed: Ungültige Option -- C

Sorry ich bin Bash DAU 😇

@shiro, danke für das ausführliche Bsp.! Da muss ich aufpassen, wo ich die zwei identisch aussehenden Strings hineinkopiere und ob dabei nicht das unsichtbare Zeichen verloren geht? Ein Screenshot (siehe unten in diesem Beitrag) von der Datei mit Geany. Die Datei kommt von einem Android Gerät mit Markor-Editor. Und auch die Datei zu Xubuntu rüberkopieren behält bei dem zweiten String den Effekt, dass dieser nicht im Webformularfeld angenommen wird. Mit den Zeilenenden hat es wohl nichts zu tun...

Wenn "Marc_BlackJack_Rintsch", Vorschlag nicht gekommen wäre hätte ich mit shiro's Script mehr Zeit investiert. Danke.

Marc_BlackJack_Rintsch schrieb:

@Kuume: Für das anschauen mit hexdump musst Du die Zeilen aus der Ausgangsdatei doch gar nicht in zwei neue Dateien kopieren sondern kannst einfach die Ausgangsdatei mit hexdump anschauen.

Ok. Also hier nun, ist das das versteckte Zeichen?

1
2
3
4
5

$ hexdump -C datei.txt
00000000  6d ** ** ** ** ** ** **  6c ** ** ** ** ** ** **  |example.com|
00000010  0a ** ** ** ** ** ** **  40 ** ** ** ** ** ** **  |....example|     # der String der nicht funktionert
00000020  2e 6f 72 67 0a                                    |.com.|
00000025

Im Editor sieht das obige so aus:

1
2

example.com
example.com     # der String der nicht funktionert

Was passiert da? Da steht ein unsichtbares Zeichen am Anfang des zweiten Strings, oder? Bzw. ist dort auch ein unsichtbarer Zeilenumbruch (bei .com)? Wie kann das dorthin gelangen (allerdings wahrscheinlich unter Android passiert!)?

Danke.

1. Warum schwärzt du alles aus bzw. machst den Hexdump mit Sternchen unlesbar? Hier möchten ja alle helfen, aber so wird das nichts!

2. Zu meinem Beispiel: ein ">" ist kein Pipe-Zeichen. Mit dem Grösser-Pfeil leitest du die Terminal-Ausgabe eines Befehls in eine Datei um. Das Pipe-Zeichen ist "|", damit leitest du die Ausgabe eines Befehls als Eingabe in einen anderen Befehl (hier hexdump -C) um.

juribel schrieb:

1. Warum schwärzt du alles aus bzw. machst den Hexdump mit Sternchen unlesbar? Hier möchten ja alle helfen, aber so wird das nichts!

Weil das hier öffentlich ist und die Information vllt. auf der entsprechenden Webseite missbraucht werden könnte? Ich bin lieber vorsichtig.

Reicht das "hexdump Bsp." nicht schon?

1
2
3

|example.com|
|....example|
|.com.|

Wenn das so aussehen sollte:

1
2

example.com
example.com

Nein, reicht nicht. Du möchtest unsichtbare störende Zeichen sichtbar haben, verbirgst uns aber die zugehörigen Hexcodes. Die Hexcodes, die du mit Sternchen unlesbar gemacht hast, sind nichts weiter als die hexadezimale Darstellung der Zeichen wie "example...", also wirklich kein schützenswertes Geheimnis. Punkte und Sternchen sind hier keine Hilfe, sie deuten hier nur an, dass da irgendwas ist, aber das wusstest du ja auch schon bei deiner ersten Fragestellung.

Ich stimme dir natürlich trotzdem zu, dass es im Internet besser ist, Vorsicht walten zu lassen. Ist klar ☺

@Kuume: Ein Beispiel, wie es mit dem Control-Character Hex 02 aussehen könnte:

$ c=$'\x02';echo -e "example.com\n${c}${c}${c}example.com" | tee x.x; xxd x.x; sed 's/[^[:print:]]/°/g' x.x
example.com
example.com
00000000: 6578 616d 706c 652e 636f 6d0a 0202 0265  example.com....e
00000010: 7861 6d70 6c65 2e63 6f6d 0a              xample.com.
example.com
°°°example.com
$ 

PS: Irgendwas stimmt nicht bei deiner "hexdump" Ausgabe. Der erste Buchstabe (6d) ist ein "m" und kein "e". Weiterhin sollten in der ersten Zeile 16 Hex-Zeichen sein, und im rechten Block auch. Dort steht aber "example.com" und das sind nur 11 Zeichen! Wenn du also Probleme hast die Zeichen mitzuteilen, schicke die Datei einfach durch "sed" um die druckbaren Zeichen in ein "X" zu verwandeln. z.B. so:

$ cat x.x | xxd ;sed 's/[[:print:]]/X/g' x.x | xxd
00000000: 6578 616d 706c 652e 636f 6d0a 0d0d 0d65  example.com....e
00000010: 7861 6d70 6c65 2e63 6f6d 0a              xample.com.
00000000: 5858 5858 5858 5858 5858 580a 0d0d 0d58  XXXXXXXXXXX....X
00000010: 5858 5858 5858 5858 5858 0a              XXXXXXXXXX.
$ 

Natürlich nur den "sed ... xxd" Teil veröffentlichen.

Ich nehme immer od z.B. als od -t x1c datei | less.

@Kuume: Das ist komisch: In Deinem (bearbeiteten) Hexdump endet die Datei mit einem Zeilenvorschub (Hexadezimal 0a, englisch „line feed“, gängige Abkürzung LF), im Bildschirmfoto von Geany tut sie das nicht. 🤔

hexdump -C zeigt immer sechzehn Bytes als zweistellige Hexzahlen und dann diese 16 Bytes noch mal als ASCII-Zeichen an, beziehungsweise als Punkt, falls es für den jeweiligen Wert kein druckbares Zeichen gibt.

Das bei zweimal der gleichen Information und wenn beide Zeilen mit einem LF angeschlossen sind, die Anzahl der Bytes in der Datei ungerade ist, bedeutet zwangsläufig, dass die beiden Informationen unterschiedlich viele Bytes haben müssen.