javascript window.name 作为数据传输：一种有效的方法？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10567847/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
window.name as a data transport: a valid approach?
提问by Dagg Nabbit
Overview and original question
概述和原始问题
window.nameis an interesting beast. MDN's description hints at the original intent:
window.name是一个有趣的野兽。MDN 的描述暗示了最初的意图：
The name of the window is used primarily for setting targets for hyperlinks and forms. Windows do not need to have names.
窗口名称主要用于设置超链接和表单的目标。Windows 不需要有名称。
So, this means we can open the console in this window, and write:
所以，这意味着我们可以在这个窗口中打开控制台，然后写：
var win = window.open('http://google.com', 'el goog');
...and then let it through the popup blocker, that should open google.com in a window named "el goog." I can't access the nameproperty of winbecause of the same-origin policy, but if I open a console in the new window and type name, I'll get "el goog".
...然后让它通过弹出窗口阻止程序，这应该会在名为“el goog”的窗口中打开 google.com。由于同源策略，我无法访问 的name属性win，但是如果我在新窗口中打开一个控制台并输入name，我会得到"el goog".
If I send the window back to the domain I opened it from (in this case stackoverflow.com), I can get the nameproperty, and it hasn't changed.
如果我将窗口发送回我打开它的域（在本例中为 stackoverflow.com），我可以获得该name属性，并且它没有改变。
win.location.replace(location.href);
win.name; // "el goog"
This means we can have a kind of cross-domain session store by setting the nameproperty of a window.
这意味着我们可以通过设置name窗口的属性来拥有一种跨域会话存储。
If google.com had changedthe value of window.namebefore the window was sent back to the original domain, we'd see the new value instead of "el goog." This could be used as a cross-domain data transport, similar in utility to JSONP or CORS.
如果 google.com在窗口发送回原始域之前更改了 的值window.name，我们将看到新值而不是“el goog”。这可以用作跨域数据传输，其效用类似于 JSONP 或 CORS。
I did a bit of searching to try to find more info, and apparently dojo thinks it's legitas a transport. Somehow, though, that doesn't completely reassure me. So my question is, are any reputable sites using window.nameas a data transport? I'd think it would be easily spotted, because their docs would say something like "add 'callback' to the query string for JSONP, or add 'whatever' for window.name," but I've never seen anything like that. Has anyone actually spotted this in the wild?
我做了一些搜索以试图找到更多信息，显然 dojo认为它作为一种交通工具是合法的。然而，不知何故，这并不能完全让我放心。所以我的问题是，是否有任何信誉良好的站点window.name用作数据传输？我认为它很容易被发现，因为他们的文档会说“在 JSONP 的查询字符串中添加‘回调’，或者为 window.name 添加‘任何’”，但我从未见过这样的事情。真的有人在野外发现过这个吗？
Alternate question
替代问题
It may be the case that nobody is really using this technique; if that's true then (as Rob W pointed out) the question above is unanswerable. So, my alternate question is, what are the problems with this approach? This might help explain why it hasn't really been adopted.
可能没有人真正使用这种技术；如果这是真的，那么（正如 Rob W 指出的那样）上面的问题是无法回答的。所以，我的另一个问题是，这种方法有什么问题？这可能有助于解释为什么它没有真正被采用。
As I see it, there are at least two benefits to this approach over JSONP.
在我看来，与 JSONP 相比，这种方法至少有两个好处。
With JSONP, you trust a script from a foreign origin to run on your domain. With
window.name, any scripts included by a malicious site would run on their own domain.With JSONP, there is no way to pass in big data (anything too big for a URL), and no way to make an HTTP POST. With
window.name, we can post arbitrary data of any size.
使用 JSONP，您可以信任来自外国的脚本在您的域上运行。使用
window.name，恶意站点包含的任何脚本都将在其自己的域中运行。使用 JSONP，无法传递大数据（对于 URL 而言太大的任何数据），也无法进行 HTTP POST。使用
window.name，我们可以发布任意大小的任意数据。
What are the drawbacks?
有什么缺点？
Example implementation
示例实现
Here is a very simple example of a client implementation. This doesn't handle POST requests, only GET.
这是一个非常简单的客户端实现示例。这不处理 POST 请求，只处理 GET。
function fetchData(url, callback) {
var frame = document.createElement('iframe');
frame.onload = function() {
frame.onload = function() {
callback(frame.contentWindow.name);
frame.parentNode.removeChild(frame);
}
frame.src = 'about:blank';
}
frame.src = url;
document.body.appendChild(frame);
}
// using it
fetchData('http://somehost.com/api?foo=bar', function(response) {
console.log(response);
});?
I've set up a fiddle to test it out here. It uses this scriptas a test server.
我已经设置了一个小提琴来测试它here。它使用此脚本作为测试服务器。
Here is a slightly longer example that can make POST requests: http://jsfiddle.net/n9Wnx/2/
这是一个可以发出 POST 请求的稍长示例：http: //jsfiddle.net/n9Wnx/2/
Summary
概括
As far as I can tell, window.namehas not caught on as a data transport. I wonder if my perception is accurate (thus the original question) and if so, I wonder whythis is the case. I've listed a few advantages that window.nameseems to have over JSONP. Can anyone identify some disadvantagesthat might have contributed to preventing adoption of this technique?
据我所知，window.name还没有流行起来作为数据传输。我想知道我的看法是否准确（因此是原始问题），如果是，我想知道为什么会这样。我列出了一些window.name似乎优于 JSONP 的优势。任何人都可以确定一些可能导致阻止采用这种技术的缺点吗？
More to the point, can anyone give me a solid reason why I shouldn't use winow.nameas a data transport?
更重要的是，谁能给我一个充分的理由为什么我不应该将其winow.name用作数据传输？
回答by duskwuff -inactive-
window.nameisn't particularly good as a transport, as (AFAIK) it doesn't fire any events when it's changed. As a result, an application which was trying to use window.nameas a two-way communications channel would have to poll it for updates.
window.name作为传输并不是特别好，因为（AFAIK）它在更改时不会触发任何事件。结果，试图window.name用作双向通信通道的应用程序必须轮询它以获取更新。
As far as sites that actually use it: I've never heard of any. There might be some, but I've only heard this technique discussed in a purely theoretical sense.
至于实际使用它的网站：我从来没有听说过。可能有一些，但我只听说过从纯理论意义上讨论这种技术。
回答by B12Toaster
More to the point, can anyone give me a solid reason why I shouldn't use winow.name as a data transport?
更重要的是，谁能给我一个充分的理由为什么我不应该使用 winow.name 作为数据传输？
While window.namecan be a true saviour when it comes to transporting data accross domain changes, the reason it cannot be used as real universal data transport mechanism is due to the lack of an api to store and retrieve data. For example localStorageprovides setItem, getItem. Such an api is necessary to abstract from how values are actually stored and to prevent format clashes (which would arise if different libraries running on your side would store in different formats).
虽然window.name在跨域更改传输数据时可能是真正的救星，但它不能用作真正的通用数据传输机制的原因是缺乏用于存储和检索数据的 api。例如localStorage提供setItem, getItem. 这样的 api 对于从实际存储值的方式中抽象出来并防止格式冲突（如果您身边运行的不同库以不同格式存储会出现这种情况）是必要的。
As far as I can tell, window.name has not caught on as a data transport. I wonder if my perception is accurate (thus the original question) and if so, I wonder why this is the case.
据我所知，window.name 还没有流行起来作为数据传输。我想知道我的看法是否准确（因此是原始问题），如果是，我想知道为什么会这样。
Since window.namedoes not provide such a store/retrieve abstraction layer – as described in my point above – 3rd-party librabries cannot know which format to use when storing data in window.mainand hence will never use window.mainas it is unreliable. If you (i.e. your main program) were the only one reading from or writing to window.nameyou could decide to store data in json format and store/retrieve accordingly. But what if a 3rd-party library also wanted to store/retrieve something and it decided not to use json and instead go with another of the numerous serialization formats... this would accidentally break your json format and definitely cause trouble.
由于window.name不提供这样的存储/检索抽象层——正如我上面的观点所述——第三方库无法知道在存储数据时使用哪种格式window.main，因此永远不会使用，window.main因为它不可靠。如果您（即您的主程序）是唯一一个读取或写入的人，window.name您可以决定以 json 格式存储数据并相应地存储/检索。但是，如果第 3 方库也想存储/检索某些内容，并且它决定不使用 json 而是使用众多序列化格式中的另一种，该怎么办……这会意外地破坏您的 json 格式并肯定会造成麻烦。
