1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

Anyone has an idea how to attach encoded base64 script to a div and execute

Discussion in 'JavaScript' started by ketting00, Mar 30, 2015.

  1. #1
    Hi guys,

    I've tried the code below unsuccessful. Anyone has an idea how to make it worked.
    
    var a = 'Y29uc29sZS5sb2coJ2FiY2RlZmdoaWxtbmprJyk=';
    
    var b = document,
        c = b.getElementById('myDiv'),
        d = b.createElement('script');
    
    d.src = 'data:text/javascript;base64,' + a;
    c.appendChild(d);
    
    Code (markup):
    Thank you,
     
    Solved! View solution.
    ketting00, Mar 30, 2015 IP
  2. ketting00

    ketting00 Well-Known Member

    Messages:
    772
    Likes Received:
    27
    Best Answers:
    3
    Trophy Points:
    128
    #2
    Never mind. It works, just not working on some browsers.
     
    ketting00, Mar 31, 2015 IP
  3. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #3
    Is there some reason you can't just run the code normally and instead want some bloated jacktard nonsense?

    Or are you just trying to do an eval without actually calling eval?
     
    deathshadow, Apr 15, 2015 IP
  4. ketting00

    ketting00 Well-Known Member

    Messages:
    772
    Likes Received:
    27
    Best Answers:
    3
    Trophy Points:
    128
    #4
    The reason is for speed. The script is not loaded until called/requested. This is to make page lightweight and load fast.

    I'm experimenting on on demand script. The speedier loading and execution the better. Base64 maybe bloated, but I heard it's native data and it fasts and every effective form of data transfer.
     
    ketting00, Apr 17, 2015 IP
  5. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #5
    Not sure what passing it as base64 has to do with that other than making it slower and take longer; since you've effectively made the code 1.37 times + 814 bytes larger AND forcing a reparse AND a reflow by adding it to the page that way.

    That's not going to save you any time, and in fact the larger the script the less time it's going to save you -- the opposite of what it sounds like you are aiming for unless I'm completely not seeing the usage scenario.

    Speedier loading and better execution? NOT.

    Wherever you heard that is full of it. Sounds almost as stupid as some of the nonsense you'll hear from the XML zealots. Base64 is an outdated relic left over from the age of big iron and usage scenarios were you couldn't use anything outside ASCII7 or needed to transport data between 4 bit (hex) and 3 bit (octal) nybble-widths. (like between older DEC/Wang hardware and microcomputers) Using it for this? Utter and complete waste of time and resources.

    Admittedly, I say the same thing about the idiocy people are doing of pulling this same stunt with things like GIF and PNG in their CSS and/or markup. Makes me wonder just what the devil is in the kool-aid...

    But seriously, even with "waiting to load it until it's needed" (which I would actually think would be painfully slower) what practical usage scenario would dicking around with encoding it be smaller than just having the code as-is?

    Much less if you are loading the base64 inline, you've basically wasted time loading a LARGER version of the code BEFORE it's needed, in which case just load it in the first place.

    Not getting at ALL where this would speed anything up or save time or any other such thing... admittedly I'm seeing a LOT of stuff being done lately that seems to be fatter/slower/nonsensical being called faster when it makes zero sense that it would be. See 90%+ of Google's pagespeed insights at this point!
     
    Last edited: Apr 17, 2015
    deathshadow, Apr 17, 2015 IP
  6. ketting00

    ketting00 Well-Known Member

    Messages:
    772
    Likes Received:
    27
    Best Answers:
    3
    Trophy Points:
    128
    #6
    Thanks for the info. I thought base64 is already native data and the machine can use it right away after decoded without having to compile/parse it.

    Disclosure: I'm a self-taught coder, many companies rejected my job applications due to no formal education;

    Never knew about this, data I collected for many years from stackoverflow indicates that folk over there believe that base64 is an effective form of data transfer, admittedly most of them are ****hole -- sorry for the ****hole ;)
     
    ketting00, Apr 17, 2015 IP
  7. #7
    A lot of people working on computers right now don't know the origins of a lot of things; and those origins are important! When DARPAnet (what eventually became the Internet) was started a lot of systems weren't capable of or include ASCII. 3 bit, five bit, 6 bit and even 36 bit character encodings were not all that uncommon. When I first started using computers in the 70's ASCII was still considered a fairly recent concept... Even by the mid 80's you were still having new computers (like the C64) that didn't have ASCII but instead had their own proprietary character set. (in Commodore's case it was jokingly called "PETSCII")

    DEC mainframes for example used 6 bits to store text; and when you worked with it at the machine language level you used octal instead of hexadecimal.

         0  1  2  3  4  5  6  7
      +-----------------------
    0 |     !  "  #  $  %  &  '
    1 |  (  )  *  +  ,  -  .  /
    2 |  0  1  2  3  4  5  6  7
    3 |  8  9  :  ;  <  =  >  ?
    4 |  @  A  B  C  D  E  F  G
    5 |  H  I  J  K  L  M  N  O
    6 |  P  Q  R  S  T  U  V  W
    7 |  X  Y  Z  [  \  ]  ^  _
    Code (markup):
    Those were ALL the characters that were available if you were working on DEC hardware. You didn't even have the option for lower case. ECMA-1 encoding is similar, but a lot of the character symbols are masked out to provide control codes, including shift-in and shift-out to allow for upper/lower case and the "missing" characters. Using ECMA-1 on the six-bit encoded systems allowed for 0..9, a..z, A..Z -- basically the characters used in Base64.

    That's why base64 was even created, as a means of transmitting data between systems with different character limits. On "more powerful" systems translation tables could be used to turn them into the native character set. Even if the native set wasn't identical, it at least fit the six bit transmission limits. In fact accessing such translation tables are why Intel added the XLAT command to it's machine language opcode set.

    Do you know why it's called base64? See how above in octal a 6 bit character set is a 8x8 grid? What's 8 times 8? It's not a 64 bit format, it's a 6 bit format capable limited to 64 possible values; so it's ALSO inefficient at storing 7 bit ascii much less 8 bit data or multi-byte UTF.

    To turn it into something useful on 'modern' systems decoding Base64 is pretty complex -- it is NOT even CLOSE to being a 'native' format. You have to basically take every 3 bytes, load them into a variable as a number (big endian) to perform "and o77" (0x3F aka 63 decimal) and then shift it right by six. THEN you have that it could even extend further depending on the presence of significant bits.

    Generally speaking that's why saying it's "native data" is the same nonsense as the XML jokers claiming that XML is a "machine readable format" -- 100% grade A fictional BS that if you said that to a machine language programmer they'd pimp slap you halfway across the planet; XML exists to be human readable to make translation between targets easier; Are integers stored bitwise? Are strings stored RLL or zero delimited? Are floats stored as 16 bit single, 32 bit double, or 80 bit extended? No? Then it's not machine readable jackasses!

    In that same way, Base64 is NOT a "native format" -- well, unless you are working on four decade old big iron. Anyone telling you it is doesn't know what Base64 is.

    ... and yeah, I've become increasingly unimpressed with the information on StackOverflow -- so much of it now is just people talking out their asses. Sadly I'm starting to have the same impression of the stuff being added and rewritten in the Google Webmaster stuff that's becoming 100% grade A farm fresh manure.
     
    deathshadow, Apr 17, 2015 IP