encrypt a letter in Javascript

Discussion in 'Javascript' started by jayender.vs@gmail.com, May 25, 2006.

  1. Guest

    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
    , May 25, 2006
    #1
    1. Advertising

  2. writes:

    > 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
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, May 25, 2006
    #2
    1. Advertising

  3. Randy Webb Guest

    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
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
    Randy Webb, May 25, 2006
    #3
  4. Randy Webb Guest

    Lasse Reichstein Nielsen said the following on 5/25/2006 9:11 AM:
    > writes:
    >
    >> 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.


    And decide how to handle the delete and backspace keys :)

    Use the onchange and do it only once.

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
    Randy Webb, May 25, 2006
    #4
  5. Lasse Reichstein Nielsen wrote:

    > <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
    --
    Indiana Jones: The Name of God. Jehovah.
    Professor Henry Jones: But in the Latin alphabet,
    "Jehovah" begins with an "I".
    Indiana Jones: J-...
    Thomas 'PointedEars' Lahn, May 26, 2006
    #5
  6. Thomas 'PointedEars' Lahn <> writes:

    > 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
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, May 27, 2006
    #6
  7. Lasse Reichstein Nielsen wrote:

    > Thomas 'PointedEars' Lahn <> writes:
    >> 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).


    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.

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

    > 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
    --
    Indiana Jones: The Name of God. Jehovah.
    Professor Henry Jones: But in the Latin alphabet,
    "Jehovah" begins with an "I".
    Indiana Jones: J-...
    Thomas 'PointedEars' Lahn, May 27, 2006
    #7
  8. Thomas 'PointedEars' Lahn <> writes:

    > 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).

    >
    >> 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.


    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.

    >> 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.


    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
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, May 27, 2006
    #8
  9. Lasse Reichstein Nielsen wrote:

    > Thomas 'PointedEars' Lahn <> writes:
    >> 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,


    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.)

    >> 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.


    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

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

    >
    > 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).

    >>> 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.

    >
    > 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.

    >> 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.


    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
    --
    Alcohol and Math don't mix. So please don't drink and derive!
    Thomas 'PointedEars' Lahn, May 27, 2006
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. vertigo

    big letter -> small letter

    vertigo, Jul 6, 2004, in forum: Python
    Replies:
    4
    Views:
    744
    Reinhold Birkenfeld
    Jul 6, 2004
  2. Tony Meyer

    RE: big letter -> small letter

    Tony Meyer, Jul 6, 2004, in forum: Python
    Replies:
    0
    Views:
    491
    Tony Meyer
    Jul 6, 2004
  3. Andrew McNamara

    Re: big letter -> small letter

    Andrew McNamara, Jul 6, 2004, in forum: Python
    Replies:
    2
    Views:
    739
    Scott David Daniels
    Jul 6, 2004
  4. http://ejobseek.com

    Encrypt in Perl, De-encrypt in Javascript

    http://ejobseek.com, Sep 1, 2003, in forum: Perl Misc
    Replies:
    3
    Views:
    268
    James Willmore
    Sep 1, 2003
  5. Fungii
    Replies:
    6
    Views:
    151
Loading...

Share This Page