Can't find anywhere namely API (REST API to receive JSON on request). What I'm looking for is:
Hiragana
Such a format:
{
ta: {
symbol: "た",
transliteration: "ta", // id
unicode: "\u305f",
pronunciation: "https://audio.db/.../ta.mp3" // Audio file or URL for audio file
}
}
// or
[
{
symbol: "た",
transliteration: "ta",
unicode: "\u305f",
pronunciation: "https://audio.db/.../ta.mp3"
}
]
Dictionary
Such a format:
{
neko: {
kanji: "猫",
kanjiUnicode: "\u732b",
hiragana: "ねこ",
// startsWith or hiraganaUnicode are required (I need to access first letter of the word)
hiraganaUnicode: "\u306d\u3053",
startsWith: "ne",
pronunciation: "https://audio.db/.../neko.mp3",
// picture or pictureSet would be useful
picture: "https://image.db/.../neko.webp",
pictureSet: ["https://image.db/.../neko1.webp", "https://image.db/.../neko2.webp"]
}
}
I have found this online dictionary. It seems quite good and accurate but the problem is it doesn't have documentation at all.
Related
I'm writing a google doc using the google docs api, and I found that there is a json 'dump' feature that helps you understand the structure of your google doc.
The only problem is, the JSON dump is different than the JSON used to actually write the doc.
For example, this is where I found out about the JSON dump:
https://developers.google.com/docs/api/samples/output-json
The truncated JSON example looks like this:
{
"body": {
"content": [
{
"endIndex": 1,
"sectionBreak": {
"sectionStyle": {
"columnSeparatorStyle": "NONE",
"contentDirection": "LEFT_TO_RIGHT"
}
}
},
{
"endIndex": 75,
"paragraph": {
"elements": [
{
"endIndex": 75,
"startIndex": 1,
"textRun": {
"content": "This is an ordinary paragraph. It is the first paragraph of the document.\n",
"textStyle": {}
}
}
],
"paragraphStyle": {
"direction": "LEFT_TO_RIGHT",
"namedStyleType": "NORMAL_TEXT"
}
},
"startIndex": 1
},
And here is documentation for making update requests to your document:
https://developers.google.com/docs/api/reference/rest/v1/documents/request
Basically what I'm seeing is that the two have some general structures in common, but the notation for actually writing the JSON is different.
For instance, here's an example of how to write to the document:
const updateObject = {
documentId: 'documentID',
resource: {
requests: [ {
insertText: {
text: 'hello world',
location: {
index: 1,
},
},
} ],
},
};
I'm hoping there is a way I can write the json in the same way that the dump is structured, and then pass that format through to create new documents. Otherwise I'm going to have to tediously translate everything from one format to the other (and there's a lot),
Does anyone have any advice on this? Maybe there is something I'm missing. Thanks!
It appears to be intended. The JSON dump in the example matches the Document object. You can also find this same structure returned when you create a document via thedocuments.create API. Unfortunately, pretty much all of the fields are output-only. I tried to plug in the body from the sample into the API, and while it didn't fail, it also ignored the input and just created a basic document.
Meanwhile, the batchUpdate methods that you found to send update requests all seem focused on specific changes and none of them take a Document object. I think your best bet would be to follow up the feature request that you found, the Docs API is still considered in v1 after all.
I am trying to POST HTTP request to Detect Text in images converted to base64 from mat image. When I run the code, I get
{
"responses":[
{
"error":{
"code":3,
"message":"Bad image data."
}
}
]
}
My curl POST field is a JSON string like this:
{
"requests":[
{
"image":{
"content":"lZ+elp+elp+elp+elZ+elZ6dlZ6dlZ6dlJ6dlJ2ck52ck52ck52ck52ck52bk5ybkpyakpyakpyakZuZkJqYj5m...........srW0srWzsrWzsrWzsrWz"
},
"features":[
{
"type":"TEXT_DETECTION"
}
]
}
]
}
I am not sure if the base64 encoded image is valid. Please help !
I have found a solution by converting the Mat object into vector and then encode.
std::vector<uchar> array;
cv::imencode(".png",mat_img, array);
std::string encoded = Base64::encode(array);
I'm trying to make a list in JSON. I'm using a tutorial I found on the internet and it seems to have a syntax error in it. I have no previous experience with JSON and I cannot figure out why this code shows an error. Line 2 in particular.
{
"quizlist":[
{
"question":"Portuguese is spoken in _______",
"option1":"Brazil",
"option2":"Argentina",
"option3":"Ecuador"
},
{
"question":"What is the capital of Peru?",
"option1":"Lima",
"option2":"Bogota",
"option3":"San Juan"
},
{
"question":"Which country is long and thin?",
"option1":"Chile",
"option2":"Uruguay",
"option3":"Colombia"
}
]}
I am using Dreamweaver CS6 as I am trying to create this for a website.
Thank you.
The JSON is fine. I have an intuition that you are trying to use this JSON as it is in html.You need to save the JSON as a javascript object. Try this:
var myJSON = {
"quizlist":[
{
"question":"Portuguese is spoken in _______",
"option1":"Brazil",
"option2":"Argentina",
"option3":"Ecuador"
},
{
"question":"What is the capital of Peru?",
"option1":"Lima",
"option2":"Bogota",
"option3":"San Juan"
},
{
"question":"Which country is long and thin?",
"option1":"Chile",
"option2":"Uruguay",
"option3":"Colombia"
}
]};
Then you can use this Javascript object myJSON wherever you want to use the JSON data.
Hope it helps .. :)
In older versions of breeze when I analyze the breeze metadata file, I'd see a format that shows a detailed json format of metadata that describes the DBContext.
So an example from Breeze's sample would be something like this:
{
"schema":{
"namespace":"Todo.Models",
"alias":"Self",
"annotation:UseStrongSpatialTypes":"false",
"xmlns:annotation":"http://schemas.microsoft.com/ado/2009/02/edm/annotation",
"xmlns":"http://schemas.microsoft.com/ado/2009/11/edm",
"cSpaceOSpaceMapping":"[[\"Todo.Models.TodoItem\",\"Todo.Models.TodoItem\"]]",
"entityType":{
"name":"TodoItem",
"key":{
"propertyRef":{
"name":"Id"
}
},
"property":[
{
"name":"Id",
"type":"Edm.Int32",
"nullable":"false",
"annotation:StoreGeneratedPattern":"Identity"
},
{
"name":"Description",
"type":"Edm.String",
"maxLength":"30",
"fixedLength":"false",
"unicode":"true",
"nullable":"false"
},
{
"name":"CreatedAt",
"type":"Edm.DateTime",
"nullable":"false"
},
{
"name":"IsDone",
"type":"Edm.Boolean",
"nullable":"false"
},
{
"name":"IsArchived",
"type":"Edm.Boolean",
"nullable":"false"
}
]
},
"entityContainer":{
"name":"TodosContext",
"entitySet":{
"name":"Todos",
"entityType":"Self.TodoItem"
}
}
}
}
But now after running this new version of breeze, and hitting my metadata file I see this weird oddity:
{
"?xml":{
"version":"1.0",
"encoding":"utf-8"
},
"schema":{
"namespace":"DBModel",
"alias":"Self",
"annotation:UseStrongSpatialTypes":"false",
"xmlns:annotation":"http://schemas.microsoft.com/ado/2009/02/edm/annotation",
"xmlns:customannotation":"http://schemas.microsoft.com/ado/2013/11/edm/customannotation",
"xmlns":"http://schemas.microsoft.com/ado/2009/11/edm",
"cSpaceOSpaceMapping":"[[\"DBModel.User\",\"Model.User\"]]",
"entityContainer":{
"name":"DBEntities",
"annotation:LazyLoadingEnabled":"true",
"entitySet":{
"name":"Users",
"entityType":"DBModel.User"
}
},
"entityType":{
"name":"User",
"key":{
"propertyRef":{
"name":"Id"
}
},
"property":[
{
"name":"Id",
"type":"Edm.Int64",
"nullable":"false",
"annotation:StoreGeneratedPattern":"Identity"
},
{
"name":"Firstname",
"type":"Edm.String",
"maxLength":"40",
"fixedLength":"false",
"unicode":"false"
},
{
"name":"Lastname",
"type":"Edm.String",
"maxLength":"60",
"fixedLength":"false",
"unicode":"false"
},
{
"name":"Email",
"type":"Edm.String",
"nullable":"false",
"maxLength":"128",
"fixedLength":"false",
"unicode":"false"
}
]
}
}
}
What's the point in including the xml information within the metadata? How is breeze able to pick up information from the metadata between these two versions and still work as it does?
The EFContextProvider (in breeze.server.net) basically just converts the metadata information from EntityFramework from XML to JSON, and sends that back to the Breeze client. The Breeze client knows how to get what it needs from that JSON format, even when there are some extra XML-related bits tacked on.
Basically, Breeze ignores the parts that aren't relevant. In newer versions of EF, the extra stuff in the XML has expanded, but the basic structure has remained the same.
I have one object (jar), which contains this (by console.log):
{ _jar: { store: { idx: { localhost: { '/': { PHPSESSID: Cookie="PHPSESSID=pe1952pk023e7b6d7t9am3kse0; Path=/; hostOnly=true; aAge=18ms; cAge=97ms" } } } } } }
I'm trying to store it to MongoDB instance which is ok, but after loading it from there, it's kind of malformed. This simulates it:
console.log(JSON.parse(JSON.stringify(jar)));
The above outputs this:
{ _jar: { store: { idx: [Object] } } }
So all of the sudden 'localhost' part got vanished into 'Object'? How to prevent this?
console.log doc says:
If formatting elements are not found in the first string then
util.inspect is used on each argument.
util.inspect doc says:
Return a string representation of object, which is useful for
debugging.
[...]
depth - tells inspect how many times to recurse while formatting the object. This is useful for inspecting large complicated objects.
Defaults to 2. To make it recurse indefinitely pass null.
That is, console.log(jar) prints only the first two levels, _jar and store, and the fields of store are printed in short format. That's why the content of store.idx is printed as [Object]. To print every level, type util.inspect(jar, { depth: null }).
That console.log formatting, not a JSON.parse problem.
console.log(jar) will give you the same output.