Bug 230895

Hi Matthias, yes, you are missing something :) The "Copy As" submenu of the "Edit" menu. Select "Values" there.
Currently a plain copy only copies the raw data. If it is text it of course appears as the characters of the local encoding if pasted.
But you are not the first one to be confused by this. Perhaps one day I will (re-)add the feature, that as an alternative the clipboard also gets the decoded data like visible in the active column, so values or text (with selected encoding).
And Okteta misses a context menu, you might have found that option there.

Hi Friedrich,

thanks for your prompt reply! Thanks for your explanation, yet I don't manage to produce the desired effect. 

I have this wordpress exploit which I wanted to examine. It injects javascript code in hex form. So for example, I have something like this: 3C736372697074206C616E67756167653D226A617661736372697074223E66756E63746 ...
I wanted to decode that using okteta, so I tried to paste this content (=the hex data) into the "values pane". It got pasted in the "char pane" though, so I got the following hex data: 33 43 37 33 36 33 37 32 36 39 37 30 37 34 32 30 36 43 36 31 36 45 36 37 37 35 36 31 36 37 36 35 33 44 32 32 36 41 36 31 37 36 36 31 37 33 36 33 37 32 36 39 37 30 37 34 32 32 33 45 36 36 37 35 36 45 36 33 37 34 36 which is not what I want (I want <script language="javascript">funct .. ).

The "copy as" seems to be only valid for copying data TO the clipboard while I want it to be configurable when fetching data FROM the clipboard. When I want to paste data, "copy as" is grayed out (which seems normal to me because I have no selection).

I hope I made my case clear, sorry if I am too elaborate. Or if it is still not clear, I will try again :)

You are right about the context menu, I tried it that way. Second way I tried was through the edit menu where I expected something like "paste as".

btw, thanks for this great program. It is these kind of little tools I don't need often but still need that make the KDE SC a complete solution!

Ah, Paste, not Copy (it's even in the report title, but you used the term "Copy" in the body text, it was similar to that mentioned other problem and late in the evening I got this wrong, sorry).

So rather: No, you sadly did not miss anything. It's Okteta which is missing something, support for parsing. Both the infrastructur as well as individual format support. Perhaps this comes for SC 4.5 mid-2010, but might also only be for 4.6 or later. But I am thinking a lot about this, because it is also needed for something else, so... no promises, though ;)

And thanks for the thanks :)

ah, now I understand the confusion! I guess it was getting late for me too ;) Feel free to adjust the bug description (I tried, but failed)

still not working...

Please write this feature, it is higly needed by us users.
I remember also that the old KHexEditor had this feature too, so it couldn't be so difficult for you to port it.

You have my vote! Very useful feature.

So it's basically "paste hex from clipboard as binary data" ? I would need this feature too..

What Okteta would need is "Paste as" -> "Binary data from HEX"  menu item? I don't think that would be hard to implement... myself..?

Also, "Binary data from base64" and others would be quite usefull.

This feature will be awesome!

Small update:  
Since 0.26.23 (released Aug 8th 2025) there is a change which does not yet fix the bug, but might serve more of the real world use cases like the one reported in the comment 2:

on a paste (or drop) the clipboard/drag content will be first checked if there is a plain text variant, if so, if it can be, depending on cursor focus, decoded using current byte value type or current 8-bit charset (supporting "\" escaping for non-printable bytes) and in that case then use bytes from the decoding, otherwise fall back to using as before raw data, either of some explicit application/octet-stream variant or the first available data variant.
More, when dropping data to create some new byte array (on empty pane or next to tabs), again there will be a check for plain text and if it can be, with higher priority be decoded as hex values, or otherwise be decoded as (escaped) iso-8869-1 chars, only then again as before taking as raw data.
So one can e.g. start Okteta, here in the page select the example data of the comment 2, drag and drop onto the empty Okteta pane ,and get a new byte array, with the bytes matching the hex data there and the chars displaying respectively the <script language="javascript">funct.

Allowing the user to chose what to use is still to-do, for now the above heuristic is hard-coded, so leaving the bug open.

*** Bug 398638 has been marked as a duplicate of this bug. ***