Les pièges du fichier ken_all.csv de la poste japonaise et la solution posuto
Le fichier CSV officiel des codes postaux japonais est célèbre pour ses anomalies de formatage et ses règles de découpage archaïques. Le projet open source posuto propose un travail de nettoyage minutieux pour transformer cette source de données complexe en un fichier JSON exploitable.
Fil « Analyse des contraintes de parsing du fichier CSV de la poste japonaise »
Un format CSV truffé de règles archaïques
Le fichier officiel ken_all.csv, publié par Japan Post pour répertorier les codes postaux du Japon, est tristement célèbre dans la communauté technique pour ses choix de conception complexes. Au lieu de s'en tenir aux spécifications standards du format CSV (Comma-Separated Values, un format de fichier texte délimité par des virgules), la poste japonaise y intègre des commentaires textuels entre parenthèses et des références directes à l'ordre des lignes dans le fichier.
L'une des particularités les plus déroutantes réside dans la gestion des champs trop longs. Si le nom d'un quartier dépasse 38 caractères ou si sa transcription en katakana semi-largeur (katakana, syllabaire japonais servant aux représentations phonétiques) excède 76 caractères, la ligne est arbitrairement coupée en plusieurs enregistrements. Le champ trop long est poursuivi sur la ligne suivante, tandis que toutes les autres colonnes sont dupliquées.
12345,Tokyo,Minato,This place name is really
12345,Tokyo,Minato,very long it didn't fit in
12345,Tokyo,Minato,a single line so we had to
12345,Tokyo,Minato,split it
Des anomalies structurelles et sémantiques
Ce découpage ne suit ni les limites précises de caractères ni les frontières naturelles des mots. Les cas extrêmes illustrent bien la complexité du traitement de ce fichier :
- Le code postal 〒452-0961 (région de Haruhi) génère à lui seul 66 lignes distinctes dans le fichier CSV, chaque quartier occupant une ligne séparée.
- Les codes postaux 〒602-8368 et 〒602-8374 à Kyoto détiennent le record de longueur avec une entrée découpée sur 8 lignes consécutives.
- Le fichier n'utilise pas de guillemets standards pour protéger les virgules mais recourt à une variante de virgule spécifique.
À cela s'ajoutent des pièges linguistiques et sémantiques. Le terme « 一円 », qui signifie habituellement « un yen » mais désigne aussi « la zone environnante » dans ce contexte, doit être nettoyé des noms de quartier, à l'exception d'un unique quartier de la préfecture de Shiga (code 〒522-0317) où il s'agit du véritable nom officiel. De même, les fichiers alternatifs en romaji (romaji, la transcription du japonais en alphabet latin) fournis par la poste souffrent de décalages de mise à jour et de conversions automatiques erronées.
La réponse avec le projet posuto
Pour éviter à chaque développeur de réinventer un algorithme de traitement dédié, le paquet Python posuto a été développé pour automatiser le nettoyage et l'assemblage de ces données. Le projet prend en charge l'ensemble des règles particulières, la concaténation des lignes scindées et la suppression des notes informatives inutiles.
Pour les applications n'utilisant pas Python (comme des services en Node.js ou Java), posuto met également à disposition un fichier JSON (JavaScript Object Notation, format d'échange de données structurées) pré-traité et prêt à être consommé directement.