I am using Google Translate API to translate a excel column from Japanese to English. The Japanese column not only contains Japanese characters but some numeric symbols like ①, ⑥ etc.
No problem in translating the Japanese characters but the symbols gets converted into a gibberish.
Example:
Japanese: ＃⑥その他
English: # â‘¥ Other
But the same text works fine with Google Translate Web
How to prevent translating symbols in Google Translate API?
The issue comes from mixing numeric symbols with a language, since then it's harder for the Translation API to detect which is the source language.
I don't know which method you are using to call the Translation API, but in any case, specifying the source language solves the issue.
For example, with a REST call from the Command Line Interface:
curl -X POST -H "Authorization: Bearer "\
$(gcloud auth application-default print-access-token) \
-H "Content-Type: application/json; charset=utf-8" --data "{
'q': '＃⑥その他',
'source': 'ja',
'target': 'en'
}" "https://translation.googleapis.com/language/translate/v2"
Will return "# ⑥ Other" as the result of the translation.
Related
I have links .php how do I substitute my values in all parameters using curl post?
Provided that I do not know what the parameters are in these php links, curl should determine for itself what parameters are in the post request and substitute my values.
If I know the parameter, then I can send it to the links like this:
while read p; do
curl $p -X POST --connect-timeout 18 --cookie "" --user-agent "" -d "parametr=helloworld" -w "%{url}:%{time_total}s\n"
done < domain.txt > output.txt
And if I do not know the parameters, what should I do? How to make curl automatically substitute values into parameters? For example, the value: "hello world" provided that I did not know "parameter"
It's simply not possible. curl is a client program and has no way of knowing or finding out which request parameters are supported by a server or which are not.
Unless of course, the API is properly documented and available as an OpenAPI/Swagger specification for example. If it isn't, you're out of luck.
I use a Telegram bot to incorporate weather alerts from a local weatherservice into my homeautomation system. Today I discovered a weird problem because the message containing the weather alert wasn't sent. If I try this in bash on Linux:
output="Nationaal Hitteplan";curl "https://api.telegram.org/botxxxxxxxxx:longsecuritycode/sendMessage?chat_id=xxxxxxxxx&text=$output"
(I removed my personal tokens in the above command of course...)
then I get a 400 Bad Request and the message is not sent.
If I change output="Nationaal Hitteplan" to output="Nationaal hitteplan" then the message is send as it is supposed to be.
I don't see what's wrong here. The term Nationaal Hitteplan is basically a set of advisories about what to do in hot weather. It has no negative meaning associated with it but apparently Telegram detects a problem.
Does someone have a solution for this except from changing the term as described above?
Url's that contains special characters like a space should be url-encoded.
Use the following curl command to let curl let the encoding:
token='xxxxxxxxx:longsecuritycode';
output="Nationaal Hitteplan";
curl -G \
--data-urlencode 'chat_id=1234567' \
--data-urlencode "text=${output}" \
"https://api.telegram.org/bot${token}/sendMessage"
How to urlencode data for curl command?
I have a base64 encoded JWT that decodes on jwt.io and on base64decode.org but does not decode using base64 command on my OSX not my Linux machine (running echo {the string} | grep base64 --decode. I have no idea why, here is the string:
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhY2NvdW50IjoiNTgzZDQzZTItY2Q2ZC00YzBjLTlkNTItMmE4ZmNlY2Y2ZTVmIiwiYWNjb3VudFJvbGVzIjpbIk9PU19QRVJTT05fUkVNQVJLU19FRElUT1IiLCJBV1MtQVJUQVBQLUFETUlOIiwiT09TX1BFUlNPTl9ET0NVTUVOVFNfUkVBREVSX05PTl9NRURJQ0FMIiwiQVdTLVZFU1NFTExPQURJTkctQURNSU4iLCJPT1NfUEVSU09OX1JFTUFSS1NfUkVBREVSX1NBTEFSWSIsIlZQTlVTRVI5IiwiT09TX0NIRUNLTElTVF9BRE1JTiIsIkFXUy1QUk9ELUFETUlOIiwiQ09OQ09VUlNFLkNJIiwiT09TX1BPUlRfQ09NTUVOVFNfRURJVE9SIiwiT09TX1BFUlNPTl9FRElUT1JfU0VSVklDRSIsIk9PU19WRVNTRUxfUkVTUE9OU0lCSUxJVElFU19FRElUT1IiLCJNQU5BR0VEIERBVEFCQVNFUyIsIlZQTlVTRVIxMCIsIk9PU19QT1JUX01ZX0NPTU1FTlRTX0RFTEVUT1IiLCJPT1NfV09SS0ZMT1dfVVNFUiIsIk9PU19QRVJTT05fRURJVE9SIiwiQVdTLVNBTkRCT1gtQURNSU4iLCJPT1NfU1VQRVJfVVNFUiIsIlZQTlVTRVI1IiwiT09TX1ZFU1NFTF9JVElORVJBUllfUkVBREVSIiwiT09TX1BFUlNPTl9SRUFERVJfQkFDS0dST1VORCIsIk9PU19QRVJTT05fTUVESUNBTF9FRElUT1IiLCJPT1NfUEVSU09OX0RFTEVUT1IiLCJPT1NfSU5TUEVDVElPTl9TQ0hFRFVMRV9ERUxFVE9SIiwiT09TX1BFUlNPTl9SRUFERVJfU0VSVklDRSIsIk9PU19QRVJTT05fRE9DVU1FTlRTX0VESVRPUiIsIk9PU19QRVJTT05fRE9DVU1FTlRTX0RFTEVUT1IiLCJWUE5VU0VSMiIsIk9PU19QT1JUX0NPTU1FTlRTX0RFTEVUT1IiLCJPT1NfUEVSU09OX1JFTUFSS1NfUkVBREVSX1BFUlNPTkFMIiwiT09TX1BPUlRfTVlfQ09NTUVOVFNfRURJVE9SIiwiT09TX1RFTVBMQVRFX0xJQlJBUllfRURJVE9SIiwiQVdTLVRFU1QtQURNSU5AOTBQT0UuSU8iLCJPT1NfUEVSU09OX0RPQ1VNRU5UU19ET1dOTE9BREVSX01FRElDQUwiLCJJTlNQRUNUSU9OX1RFTVBMQVRFIiwiVlBOVVNFUjgiLCJPT1NfUEVSU09OX1JBTktfQVZBSUxBQklMSVRZX0VESVRPUiIsIlZQTlVTRVI0IiwiVlBOVVNFUjEiLCJPT1NfUEVSU09OX01FRElDQUxfREVMRVRPUiIsIlZQTlVTRVIzIiwiQVdTLUlBTS1BRE1JTiIsIkFXUy1BUlRBUFAtUFJPRC1BRE1JTiIsIk9PU19GTEVFVF9QRVJGT1JNQU5DRSIsIk9PU19JTlNQRUNUSU9OX1NDSEVEVUxFX1JFQURFUiIsIk9PU19QRVJTT05fRE9DVU1FTlRTX0RPV05MT0FERVJfTk9OX01FRElDQUwiLCJPT1NfUEVSU09OX0RPQ1VNRU5UU19SRUFERVJfTUVESUNBTCIsIk9PU19QT1JUX0lORk9fUkVBREVSIiwiVlBOVVNFUjYiLCJPT1NfUEVSU09OX1JFTUFSS1NfUkVBREVSX01FRElDQUwiLCJBV1MtREVWLUFETUlOIiwiQVdTLVRPT0xTLUFETUlOIiwiQVdTLUJJTExJTkctQURNSU4iLCJJTlNQRUNUSU9OX1RFTVBMQVRFX0lURU0iLCJPT1NfUEVSU09OX1JFTUFSS1NfREVMRVRPUiIsIk9PU19QRVJTT05fUkVBREVSX1NVTU1BUlkiLCJPT1NfUEVSU09OX1JFQURFUl9QSFlTSUNBTCIsIk9PU19XT1JLRkxPV19FRElUT1IiLCJPT1NfVEVNUExBVEVfTElCUkFSWV9SRUFERVIiLCJBUFBST0FDSF9JTkZPX0VESVRPUiIsIk9PU19URU1QTEFURV9MSUJSQVJZX0RFTEVUT1IiLCJBV1MtU1RHLUFETUlOIiwiT09TX1BFUlNPTl9SRU1BUktTX1JFQURFUl9UUkFWRUwiLCJPT1NfTUFOTklOR19BR0VOVF9WQVJOQSIsIk9PU19QRVJTT05fUkVBREVSX0NPTlRBQ1QiLCJPT1NfUEVSU09OX1JFQURFUl9ORVhUT0ZLSU4iLCJPT1NfSU5TUEVDVElPTl9TQ0hFRFVMRV9FRElUT1IiLCJFVkVSWU9ORSIsIk9PU19QRVJTT05fUkVBREVSX0ZBTUlMWSIsIk9PU19QRVJTT05fUkVNQVJLU19SRUFERVJfRElTQ0lQTElOQVJZIl0sImFwcGxpY2F0aW9uIjoiT09TIiwiY29udGV4dCI6Ik1BTk5JTkdfT0ZGSUNFOjEyOWQxNjAzLWFhZTktNDQ1NC04OWRjLWI4NzFhMGNmNGJhMCIsImV4cCI6MTU0MTc3Njg3OCwiaWF0IjoxNTQxNzc2Mjc4LCJpc3MiOiIiLCJwZXJtaXNzaW9ucyI6WyJJTlNQRUNUSU9OX1NDSEVEVUxFOkRMUlVDIiwiUEVSU09OX1JFTUFSS1NfU0FMQVJZOkNMUlVEIiwiUEVSU09OX0RPQ1VNRU5UU19DRVJUSUZJQ0FURVM6TFJDTlVEIiwiUEVSU09OOkxSQ1VEIiwiUEVSU09OX05FWFRPRktJTjpDTFJVRCIsIlBFUlNPTl9SRU1BUktTX01FRElDQUw6Q0xSVUQiLCJQRVJTT05fRE9DVU1FTlRTX0xJQ0VOU0U6TFJDTlVEIiwiUEVSU09OX0ZBTUlMWTpDTFJVRCIsIlBPUlRfSU5GT19BUFBST0FDSDpMUlVDIiwiSU5TUEVDVElPTl9URU1QTEFURTpMUlVDRCIsIklOU1BFQ1RJT05fVEVNUExBVEVfSVRFTTpMUlVDRCIsIlBMQVRGT1JNX1JFTUFSS1M6TFJVQ0QiLCJQTEFURk9STV9XT1JLRkxPV19ERUZJTklUSU9OOkNVIiwiVkVTU0VMX0lUSU5FUkFSWTpMUiIsIlBPUlRfQ09NTUVOVFM6TFJVQ0QiLCJQRVJTT05fUkFOS19BVkFJTEFCSUxJVFk6TFJDVUQiLCJQRVJTT05fQkFDS0dST1VORDpDTFJVRCIsIkZMRUVUX1BFUkZPUk1BTkNFOkxSIiwiUEVSU09OX1NFUlZJQ0U6TFJVQ0QiLCJQRVJTT05fQ09OVEFDVDpDTFJVRCIsIlBMQVRGT1JNX0RPQ1VNRU5UUzpMUlVDTkQiLCJQRVJTT05fUEhZU0lDQUw6Q0xSVUQiLCJQRVJTT05fUkVNQVJLU19QRVJTT05BTDpDTFJVRCIsIlBMQVRGT1JNX1dPUktGTE9XX0lOU1RBTkNFOkNVIiwiUEVSU09OX0RPQ1VNRU5UU19NRURJQ0FMOkxSVUNORCIsIlBFUlNPTl9SRU1BUktTX1RSQVZFTDpMUiIsIlBFUlNPTl9SRU1BUktTX0RJU0NJUExJTkFSWTpDTFJVRCIsIlBPUlRfTVlfQ09NTUVOVFM6TFJVQ0QiLCJQT1JUX0lORk86TFIiLCJWRVNTRUxfUkVTUE9OU0lCSUxJVElFUzpMUlVDIl0sInVzZXJJZCI6ImYxYzU3ZTRiLWEwZmEtNGJhZS04NWM4LTMzMzE1YWE4ZjJlZCJ9.NJ9jflW7Hk_RLL8X7olwvxeSl6bdeO783_iOkLegBcocZCP-0szh3kZ45gG3WAGN6O2KERuyg7lVGz1b5PT7CpaOyBGTGMYZDN6H6mqqs4EUidS10OV7191rYxLy0xh5axdw4O9Oci3fUL8U8ueO0AUNVomb_Tdw-3Ncgi7e35wmxv-PZiPe6fs_1aldy3BCCs4nZxV6cu8DeOmBRYuSC8qzYwmwZvWAlj_JAOOOT_1xvG8zQ6YUGPrNreADKZhVnbksjfGBee3fE3GjcFK8Sd1dbwap2hcw0n-FX-2PPK2IqLLeEdrOK1KcaxwHSfCupPGvXQa9ga03GMRhyd95Q9uZ6nSt2UijMEglCCQzSMKMQykriBsAD3_gQ375UnrXwzFdo6qfBWrNiBOuQiHN2E5XqMpRk1GYBH1K1cf8wp1ninGX4kJP6jbIGkAwNlsE0sLeXifUV0SLBHwEEFreq6BjLyXrWnmhXUPMoQOa-07zwx5iypwSSSr_o6x2xsEjKtJWA6kau_uArEfS7fYpTqKrOpZhPMZyrk5LojLgAnsPEgoDmm0PxMDDPaDSExXGwwDDumOw5UDrgoSp6Holt0XJ9sV1N2Jy7uoKCT6268ovIHOwjsrAKugNJAfGRYuxAzT9Dr5R3wxxZxw571yLAxitA_5fZeejgqZqrZ1MaII
I think the issue is that you're trying to decode the full JWT in a single hit. The JWT specification says that a JWT is three . separated base64 encoded pieces.
If you split the string on the two dots then each of the three pieces do decode using standard command line tools. The earlier poster is correct that underscores and hyphens are not valid in pure base64 encoding, but there are variants and some do allow these characters so provided you are following a consistent strategy those characters are fine.
What you have is not properly encoded base64. You have periods, underscores and hyphens in there.
I was able to clean up your string
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9eyJhY2NvdW50IjoiNTgzZDQzZTItY2Q2ZC00YzBjLTlkNTItMmE4ZmNlY2Y2ZTVmIiwiYWNjb3VudFJvbGVzIjpbIk9PU19QRVJTT05fUkVNQVJLU19FRElUT1IiLCJBV1MtQVJUQVBQLUFETUlOIiwiT09TX1BFUlNPTl9ET0NVTUVOVFNfUkVBREVSX05PTl9NRURJQ0FMIiwiQVdTLVZFU1NFTExPQURJTkctQURNSU4iLCJPT1NfUEVSU09OX1JFTUFSS1NfUkVBREVSX1NBTEFSWSIsIlZQTlVTRVI5IiwiT09TX0NIRUNLTElTVF9BRE1JTiIsIkFXUy1QUk9ELUFETUlOIiwiQ09OQ09VUlNFLkNJIiwiT09TX1BPUlRfQ09NTUVOVFNfRURJVE9SIiwiT09TX1BFUlNPTl9FRElUT1JfU0VSVklDRSIsIk9PU19WRVNTRUxfUkVTUE9OU0lCSUxJVElFU19FRElUT1IiLCJNQU5BR0VEIERBVEFCQVNFUyIsIlZQTlVTRVIxMCIsIk9PU19QT1JUX01ZX0NPTU1FTlRTX0RFTEVUT1IiLCJPT1NfV09SS0ZMT1dfVVNFUiIsIk9PU19QRVJTT05fRURJVE9SIiwiQVdTLVNBTkRCT1gtQURNSU4iLCJPT1NfU1VQRVJfVVNFUiIsIlZQTlVTRVI1IiwiT09TX1ZFU1NFTF9JVElORVJBUllfUkVBREVSIiwiT09TX1BFUlNPTl9SRUFERVJfQkFDS0dST1VORCIsIk9PU19QRVJTT05fTUVESUNBTF9FRElUT1IiLCJPT1NfUEVSU09OX0RFTEVUT1IiLCJPT1NfSU5TUEVDVElPTl9TQ0hFRFVMRV9ERUxFVE9SIiwiT09TX1BFUlNPTl9SRUFERVJfU0VSVklDRSIsIk9PU19QRVJTT05fRE9DVU1FTlRTX0VESVRPUiIsIk9PU19QRVJTT05fRE9DVU1FTlRTX0RFTEVUT1IiLCJWUE5VU0VSMiIsIk9PU19QT1JUX0NPTU1FTlRTX0RFTEVUT1IiLCJPT1NfUEVSU09OX1JFTUFSS1NfUkVBREVSX1BFUlNPTkFMIiwiT09TX1BPUlRfTVlfQ09NTUVOVFNfRURJVE9SIiwiT09TX1RFTVBMQVRFX0xJQlJBUllfRURJVE9SIiwiQVdTLVRFU1QtQURNSU5AOTBQT0UuSU8iLCJPT1NfUEVSU09OX0RPQ1VNRU5UU19ET1dOTE9BREVSX01FRElDQUwiLCJJTlNQRUNUSU9OX1RFTVBMQVRFIiwiVlBOVVNFUjgiLCJPT1NfUEVSU09OX1JBTktfQVZBSUxBQklMSVRZX0VESVRPUiIsIlZQTlVTRVI0IiwiVlBOVVNFUjEiLCJPT1NfUEVSU09OX01FRElDQUxfREVMRVRPUiIsIlZQTlVTRVIzIiwiQVdTLUlBTS1BRE1JTiIsIkFXUy1BUlRBUFAtUFJPRC1BRE1JTiIsIk9PU19GTEVFVF9QRVJGT1JNQU5DRSIsIk9PU19JTlNQRUNUSU9OX1NDSEVEVUxFX1JFQURFUiIsIk9PU19QRVJTT05fRE9DVU1FTlRTX0RPV05MT0FERVJfTk9OX01FRElDQUwiLCJPT1NfUEVSU09OX0RPQ1VNRU5UU19SRUFERVJfTUVESUNBTCIsIk9PU19QT1JUX0lORk9fUkVBREVSIiwiVlBOVVNFUjYiLCJPT1NfUEVSU09OX1JFTUFSS1NfUkVBREVSX01FRElDQUwiLCJBV1MtREVWLUFETUlOIiwiQVdTLVRPT0xTLUFETUlOIiwiQVdTLUJJTExJTkctQURNSU4iLCJJTlNQRUNUSU9OX1RFTVBMQVRFX0lURU0iLCJPT1NfUEVSU09OX1JFTUFSS1NfREVMRVRPUiIsIk9PU19QRVJTT05fUkVBREVSX1NVTU1BUlkiLCJPT1NfUEVSU09OX1JFQURFUl9QSFlTSUNBTCIsIk9PU19XT1JLRkxPV19FRElUT1IiLCJPT1NfVEVNUExBVEVfTElCUkFSWV9SRUFERVIiLCJBUFBST0FDSF9JTkZPX0VESVRPUiIsIk9PU19URU1QTEFURV9MSUJSQVJZX0RFTEVUT1IiLCJBV1MtU1RHLUFETUlOIiwiT09TX1BFUlNPTl9SRU1BUktTX1JFQURFUl9UUkFWRUwiLCJPT1NfTUFOTklOR19BR0VOVF9WQVJOQSIsIk9PU19QRVJTT05fUkVBREVSX0NPTlRBQ1QiLCJPT1NfUEVSU09OX1JFQURFUl9ORVhUT0ZLSU4iLCJPT1NfSU5TUEVDVElPTl9TQ0hFRFVMRV9FRElUT1IiLCJFVkVSWU9ORSIsIk9PU19QRVJTT05fUkVBREVSX0ZBTUlMWSIsIk9PU19QRVJTT05fUkVNQVJLU19SRUFERVJfRElTQ0lQTElOQVJZIl0sImFwcGxpY2F0aW9uIjoiT09TIiwiY29udGV4dCI6Ik1BTk5JTkdfT0ZGSUNFOjEyOWQxNjAzLWFhZTktNDQ1NC04OWRjLWI4NzFhMGNmNGJhMCIsImV4cCI6MTU0MTc3Njg3OCwiaWF0IjoxNTQxNzc2Mjc4LCJpc3MiOiIiLCJwZXJtaXNzaW9ucyI6WyJJTlNQRUNUSU9OX1NDSEVEVUxFOkRMUlVDIiwiUEVSU09OX1JFTUFSS1NfU0FMQVJZOkNMUlVEIiwiUEVSU09OX0RPQ1VNRU5UU19DRVJUSUZJQ0FURVM6TFJDTlVEIiwiUEVSU09OOkxSQ1VEIiwiUEVSU09OX05FWFRPRktJTjpDTFJVRCIsIlBFUlNPTl9SRU1BUktTX01FRElDQUw6Q0xSVUQiLCJQRVJTT05fRE9DVU1FTlRTX0xJQ0VOU0U6TFJDTlVEIiwiUEVSU09OX0ZBTUlMWTpDTFJVRCIsIlBPUlRfSU5GT19BUFBST0FDSDpMUlVDIiwiSU5TUEVDVElPTl9URU1QTEFURTpMUlVDRCIsIklOU1BFQ1RJT05fVEVNUExBVEVfSVRFTTpMUlVDRCIsIlBMQVRGT1JNX1JFTUFSS1M6TFJVQ0QiLCJQTEFURk9STV9XT1JLRkxPV19ERUZJTklUSU9OOkNVIiwiVkVTU0VMX0lUSU5FUkFSWTpMUiIsIlBPUlRfQ09NTUVOVFM6TFJVQ0QiLCJQRVJTT05fUkFOS19BVkFJTEFCSUxJVFk6TFJDVUQiLCJQRVJTT05fQkFDS0dST1VORDpDTFJVRCIsIkZMRUVUX1BFUkZPUk1BTkNFOkxSIiwiUEVSU09OX1NFUlZJQ0U6TFJVQ0QiLCJQRVJTT05fQ09OVEFDVDpDTFJVRCIsIlBMQVRGT1JNX0RPQ1VNRU5UUzpMUlVDTkQiLCJQRVJTT05fUEhZU0lDQUw6Q0xSVUQiLCJQRVJTT05fUkVNQVJLU19QRVJTT05BTDpDTFJVRCIsIlBMQVRGT1JNX1dPUktGTE9XX0lOU1RBTkNFOkNVIiwiUEVSU09OX0RPQ1VNRU5UU19NRURJQ0FMOkxSVUNORCIsIlBFUlNPTl9SRU1BUktTX1RSQVZFTDpMUiIsIlBFUlNPTl9SRU1BUktTX0RJU0NJUExJTkFSWTpDTFJVRCIsIlBPUlRfTVlfQ09NTUVOVFM6TFJVQ0QiLCJQT1JUX0lORk86TFIiLCJWRVNTRUxfUkVTUE9OU0lCSUxJVElFUzpMUlVDIl0sInVzZXJJZCI6ImYxYzU3ZTRiLWEwZmEtNGJhZS04NWM4LTMzMzE1YWE4ZjJlZCJ9NJ9jflW7HkRLL8X7olwvxeSl6bdeO783iOkLegBcocZCP0szh3kZ45gG3WAGN6O2KERuyg7lVGz1b5PT7CpaOyBGTGMYZDN6H6mqqs4EUidS10OV7191rYxLy0xh5axdw4O9Oci3fUL8U8ueO0AUNVombTdw3Ncgi7e35wmxvPZiPe6fs1aldy3BCCs4nZxV6cu8DeOmBRYuSC8qzYwmwZvWAljJAOOOT1xvG8zQ6YUGPrNreADKZhVnbksjfGBee3fE3GjcFK8Sd1dbwap2hcw0nFX2PPK2IqLLeEdrOK1KcaxwHSfCupPGvXQa9ga03GMRhyd95Q9uZ6nSt2UijMEglCCQzSMKMQykriBsAD3gQ375UnrXwzFdo6qfBWrNiBOuQiHN2E5XqMpRk1GYBH1K1cf8wp1ninGX4kJP6jbIGkAwNlsE0sLeXifUV0SLBHwEEFreq6BjLyXrWnmhXUPMoQOa07zwx5iypwSSSro6x2xsEjKtJWA6kauuArEfS7fYpTqKrOpZhPMZyrk5LojLgAnsPEgoDmm0PxMDDPaDSExXGwwDDumOw5UDrgoSp6Holt0XJ9sV1N2Jy7uoKCT6268ovIHOwjsrAKugNJAfGRYuxAzT9Dr5R3wxxZxw571yLAxitA5fZeejgqZqrZ1MaII
That decodes fine in https://www.developertoolkits.com/base64/decoder
#Gary Lloyd is right in that because JWT format is <header>.<payload>.<signature> and . is not part of base64, that causes base64 command to error out with invalid input.
What's more is that JWT format for <header>, <payload>, and <signature> are base64URL which is slight modification of base64.
Another note is that if you try to decode <signature>, it inherently has all kinds of funny characters(maybe binary?) which will fail if you try decoding it.
All that said, try separating the <header> and <payload> and it should decode just fine.
Here's a simple bash script that you can add in your bashrc file if you really want to use cli.
#!/usr/bin/env bash
function base64jwt() {
read content
token_parts=($(echo "$content" | tr "." "\n"))
echo "[$(base64 -d <<< "$token_parts[1]"), $(base64 -d <<< "$token_parts[2]")]"
}
Note that I added the content in an array format [<header_content>, <payload_content>] so that you can easily pipe that to tool like jq for prettier json format.
e.g.
echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG5Eb2UiLCJpYXQiOjE1MTYyMzkwMjJ9.RW7PfdmXPU5baGCV2WIXosKpuahEMUUY4nJvEh7gLDo" \
| base64jwt \
| jq
curl --data "<xml>" --header "Content-Type: text/xml" --request PROPFIND url.com
By reading the curl man page I could not understand how the above commandline is using --data option.
Question:
What does above commandline do ?
Why doesn't man page describe this usage? If it does then what did I not understand after reading the man page?
The --data flag is for defining POST data.
The command sends a POST with contents <xml> and MIME type text/xml. However, with the flag --request, you are setting the HTTP method from POST to PROPFIND and sending the request to url.com.
I also did manage to find the --data flag in the manual:
-d, --data <data>
(HTTP) Sends the specified data in a POST request to the HTTP server,
in the same way that a browser does when a user has filled in an HTML
form and presses the submit button. This will cause curl to pass the
data to the server using the content-type
application/x-www-form-urlencoded. Compare to -F, --form.
-d, --data is the same as --data-ascii. To post data purely binary, you should instead use the --data-binary option. To URL-encode the
value of a form field you may use --data-urlencode.
If any of these options is used more than once on the same command
line, the data pieces specified will be merged together with a
separating &-symbol. Thus, using '-d name=daniel -d skill=lousy' would
generate a post chunk that looks like 'name=daniel&skill=lousy'.
If you start the data with the letter #, the rest should be a file
name to read the data from, or - if you want curl to read the data
from stdin. The contents of the file must already be URL-encoded.
Multiple files can also be specified. Posting data from a file named
'foobar' would thus be done with --data #filename. When --data is told
to read from a file like that, carriage returns and newlines will be
stripped out.
I am using Apache Stanbol. It works for enhancing the text, however when I tried sentiment analysis and sentence detection, it doesn't work.
I tried this code
curl -v -X POST -H "Accept: text/plain" -H "Content-type: text/plain; \
charset=UTF-8" --data "Some text for analysis" \
"http://localhost:8081/enhancer/engine/sentiment-wordclassifier"
But it gives blank { } output, I tried changing the header attributes but no luck.
am I missing something? Do I need to do some configuration first?
I even tried adding analyzer in the enhancer chain but the same blank output, also tried REST API for opennlp-sentence, but it didn't work.
I guess you are sending data to the wrong endpoint... usually calls to the enhancer need to be done to all chains:
http://host/stanbol/enhancer
or to a concrete chain:
http://host/stanbol/enhancer/chain/<name>
The enhancer results couldn't be serialized as plain text, but in any of the RDF serialization supported by Stanbol. So the Accept header would need to be any of those, text/turtle for instance.
Further details at the documentation: http://stanbol.apache.org/docs/trunk/components/enhancer/#RESTful_API