Rozwiązanie problemu z str_getcsv

Ostatnio musiałem zrobić coś w języku pecha (jak go nazywa Grxmrx - pozdrawiam). Wszystko byłoby dobrze, gdyby nie jeden mały problem. Miałem do przerobienia pewien tekst zapisany w tabeli w formacie csv.
W PHP jest do tego dedykowana metoda: str_getcsv, więc skorzystałem z niej. Wszystko było pięknie, do momentu, gdy pojawiły się znaczki zakodowane w utf-8. No cóż, "wujek google twoim przyjacielem", więc szybko znalazłem jakieś rozwiązanie. Niestety nie było zbyt pomocne. Główne rady jakie znajdowałem, to albo napisanie własnej procedury, albo zabawy z lokalami. No niestety lokale za bardzo nie rozwiązują problemu, bo w rekordach znajdowały się znaczki nie tylko z polskimi ogonkami. Już chciałem zacząć pisać własną procedurę, ale tak pokombinowałem i wyszło, że jeśli nie zależy nam tak bardzo na optymalizacji pod względem czasu wykonywania, to można zrobić to prościej:

$s = str_replace(urlencode(','), ',', urlencode($astr));
$ltab = str_getcsv($s, ',');
foreach ($ltab as &$lval)
{
	$lval = trim(urldecode($lval));
}

• W pierwszej linii kodu zamieniamy tekst za pomocą urlencode na strawny dla funkcji str_getcsv.
• Przywracamy jednocześnie znaki przecinka za pomocą funkcji str_replace.
• W drugiej linii tak zakodowane dane podajemy do obróbki funkcji str_getcsv.
• Wynik jednak musimy podać rozkodowaniu (ostatnie linie). Pomocna będzie funkcja urldecode.

Może to troszkę naokoło, ale dla pierdoły, która nie jest czasowo istotna (operacje te wykonuję rzadko na "zapleczu" strony), szkoda było mi czasu na pisanie własnej funkcji wykonującej tak podstawowe operacje poprawnie.

Acha - może też jest jakieś prostsze rozwiązanie, niestety dość głęboko zakopane w wynikach googla.

Uzupełnienie

Po namowach Szczepana (hi Hrw) sprawdziłem też opcję z ustawieniem lokali. Choć to mało logiczne, ale zadziałało... Tak więc po użyciu funkcji setlocale działa bez opisanego przeze mnie wcześniej kombinowania. Tak więc do kodu wstawiamy:

setlocale(LC_ALL, "pl_PL");
$ltab = str_getcsv($astr, ',');

Niby rozwiązuje to problem, ale jednocześnie wskazuje, że implementacja jest zrobiona "na około", skoro zamiast wykrywać w odpowiedniej sekwencji 3 znaki i odpowiednio reagować, ma problemy ze znakami zapisanymi w standardzie utf-8.

pozdrawiam Kaczuś

2014-03-28 20:19:05