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.
olcObjectClasses:: ezZ9KCAxLjMuNi4xLjQuMS4zNTI2OS4zLjI0NS4yLjcgTkFNRSAncGNyZ lBhY2thZ2UnIERFU0MgJ0NvbW1vbiBwYWNrYWdlIGRlc2NyaXB0aW9uIOKAkyBzZXJ2aWNlIHBh cmFtZXRlcnMgZGVmaW5lZCBieSBNTk8nIFNVUCB0b3AgU1RSVUNUVVJBTCBNVVNUICggcGNyZlB hY2thZ2VUaXRsZSAkIHBhY2thZ2VMaWZldGltZVR5cGUgKSBNQVkgKCBwYWNrYWdlQWN0aXZhdG lvbkRhdGUgJCBwYWNrYWdlRXhwaXJ5RGF0ZSAkIHBhY2thZ2VDeWNsZSAkIHRvdGFsTWF4aW11b VZvbHVtZSAkIHRvdGFsTWF4aW11bVRpbWUgJCBtb25pdG9yaW5nS2V5ICQgdG90YWxNYXhpbXVt QW1vdW50ICQgY3ljbGVNdWx0aXBsaWVyICkgKQ==
Others are normal and human readable.
--On Wednesday, October 23, 2019 5:52 PM +0200 Saša-Stjepan Bakša ssbaksa@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.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Wed, 23 Oct 2019, Quanah Gibson-Mount wrote:
--On Wednesday, October 23, 2019 5:52 PM +0200 Saša-Stjepan Bakša ssbaksa@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.
Philip Guenther pguenther@proofpoint.com schrieb am 23.10.2019 um 18:28
in Nachricht alpine.BSO.2.21.1910230926270.77036@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@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)...
On Thu, 24 Oct 2019 at 08:26, Ulrich Windl < Ulrich.Windl@rz.uni-regensburg.de> wrote:
Philip Guenther pguenther@proofpoint.com schrieb am 23.10.2019 um
18:28 in Nachricht alpine.BSO.2.21.1910230926270.77036@morgaine.local:
On Wed, 23 Oct 2019, Quanah Gibson-Mount wrote:
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)...
Mine came from using Notepad++ for "beautification" (forced to do so) and saving it from there. I have should known better.
It appears to me to be the mdash in the 'Common package description [mdash] service parameters defined by MNO' string... ________________________________________ From: openldap-technical openldap-technical-bounces@openldap.org on behalf of Quanah Gibson-Mount quanah@symas.com Sent: Wednesday, October 23, 2019 12:09:50 PM To: Saša-Stjepan Bakša; openldap-technical@openldap.org Subject: Re: Garbled objectClass
--On Wednesday, October 23, 2019 5:52 PM +0200 Saša-Stjepan Bakša ssbaksa@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.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Wed, Oct 23, 2019 at 04:52:41PM +0200, Saša-Stjepan Bakša 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.
olcObjectClasses:: ezZ9KCAxLjMuNi4xLjQuMS4zNTI2OS4zLjI0NS4yLjcgTkFNRSAncGNyZ lBhY2thZ2UnIERFU0MgJ0NvbW1vbiBwYWNrYWdlIGRlc2NyaXB0aW9uIOKAkyBzZXJ2aWNlIHBh cmFtZXRlcnMgZGVmaW5lZCBieSBNTk8nIFNVUCB0b3AgU1RSVUNUVVJBTCBNVVNUICggcGNyZlB hY2thZ2VUaXRsZSAkIHBhY2thZ2VMaWZldGltZVR5cGUgKSBNQVkgKCBwYWNrYWdlQWN0aXZhdG lvbkRhdGUgJCBwYWNrYWdlRXhwaXJ5RGF0ZSAkIHBhY2thZ2VDeWNsZSAkIHRvdGFsTWF4aW11b VZvbHVtZSAkIHRvdGFsTWF4aW11bVRpbWUgJCBtb25pdG9yaW5nS2V5ICQgdG90YWxNYXhpbXVt QW1vdW50ICQgY3ljbGVNdWx0aXBsaWVyICkgKQ==
Others are normal and human readable.
Your DESC contains an en dash (U+2014, \xe2\x80\x93). If I replace that with a regular ASCII hyphen (U+002D, \x2d) then ldapsearch prints it normally.
Thank you all for quick and enlightening analyses of my beginners like error. I have used search for double spaces, wrong naming, whatever ... but that, that would never even cross my mind.
Use vi Luke! vi!
Tnx again.
On Wed, 23 Oct 2019 at 19:13, Ryan Tandy ryan@nardis.ca wrote:
On Wed, Oct 23, 2019 at 04:52:41PM +0200, Saša-Stjepan Bakša 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.
olcObjectClasses::
ezZ9KCAxLjMuNi4xLjQuMS4zNTI2OS4zLjI0NS4yLjcgTkFNRSAncGNyZ
lBhY2thZ2UnIERFU0MgJ0NvbW1vbiBwYWNrYWdlIGRlc2NyaXB0aW9uIOKAkyBzZXJ2aWNlIHBh
cmFtZXRlcnMgZGVmaW5lZCBieSBNTk8nIFNVUCB0b3AgU1RSVUNUVVJBTCBNVVNUICggcGNyZlB
hY2thZ2VUaXRsZSAkIHBhY2thZ2VMaWZldGltZVR5cGUgKSBNQVkgKCBwYWNrYWdlQWN0aXZhdG
lvbkRhdGUgJCBwYWNrYWdlRXhwaXJ5RGF0ZSAkIHBhY2thZ2VDeWNsZSAkIHRvdGFsTWF4aW11b
VZvbHVtZSAkIHRvdGFsTWF4aW11bVRpbWUgJCBtb25pdG9yaW5nS2V5ICQgdG90YWxNYXhpbXVt
QW1vdW50ICQgY3ljbGVNdWx0aXBsaWVyICkgKQ==
Others are normal and human readable.
Your DESC contains an en dash (U+2014, \xe2\x80\x93). If I replace that with a regular ASCII hyphen (U+002D, \x2d) then ldapsearch prints it normally.
openldap-technical@openldap.org
-
Francis Swasey -
Philip Guenther -
Quanah Gibson-Mount -
Ryan Tandy -
Saša-Stjepan Bakša -
Ulrich Windl