user15552: All the terminologies I find seem rather confusing about what explains what and they usually miss a few steps.  
Example: Transaction 82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653
Found at https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653
Shows an "Input Script" of:
3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01
03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27
So, what parts of that are what, and how can I tell which parts are what in this transaction's "input script" as well as others?

user208: 
3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01 

is an ECDSA signature with the sender's key.

03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27

is the sender's public key (whose hash is stored in the address the coins were previously sent to).
However, in order to interpret these, you need to look at the output being spent, which is:

OP_DUP OP_HASH160 6ffdc2e9e69434a7832208db5a6148c67563e8ae OP_EQUALVERIFY OP_CHECKSIG 

Which is a script that takes as input a public key and a signature, checks whether the hash of the public key is 6ffdc2e9e69434a7832208db5a6148c67563e8ae, and then verifies the signature against that public key.
In general, in order to know what is what in a scriptSig, you need to look at the output being spent. The output gives the conditions under which it can be spent (in the form of a script), and the input just contains the "variables" passed into the output's verification routine.

user38482: the signature: 483045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01
and it's decomposition:
  ##################################################################
  ### tcls_in_sig_script.sh: decode SIG_script OPCODES from a TX ###
  ##################################################################
    48: OP_DATA_0x48:     push hex 48 (decimal 72) bytes as data
    30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
    45: OP_LENGTH_0x45:   length of R + S
    02: OP_INT_0x02:      type tag indicating INTEGER
    21: OP_LENGTH_0x21:   this is SIG R
        00D52330113CCD03:3CCB1AAA3B759E96
        96C216E802922E5F:1902CD5ADA69C612
        E5
    02: OP_INT_0x02:      type tag indicating INTEGER
    20: OP_LENGTH_0x20:   this is SIG S
        57880205319DCCB0:5EEBBE34323A852E
        E82653F09F81253D:DCCD08A810E9D42D
    01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)


user208: 
3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01

Is a DER encoded ECDSA signature. I'll break it down:

30

indicates that a compound structure follows (ECDSA signatures are treated as a compound of 2 integers, r and s)

45

is the total length of the compound structure (excluding the 2 header bytes, 30 45), 69.

02

the start of the contents of the compound structure, 02 indicates an integer (the signature's r value)

21

of 33 bytes

00d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5

the integer's value encoded in 33 big-endian bytes. The first byte is zero, as without it, it would be interpreted as a negative number (see 2's complement notation).

02

another integer follows (s)

20

of 32 bytes

57880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d

the 32 bytes encoding the s value

01

this is a sighash byte appended by Bitcoin, and is not technically part of the ECDSA signature. As such, it's not counted as part of the length 69 (byte 45) at the start. It indicates what fields of the transaction are signed. 01 means "all".

15552: <p>All the terminologies I find seem rather confusing about what explains what and they usually miss a few steps.  </p>

<p>Example: Transaction 82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653</p>

<p>Found at <a href="https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653" rel="nofollow noreferrer">https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653</a></p>

<p>Shows an "Input Script" of:</p>

<p>3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01
03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27</p>

<p>So, what parts of that are what, and how can I tell which parts are what in this transaction's "input script" as well as others?</p>
 208: <blockquote>
  <p>3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01 </p>
</blockquote>

<p>is an ECDSA signature with the sender's key.</p>

<blockquote>
  <p>03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27</p>
</blockquote>

<p>is the sender's public key (whose hash is stored in the address the coins were previously sent to).</p>

<p>However, in order to interpret these, you need to look at the output being spent, which is:</p>

<blockquote>
  <p>OP_DUP OP_HASH160 6ffdc2e9e69434a7832208db5a6148c67563e8ae OP_EQUALVERIFY OP_CHECKSIG </p>
</blockquote>

<p>Which is a script that takes as input a public key and a signature, checks whether the hash of the public key is <code>6ffdc2e9e69434a7832208db5a6148c67563e8ae</code>, and then verifies the signature against that public key.</p>

<p>In general, in order to know what is what in a scriptSig, you need to look at the output being spent. The output gives the conditions under which it can be spent (in the form of a script), and the input just contains the "variables" passed into the output's verification routine.</p>
 38482: <p>the signature: 483045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01</p>

<p>and it's decomposition:</p>

<pre><code>  ##################################################################
  ### tcls_in_sig_script.sh: decode SIG_script OPCODES from a TX ###
  ##################################################################
    48: OP_DATA_0x48:     push hex 48 (decimal 72) bytes as data
    30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
    45: OP_LENGTH_0x45:   length of R + S
    02: OP_INT_0x02:      type tag indicating INTEGER
    21: OP_LENGTH_0x21:   this is SIG R
        00D52330113CCD03:3CCB1AAA3B759E96
        96C216E802922E5F:1902CD5ADA69C612
        E5
    02: OP_INT_0x02:      type tag indicating INTEGER
    20: OP_LENGTH_0x20:   this is SIG S
        57880205319DCCB0:5EEBBE34323A852E
        E82653F09F81253D:DCCD08A810E9D42D
    01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)
</code></pre>
 208: <blockquote>
  <p>3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01</p>
</blockquote>

<p>Is a DER encoded ECDSA signature. I'll break it down:</p>

<blockquote>
  <p>30</p>
</blockquote>

<p>indicates that a compound structure follows (ECDSA signatures are treated as a compound of 2 integers, r and s)</p>

<blockquote>
  <p>45</p>
</blockquote>

<p>is the total length of the compound structure (excluding the 2 header bytes, 30 45), 69.</p>

<blockquote>
  <p>02</p>
</blockquote>

<p>the start of the contents of the compound structure, 02 indicates an integer (the signature's r value)</p>

<blockquote>
  <p>21</p>
</blockquote>

<p>of 33 bytes</p>

<blockquote>
  <p>00d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5</p>
</blockquote>

<p>the integer's value encoded in 33 big-endian bytes. The first byte is zero, as without it, it would be interpreted as a negative number (see 2's complement notation).</p>

<blockquote>
  <p>02</p>
</blockquote>

<p>another integer follows (s)</p>

<blockquote>
  <p>20</p>
</blockquote>

<p>of 32 bytes</p>

<blockquote>
  <p>57880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d</p>
</blockquote>

<p>the 32 bytes encoding the s value</p>

<blockquote>
  <p>01</p>
</blockquote>

<p>this is a sighash byte appended by Bitcoin, and is not technically part of the ECDSA signature. As such, it's not counted as part of the length 69 (byte 45) at the start. It indicates what fields of the transaction are signed. 01 means "all".</p>
