Skip to content

Missing parse function #65

Description

@1chb

Shouldn't there be a parse function? Given a base64 encoded string from the untyped world out there, do I really need to both check if its encoding is correct and then assert that it is correct? I looked for a function of type a -> Either e (Base64 k a) and a -> Maybe (Base64 k a) but couldn't find anything.

Activity

  1. emilypi commented on Feb 12, 2025

    @emilypi
    Owner

    The problem with base64 is that you can have a string that consists only of valid characters from a particular base64 alphabet, and have it still be structurally incorrect base64, because the bytes are messed up in one way or another. The only real way to know that a string is base64 is to actually decode it and check to see if the value is correct, and produce errors along the way. decodeBase64Untyped and the like are roughly that process, so to parse is to decode and validate whether you have an error. I provide a quick check in the form of isBase64, which produces a Bool, which isn't quite what you want, but the decode step is exactly the shape of what you want:

    decodeBase64Untyped :: ByteString -> Either Text ByteString
    .

    Otherwise, if you want something that asserts this yourself, i mean, it doesn't quite meet my Fairbarn threshold for writing a new function, since it's special in the sense that it's basically \b -> if isBase64 b then assertBase64 b else "your error" or simply \b -> assertBase64 b <$ decodeBase64Untyped b.

  2. emilypi commented on Feb 16, 2025

    @emilypi
    Owner

    Though, actually, now that i think about it, this would also subsume the isValid check and I could remove some code. Do you want to work on this or should i?

  3. 9999years commented on Jun 10, 2025

    @9999years

    The only real way to know that a string is base64 is to actually decode it and check to see if the value is correct, and produce errors along the way

    If this is the case, I'm not sure I understand the value of the new type signatures for decodeBase64. If they encode an invariant that can't be checked, why bother? It's very rare for a base64 value to come from within a program (why bother base64 encoding it if it's going to stay within the program between encoding and decoding anyways?), so almost all base64 values we want to decode come from the disk or the network as untagged bytes.

  4. emilypi commented on Jun 10, 2025

    @emilypi
    Owner

    If they encode an invariant that can't be checked, why bother? It's very rare for a base64 value to come from within a program (why bother base64 encoding it if it's going to stay within the program between encoding and decoding anyways?)

    Well that's not necessarily the case. When you can establish the provenance of the values being produced, you can sidestep alot of that invariant checking and optimize the decode process. Establishing that kinda provenance isn't so tough - it can happen within networks of microservices and doesn't necesssarily have to come out of network band, if off-prem. So this library addresses both. You have options. God forbid we get a little optimism in our lives 😄

    If you don't like those options, there's always base64-bytestring which just always does the pessimistic thing and I'd encourage you to use that if you just like rawdogging your bytes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions