Muszę pobrać dane z zewnętrznego pliku CSV.
Wszystko cacy, ale całość rozbija się o kodowanie znaków. Ten kto stworzył tego CSV zakodował tak znaki, że nie mogę dojść do ładu i składu, więc może ktoś z forum ma większe doświadczenie w tym hardkorze.
W sumie muszę zawartość zakodować do iso-8859-2 i nakarmić tym bazę MySQL. Sądząc po długości stringa, kodowanie jest dwubajtowe na znak, czyli np. "tekst" wg strlen zajmuje 11.
Więc po kolei:

1. Gdy CSV testowo importuję do Openoffice Calc, to prawidłowe polskie znaki są, gdy wybiorę "Unicode", gdy wybiorę "Unicode (UTF-7)" lub "Unicode (UTF-8)" to mam krzaki.

2. Grzegżółka twierdzi że kodowanie to "Kodowanie: Unicode UCS2 LE (Intel)", ale mb_convert_encoding($tekst,"ISO-8859-2","ucs-2le") daje w wyniku krzaczki (inne wariancje ucs też)

3. Z poziomu php funkcja mb_detect_encoding twierdzi że kodowanie to UTF-8 (lub ASCII gdy nie ma w polu polskich znaczków), ale mb_convert_encoding($tekst,"ISO-8859-2","UTF-8") daje w wyniku krzaczki (przeglądarka jest ustawiona na iso-8859-2).

4. rozzłoszczony zużytym na poszukiwania czasem zrobiłem pętęlkę:

[PHP] pobierz, plaintext 
foreach (mb_list_encodings()  as $value) {
echo '<br>'. mb_convert_encoding($tekst,"ISO-8859-2",$value);
}
[PHP] pobierz, plaintext 

i żaden wynik w przeglądarce nie wygląda prawidłowo.

Tak więc chwilowo nie mam pomysłu i jestem otwarty na propozycje jak mogę jeszcze ten temat ugryźć....

Weź sobie całe źródło zrzuć do heksadecymalnej formy zapisu bajtów, a następnie w jakimś edytorze HEX (Notepad++ ma plugin, PSPad ma wbudowany) zobacz jakie bajty odpowiadają charakterystycznym znaczkom (np. "a", "ś", "<"). Wiedząc już jakie bajty reprezentują dany znak łatwo będzie znaleźć jakie jest to kodowanie.

Zdanie: Poznań

W hexie jest: 5000 6F00 7A00 6E00 6100 4401

Łódź = 4101 F300 6400 7A01

ę = 1901

ł = 4201

czyli na pierwszy rzut oka jest to jakiś unicode

Wygląda to na UTF-16LE.

Myślałem podobnie, ale

[PHP] pobierz, plaintext 
$tekst2 = mb_convert_encoding($tekst,"iso-8859-2","UTF-16LE");
echo tekst2 ;
[PHP] pobierz, plaintext 

w przeglądarce ustawionej na iso-8859-2 wyświetla się: ?

Kawałek pliku CSv wrzuciłem pod adresem:
http://chomikuj.pl/iksow/Dokumenty/plikcsv,1241323892.csv

W pliku mamy BOM (0xFF 0xFE), nazwy miast oddzielone średnikiem oraz znak nowej linii (CRLF) - wszystko wskazuje na to, że jest to UTF-16LE.
Sprawdź czy mb_convert_encoding / iconv poprawnie konwertuje tekst na ISO-8859-2 - ta sama metoda, podejrzyj wygenerowane bajty.

Na razie dostałem odpowiedź "na około" że jest to zapisany wynik zapytania z bazy.

[PHP] pobierz, plaintext 
$tekst2 = mb_convert_encoding($tekst,"iso-8859-2","UTF-16LE");
$fp = fopen('plikwynikowy', 'w');
fwrite($fp, $tekst2);
fclose($fp);
[PHP] pobierz, plaintext 

W pliku wynikowym dostaję 3F3F3F3F3F3F3F3F

Jeśli zas zrobię mb_convert_encoding($tekst,"iso-8859-2","UCS-2");

to w pliku Łódź = 41 3F 64 7A


Powoll zaczynam dojrzewać do myśli, że napiszę własną funkcję konwertującą, na chama wypisze sobie wszystkie literki i interesujące mnie znaczki...

[PHP] pobierz, plaintext 
$tekst2 = mb_convert_encoding($tekst,"iso-8859-2","UTF-16LE");
[PHP] pobierz, plaintext 

Sprawdziłem na swoim serwerze i działa to niemal bez problemów - nie radzi sobie jedynie z BOM-em, ale tego można od biedy przyciąć:

[PHP] pobierz, plaintext 
$fileContents = substr($fileContents, 2);
[PHP] pobierz, plaintext 

Można też pominąć informację o kolejności bajtów (podając samo UTF-16), wtedy też odczyta to sobie na podstawie BOM-u i poprawnie go odczyta.

W takim przypadku radziłbym upewnić się czy aby na pewno problemem nie jest samo wyświetlanie tekstu w przeglądarce oraz czy aby na pewno PHP w Twoim przypadku wspiera UTF-16/UTF-16LE.

Odpada, wtedy w wygenerowanym pliku byłoby dobrze, ale źle się wyświetlało.



To może być prędzej - jak to można sprawdzić?
Serwer to vps na debianie, być może faktycznie czegoś mu brakować, bo instalacja w miarę standardowa.

http://www.php.net/manual/en/function.mb-list-encodings.php

no nie, to to od razu sprawdziałem wcześniej

[PHP] pobierz, plaintext 
foreach (mb_list_encodings() as $value) {
   echo '<br>'. $value;
}
[PHP] pobierz, plaintext 

i wynik:

[PHP] pobierz, plaintext 
pass
auto
wchar
byte2be
byte2le
byte4be
byte4le
BASE64
UUENCODE
HTML-ENTITIES
Quoted-Printable
7bit
8bit
UCS-4
UCS-4BE
UCS-4LE
UCS-2
UCS-2BE
UCS-2LE
UTF-32
UTF-32BE
UTF-32LE
UTF-16
UTF-16BE
UTF-16LE
UTF-8
UTF-7
UTF7-IMAP
ASCII
EUC-JP
SJIS
eucJP-win
SJIS-win
CP51932
JIS
ISO-2022-JP
ISO-2022-JP-MS
Windows-1252
ISO-8859-1
ISO-8859-2
ISO-8859-3
ISO-8859-4
ISO-8859-5
ISO-8859-6
ISO-8859-7
ISO-8859-8
ISO-8859-9
ISO-8859-10
ISO-8859-13
ISO-8859-14
ISO-8859-15
ISO-8859-16
EUC-CN
CP936
HZ
EUC-TW
BIG-5
EUC-KR
UHC
ISO-2022-KR
Windows-1251
CP866
KOI8-R
ArmSCII-8
[PHP] pobierz, plaintext 

Bardziej myślałem że to może jakiś błąd pliku, błąd generowania pliku lub błąd w obsłudze kodowania mimo tego, że na liście jest.

Zrobiłem kilka testów i równierz mam krzaczki na iso, tak więc ustawienia przeglądarki odpadają i ustawienia serwera także...
Gdy konwertowałem na utf8 to bodajże 3 były OK ale przy kodowaniu utf8..

No i chyba wiem, czemu Crozin ma dobrze a ja i ew. inni źle. Natrknąłem się w sieci na informację:

"Nie da się odczytać pliku, zawierającego polskie ogonki, zakodowanego w UTF-16LE (standard Windowsa, pliki wypluwane np. przez PowerShella) przy użyciu funkcji php file(). Tzn. można ale przy konwersji iconv() dostajemy i tak chińskie krzaki. Plik trzeba odczytać przy pomocy file_get_contents() i wtedy już ładnie konwertuje. Dopiero potem można bawić się w cięcie stringa w tablicę."

Sprawdzę to i ew. zamkniemy temat...




EDIT:
Sprawdziłem, faktycznie jest jakiś bug w php i podsumowanie:

Jeśli zaczytujemy plik tekstowy / csv z pliku zakodowanego "UTF-16LE" to należy plik wczytać funkcją file_get_contents() !