Split von Texten an nicht druckbaren Zeichen

Ich habe Text mit unterschiedlichen nicht druckbaren Zeichen,
z.B. HEX’11’.
Wie kann ich diese splitten?
Wie kann ich an der Stelle des * einen Hex-Wertangeben?

Look in the Gallery for the app CRLF.

Why do you have non-printable characters in text values?
Where do they come from?CR CRLF hexify LF TAB

These draggable blocks will do hex conversion under 7F.
A Web component is required for the hexify procedure.

1 Like

Danke, es funktioniert.
Jetzt würde mich noch der umgekehrte Weg interessieren, d.h. wie kann man ein nicht druckbares Zeichen wie z.B. x’09’ als ‘09’ sichtbar machen (konvertieren)?

Und ein neues Problem, wenn an zwei Sonderzeichen getrennt werden soll.
Eine Trennung erfolgt problemlos bei z.B. “xy”, aber auch im folgenden Beispiel:

Es funktioniert aber nicht im folgenden Beispiel:

Woran liegt dies?

See Redirecting to Google Groups
from FAQ section: Maths
(I guess those belong in the Text FAQ more than the Math FAQ)

Draggable blocks ...
asc asc_test AsciiCHRASCprocedures.aia (4.0 KB) chr chr_test
(Blocks by @Italo)

The German to English translator mangled your comparison of x'0809' vs x'0D0A' split efficacy.
I can't tell from the translation which one worked for you.

I also had trouble splitting an input file at CRLF recently, and had to settle on splitting it at \n and leaving the CR at the end of the text items, where it did no harm.
I can't explain that. Some of the text blocks are smarter than they advertise.

x’0809" works.
x’0D0A’ does not.

I got an idea for what might be happening.
It needs some experiments, though.

I remember from working with the FTP program that when it copies a file across different architectures (Windows vs Unix vs IBM mainframe) it changes the line ending codes to match the expectations of the target operating system:

  • Windows: CRLF
  • unix (Android): LF
  • mainframe: new record.

So the first question to ask is:

  • Does the Android file whose content hits the split block actually contain CRLF?
  • Does the text value that arrives from a File Get of an Android file still hold the CRLF sequence?

These questions can be answered with some experiments:

  • What value is returned by the index in text block for CR? 0 or non-zero? (0 tells us the CR has been dropped along the way in.)
  • How do the file sizes compare between pre-upload and post-upload?
  • How well would split at CRLF work against a hand-built piece of text we know contains CRLF in its interior?

I leave these experiments to you, the Original Poster.
Please let us know what you discover.

If you like readable hex, the decimal value returned by the asc() function can be passed through the math block that converts decimal to hexadecimal text.
Wrap the result with x' ' if you like.

Seltsam, strange:

Aus dem ASCII-Zeichen 90 wird in der Datei korrekt ‘Z’

Aus dem ASCII-Zeichen 10 wird x’E29799’ also 3 Character!

Ich blicke nicht mehr durch!

What tool do you use to see the file contents in hex on Android?

With HEX (Hex Editor) and with WH (WindHex)