Hello.
Since I have been working on a Chinese language based directory the ldapsearch tool was difficult for me to use, the result is always not readable.
This is because if an attribute value contain Chinese, it's automatically displayed using base64. I had to copy & paste the result to 'base64 -d' to read every result, which kills my efficiency. I had to switch to a GUI ldapbrower, which kills my efficiency more because I cannot store most of my frequent queries and call them back as easily would be done on console with readline support.
Is there a way to use ldapsearch and disable using base64 for non-ascii characters? I searched into the manual without a clue.
Example of un-readable output:
zhangweiwu@esmeralda:~$ ldapsearch -H ldap://gtz.ods.org -D uid=admin,st=jiangxi,o=LGOP -x -w secret -b st=jiangxi,o=LGOP '(pwdFailureTime=*)' pwdFailureTime pwdAccountLockedTime # extended LDIF # # LDAPv3 # base <st=jiangxi,o=LGOP> with scope subtree # filter: (pwdFailureTime=*) # requesting: pwdFailureTime pwdAccountLockedTime #
# \E5\90\89\E5\AE\89\E5\B8\82, jiangxi, LGOP dn:: b3U95ZCJ5a6J5biCLHN0PWppYW5neGksbz1MR09Q pwdFailureTime: 20080513080747Z
# \E4\B9\9D\E6\B1\9F\E5\B8\82, jiangxi, LGOP dn:: b3U95Lmd5rGf5biCLHN0PWppYW5neGksbz1MR09Q pwdFailureTime: 20080612200319Z pwdFailureTime: 20080612200326Z
# \E5\8D\97\E6\98\8C\E5\B8\82, jiangxi, LGOP dn:: b3U95Y2X5piM5biCLHN0PWppYW5neGksbz1MR09Q pwdFailureTime: 20080726054305Z pwdFailureTime: 20080726054306Z
# \E6\96\B0\E4\BD\99\E5\B8\82\E5\88\86\E5\AE\9C\E5\8E\BF, jiangxi, LGOP dn:: b3U95paw5L2Z5biC5YiG5a6c5Y6/LHN0PWppYW5neGksbz1MR09Q pwdFailureTime: 20080613022146Z
# search result search: 2 result: 0 Success
# numResponses: 5 # numEntries: 4
Zhang Weiwu wrote:
Since I have been working on a Chinese language based directory the ldapsearch tool was difficult for me to use, the result is always not readable.
This is because if an attribute value contain Chinese, it's automatically displayed using base64. I had to copy & paste the result to 'base64 -d' to read every result, which kills my efficiency.
This LDIF output is supposed to be ASCII-clean. You can easily pass it around in e-mails.
I had to switch to a GUI ldapbrower, which kills my efficiency more because I cannot store most of my frequent queries and call them back as easily would be done on console with readline support.
For my web2ldap you can construct persistent URLs (bookmarks) for certain tasks (search, add, passwd, etc.) with arbitrary LDAP URLs as query strings:
See short description here: http://www.web2ldap.de/usability.html
More examples: http://www.web2ldap.de/demo.html
Ciao, Michael. (with german umlauts in his name)
Michael Ströder wrote:
Zhang Weiwu wrote:
Since I have been working on a Chinese language based directory the ldapsearch tool was difficult for me to use, the result is always not readable.
This is because if an attribute value contain Chinese, it's automatically displayed using base64. I had to copy & paste the result to 'base64 -d' to read every result, which kills my efficiency.
This LDIF output is supposed to be ASCII-clean.
Yes I know, and is the only command line tool currently on my computer that doesn't output Chinese in UTF-8, given the console (both framebuffer and X11 terminals) supports UTF-8... (I do most things on commandline except browsing, e.g. using SQL client)
I would consider being able to produce UTF-8 is a requirement, being able to output ASCII-only is an option that some user find useful and can activate or configure/enable, if you can think from a non-western oriented view.
You can easily pass it around in e-mails.
As easy as I pass command-line output that contain Chinese to email? I've been doing such things for years:)
Zhang Weiwu wrote:
Michael Ströder wrote:
Zhang Weiwu wrote:
Since I have been working on a Chinese language based directory the ldapsearch tool was difficult for me to use, the result is always not readable.
This is because if an attribute value contain Chinese, it's automatically displayed using base64. I had to copy & paste the result to 'base64 -d' to read every result, which kills my efficiency.
This LDIF output is supposed to be ASCII-clean.
Yes I know, and is the only command line tool currently on my computer that doesn't output Chinese in UTF-8, given the console (both framebuffer and X11 terminals) supports UTF-8...
...and have the necessary fonts installed.
I also don't know what the implications are for BIDI fonts. E.g. the attribute type (ASCII) would be output from left to right, and the LDIF is normally read top-down like western-oriented console terminals are designed. But if there's a language read right-to-left or even bottom-up how should that be handled by the console?
(I do most things on commandline except browsing, e.g. using SQL client)
You should seriously consider a LDAP UI client meeting your needs for automatically accessing certain tasks.
I would consider being able to produce UTF-8 is a requirement, being able to output ASCII-only is an option that some user find useful and can activate or configure/enable, if you can think from a non-western oriented view.
Indeed I can think from non-western oriented view. But having implemented web2ldap I know that producing UTF-8 would only suitable for strings of Unicode characters. web2ldap is schema-aware, OpenLDAP's command-line tools are not.
One possibility which could easily implemented would be that one specifies with a command-line option which attributes to output as UTF-8. The user is responsible for all the mess which could be output at the console.
You can easily pass it around in e-mails.
As easy as I pass command-line output that contain Chinese to email? I've been doing such things for years:)
Well, the amount of information transferred is what the receiver understands. ;-)
Serious: If you post LDIF dara one can add it to the directory for testing without having the necessary fonts installed.
Ciao, Michael.
Michael Ströder wrote:
Indeed I can think from non-western oriented view. But having implemented web2ldap I know that producing UTF-8 would only suitable for strings of Unicode characters. web2ldap is schema-aware, OpenLDAP's command-line tools are not.
You are right that I overlooked the fact ldapsearch(1) is not schema-aware.
Michael Ströder michael@stroeder.com wrote:
This LDIF output is supposed to be ASCII-clean. You can easily pass it around in e-mails.
Sure, but a ldapsearch flag to output raw binary would not hurt. I can implement it if such a feature is considered acceptable.
Emmanuel Dreyfus wrote:
Michael Ströder michael@stroeder.com wrote:
This LDIF output is supposed to be ASCII-clean. You can easily pass it around in e-mails.
Sure, but a ldapsearch flag to output raw binary would not hurt.
It would hurt for e.g. 'jpegPhoto' or 'userCertificate;binary'.
I can implement it if such a feature is considered acceptable.
But please only for character string syntaxes like DirectoryString. But then you have to make ldapsearch kind of schema-aware.
Ciao, Michael.
Michael Ströder michael@stroeder.com wrote:
It would hurt for e.g. 'jpegPhoto' or 'userCertificate;binary'.
What about a flag to get a display a la hexdump -C when the data is not pure ASCII? hexdump output, with ASCII display at the end of the line.
The flag could have an argument to accomodate various needs:
ldapsearch -o output_style where output_style is: - ldif: ASCII strings in ASCII, and everything else in base64 (default) - hexdump: ASCII strings in ASCII, binary as hexdump -C - allhexdump: every attribute as hexdump - binary: every attribute as raw binary
Emmanuel Dreyfus wrote:
Michael Ströder michael@stroeder.com wrote:
It would hurt for e.g. 'jpegPhoto' or 'userCertificate;binary'.
What about a flag to get a display a la hexdump -C when the data is not pure ASCII?
This won't help the original poster. He wants that ldapsearch outputs LDIF which he can read directly on the console (probably with LANG=cn_CN.UTF-8).
ldapsearch -o output_style where output_style is:
- ldif: ASCII strings in ASCII, and everything else in base64 (default)
- hexdump: ASCII strings in ASCII, binary as hexdump -C
- allhexdump: every attribute as hexdump
- binary: every attribute as raw binary
At the moment I would not introduce other output formats than LDIF. The usefulness of hex-dumps in comparison to base64-encoded data is debatable.
The only thing I could imagine without making ldapsearch schema-aware is a command-line option defining which attributes to output as UTF-8. If the user specifies jpegPhoto for that he's on his own if the raw binary output messes up the terminal.
Ciao, Michael.
Michael Ströder michael@stroeder.com wrote:
At the moment I would not introduce other output formats than LDIF. The usefulness of hex-dumps in comparison to base64-encoded data is debatable.
Well, you have an ascii column at the end that helps reading what's inside a bit more easily than base64.
Emmanuel Dreyfus wrote:
Michael Ströder michael@stroeder.com wrote:
At the moment I would not introduce other output formats than LDIF. The usefulness of hex-dumps in comparison to base64-encoded data is debatable.
Well, you have an ascii column at the end that helps reading what's inside a bit more easily than base64.
Which won't help with displaying Chinese UTF-8 strings at all.
Ciao, Michael.
Michael Ströder wrote:
At the moment I would not introduce other output formats than LDIF. The usefulness of hex-dumps in comparison to base64-encoded data is debatable.
Agreed.
The only thing I could imagine without making ldapsearch schema-aware is a command-line option defining which attributes to output as UTF-8. If the user specifies jpegPhoto for that he's on his own if the raw binary output messes up the terminal.
Perhaps an ldap.conf option as well. It essentially becomes a half-baked schema for the client side.
openldap-software@openldap.org