>> Philip Guenther <pguenther(a)proofpoint.com> schrieb am
23.10.2019 um 18:28
in
Nachricht <alpine.BSO.2.21.1910230926270.77036(a)morgaine.local>:
On Wed, 23 Oct 2019, Quanah Gibson-Mount wrote:
> --On Wednesday, October 23, 2019 5:52 PM +0200 Saša-Stjepan Bakša
> <ssbaksa(a)gmail.com> wrote:
> > Is there any good reason that I see one of my custom objectClass garbled
> > like this below. It happens when I am reading content from file. From
GUI
> > tool it looks as it should.
>
> This is not garbled, it's base 64 encoded. This generally occurs when a
space
> or tab character is left at the end of an attribute value or there is some
> type of unprintable (unicode often) character contained within the value.
>
> Decoding it generates:
>
> {6}( 1.3.6.1.4.1.35269.3.245.2.7 NAME 'pcrfPackage' DESC 'Common package
> description – service parameters defined by MNO' SUP top STRUCTURAL MUST (
> pcrfPackageTitle $ packageLifetimeType ) MAY ( packageActivationDate $
> packageExpiryDate $ packageCycle $ totalMaximumVolume $ totalMaximumTime $
> monitoringKey $ totalMaximumAmount $ cycleMultiplier ) )
>
> Nothing jumps out at me here as to why it's being encoded, but hopefully
> that gives you enough clues to start from.
The "–" in the DESC is not the ascii "-" but a Unicode hyphen.
Good spot. I think I also had some fun with a Unicode mathematical minus when
being processed in Java, because that glyph has a three-byte encoding in UTF-8.
In my case it originated from copy&paste from PDF (where it looked like a
normal minus)...