Menu

Định dạng địa chỉ theo quốc gia trong biểu mẫu

Định dạng địa chỉ theo quốc gia khác nhau ở thứ tự trường, dạng mã bưu chính và những trường bắt buộc. Bài này nói cách thiết kế một mô hình trường đa quốc gia có thể kiểm thử.

Đăng ngày

  • địa chỉ
  • đa quốc gia
  • kiểm thử

Định dạng địa chỉ theo quốc gia là tập hợp những quy ước mà mỗi nước áp dụng cho việc viết địa chỉ, từ thứ tự các tầng hành chính cho tới hình dạng của mã bưu chính và những trường bắt buộc phải có. Với người xây dựng phần mềm, đây là một trong những chủ đề tốn nhiều thời gian nhất, bởi mỗi quốc gia mới được thêm vào đều mang theo một tập quy tắc riêng, và một mô hình trường được thiết kế cho một quốc gia thường không chịu được quốc gia thứ hai. Đọc hết bài này, bạn sẽ nắm được những trục khác biệt chính giữa các quốc gia, vì sao các dòng địa chỉ đánh số là một thỏa hiệp có giá, và cách thiết kế một mô hình trường vừa đủ linh hoạt cho nhiều nước vừa đủ chặt để kiểm thử tự động.

Thứ tự các trường địa chỉ khác nhau giữa các quốc gia như thế nào?

Có hai trật tự cơ bản. Trật tự từ nhỏ tới lớn bắt đầu ở đơn vị hẹp nhất là số nhà và kết thúc ở đơn vị rộng nhất là quốc gia. Trật tự từ lớn tới nhỏ đi theo hướng ngược lại, bắt đầu ở tỉnh hoặc thành phố rồi hạ dần xuống số nhà. Hoa Kỳ, Anh và phần lớn châu Âu đi theo trật tự thứ nhất. Nhật Bản, Trung Quốc và Hàn Quốc đi theo trật tự thứ hai.

Trên thực tế, hai trật tự này không đủ để mô tả hết mọi quốc gia. Thổ Nhĩ Kỳ có một trật tự trung gian, trong đó cách viết giao dịch thường ngày bắt đầu từ đơn vị nhỏ nhưng cách đọc trong biểu mẫu hành chính lại bắt đầu từ tỉnh. Mexico và một số nước Mỹ Latinh có nhiều tầng hành chính hơn hẳn, với bang, thành phố, quận và khu phố cùng xuất hiện trong một địa chỉ. Ấn Độ có hệ thống mã bưu chính gắn chặt với quận nhưng vẫn cần tên bang riêng. Bài định dạng địa chỉ quốc tế đặt những trường hợp này cạnh nhau.

Vì trật tự không đồng nhất, hãy tránh mọi thiết kế dựa vào việc tách một dòng văn bản tự do thành các tầng. Cách tách đó chỉ hoạt động cho những quốc gia có trật tự mà bạn đã lường trước, và nó thất bại im lặng với những quốc gia còn lại: dữ liệu vẫn được lưu, vẫn hiển thị, nhưng các tầng đã bị đặt sai chỗ. Nếu bạn muốn có các tầng riêng, hãy để người dùng nhập chúng vào ô riêng và để hệ thống ghép lại khi cần in.

Mã bưu chính có những dạng nào và quốc gia nào không dùng?

Mã bưu chính có bốn dạng chính. Dạng thứ nhất là thuần chữ số với độ dài khác nhau giữa các nước, phổ biến ở Hoa Kỳ, Đức, Tây Ban Nha, Thổ Nhĩ Kỳ và Việt Nam. Dạng thứ hai là chữ và số trộn lẫn, trong đó chữ cái mang thông tin về khu vực, phổ biến ở Anh, Canada và Hà Lan. Dạng thứ ba là mã có dấu gạch nối chia thành hai phần, như ở Nhật Bản và Brazil. Dạng thứ tư là trường hợp không có mã bưu chính, hoặc có nhưng không được dùng phổ biến, như ở Ireland với hệ thống mã riêng, và ở Hồng Kông cùng một số vùng lãnh thổ nhỏ.

Bốn dạng này dẫn tới bốn cách hỏng khác nhau. Nếu biểu mẫu của bạn chỉ cho phép chữ số, khách hàng ở Anh và Canada không nhập được. Nếu bạn bắt buộc phải có mã bưu chính, khách hàng ở những nơi không dùng mã sẽ không hoàn tất được biểu mẫu. Nếu bạn giới hạn độ dài năm ký tự, mã sáu ký tự bị cắt. Nếu bạn không chấp nhận dấu cách bên trong mã, rất nhiều mã hợp lệ sẽ bị từ chối chỉ vì lý do trình bày.

