I'm following the Hello Prediction example of the Google Prediction API.
Unfortunately the training file language_id.txt seems to be corrupted somehow? I tested downloading it using Google Chrome and Firefox, same result, see screenshot:
I think, therefore my tests do not work and I always get back English 1.0 as score for the Muy Bueno example string.
...
{
"label": "English",
"score": "1.000000"
},
...
Where do I get a usable language_id.txt test file from or is there anything else I can do?
EDIT: My guess is, the file has not been stored in UTF-8 format on the Google server?
The file is in UTF-8, but it doesn't declare an encoding, so viewing it in a browser assumes the default HTTP charset, ISO-8859-1.
I'm not sure why you're actually getting a corrupted copy (if I view it in Chrome, it appears corrupt, but saving it results in a correct UTF-8-encoded file), but perhaps you could try another mechanism to download it?
Related
The Google Drive API v2 to v3 migration guide says:
The exportLinks field has been removed from files. To export Google Documents, use the files.export method instead.
I don't want to export (download) the file right away. "files.export" will actually download the file. I want a link to download the file, later. This was possible in v2 by means of the exportLinks.
How can I in v3 accomplish the same? If it is not possible, why was this useful feature removed?
Besides, (similar problem to above) downloadUrl was also removed, and the suggested alternative ("files.get with ?alt=media") downloads the file instead of providing a download link. This means there is no way in v3 to get a public short lived URL for a file?
EDIT:
there is no way in v3 to get a public short lived URL for a file?
For regular files, apparently yes.
This seems to work fine (a public short lived link to the file with its right name and contents):
https://www.googleapis.com/drive/v3/files/ID?alt=media&access_token=TOKEN
For google apps files, no (not even private, as v2 exportLinks used to be).
https://www.googleapis.com/drive/v3/files/ID/exportmimeType=TYPEv&access_token=TOKEN
Similar to regular files, this URL is a short lived link to the file contents, but lacking of its right name.
BTW, I see the API is not behaving consistently: /drive/v3/files/FILEID delivers the right file name, but /drive/v3/files/FILEID/export does not.
I think the API itself should be setting the right Content-Disposition, as it is apparently doing when issuing a /drive/v3/files/FILEID call.
This file naming problem invalidates the workaround to the lack of ExportLinks in v3.
The v2 ExportLinks allowed me to link a file (which is not the same as getting its content right away). Anyone logged in and with the proper permissions was able to access it, and the link didn't needed any access_token, and it wasn't short lived. It was good and useful.
Building a link with a raw API call like /drive/v3/files/FILEID/export (with mandatory access_token) would be an close enough workaround (it is temporary and public, not the same as it was, anyway). However, the naming problem invalidates it.
In v2, regular files have a WebContentLink and google apps files have exportLinks. In v3 exportLinks are gone, and I don't see any suitable alternative to them.
Once you query for your file by id you can use the function getWebContentLink() to get the download link of the file (eg. $file->getWebContentLink() ).
I think you're placing too much emphasis on the word "method".
There is still a link to export a file, it's https://www.googleapis.com/drive/v3/files/fileIdxxxxx/export&mimeType=xxxxx/xxxxx. Make sure you URL encode the mime type.
Eg
https://www.googleapis.com/drive/v3/files/1fGBQ81haNU_nEiC5GITZD3bxT0ppL2LHg-C0ubD4Q_s/export?mimeType=text/csv&access_token=ya29.Gmo0BMvO-pVEPKsiD9j4D-NZVGE91MChRvwOcBSg3cTHt5uAClf-jFxcovQScbO2QQhwHS95eSGW1eQQcK5G1UQ6oI4BFEJJkntEBkgriZ14GbHuvpDL7LT2pKA--WiPuNoDDIuZMm5lWtlr
These links form part of the API, so the expectation is that you've written a client that sends authenticated requests, and deals with the response data. This explains why, if you simply paste the link into a browser without an access_token, it will fail. It also explains why the filename is export, ie. it isn't intended that your client would ever use a filename, but rather it should receive the data as a stream. This SO answer discusses the situation in more detail How to set name of file downloaded from browser?
Our application is entirely built on websockets. We don't do any HTTP request-reply. However, we are stuck with file download. If i receive file content via websockets can I wrote to local folder on user computer ?
If it makes a difference, we are only supporting Chrome so not issue if it doesn't work on other browsers.
Also, I know i can do this via HTTP. Trying to avoid it and stick to websockets since thats how the entire app is.
Thanks a lot in advance!
The solution depends on size of your file.
If size is less than about 50 MB, I would encode file's content to base64 string on the server and send this string to the client. Client should receive parts of the string, concat them to single result, and store. After receiving whole string, add link (tag <a>) to your page with attribute href set to "data:<data_type>;base64,<base64_encoded_file_content>". <data_type> is a mime type of your file, for example "text/html" or "image/png". Suggest file name by adding download attribute set to name of file (doesn't work for Chrome on OS X).
Unfortunately I have no solution for large files. Currently there is only FileEntry API that allows to write files with JS, but according to documentation it is supported only by Chrome v13+, learn more here https://developer.mozilla.org/en-US/docs/Web/API/FileEntry.
I've been using Google Apps Email Settings API for a while but I came to a problem when I tried to insert aliases, signatures or any information with "ñ" or "Ñ". It adds garbage instead of those characters and it doesn't seem to respect the charset specified (utf-8) in the HTTP header nor the XML character encoding.
I have tried via my own python code and also using OAuth Playground[1] but it's been impossible to properly add the mentioned characters.
¿Any idea/suggestion?
Thanks in advance.
EDIT: It seems that the problem is not in the request but in the response. I have encoded it successfully in my code but it should be also fixed in OAuth Playground.
[1] https://developers.google.com/oauthplayground/
I have succesfully called Google API client methods using UTF8-encoded strings, so it is definitely an issue with your Python setup.
I would workaround this issue sending Unicode strings instead of UTF-8 encoded:
u'literal string' # This is unicode
'encoded utf-8 string'.decode('utf-8') # This is unicode
EDIT: Re-reading your answer it seems that you are making raw HTTP calls with hand-made XML documents. I can't understand why. If it's the way you want to go, take a look into Emails Settings API client code to learn how to build the XML documents.
I have a concrete5 site, which uses 'designer content' an add on available via their market place.
Our clients site requires the use of macrons for their language.
Now this is fine throughout 99% of the site, whether hard-coded html or via a content block etc. However, when macrons are used inside a block created with 'designer content' the macron is replaced with a "?"...
Can anyone help?
Unfortunately this site wont let me post an image to help you see whats going on due to my 'low reputation'....riiiiight thats helpful.
Thanks in advance!
usually the apparition of question marks "?" instead of certain characters is the sign of a charset coding problem. With C5 you should be using a generic UTF8 encoding however if your database table was set to use a different charset or if your php settings are set to a different charset, then you will get those weird characters.
You should start with your php.ini and set the charset to utf8
If that doesn't fix the problem, check this thread, it has a useful script to use to fix the database
http://www.concrete5.org/community/forums/usage/utf-8-or-unicode-problems-preventing-corrrupt-fonts-on-the-front/#52300
Be aware however that if content was saved while the charset was not correct, you may discover that the content still looks weird and you will have to insert it again AFTER having set the correct charset.
I have a problem with an attachment's name. When I call the site on google chrome it returns the file with the right name and extension. I tested it with internet explorer and it works fine too. The issue lies with only Firefox. I call the site and it returns the first word on the file title and no extension.
For example if I wanted a file called "My report.docx" it turns a file called "My". I Googled around and it turns out this is a common issue with people because browsers read the headers differently. They said the fix is to quote the file name:
Content-Disposition: attachment; filename=My Report.docx
is now: (note the quotes)
Content-Disposition: attachment; filename="My Report.docx"
However, that did not work for me.
On chrome it returned "My Report.docx" (actually with the quotes). Firefox returned a odd file that had the proper extension and proper name and no quotes yet it could not be executed. It was the proper file size, proper extension, and proper name yet it could not be executed. Also it returns a space before and after the file name.
I know this is a very old question, but I was recently having the same problem. The solution is to either
Encode your filename per RFC2184 or,
If you don't have special characters in your filename, quote it in the content disposition string.
Since you've already tried 2, you could try using 1 and seeing how that works out.
Usually I use the ContentDisposition class to generate my header for me:
Dim contentDispositionHeader = New Net.Mime.ContentDisposition() With {.FileName = filename}
Response.AddHeader("Content-Disposition", contentDispositionHeader.ToString())
Hope this helps.
This should work as expected, here's another SOq with the same problem:
Downloading a file with a different name to the stored name
and also the Mozilla page (I guess you were referencing this one):
http://kb.mozillazine.org/Filenames_with_spaces_are_truncated_upon_download
I don't know the specifics of your server side code, but here are some things to confirm / try:
If you have PHP available at the server, can you try the code from the first link above? If not, you can probably find something on the Net in your language of choice. That way, you can confirm whether the issue is in your code or somewhere else (server setup, browser, etc.)
Is this happening on other client machines (i.e. where you try the download from) or only on that one? You might want to try others to confirm.
Is this working fine in IE / Safari or some other browser? You can even try doing it with wget or curl from the command line or something like that.
Are you also providing the Content-Type header correctly?
Can you try downloading some other file or a file of a different type, e.g. a .png or a .xls? In fact, probably the easiest would be to try a plain text file (text/plain) and then take it from there.
Hope this helps.