土耳其地址產生器面對的是一個層級特別多的地址體系：省、區、街區、街道、門牌與門牌內號一層扣一層，再加上五位郵遞區號與土耳其語特有的字母。這些層級的書寫順序和外國系統習慣的「街道、城市、郵遞區號」不一樣，郵遞區號也必須和區與省對得上，否則整筆資料就是矛盾的。以下說明這些層級怎麼排、郵遞區號與省怎麼對應、土耳其語字母會造成哪些誤判，以及做表單測試時該準備什麼樣的樣本。
土耳其地址的層級由大到小怎麼排
土耳其的行政層級由大到小是 il（省）、ilçe（區）、mahalle（街區），再往下才是 sokak 或 cadde（街道）、bina no（門牌號）與 daire（門牌內號）。全國共有八十一個省，省以下是為數眾多的區，區以下再切成街區。這種四層以上的結構，比多數英語系國家只到「城市」一層要深得多。
在資料庫裡，這幾層通常應該分開存放。把 mahalle 與街道併成一欄，看起來省事，但一旦要做地區統計、路線規劃或配送範圍比對，就必須重新把字串拆開，而拆分規則永遠比儲存規則更難維護。
mahalle 是最常被外國系統忽略的一層。許多表單只提供街道與城市兩欄，於是使用者把街區名稱塞進街道行，格式就再也回不去了。這種資料在土耳其本地看起來勉強可用，跨系統交換時卻無法解析。
daire 則是另一個極端。它是同一門牌內部的單位編號，公寓、辦公室與住家都可能用到。它通常不是必填，但只要出現，就代表這筆地址指向的是建築內的一個單位，而不是整棟建築。
還有一點常被忽略，就是門牌號本身可能不是純數字。部分地區的門牌會帶字母後綴，或在同一門牌下細分成不同編號，若把門牌欄位限定成整數型別，遇到這類輸入就會直接失敗。
鄉村地區的寫法又是另一種情況。在村落一帶，地址常以村名為主體，街道名稱可能不存在或不被使用，於是原本的層級會少掉一兩層。若你的欄位模型假設每一筆地址都必須有街道，這些樣本就會被誤判為無效，而它們在當地其實完全正常。
書寫順序和歐洲習慣相反嗎?
儲存時由大到小，書寫時卻常常反過來。土耳其的地址在紙上與包裹上通常從最小的 mahalle 開始寫，接著是街道、門牌與門牌內號，最後才接郵遞區號、區與省。這個「儲存順序與顯示順序相反」的落差，是多國表單最常見的錯誤來源。
和日本相比，兩者的差異更明顯。日本的地址是由大到小書寫，先寫都道府縣再往下縮；土耳其則是把街區與街道放在最前面，省放在最後。同一個介面若假設「所有亞洲國家都由大到小」，就會在土耳其資料上出錯。
郵遞區號的位置也值得一提。土耳其習慣把五位郵遞區號放在區與省之前，而不是像美國那樣放在最後。這個位置差異對人工閱讀影響不大，對自動解析卻很關鍵，因為解析器往往靠「最後一段是郵遞區號」這種假設來切分。
實務上，各家機構的欄位順序並不完全一致，郵政與貨運業者的寫法也有出入。做測試時不需要強求單一正解，而是要確認你的系統在遇到兩種順序時都能給出合理的處理，而不是靜默地存下一筆錯位資料。
五位郵遞區號與八十一省的對應
土耳其的 posta kodu 是五位數字，前兩位通常與該省的代碼相對應，後三位則指向省內的投遞區域。這代表郵遞區號與省之間存在可檢查的關係，而不是兩欄互不相干的自由文字。
既然是可檢查的關係，測試資料就必須讓兩者同時成立。手動拼湊時最常見的錯誤，就是從一個省抄郵遞區號、從另一個省抄省名，單看兩欄都合法，合起來卻不存在。這種組合在畫面上沒有任何異狀，只有在做交叉比對時才會露出來。
郵遞區號也不能單獨拿來判斷區。同一個郵遞區號可能涵蓋多個街區，甚至跨區邊界，所以比對時應該以「郵遞區號加區」為單位，而不是只看其中一個。這一點和美國以投遞區域為單位的邏輯類似，但土耳其多了一層區與街區。
本站的土耳其資料會讓省、區、郵遞區號與電話區號取自同一筆記錄，產生的組合先天自洽。想確認這個國家頁面上有哪些欄位，可以開土耳其國家頁對照，官方郵政資訊則以土耳其郵政總局公布為準。
土耳其語的大小寫為什麼會出錯?
土耳其語有兩組字母配對是其他語言沒有的：帶點的大寫 İ 對應小寫 i，不帶點的大寫 I 對應小寫 ı。這個規則看起來只是細節，卻會讓沿用英文規則的大小寫轉換函式產生完全錯誤的結果。
最典型的問題是把 I 轉成小寫時得到 i，但土耳其語正解是 ı。反過來把 İ 轉小寫時，某些實作會產生 i 加上一個組合用的點字元，形成兩個字元的序列。這種字串在肉眼上和一般的 i 幾乎一樣，比對時卻永遠不相等。
這個問題在地址資料上的後果很實際：同一個省名或街區名在不同筆資料裡寫法不一，去重時被當成兩個不同的地方；排序時位置錯亂；搜尋時打對了字卻找不到。若系統還會做地區統計，這些重複項會讓報表出現憑空多出來的地區。
比較穩妥的做法，是在儲存前明確定義一套正規化規則，並在比對時使用語言感知的轉換，而不是預設英文規則。同時把「İstanbul」「ISTANBUL」「Istanbul」這類變體放進測試樣本，確認系統的反應是一致的，而不是時好時壞。
資料庫層的設定也會參與這個問題。若欄位使用不分大小寫的排序規則，而該規則又不是土耳其語專用版本，兩個不同的字母可能被視為相同，正確的拼寫反而被當成重複值。測試時值得刻意放入只差一個字母的兩筆資料，看看系統是否真的能分開它們。
電話區號和城市要怎麼搭配?
土耳其的國際冠碼是 90，國內市內電話則是以零開頭的三碼區號，例如伊斯坦堡同時使用兩組區號，安卡拉與伊茲密爾各有自己的區號。行動電話號碼不使用地區區號，因此不能拿來推斷城市。
這代表電話與城市之間只能做部分檢查：市內電話的區號必須與城市相符，行動電話則沒有這種對應關係。若驗證規則一律要求區號與城市匹配，就會把行動電話號碼全部擋掉，反而製造出大量假錯誤。
反過來，如果完全不檢查，就會出現市內電話區號與城市明顯不符的資料，而這種矛盾在真實的客服與配送流程裡是會造成困擾的。測試時應該同時準備「區號相符」與「區號不符」兩種樣本，觀察系統是擋下、警告，還是照單全收。
跨國表單還有一層問題：使用者可能以國際格式輸入手機號碼，開頭是加號與國碼，而不是國內格式。若系統同時接受兩種寫法，就必須在儲存前統一，否則同一個號碼會以不同形式重複存在。延伸的判斷方式整理在電話區號與地區匹配。
地址表單還要注意哪些字符問題?
土耳其語使用 ç、ğ、ı、ö、ş、ü 等字母，街道名與街區名裡出現的頻率相當高。若資料庫的編碼設定不當，或前端在送出前做了錯誤的轉換，這些字母就會變成問號或亂碼，而錯誤往往要等到使用者回報才會被發現。
長度限制也是常見的坑。有些系統以位元組計算欄位長度，土耳其語字母在多數編碼下佔用的位元組比英文字母多，於是畫面上看起來還很短的街道名，實際上已經超過限制。以字元數為單位檢查，或把上限放寬一些，都能避免這類失敗。
搜尋與排序同樣受影響。土耳其語有兩個不同的 i 字母，字典序也不同，若直接沿用英文字母的排序規則，使用者會覺得清單的順序毫無道理。這在國別或城市下拉選單上特別明顯。
還有一類問題來自輸入法。使用者可能貼上從其他系統複製的字串，夾帶多餘空白、全形字元或不可見的控制字元。這些輸入本身不算錯誤，但比對前必須清理，否則同一條地址會被判斷成兩條不同的記錄。跨國的寫法差異可以延伸閱讀國際地址格式。
電話號碼的前導零同樣是常見的受害者。國內格式以零開頭，一旦存成數字型別，那個零就會消失，之後再要轉成國際格式就補不回來。把電話欄位當成文字處理，並在顯示時才依情境加上冠碼，是比較不會出錯的順序。
要測哪些輸入才算測到土耳其情境
一組實用的樣本應該包含完整填寫的地址、缺少 mahalle 的地址、郵遞區號與省不符的地址，以及把街區名稱塞進街道行的地址。這四種分別對應正常路徑、必填欄位、交叉檢查與解析規則，能覆蓋大部分邏輯分支。
再往下可以加入帶有土耳其語特殊字母的街道名、門牌號帶字母後綴、地址行超出長度上限，以及以國際格式填寫的手機號碼。這些樣本測的是編碼、型別、長度與格式轉換，通常是上線後才出問題的地方。
還有一類樣本經常被忘記，就是外國使用者填寫土耳其地址。他們可能不知道 mahalle 是什麼，也可能把省名寫成英文拼法。系統在這種情況下應該給出可理解的提示，而不是只丟出一句格式錯誤。
把這些樣本固定下來，每次調整驗證規則就重跑一輪，才能分辨某次失敗是新規則造成的，還是樣本本身就已經過時。各國地址格式對照把土耳其與其他國家的差異並排整理，適合拿來檢查你的欄位模型是否撐得住這些差異。
產生的土耳其地址能不能當真
不能。這些是合成的測試資料，格式、層級與校驗關係符合土耳其的實際規則，卻不對應任何真實住戶，也沒有任何人在這個地址上收信。把它填進要寄出的包裹，結果只會是投遞失敗。
它也不該被當成居住證明、帳單地址或身分佐證，更不能拿去冒充他人或申請真實服務。這些樣本的用途，是讓你的表單、解析器與校驗邏輯在受控環境裡被測到，包含測試環境的資料填充與自動化流程的固定輸入。
判斷方式很簡單：如果這筆資料被送去寄信、驗證或申請，會有真實的人受到影響嗎。答案是會，就不該使用。