encrypt a letter in Javascript

[jayender.vs]

Well .. i have a text box .. and in that i will enter a letter say"A"
and in return there should be a message box saying the encrypted value
say "J".
In simple :
how to encrypt a letter in Javascript...???

thanks,
Jayender

 

[Lasse Reichstein Nielsen]

Well .. i have a text box .. and in that i will enter a letter say"A"
and in return there should be a message box saying the encrypted value
say "J".

Why "J"?

In simple :
how to encrypt a letter in Javascript...???

It's really simple:
----
<script type="text/javascript">
function encrypt(text) {
// your encryption algorithm here
}
function update(input) {
setTimeout(function(){
document.getElementById("output").value = encrypt(input.value);
},1);
}
</script>
<textarea
onkeypress="update(this)">
</textarea>

<textarea id="output"></textarea>
----

You will have to specify which letters are mapped to which other letter,
i.e., why "A" becomes "J", what "B" becomes, etc.

/L

 

[Randy Webb]

(e-mail address removed) said the following on 5/25/2006 8:43 AM:

Well .. i have a text box .. and in that i will enter a letter say"A"
and in return there should be a message box saying the encrypted value
say "J".
In simple :
how to encrypt a letter in Javascript...???

You need a lookup table with the values to be transposed:

var lookup = new Object();
lookup[a] = "j";
lookup[A] = "J";

And so on.

Then, you loop through each character of the input's value and convert
it. Or, use the onkeyup event handler to convert it each time a letter
is pressed. That can get messy with the backspace and delete keys though.

 

[Randy Webb]

Lasse Reichstein Nielsen said the following on 5/25/2006 9:11 AM:

Why "J"?


It's really simple:
----
<script type="text/javascript">
function encrypt(text) {
// your encryption algorithm here
}
function update(input) {
setTimeout(function(){
document.getElementById("output").value = encrypt(input.value);
},1);
}
</script>
<textarea
onkeypress="update(this)">
</textarea>

<textarea id="output"></textarea>

And decide how to handle the delete and backspace keys

Use the onchange and do it only once.

 

[Thomas 'PointedEars' Lahn]

<script type="text/javascript">
function encrypt(text) {
// your encryption algorithm here
}
function update(input) {
setTimeout(function(){
document.getElementById("output").value = encrypt(input.value);
},1);
}
</script>
<textarea
onkeypress="update(this)">
</textarea>

<textarea id="output"></textarea>

Could you please elaborate on why you deem the setTimeout()
construction and the gEBI reference worm necessary?


PointedEars

 

[Lasse Reichstein Nielsen]

Could you please elaborate on why you deem the setTimeout()
construction and the gEBI reference worm necessary?

gEBI: It's the simplest way to refer to an element (notice that
neither textarea is inside a form).

setTimeout: The conversion is triggered by a "keypress" event.
This is a cancellable event that happens before the default
behavior (e.g., inserting the pressed letter). The timeout waits
for the default behavior to have happened, so the encryption is
performed on the fully updated input.

/L

 

[Thomas 'PointedEars' Lahn]

gEBI: It's the simplest way to refer to an element (notice that
neither textarea is inside a form).

It would have been better (and more simple) to give the controls a name
(instead of an ID) and to make them part of a form. Because that would
have allowed the developer to use both backwards-compatible and standards
compliant references to access the element objects that represent the
controls in the DOM.

However, even if the markup would be kept as is, certainly it would have
been better to test if gEBI returned a viable reference before using its
return value in a property access. Such reference worms are the direct
result of the ill-advised preconception that what works in one UA also
must work in another.

setTimeout: The conversion is triggered by a "keypress" event.

Yes, it is.

This is a cancellable event that happens before the default
behavior (e.g., inserting the pressed letter).

So one should better had made use of the `keyup' event, instead of
attempting to produce an unreliable delay through an equally unreliable
proprietary host-defined feature.

The timeout waits for the default behavior to have happened,

Not at all. Instead, because it is too small for the minimum time frame
known to be assigned to the process from the scheduler, a one millisecond
timeout will either not cause a delay at all, or delay for an undefined
non-zero number of milliseconds, at least the size of the scheduled time
frame, depending on the implementation and the OS. In that time, if there
was a timing issue (which I doubt), it may as well be that the default
behavior did not happen due to some other factors we cannot know of.

so the encryption is performed on the fully updated input.

Non sequitur.


PointedEars

 

[Lasse Reichstein Nielsen]

Lasse Reichstein Nielsen wrote:

It would have been better (and more simple) to give the controls a name
(instead of an ID) and to make them part of a form. Because that would
have allowed the developer to use both backwards-compatible and standards
compliant references to access the element objects that represent the
controls in the DOM.

That would be a workaround. There is no form because there is no
relevant action attribute to give the form, i.e., the form isn't
really a form, it's just a programming hack to allow another way
to address elements.

However, even if the markup would be kept as is, certainly it would have
been better to test if gEBI returned a viable reference before using its
return value in a property access. Such reference worms are the direct
result of the ill-advised preconception that what works in one UA also
must work in another.

In this case it's te result of deliberatly not writing for non-W3C-DOM
compliant browsers. Should fallback for such browsers be deemed
necessary, obviously it should be added.

<URL:http://pointedears.de/scripts/test/whatami#inference>

No inference here, just assumptions (of requirements being satisfied).

Yes, it is.


So one should better had made use of the `keyup' event, instead of
attempting to produce an unreliable delay through an equally unreliable
proprietary host-defined feature.