Với người viết kiểm thử, hãy chuẩn bị ca cho cả bốn dạng, và với mỗi dạng hãy thử cả biến thể có dấu cách lẫn không có. Bài định dạng mã bưu chính theo quốc gia tổng hợp danh sách này theo từng nước, kèm những lưu ý về cách chuẩn hóa trước khi lưu.

Những trường nào bắt buộc ở nước này nhưng không tồn tại ở nước khác?

Khác biệt về trường bắt buộc là nguồn gốc của phần lớn lỗi trong biểu mẫu đa quốc gia. Một số nước có tầng bang hoặc tỉnh như một phần bắt buộc của địa chỉ, trong khi một số nước khác không có tầng tương đương. Một số nước yêu cầu số căn hộ hoặc số tầng trong những khu vực nhất định. Một số nước dùng tên gọi khác cho cùng một khái niệm, chẳng hạn quận, huyện, xã, khu phố, và những tên gọi đó không thay thế được cho nhau.

Vấn đề trở nên khó khi một trường tồn tại trong mô hình dữ liệu nhưng không có ý nghĩa với quốc gia đã chọn. Nếu bạn để trường đó bắt buộc, người dùng phải điền một giá trị vô nghĩa để qua bước kiểm tra. Nếu bạn để trường đó tùy chọn, bạn mất dữ liệu cần cho những quốc gia thật sự dùng nó. Cách giải quyết là gắn thuộc tính bắt buộc cho từng trường theo từng quốc gia, và coi bảng thuộc tính đó là dữ liệu có thể cập nhật.

Cũng có những trường chỉ tồn tại trong một số trường hợp đặc biệt. Ví dụ, một số quốc gia có hệ thống mã địa phương riêng cho những vùng nông thôn không dùng tên đường, và địa chỉ ở đó được mô tả bằng mốc tham chiếu thay vì số nhà. Một số vùng lãnh thổ dùng chung hệ thống của nước mẹ nhưng có mã riêng. Bài các vùng lãnh thổ nhỏ và mã đặc biệt đi qua những trường hợp này để bạn biết chỗ nào cần ngoại lệ thay vì quy tắc chung.

Vì sao các dòng địa chỉ đánh số là một thỏa hiệp?

Cách làm phổ biến trong các cổng thanh toán là cho người dùng hai hoặc ba dòng địa chỉ tự do, cộng với thành phố, vùng và mã bưu chính. Sự thỏa hiệp này ra đời vì một lý do rất thực tế: nó chấp nhận được với hầu hết quốc gia, không cần biết trước cấu trúc của từng nước, và nó khớp với định dạng mà nhiều hệ thống vận chuyển và thanh toán yêu cầu.

Cái giá của thỏa hiệp này là bạn mất cấu trúc. Khi mọi thứ được nhồi vào dòng địa chỉ một và dòng địa chỉ hai, bạn không thể sắp xếp theo quận, không thể lọc theo khu vực, không thể phát hiện sự lệch giữa vùng và mã bưu chính, và không thể đối chiếu từng tầng với danh mục hành chính. Bạn cũng không thể hiển thị lại địa chỉ theo đúng thứ tự của quốc gia gốc, vì trật tự đã bị hòa vào một khối văn bản.

Một cái giá thứ hai ít được chú ý hơn là khó gỡ lỗi. Khi người dùng báo rằng địa chỉ của họ bị hệ thống hiểu sai, bạn không có cách nào xác định tầng nào bị đặt nhầm chỗ, vì mọi tầng nằm chung trong một chuỗi. Hệ quả là những lỗi dữ liệu địa chỉ trở nên tốn kém hơn nhiều so với việc thiết kế đúng ngay từ đầu.

Cách cân bằng thường được chọn là dùng mô hình tầng cho những quốc gia bạn phục vụ nhiều nhất, và dùng dòng tự do cho những quốc gia còn lại. Điều cần chú ý là hai chế độ này phải cùng chảy về một mô hình lưu trữ thống nhất, nếu không bạn sẽ có hai loại dữ liệu không thể so sánh được với nhau ở tầng báo cáo.

Làm sao thiết kế một mô hình trường địa chỉ đa quốc gia có thể kiểm thử?

Nguyên tắc đầu tiên là tách phần mô tả khỏi phần lưu trữ. Bảng mô tả nói rằng quốc gia nào có tầng nào, tầng nào bắt buộc, tầng nào có nhãn gì, và mã bưu chính có dạng nào. Phần lưu trữ chỉ cần một tập trường chung cộng với một trường chỉ ra quốc gia. Khi tách như vậy, bạn có thể thêm một quốc gia mới bằng cách cập nhật dữ liệu mô tả mà không phải sửa mã nguồn.

