Philippe Verdy via Unicode wrote in :
|Padding itself does not clearly indicate the length.
|
|It's an artefact that **may** be infered only in some other layers \
|of protocols which specify when and how padding is needed (and how \
|many padding bytes
|are required or accepted), it works
gt; that length and not treated as part of the encoding.
>
> Maybe we differ on define where the encoding begins and ends, and where
> higher level protocols prescribe how they are embedded within the protocol.
>
>
>
> Tex
>
>
>
>
>
>
>
>
>
> *From
On 10/14/18 3:59 PM, Philippe Verdy via Unicode wrote:
>
>
> Le dim. 14 oct. 2018 à 21:21, Doug Ewell via Unicode
> mailto:unicode@unicode.org>> a écrit :
>
> Steffen Nurpmeso wrote:
>
> > Base64 is defined in RFC 2045 (Multipurpose Internet Mail Extensions
> > (MIME) Part One:
Doug Ewell via Unicode wrote in <2A67B4F082F74F8AADF34BA11D885554@DougEwell>:
|Steffen Nurpmeso wrote:
|> Base64 is defined in RFC 2045 (Multipurpose Internet Mail Extensions
|> (MIME) Part One: Format of Internet Message Bodies).
|
|Base64 is defined in RFC 4648, "The Base16, Base32, and
ippe Verdy [mailto:verd...@wanadoo.fr]
Sent: Monday, October 15, 2018 4:14 AM
To: Tex Texin
Cc: Adam Borowski; unicode Unicode Discussion
Subject: Re: Base64 encoding applied to different unicode texts always yields
different base64 texts ... true or false?
Look into https://tools.ietf.org/ht
pace? If
>>> linebreaks are forced at some line length they can presumably be removed at
>>> that length and not treated as part of the encoding.
>>>
>>> Maybe we differ on define where the encoding begins and ends, and where
>>> higher level protocols prescribe how they are embed
col.
>>
>>
>>
>> Tex
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* Unicode [mailto:unicode-boun...@unicode.org] *On Behalf Of *Philippe
>> Verdy via Unicode
>> *Sent:* Sunday, October 14, 2018 1:41 AM
>> *To:
protocol.
>
>
>
> Tex
>
>
>
>
>
>
>
>
>
> *From:* Unicode [mailto:unicode-boun...@unicode.org] *On Behalf Of *Philippe
> Verdy via Unicode
> *Sent:* Sunday, October 14, 2018 1:41 AM
> *To:* Adam Borowski
> *Cc:* unicode Unicode Discussion
>
-boun...@unicode.org] *On Behalf Of *Philippe
> Verdy via Unicode
> *Sent:* Sunday, October 14, 2018 1:41 AM
> *To:* Adam Borowski
> *Cc:* unicode Unicode Discussion
> *Subject:* Re: Base64 encoding applied to different unicode texts always
> yields different base64 texts ... tru
Borowski
Cc: unicode Unicode Discussion
Subject: Re: Base64 encoding applied to different unicode texts always yields
different base64 texts ... true or false?
Note that 1-byte pieces do not need to be padded by 2 = signs; only 1 is enough
to indicate the end of an octets-span. The extra = after
Le dim. 14 oct. 2018 à 21:21, Doug Ewell via Unicode
a écrit :
> Steffen Nurpmeso wrote:
>
> > Base64 is defined in RFC 2045 (Multipurpose Internet Mail Extensions
> > (MIME) Part One: Format of Internet Message Bodies).
>
> Base64 is defined in RFC 4648, "The Base16, Base32, and Base64 Data
>
It's also interesting to look at https://tools.ietf.org/html/rfc3501
- which defines (for IMAP v4) another "BASE64" encoding,
- and also defines a "Modified UTF-7" encoding using it, deviating from
Unicode's definition of UTF-7,
- and adding other requirements (which forbids alternate encodings
Steffen Nurpmeso wrote:
Base64 is defined in RFC 2045 (Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies).
Base64 is defined in RFC 4648, "The Base16, Base32, and Base64 Data
Encodings." RFC 2045 defines a particular implementation of base64,
specific
Note that 1-byte pieces do not need to be padded by 2 = signs; only 1 is
enough to indicate the end of an octets-span. The extra = after it do not
add any other octet. and as well you're allowed to insert whitespaces
anywhere in the encoded stream (this is what ensures that the
Base64-encoded
On Sun, Oct 14, 2018 at 01:37:35AM +0200, Philippe Verdy via Unicode wrote:
> Le sam. 13 oct. 2018 à 18:58, Steffen Nurpmeso via Unicode <
> unicode@unicode.org> a écrit :
> > The only variance is described as:
> >
> > Care must be taken to use the proper octets for line breaks if base64
> >
Le sam. 13 oct. 2018 à 18:58, Steffen Nurpmeso via Unicode <
unicode@unicode.org> a écrit :
> Philippe Verdy via Unicode wrote in w9+jearw4ghyk...@mail.gmail.com>:
> |You forget that Base64 (as used in MIME) does not follow these rules \
> |as it allows multiple different encodings for the
Philippe Verdy via Unicode wrote in :
|You forget that Base64 (as used in MIME) does not follow these rules \
|as it allows multiple different encodings for the same source binary. \
|MIME actually
|splits a binary object into multiple fragments at random positions, \
|and then encodes these
In summary, two disating implementations are allowed to return different
values t and t' of Base64_Encode(d) from the same message d, but both
Base64_Decode(t') and Base64_Decode(t) will be equal and will MUST return
d exactly.
There's an allowed choice of implementation for Base64_Encode() but
You forget that Base64 (as used in MIME) does not follow these rules as it
allows multiple different encodings for the same source binary. MIME
actually splits a binary object into multiple fragments at random
positions, and then encodes these fragments separately. Also MIME uses an
extension of
Hi Folks,
Thank you for your outstanding responses!
Below is a summary of what I learned. Are there any errors in the summary? Is
there anything you would add? Please let me know of anything that is not clear.
/Roger
1. While base64 encoding is usually applied to binary, it is also
I also think the reverse is also true !
Decoding a Base64 entity does not warranty it will return valid text in any
known encoding. So Unicode normalization of the output cannot apply.
Even if it represents text, nothing indicates that the result will be
encoded with some Unicode encoding form
applied to different unicode texts always yields
different base64 texts ... true or false?
On Fri, Oct 12, 2018 at 9:23 AM Doug Ewell via Unicode
wrote:
J Decker wrote:
>> How about the opposite direction: If m is base64 encoded to yield t
>> and then t is base64 decode
On Fri, Oct 12, 2018 at 9:23 AM Doug Ewell via Unicode
wrote:
> J Decker wrote:
>
> >> How about the opposite direction: If m is base64 encoded to yield t
> >> and then t is base64 decoded to yield n, will it always be the case
> >> that m equals n?
> >
> > False.
> > Canonical translation may
J Decker wrote:
>> How about the opposite direction: If m is base64 encoded to yield t
>> and then t is base64 decoded to yield n, will it always be the case
>> that m equals n?
>
> False.
> Canonical translation may occur which the different base64 may be the
> same sort of string...
Base64 is
On Fri, Oct 12, 2018 at 3:57 AM Costello, Roger L. via Unicode <
unicode@unicode.org> wrote:
> Hi Unicode Experts,
>
> Suppose base64 encoding is applied to m to yield base64 text t.
>
> Next, suppose base64 encoding is applied to m' to yield base64 text t'.
>
> If m is not equal to m', then t
Hi Unicode Experts,
Suppose base64 encoding is applied to m to yield base64 text t.
Next, suppose base64 encoding is applied to m' to yield base64 text t'.
If m is not equal to m', then t will not equal t'.
In other words, given different inputs, base64 encoding always yields different
26 matches
Mail list logo