I can see that the keyup event happens after the character is added to
the textarea in my browser. However, since we are mentioning standards,
there is no specification of key events in the DOM2 Events specification,
so that could be a conincidence.

Personally, I would prefer writing the entire text and the pressing a
key to convert it, but the OP asked for continuous conversion.
Another approach would be using setInterval to convert repeatedly with
a small interval. This would be just as non-standard, obviously.

Not at all. Instead, because it is too small for the minimum time frame
known to be assigned to the process from the scheduler, a one millisecond
timeout will either not cause a delay at all, or delay for an undefined
non-zero number of milliseconds, at least the size of the scheduled time
frame, depending on the implementation and the OS.

I assume here that the script is being executed single-threaded, so at
least the timer event won't trigger until after the current event is
finished.

In that time, if there was a timing issue (which I doubt), it may as
well be that the default behavior did not happen due to some other
factors we cannot know of.

It is true that if any other execution comes between the key event and
the timer event, the content of the textarea could have changed. I can
live with that. In fact, it would be desireable that the conversion
happens after any change to the input textarea.

Yet another approach is to have each keypress/keyup schedule a
conversion 500ms later, and having new key events in the meantime
cancel the timer and create a new. Especially if conversion is
time consuming.

The possibilities are endless, but there is no completely standard
compliant way of having continous updates when neither timers
nor key events are standardized.

/L

 

[Thomas 'PointedEars' Lahn]

That would be a workaround. There is no form because there is no
relevant action attribute to give the form,

Of course there is: action=""

i.e., the form isn't really a form, it's just a programming hack to allow
another way to address elements.

That does not matter. First, with only two textareas and without a submit
button it is usually not possible to submit the form. Second, even if we
ignore that, this requires client-side scripting to work. So a) it is
possible to cancel the a submit event that could be triggered somehow and
b) it is possible to generate the whole form with client-side scripting.

On the other hand, it would be possible to extend the functionality of
the form so that in case client-side scripting is not available, the
server-side alternative would be triggered instead (which required an
additional control to trigger either of those, like a submit button,
of course.)

In this case it's te result of deliberatly not writing for non-W3C-DOM
compliant browsers.

A questionable statement, for the implementation of the HTMLDocument
interface in the proprietary host-defined property `document' of the
Global Object (or the proprietary host-defined `window' property),
is itself not fully "W3C-DOM compliant", and the interface may still
be implemented any other, maybe more "W3C-DOM compliant" way.

Should fallback for such browsers be deemed necessary, obviously it
should be added.
ACK


No inference here, just assumptions (of requirements being satisfied).

Yes, unfortunately there is.

[keypress] is a cancellable event that happens before the default
behavior (e.g., inserting the pressed letter).

So one should better had made use of the `keyup' event, instead of
attempting to produce an unreliable delay through an equally unreliable
proprietary host-defined feature.

I can see that the keyup event happens after the character is added to
the textarea in my browser. However, since we are mentioning standards,
there is no specification of key events in the DOM2 Events specification,
so that could be a conincidence.

Not really:

<URL:http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.3>

And <http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-keyup>,
although not being usable as reference material due to its early WD
status, can provide some indication of how keyboard events are going to be
standardized (and are implemented already, at least partially in Geckos).
As you can see, the `keypress' event is intentionally missing there (there
is `keydown' already to detect a key being pressed but not yet released).

I assume here that the script is being executed single-threaded, so at
least the timer event won't trigger until after the current event is
finished.

You cannot know this.

It is true that if any other execution comes between the key event and
the timer event, the content of the textarea could have changed.
I can live with that.

But that was not my point at all. Instead, I was pointing out that it is
entirely possible that the default behavior (change of the value/content
of the control/textarea) did _not_ happen yet then. So you are retrieving
and encrypting the _old_ value then. This cannot (well, SHOULD NOT) happen
with `keyup'.


PointedEars