1. 24 May, 2019 1 commit
  2. 18 Aug, 2018 1 commit
  3. 05 Aug, 2018 1 commit
  4. 03 Apr, 2018 1 commit
  5. 29 Mar, 2018 1 commit
    • Harris Hancock's avatar
      Implement URL fragment, path, and userinfo component encode functions · 084f5526
      Harris Hancock authored
      According to the WHATWG URL spec, each different component of a URL gets its very own percent encode set, which we've been doing wrong this whole time.
      
      In terms of reserved characters, the fragment set is a subset of the path set, which is a subset of the userinfo set, which is a subset of RFC 2396's reserved set.
      084f5526
  6. 22 Mar, 2018 1 commit
  7. 05 Feb, 2018 1 commit
    • Harris Hancock's avatar
      Implement application/x-www-form-urlencoded encode/decode functions · 4982c9e8
      Harris Hancock authored
      These are almost the same as {encode,decode}UriComponent, differing only in the set of characters they consider reserved, and their treatment of spaces.
      
      I wasn't sure what to name them -- encodeWwwForm() seemed least bad.
      
      For the encode side, I added a completely separate function -- it seemed like more trouble than it was worth trying to integrate the changes into encodeUriComponent(). For the decode side, I integrated the change (plus-to-space) into decodeBinaryUriComponent(), since that function is a bit longer, and the change was trivial.
      4982c9e8
  8. 20 Jan, 2018 1 commit
  9. 11 Dec, 2017 2 commits
    • Kenton Varda's avatar
      Support encoding to and from wchar_t arrays. · ff9c3321
      Kenton Varda authored
      Different platforms have different sizes for wchar_t. For example:
      
      * Linux: 32-bit (originally intended as UCS-4, rarely used in practice)
      * Windows: 16-bit (originally intended as UCS-2, but now probably treated as UTF-16)
      * BeOS: 8-bit (strictly intended to be UTF-8)
      
      For KJ purposes, we'll assume wchar_t arrays use the UTF encoding appropriate to their size, whatever that may be on the target platform.
      
      This is mainly being added because the Win32 API uses wchar_t heavily.
      ff9c3321
    • Kenton Varda's avatar
      Extend Unicode encoders to support 'WTF-8'. · 5483d8f7
      Kenton Varda authored
      This allows arbitrary char16 arrays to round-trip through UTF-8 without losing information, even if the char16 arrays are not valid UTF-16.
      
      This is necessary e.g. for filesystem manipulation on Windows, where filenames contain 16-bit characters but valid UTF-16 is not enforced.
      
      Invalid UTF-16 represented in UTF-8 is affectionately known as WTF-8: http://simonsapin.github.io/wtf-8/
      5483d8f7
  10. 04 Dec, 2017 2 commits
    • Harris Hancock's avatar
      c137c9fd
    • Harris Hancock's avatar
      decodeBase64() reports errors required by HTML spec · f3e0ed22
      Harris Hancock authored
      This change modifies decodeBase64() to report errors as required by the WHATWG HTML spec's atob() JavaScript function. Notably, it reports errors for non-whitespace characters outside of the valid base64 character range ([+/0-9A-Za-z=]), and performs sanity checks on padding and input length.
      
      I took care to keep the algorithm single-pass, and to support streaming via multiple calls of base64_decode_block(), though we don't currently expose that functionality.
      f3e0ed22
  11. 14 Oct, 2017 2 commits
    • Ed Catmur's avatar
      Don't write plainchar on entry in step a · c10572fe
      Ed Catmur authored
      for the same reason - if we're called on an empty input, the output might not be a writeable pointer.
      Results in memory corruption and crash in delete on MSVC.
      c10572fe
    • Edward Catmur's avatar
      Don't read past the end of the decode out buffer. · c2fbfc70
      Edward Catmur authored
      If we finish decoding in step_a state, there is no current output character, so reading *plainchar will either be an uninitialized read or (if the output buffer is minimally sized) a past-the-end read.
      
      Detected by -fsanitize=address.
      c2fbfc70
  12. 12 Oct, 2017 2 commits
  13. 30 May, 2017 1 commit
  14. 23 May, 2017 2 commits
  15. 22 May, 2017 1 commit