Il y a quelque temps, j’ai lancé posuto, un package qui présente les données postales japonaises dans un format facile à utiliser. Il est basé sur les données publiées par Japan Post, qui est célèbre pour être largement utilisée mais difficile à analyser. J’ai d’abord pris connaissance des données postales lorsque j’ai saisi mon code postal dans un formulaire en ligne et qu’il s’est automatiquement complété avec l’adresse "XXX-borough (except the following buildings)".

Je n’avais aucune idée de ce à quoi se référait cette partie entre parenthèses, alors j’ai cherché une source commune des données postales, j’ai trouvé le fichier CSV et j’ai découvert le problème. Il s’avère que le fichier CSV contient des notes entre parenthèses destinées à toute personne lisant le fichier CSV et fait référence à l’ordre des lignes. Cela pose problème.

Les données sont principalement utiles ligne par ligne, où les parenthèses sont sans sens. Puisque CSV est un format délimité par champs, il n’y a pas besoin de parenthèses - vous pourriez simplement ajouter un champ de notes. Ce n’est qu’un exemple parmi nombreux problèmes avec ken_all.csv.

Vous pouvez régulièrement trouver des gens se plaindre de cela sur Twitter, et il y a même eu un moment où un blog collectait simplement les publications de tout le web à propos de ce sujet. Un tweet particulièrement amusant décrit les personnes qui s’attendent à ce que les ordinateurs s’inclinent à la volonté humaine étant punies dans l’Enfer de devoir analyser ken_all.csv pour toujours. La README du fichier explique que les lignes avec des champs trop longs seront divisées en plusieurs lignes.

Plus précisément, si le nom du quartier dépasse 38 caractères, ou si le champ de prononciation en katakana pleine largeur dépasse 76 caractères, la ligne sera divisée en deux lignes. Le champ de quartier trop long continuera et tous les autres champs seront dupliqués. Il convient également de noter que bien que les limites de longueur soient comme indiqué, l’endroit où les ruptures de ligne sont insérées dans les lignes longues semble aléatoire, n’intervenant ni à la limite de caractères ni aux limites de mots normales.

Il convient de noter que tous les problèmes du CSV ne sont pas inhérentslement techniques ; les codes postaux sont toujours complexes. Le code postal avec le plus de lignes dans le CSV - un étonnant 66 - est 〒452-0961, qui se réfère à la région Haruhi de la ville de Kiyosu dans le préfecture d’Aichi. Cela a ce nombre de lignes parce que chaque quartier obtient une ligne séparée. À l’inverse, la ligne continue la plus longue, en utilisant les règles de division de ligne ci-dessus, est l’entrée pour 〒602-8368 ou 〒602-8374, toutes deux avec huit lignes.

Ces deux entrées se trouvent dans l’une des rares zones de Kyoto qui utilisent un système unique, bizarre et basé sur les intersections. Il existe des codes postaux « tout compris » pour de nombreuses zones, où le quartier est donné comme "except the following", et la seule chose à faire est de chercher cette chaîne exacte et de l’exclure. Il existe une variété de chaînes similaires, et il est difficile de savoir si j’ai bien capturé toutes.

Un exemple d’un autre commentaire est 一円. Normalement, cela signifie "un yen", mais cela signifie aussi "la zone environnante", et s’agit d’une note dans le CSV qui doit être supprimée des noms de quartier, sauf...