A block is a well-ordered set of transactions that are plainly readable, as well as header information containing metadata such as the previous block hash for block ordering purposes. I should mention that a single block is insufficient to confirm the authenticity of the block itself.
Transactions contain some fields (partial list) such as
from is an address that signed the transaction and
amount is ETH sent. Those are plain to see. A single block is insufficient to interpret
data in every case.
to may be a contract. Without knowledge of what the contract does (the code), this is ambiguous, but it is sufficient to catch transactions directed to a particular address.
data is also ambiguous because it gains meaning through interpretation by the receiver. The first 4 bytes may be a function signature if the transaction is directed to a contract. The remaining n bytes correspond to a field layout defined in a contract function. This will be hard to interpret in every case without the knowledge of the
to contract. In an idealized form, that knowledge comes from interpreting a previous block that contains a deployment transaction with bytecode (roughly,
to: 0x0, data: bytecode) for the contract of interest.
If one is interested in a narrow band of contracts (say, ERC20 token transfers), then one does indeed "have knowledge of the contract" - the function signatures and field layouts.
Some contracts will deliberately obfuscate
data by encrypting client-side before data is sent to a blockchain precisely because plain data is readable by everyone.
Hope it helps.