Nguyên tắc thứ hai là mọi phép kiểm tra phải đọc từ cùng bảng mô tả đó. Nếu giao diện kiểm tra theo một cách còn máy chủ kiểm tra theo cách khác, bạn sẽ có những trường hợp dữ liệu qua được giao diện nhưng bị máy chủ từ chối, và ngược lại. Đây là loại lỗi tốn nhiều thời gian nhất khi truy nguyên, vì nó chỉ xuất hiện ở một số tổ hợp quốc gia và trường nhất định.

Nguyên tắc thứ ba là chuẩn hóa ở một chỗ duy nhất. Dấu cách trong mã bưu chính, dấu chấm trong tên đường, chữ hoa chữ thường trong mã vùng, và các ký tự có dấu đều cần một quy tắc chuẩn hóa chung được áp dụng trước khi so khớp. Hãy kiểm thử quy tắc đó riêng, tách khỏi việc kiểm thử biểu mẫu, vì đó là hai vấn đề khác nhau. Bài chuẩn hóa và xác thực địa chỉ phân biệt rõ hai khái niệm này.

Nguyên tắc thứ tư là chuẩn bị dữ liệu kiểm thử theo từng quốc gia, không chỉ theo từng trường hợp. Bạn có thể dùng trình tạo địa chỉ Hoa Kỳ và trình tạo địa chỉ Thổ Nhĩ Kỳ như hai đầu đối lập về số tầng và trật tự viết, rồi mở rộng dần. Với mỗi quốc gia, hãy có ít nhất một bản ghi đầy đủ, một bản ghi thiếu tầng tùy chọn, và một bản ghi có tầng ở dạng viết tắt. Bài các tình huống địa chỉ xuyên biên giới mở rộng danh sách này cho những trường hợp đặc biệt.

Cuối cùng, hãy kiểm thử cả những quốc gia mà bạn chưa hỗ trợ. Nếu biểu mẫu của bạn gặp một quốc gia chưa có trong bảng mô tả, nó nên thất bại một cách rõ ràng thay vì rơi vào một chế độ mặc định âm thầm. Chế độ mặc định âm thầm là cách phổ biến nhất để một lỗi dữ liệu đi vào hệ thống mà không ai phát hiện.

Dữ liệu quốc gia cần được bảo trì từ những nguồn nào?

Dữ liệu quốc gia gồm mã quốc gia, mã đơn vị hành chính, danh mục thành phố, dạng mã bưu chính và quy tắc bắt buộc của từng trường. Những dữ liệu này thay đổi theo thời gian: các đơn vị hành chính được sáp nhập hoặc tách ra, mã bưu chính được điều chỉnh, và quy tắc của một số quốc gia được cập nhật. Một bộ dữ liệu quốc gia không được bảo trì sẽ lão hóa âm thầm.

Về nguồn, có ba nhóm đáng tin cậy. Nhóm thứ nhất là các cơ quan bưu chính quốc gia, nơi công bố định dạng mã bưu chính và đôi khi cả danh mục địa chỉ. Nhóm thứ hai là các tổ chức tiêu chuẩn quốc tế, nơi công bố mã quốc gia và mã đơn vị hành chính. Nhóm thứ ba là cơ quan thuế và cơ quan đăng ký doanh nghiệp của từng nước, nơi công bố quy tắc về mã số và tên gọi trong hóa đơn.

Điều quan trọng không nằm ở việc có nguồn mà ở việc có quy trình. Hãy ghi lại ngày bạn cập nhật từng phần của bộ dữ liệu, ghi lại nguồn, và có một phép kiểm tra tự động báo động khi một quốc gia không được cập nhật trong một khoảng thời gian dài. Bài độ mới và nguồn của dữ liệu quốc gia trình bày cách làm này.

Một điểm nữa là đừng trộn dữ liệu mô tả với dữ liệu kiểm thử. Bảng mô tả quốc gia là kiến thức về thế giới thật và cần đúng; dữ liệu địa chỉ dùng cho kiểm thử là dữ liệu tổng hợp và cần nhất quán. Giữ hai loại này tách biệt giúp bạn cập nhật cái này mà không làm hỏng cái kia.

Bước tiếp theo

Hãy mở danh mục quốc gia, chọn hai quốc gia có trật tự viết địa chỉ trái ngược nhau, rồi lần lượt thiết kế mô hình trường cho từng nước và kiểm tra xem mô hình của bạn có chịu được cả hai hay không. Sau đó thử thêm một quốc gia có dạng mã bưu chính khác hẳn, và ghi lại những chỗ mô hình của bạn phải sửa.

Toàn bộ dữ liệu do trang này sinh ra là dữ liệu kiểm thử tổng hợp: các trường mang đúng hình dạng và đúng quan hệ theo quy ước của từng quốc gia, nhưng không ứng với người nào, nhà nào hay doanh nghiệp nào có thật, và chỉ nên dùng cho việc thử phần mềm, thử biểu mẫu và trình diễn giao diện.

Đọc tiếp

Công cụ phổ biến và bài hướng dẫn sử dụng