這里有一個直觀的描述來解釋什么是“一維數據類型”：number或string被格式化為多種多樣的值，可以通過數學運算或某種轉換方法可以算出它們的值。比如：十六進制的顏色值 <tt style="box-sizing: border-box; color: rgb(238, 130, 98);">#EE8262</tt> 的紅綠藍三原色的值通過掩碼或移位運算得出；正則表達式可以通過少量字符中復雜的樣本中進行匹配。
在所有的一維數據類型中，URI 有著至高地位。單獨就人類可閱讀的字符串這一點來說，它存在并將永遠存在于計算機中任何你能夠想象到的對位置信息進行編碼的數據中。
它最基礎的表示法中，URI 由一個 scheme 和一個 hierarchical part 組成，帶有 query 和 fragment（后兩者非必需）：
<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
很多像HTTP的協議中會定義有一定的規范結構，例如：username、password、port, 以及hierarchical part 中的 path：
對網絡編程的扎實理解植根于對于 URL 各個部分的完全的熟悉。作為軟件開發工程師，這意味著在你的編程語言標準庫中存在著對URI進行指揮功能的命令。
如果某門語言在標準庫中沒有 URL 模塊，你要跑著離開這門語言（不能用走的！>一定要跑?。?，這不是一門真正的編程語言。
在 Foundation 庫中，NSURL用來代表 URL。
NSURL 可以通過 URLWithString: 類方法實例化。
NSURL *url = [NSURL URLWithString:@"http://example.com"];
如果傳入值不是合法URL，這個方法會返回一個 nil 值。
我們幾周前提到過 NSString 也有一些關于path處理的殘留功能，但這些功能對于處理 NSURL 實在是太麻煩了。把 NSString 轉化為 NSURL 帶來的額外轉化成本讓這件事并不那么方便，你總是要花時間在這個上面。如果一個值就是一個URL，那么它就應該被保存為 NSURL，把這兩種類型搞混是懶惰而魯莽的API設計。
附加提示：@@ 是創建 NSURL 的字面量的絕佳方法（例如：@@"http://example.com"），怎么樣，很方便吧？
NSURL 也有一個類方法 +URLWithString:relativeToURL: 可以根據一個 base URL 地址和關聯字符串來構造 URL。這個方法的行為由于其對子目錄的/符號的處理而變得非?；靵y無序。
這里有一些這個方法用法的典型參考：
NSURL *baseURL = [NSURL URLWithString:@"http://example.com/v1/"];
[NSURL URLWithString:@"foo" relativeToURL:baseURL];
// http://example.com/v1/foo
[NSURL URLWithString:@"foo?bar=baz" relativeToURL:baseURL];
// http://example.com/v1/foo?bar=baz
[NSURL URLWithString:@"/foo" relativeToURL:baseURL];
// http://example.com/foo
[NSURL URLWithString:@"foo/" relativeToURL:baseURL];
// http://example.com/v1/foo
[NSURL URLWithString:@"/foo/" relativeToURL:baseURL];
// http://example.com/foo/
[NSURL URLWithString:@"http://example2.com/" relativeToURL:baseURL];
// http://example2.com/
