objective-c - qué - teoria del conocimiento resumen

¿Una forma confiable de comparar dos NSURL o una NSURL y una NSString?

Question

Recientemente tuve un problema al comparar dos NSURL y comparar un NSURL con una NSString (que es una dirección URL), la situación es que recibí una NSURLRequest de algún lugar, puedo o no saber la dirección URL a la que apunta, y tengo una URL NSString, diga "http://m.google.com", ahora necesito verificar si la URL en esa NSURLRequest es la misma que la cadena URL que tenía:

[[request.URL.absoluteString lowercaseString] isEqualToString: [self.myAddress lowercaseString]];

esto devuelve NO, ya que absoluteString me da "http://m.google.com/" mientras que mi cadena es "http://m.google.com" sin una barra al final, incluso si creo la solicitud NSURLRequest

[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://m.google.com"]]

todavía me da "http://m.google.com/" para absoluteString , me pregunto si hay alguna manera confiable de comparar a NSURL o una NSURL y una NSString.

1. verifique si uno ''contiene'' otro, pero esto no es confiable ya que ''http://m.google.com/blabla'' contiene ''http://m.google.com''.

2. convierta la NSString a NSURL y use el método isEqual para comparar dos NSURL y, con suerte, la implementación de la isEqual de isEqual puede resolverlo.

3. ¿Está basado en el paso 2, pero convierte cada NSURL a una URL standardizedURL usando la URL standardizedURL ?

¡Muchas gracias!

Answer 1

Al haber encontrado recientemente la situación en la que el [NSURL isEqual] devuelve falso al comparar dos URL como https://www.google.com/ y https://www.google.com , he encontrado que al aplicar URLByAppendingPathComponent con un vacío La cadena como parámetro para ambas URL devolverá el resultado correcto.

Así que algo como:

[[urlOne URLByAppendingPathComponent:@""] isEqual:[urlTwo URLByAppendingPathComponent:@""]]

agregará la barra diagonal final si falta y la dejará sola si ya está incluida, por lo que la comparación funcionará como se esperaba.

Me parece que estoy confiando en un comportamiento extraño para solucionar otro comportamiento extraño, pero esto es con lo que voy a menos que pueda convencerme de lo contrario ;-).

Answer 2

La manera fácil es:

NSString*urlString=[NSString stringWithFormat:@"%@",request.URL];

por lo que se compara con el método NSString isEqual:

BOOL equalty=[urlString isEqual:anotherNSString];

XD

Answer 3

Sé que esto es respondido. Pero no creo, está claro.

Me gustaría recomendar lo siguiente.

if ([[url1 absoluteString] isEqualToString:[url2 absoluteString]]) 
{
   //Add your implementation here
}

Answer 4

Si solo te preocupa la ambigüedad de la barra final, puedes prescindir de esta pregunta rápidamente sabiendo que la ruta NSURL recorta la barra al final.

Pero me gusta la idea de un método de categoría en NSURL que implemente alguna equivalencia basada en estándares ("equivalencia" es probablemente un término mejor que igualdad en este caso).

@RobNapier se refiere a una pregunta relacionada con una buena respuesta que apunta a RFC2616 . Otro estándar relevante para la sintaxis url es RFC1808 .

La parte difícil es decidir qué entendemos por equivalencia, por ejemplo, ¿qué pasa con las diferentes consultas o fragmentos (enlaces de anclaje)? El código de abajo se equivoca en el lado de la permisividad para la mayoría de estas ambigüedades ...

// in NSURL+uriEquivalence.m

- (BOOL)isEquivalent:(NSURL *)aURL {

    if ([self isEqual:aURL]) return YES;
    if ([[self scheme] caseInsensitiveCompare:[aURL scheme]] != NSOrderedSame) return NO;
    if ([[self host] caseInsensitiveCompare:[aURL host]] != NSOrderedSame) return NO;

    // NSURL path is smart about trimming trailing slashes
    // note case-sensitivty here
    if ([[self path] compare:[aURL path]] != NSOrderedSame) return NO;

    // at this point, we''ve established that the urls are equivalent according to the rfc
    // insofar as scheme, host, and paths match

    // according to rfc2616, port''s can weakly match if one is missing and the
    // other is default for the scheme, but for now, let''s insist on an explicit match
    if ([self port] || [aURL port]) {
        if (![[self port] isEqual:[aURL port]]) return NO;
        if (![[self query] isEqual:[aURL query]]) return NO;
    }

    // for things like user/pw, fragment, etc., seems sensible to be
    // permissive about these.
    return YES;
}