xcode，nslog奇怪的问题 [英] xcode, nslog weird hitch

问题描述

下面的代码在单击tinyurl链接时为我提供了tinyurl链接上的NSLog重定向位置.但是，如果我删除以下代码 [[UIApplication sharedApplication] openURL:[request URL]]; ，它将为我提供NSLog中的实际网站，而不是tinyurl链接.在显示共享应用程序代码时，如何在NSLog中拥有实际网站URL的地方?

The code below gives me an NSLog redirect location on a tinyurl link when clicking on a tinyurl link. However, if I remove the following piece of code [[UIApplication sharedApplication] openURL:[request URL]];, it will give me the actual website in NSLog and not the tinyurl link. How can I make it where I can have the actual website URL in NSLog while the share application code is presented?

- (BOOL)webView:(UIWebView*)webView shouldStartLoadWithRequest:(NSURLRequest*)request navigationType:(UIWebViewNavigationType)navigationType  {
    NSLog(@"Redirect Location: %@",[request.URL absoluteString]);
    [[UIApplication sharedApplication] openURL:[request URL]];
}

推荐答案

简短答案:

使用 UIWebViewDelegate 方法 shouldStartLoadWithRequest 并不是确定要重定向到哪个站点的好方法(特别是因为从代码中判断，您最终会在外部应用程序(而不是 UIWebView )中打开它，因为在重定向发生之前，您将获得 shouldStartLoadWithRequest .不过，您可以使用 NSURLConnection 和

Using UIWebViewDelegate method shouldStartLoadWithRequest is not a great mechanism for figuring out to which site you'll be redirected (especially since, judging from your code, you'll ultimately opening it in an external app, not your UIWebView), because you're getting shouldStartLoadWithRequest before the redirect takes place. You can, though, use NSURLConnection and NSURLConnectionDataDelegate methods to figure out where you'll eventually be redirected.

长答案:

如果查看 shouldStartLoadWithRequest ，如果返回 YES ，则将让 UIWebView 遵循重定向请求.考虑以下 shouldStartLoadWithRequest :

If you look at shouldStartLoadWithRequest, if you return YES, you'll let the UIWebView follow the redirect requests. Consider the following shouldStartLoadWithRequest:

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
{
    NSLog(@"%@", request.URL);
    return YES;
}

如果将它与随机的 bit.ly URL结合使用，例如 http://nyti.ms/Yi6EAk ，则会看到以下日志:

If you use this with the a random bit.ly URL, say, http://nyti.ms/Yi6EAk, you'll see the following log:

2013-03-12 21:23:31.418 webtest[6959:c07] http://nyti.ms/Yi6EAk
2013-03-12 21:23:31.511 webtest[6959:c07] http://bit.ly/Yi6EAk?cc=0d7134b272b1004cb954d0400076e9fa
2013-03-12 21:23:31.560 webtest[6959:c07] http://www.nytimes.com/2013/03/13/us/politics/ryans-plan-aims-to-balance-budget-in-10-years.html?hp&_r=0

对 shouldStartLoadWithRequest 的第三次调用是我为其定义了 bit.ly 重定向URL的实际URL，即两次连续重定向的最终目标.但是，如果您的 shouldStartLoadWithRequest 返回 NO ，那么您将永远找不到最终将其重定向到哪个站点.(顺便说一句，您的 shouldStartLoadWithRequest 肯定应该返回 YES 或 NO ...您的示例也不会返回.)

That third call to shouldStartLoadWithRequest is the actual URL for which I defined the bit.ly redirect URL, i.e. the final destination of two consecutive redirects. But if your shouldStartLoadWithRequest returned NO, then you'll never figure out to which site it would ultimately be redirected. (And by the way, your shouldStartLoadWithRequest should definitely return YES or NO ... your sample doesn't return either.)

如您所见，因为 shouldStartLoadWithRequest 发生在重定向发生之前，所以您将看到每个重定向都在发生.根据结果​​站点的作用，您可能会在页面检索到更多内容时看到随后的 shouldStartLoadWithRequest 调用.这样一来，您就很难找到最终将您重定向到哪个网站的机制.

As you can see, because shouldStartLoadWithRequest happens before the redirect has a chance to take place, you'll see each and every redirect taking place. Depending upon what the resulting site does, you may see subsequent shouldStartLoadWithRequest calls as the page retrieves extra content. This makes this an awkward mechanism for finding out what site to which you were ultimately redirected.

如果您确实需要将您重定向到的站点，则可能需要使用 NSURLConnection .虽然通常用于实际从服务器检索数据，但它也可以用于捕获重定向(但不会遇到 UIWebViewDelegate 方法 shouldStartLoadWithRequest 的问题，很难区分真正的重定向和页面随后可能请求的随机其他内容.

If you really need the site you're being redirected to, you might want to use NSURLConnection, instead. While that is generally used for actually retrieving the data from the server, it can also be used for capturing the redirects (but not suffering from the problems of the UIWebViewDelegate method shouldStartLoadWithRequest, where it's tough to differentiate between genuine redirects from just random additional content that the page may subsequently request).

因此请考虑以下事项:

self.url = [NSURL URLWithString:@"http://nyti.ms/Yi6EAk"];
NSURLRequest *request = [NSURLRequest requestWithURL:self.url];
[NSURLConnection connectionWithRequest:request delegate:self];

然后，您可以实现 connection:willSendRequest:redirectResponse:，一种 NSURLConnectionDataDelegate 方法，该方法将跟踪各种重定向:

You can then implement connection:willSendRequest:redirectResponse:, a NSURLConnectionDataDelegate method, that will track the various redirects:

- (NSURLRequest *)connection:(NSURLConnection *)connection willSendRequest:(NSURLRequest *)request redirectResponse:(NSURLResponse *)response
{
    self.url = request.URL;

    return request;
}

很显然，因为您使用的是 NSURLConnection 来跟踪重定向，但是我们并不关心通常使用 NSURLConnection 的 responseData code>进行检索，我们可以在收到良好响应后立即取消连接(确信我们已经知道最终重定向到了哪个站点):

Clearly, because you're using NSURLConnection to track the redirects, but we don't really care about the responseData that we generally use NSURLConnection to retrieve, we can just cancel the connection as soon as you receive a good response (confident that we already know to which site were finally redirected):

- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response
{
    [connection cancel];

    NSLog(@"Ok, we now know that the resulting URL is %@", self.url);
}

顺便说一句，您可能还想捕获连接错误，例如:

You might, by the way, also want to capture connection errors, for example:

- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error
{
    NSLog(@"Ok, we failed trying to retrieve data from %@", self.url);
}

最后，值得指出的是，使用 NSURLConnection 发出HTTP请求并使其遵循整个重定向系列的技术是一个非常低效的过程，因此您必须决定是否值得.但这是弄清楚HTTP重定向将引导您到何处的一种方法.

In closing, it's worth pointing out that this technique, of making the HTTP request with NSURLConnection and letting it follow the whole series of redirects, is a pretty inefficient process, so you'll have to decide whether it's worth it. But this is one way to figure out where your HTTP redirects will lead you.

最后一个警告，它捕获了传统的重定向，但是，如果页面正在执行任何客户端JavaScript重定向，则我认为这种技术将行不通.不过，它适用于绝大多数重定向的HTTP请求.

One final caveat, this captures traditional redirects, but if the page is doing any client-side JavaScript redirects, I don't think this technique will work. It works for the vast majority of redirected HTTP requests, though.

这篇关于xcode，nslog奇怪的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！